Redes de Windows - Amazon EKS

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.

redes de Windows

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, 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 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 prefixes asignará 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 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 Windows Containers on AWS.

dsr

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 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.