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 (HCS). El HCS actúa como una capa de API que se encuentra por encima de la implementación del contenedor en Windows. Los contenedores de Windows también utilizan el Host Network Service (HNS), que define la topología de red de un nodo.

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 Hyper-V virtual (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, que se ejecuta en el plano de control. Puede encontrar más detalles sobre el flujo de trabajo para la administración de direcciones IP de los nodos de Windows aquí.

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 direcciones IPv4 disponibles. Puede calcular la dirección IPv4 disponible en el nodo de la siguiente manera:

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:

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:

«Error al crear la política: CreateLoadBalancer error en hcn 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 las AMI optimizadas para EKS SAC de Windows Server. En el caso de las AMI optimizadas para Windows Server 2019 LTSC para EKS, tendrá que habilitarla durante el aprovisionamiento de instancias mediante el siguiente script y utilizando Windows Server 2019 Full o Core como la familia AMIFamily en el grupo de nodos. eksctl Consulte la AMI personalizada de eksctl para obtener información adicional.

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 durante el inicio de la instancia. Para ello, puede ajustar el script de datos de usuario asociado a la plantilla de lanzamiento del grupo de nodos autogestionado.

<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 y del laboratorio de contenedores de Windows en AWS.

Si conservar las direcciones IPv4 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 las direcciones IPv4 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 direcciones IPv4. Ajustar estas configuraciones puede ayudarle a lograr un equilibrio entre la conservación de las direcciones IPv4 y las ventajas de la delegación de prefijos en cuanto a densidad de pods.

Cuando se utiliza la configuración predeterminada de asignar direcciones IPv4 secundarias, actualmente no hay configuraciones compatibles para manipular la forma en que el controlador de recursos de VPC solicita y asigna las direcciones IPv4. Más específicamente, solo se admiten en el minimum-ip-target modo de delegación de warm-ip-target 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 direcciones IPv4 no utilizadas en el nodo en su nombre para mantener las IP calientes y acelerar los tiempos de inicio del pod. Si quiere minimizar el despilfarro de IP producido 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. De forma más explícita, podrías evitar tener direcciones IP inactivas y no utilizadas si todas las direcciones IP del ENI ya están siendo utilizadas por el nodo y los pods en ejecución. 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, los nodos de Windows no admiten IPv6.

Opciones de interfaz de red de contenedores (CNI)

El CNI de AWSVPC es el complemento CNI de facto para los nodos de trabajo de Windows y Linux. Si bien el CNI de AWSVPC satisface las necesidades de muchos clientes, es posible 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 de AWSVPC. Project Calico es un software de código abierto desarrollado por Tigera. Ese software incluye un CNI que funciona con EKS. Las instrucciones para instalar Calico CNI en EKS se encuentran en la página de instalación del Proyecto Calico EKS.

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, de código abierto, apoya decididamente las políticas de red que funcionan con nodos de Linux y Windows. Esta función es independiente y no depende del uso del CNI de Calico. Por lo tanto, recomendamos instalar Calico y usarlo para la administración de políticas de red.

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; sin embargo, Windows no admite algunas funciones, como los «Grupos de seguridad para pods», en este momento.