Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Redes de Windows
Descripción general de las redes de contenedores de Windows
Los contenedores de Windows son fundamentalmente diferentes a los contenedores de Linux. Los contenedores de Linux utilizan construcciones de Linux como los espacios de nombres, el sistema de archivos de unión y los cgroups. En Windows, esas construcciones se abstraen de las que contiene el Host Compute Service
Desde la perspectiva de las redes, HCS y HNS hacen que los contenedores de Windows funcionen como máquinas virtuales. Por ejemplo, cada contenedor tiene un adaptador de red virtual (vNIC) que está conectado a un conmutador virtual de Hyper-V (vSwitch), como se muestra en el diagrama anterior.
Administración de direcciones IP
Un nodo de Amazon EKS utiliza su interfaz de red elástica (ENI) para conectarse a una red de VPC de AWS. En la actualidad, solo se admite un ENI por nodo de trabajo de Windows. La administración de direcciones IP para los nodos de Windows la realiza el controlador de recursos de VPC
El número de pods que puede admitir un nodo de trabajo de Windows depende del tamaño del nodo y del número de IPv4 direcciones disponibles. Puede calcular la IPv4 dirección disponible en el nodo de la siguiente manera:
-
De forma predeterminada, solo se asignan IPv4 direcciones secundarias al ENI. En tal caso:
Total IPv4 addresses available for Pods = Number of supported IPv4 addresses in the primary interface - 1
Reducimos una del recuento total, ya que una IPv4 dirección se utilizará como dirección principal del ENI y, por lo tanto, no se podrá asignar a los Pods.
-
Si el clúster se ha configurado para una alta densidad de pods habilitando la función de delegación de prefijos, entonces-
Total IPv4 addresses available for Pods = (Number of supported IPv4 addresses in the primary interface - 1) * 16
Aquí, en lugar de asignar IPv4 direcciones secundarias, el controlador de recursos de VPC las
/28 prefixesasignará y, por lo tanto, el número total de direcciones IPv4 disponibles aumentará 16 veces.
Con la fórmula anterior, podemos calcular el número máximo de pods para un nodo de trabajo de Windows basado en una instancia m5.large de la siguiente manera:
-
De forma predeterminada, cuando se ejecuta en modo IP secundario:
10 secondary IPv4 addresses per ENI - 1 = 9 available IPv4 addresses
-
Cuando se usa
prefix delegation-(10 secondary IPv4 addresses per ENI - 1) * 16 = 144 available IPv4 addresses
Para obtener más información sobre cuántas direcciones IP puede admitir un tipo de instancia, consulta Direcciones IP por interfaz de red por tipo de instancia.
Otra consideración clave es el flujo del tráfico de red. Con Windows, existe el riesgo de que se agoten los puertos en los nodos con más de 100 servicios. Cuando se presente esta condición, los nodos comenzarán a generar errores con el siguiente mensaje:
«Falló la creación de la política: el hcnCreateLoad balanceador falló en Win32: el puerto especificado ya existe».
Para solucionar este problema, utilizamos Direct Server Return (DSR). El DSR es una implementación de la distribución asimétrica de la carga de la red. En otras palabras, el tráfico de solicitud y respuesta utiliza diferentes rutas de red. Esta función acelera la comunicación entre los módulos y reduce el riesgo de agotamiento de los puertos. Por lo tanto, recomendamos habilitar el DSR en los nodos de Windows.
El DSR está habilitado de forma predeterminada en Windows Server SAC EKS Optimized. AMIs En el caso de Windows Server 2019 LTSC EKS Optimized AMIs, tendrá que habilitarlo durante el aprovisionamiento de instancias mediante el siguiente script y utilizando Windows Server 2019 Full o Core como AMIFamily en el NodeGroup. eksctl Consulte la AMI personalizada de eksctl
nodeGroups: - name: windows-ng instanceType: c5.xlarge minSize: 1 volumeSize: 50 amiFamily: WindowsServer2019CoreContainer ssh: allow: false
Para utilizar DSR en Windows Server 2019 y versiones posteriores, tendrás que especificar los siguientes indicadores de kube-proxy
<powershell> [string]$EKSBinDir = "$env:ProgramFiles\Amazon\EKS" [string]$EKSBootstrapScriptName = 'Start-EKSBootstrap.ps1' [string]$EKSBootstrapScriptFile = "$EKSBinDir\$EKSBootstrapScriptName" (Get-Content $EKSBootstrapScriptFile).replace('"--proxy-mode=kernelspace",', '"--proxy-mode=kernelspace", "--feature-gates WinDSR=true", "--enable-dsr",') | Set-Content $EKSBootstrapScriptFile & $EKSBootstrapScriptFile -EKSClusterName "eks-windows" -APIServerEndpoint "https://<REPLACE-EKS-CLUSTER-CONFIG-API-SERVER>" -Base64ClusterCA "<REPLACE-EKSCLUSTER-CONFIG-DETAILS-CA>" -DNSClusterIP "172.20.0.10" -KubeletExtraArgs "--node-labels=alpha.eksctl.io/cluster-name=eks-windows,alpha.eksctl.io/nodegroup-name=windows-ng-ltsc2019 --register-with-taints=" 3>&1 4>&1 5>&1 6>&1 </powershell>
La habilitación del DSR se puede verificar siguiendo las instrucciones del blog de Microsoft Networking
Si conservar IPv4 las direcciones disponibles y minimizar el desperdicio es crucial para su subred, generalmente se recomienda evitar el uso del modo de delegación de prefijos, tal como se menciona en Modo de prefijo para Windows: Cuándo evitar. Si aún desea utilizar la delegación de prefijos, puede tomar medidas para optimizar la utilización de IPv4 direcciones en la subred. Consulte Configuración de los parámetros para la delegación de prefijos para obtener instrucciones detalladas sobre cómo ajustar el proceso de solicitud y asignación de IPv4 direcciones. Ajustar estas configuraciones puede ayudarle a lograr un equilibrio entre la conservación de las IPv4 direcciones y las ventajas de la delegación de prefijos en cuanto a densidad de pods.
Cuando se utiliza la configuración predeterminada de asignar IPv4 direcciones secundarias, actualmente no hay configuraciones compatibles para manipular la forma en que el controlador de recursos de VPC solicita y IPv4 asigna las direcciones. Más específicamente, solo warm-ip-target se admiten en minimum-ip-target el modo de delegación de prefijos. Tenga en cuenta también que, en el modo IP secundario, según las direcciones IP disponibles en la interfaz, el controlador de recursos de la VPC normalmente asignará 3 IPv4 direcciones no utilizadas en el nodo en su nombre IPs para mantenerlas calientes y acelerar los tiempos de inicio del pod. Si quiere minimizar el despilfarro de IP generado por las direcciones IP cálidas no utilizadas, puede programar más pods en un nodo de Windows determinado, de forma que utilice la mayor capacidad de direcciones IP del ENI como sea posible. IPs De forma más explícita, se podría evitar que el nodo y los módulos en ejecución utilizaran ya todas las direcciones IP del ENI. Otra solución alternativa que le ayude a resolver las limitaciones de disponibilidad de las direcciones IP en sus subredes podría consistir en aumentar el tamaño de la subred o separar los nodos de Windows en sus propias subredes dedicadas.
Además, es importante tener en cuenta que, por el momento, no IPv6 es compatible con los nodos de Windows.
Opciones de interfaz de red de contenedores (CNI)
El AWSVPC CNI es el complemento CNI de facto para los nodos de trabajo de Windows y Linux. Si bien el AWSVPC CNI satisface las necesidades de muchos clientes, puede que haya ocasiones en las que necesite considerar alternativas como una red superpuesta para evitar el agotamiento de la IP. En estos casos, se puede utilizar el CNI de Calico en lugar del CNI. AWSVPC Project Calico
Políticas de red
Se considera una buena práctica cambiar del modo predeterminado de comunicación abierta entre los pods del clúster de Kubernetes a limitar el acceso en función de las políticas de red. El proyecto Calico
Las instrucciones para instalar Calico en EKS se encuentran en la página Instalación de Calico en Amazon EKS.
Además, los consejos proporcionados en la sección Red de la Guía de mejores prácticas de seguridad de Amazon EKS se aplican por igual a los clústeres de EKS con nodos de trabajo de Windows;
