Implementación de nodos de Windows en clústeres de EKS

Antes de implementar nodos de Windows, tenga en cuenta lo siguiente.

Consideraciones

• Puede utilizar redes de host en nodos de Windows mediante Pods HostProcess. Para obtener más información, consulte Crear un HostProcessPod de Windows en la documentación de Kubernetes.

• Los clústeres de Amazon EKS deben contener uno o varios nodos de Linux o Fargate para ejecutar Pods del sistema principal que solo se ejecutan en Linux, como CoreDNS.

• Los registros de eventos kubelet y kube-proxy se redirigen al registro de eventos de Windows de EKS y se establecen en un límite de 200 MB.

• No puede utilizar Grupos de seguridad de Pods con Pods en ejecución en nodos de Windows.

• No puede utilizar redes personalizadas con Windows.

• No puede usarIPv6 con los nodos de Windows.

• Los nodos de Windows admiten una interfaz de red elástica por nodo. De forma predeterminada, la cantidad de Pods que puede ejecutar por nodo de Windows es igual a la cantidad de direcciones IP disponibles por interfaz de red elástica para el tipo de instancia del nodo, menos uno. Para obtener más información, consulte Direcciones IP por interfaz de red por tipo de instancia en la Guía del usuario de Amazon EC2.

• En un clúster de Amazon EKS, un único servicio con un equilibrador de carga puede admitir hasta 1024 Pods de backend. Cada Pod tiene su propia dirección IP única. El límite anterior de 64 Pods dejará de aplicarse después de una actualización de Windows Server a partir de la compilación del SO 17763.2746.

• No se admiten contenedores de Windows para Pods de Amazon EKS en Fargate.

• No puede recuperar registros del pod de vpc-resource-controller. Anteriormente podía hacerlo cuando se implementaba el controlador en el plano de datos.

• Hay un periodo de enfriamiento antes de que se asigne una dirección IPv4 a un nuevo pod. Esto evita que el tráfico fluya hacia un pod anterior con la misma dirección IPv4 debido a reglas caducadas de kube-proxy.

• El origen del controlador se administra en GitHub. Para registrar problemas con el controlador u ofrecer ayuda con estos, visite el proyecto en GitHub.

• Al especificar un ID de AMI personalizado para los grupos de nodos administrados de Windows, agregue eks:kube-proxy-windows al mapa de configuración de AWS IAM Authenticator. Para obtener más información, consulte Límites y condiciones al especificar un ID de AMI.

• Si conservar las direcciones IPv4 disponibles es fundamental para su subred, consulte la Guía de prácticas recomendadas de EKS: Administración de direcciones IP de redes de Windows para obtener orientación.

Requisitos previos

• Un clúster existente. El clúster debe estar ejecutando una de las versiones de Kubernetes y versiones de la plataforma que se enumeran en la siguiente tabla. Se admite cualquier versión de Kubernetes y plataformas posteriores a las enumeradas en la tabla. Si la versión de su clúster o plataforma es anterior a una de las siguientes versiones, debe habilitar la compatibilidad con Windows heredado en el plano de datos del clúster. Una vez que el clúster se encuentre en una de las siguientes versiones de Kubernetes y la plataforma, o posteriores, puede eliminar la compatibilidad con Windows heredado y habilitar la compatibilidad con Windows en el plano de control.

  Versión de Kubernetes	Versión de la plataforma
  1.30	eks.2
  1.29	eks.1
  1.28	eks.1
  1.27	eks.1
  1.26	eks.1
  1.25	eks.1
  1.24	eks.2

• El clúster debe tener al menos un nodo de Linux o Pod de Fargate (recomendamos al menos dos) para ejecutar CoreDNS. Si habilita la compatibilidad con Windows heredado, debe utilizar un nodo de Linux (no puede usar un Pod de Fargate) para ejecutar CoreDNS.

• Un Rol de IAM del clúster de Amazon EKS existente.

Habilitación de la compatibilidad con Windows

Si el clúster no se encuentra en una de las versiones de Kubernetes y la plataforma enumeradas en los Requisitos previos o es posterior a ellas, debe habilitar en su lugar la compatibilidad con Windows heredado. Para obtener más información, consulte Compatibilidad heredada de clústeres con nodos de Windows.

Si nunca ha habilitado la compatibilidad con Windows en el clúster, vaya al siguiente paso.

Si ha habilitado la compatibilidad con Windows en un clúster anterior a una de las versiones de Kubernetes o la plataforma que aparecen en los Requisitos previos, debe primero eliminar el vpc-resource-controller y el vpc-admission-webhook del plano de datos. Estos están obsoletos y ya no se necesitan.

Para habilitar la compatibilidad con Windows en su clúster

1. Si no tiene nodos de Amazon Linux en su clúster y utiliza grupos de seguridad para Pods, avance al siguiente paso. De lo contrario, confirme que la política administrada AmazonEKSVPCResourceController esté adjunta al rol del clúster. Reemplace eksClusterRole por el nombre de rol del clúster.

   aws iam list-attached-role-policies --role-name eksClusterRole
   

   Un ejemplo de salida sería el siguiente.

   {
       "AttachedPolicies": [
           {
               "PolicyName": "AmazonEKSClusterPolicy",
               "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
           },
           {
               "PolicyName": "AmazonEKSVPCResourceController",
               "PolicyArn": "arn:aws:iam::aws:policy/AmazonEKSVPCResourceController"
           }
       ]
   }

   Si la política está adjunta, como en la salida anterior, omita el siguiente paso.

2. Adjunte la política administrada AmazonEKSVPCResourceController al Rol de IAM del clúster de Amazon EKS. Reemplace eksClusterRole por el nombre de rol del clúster.

   aws iam attach-role-policy \
     --role-name eksClusterRole \
     --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
   

3. Cree un archivo denominado vpc-resource-controller-configmap.yaml con el siguiente contenido.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: amazon-vpc-cni
     namespace: kube-system
   data:
     enable-windows-ipam: "true"

4. Aplique el ConfigMap en su clúster.

   kubectl apply -f vpc-resource-controller-configmap.yaml
   

5. Verifique que el ConfigMap de aws-auth contenga una asignación para que el rol de instancia del nodo Windows incluya el grupo de permisos RBAC de eks:kube-proxy-windows. Puede verificar ejecutando el siguiente comando:

   kubectl get configmap aws-auth -n kube-system -o yaml
   

   Un ejemplo de salida sería el siguiente.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: aws-auth
     namespace: kube-system
   data:
     mapRoles: |
       - groups:
         - system:bootstrappers
         - system:nodes
         - eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
         rolearn: arn:aws:iam::111122223333:role/eksNodeRole
         username: system:node:{{EC2PrivateDNSName}}
   [...]
   

   eks:kube-proxy-windows debería aparecer en la lista de grupos. Si el grupo no está especificado, debe actualizar ConfigMap o crearlo para incluir el grupo requerido. Para obtener más información sobre ConfigMap de aws-auth, consulte Aplique el ConfigMap de aws-auth en su clúster.

Implementación de pods de Windows

Cuando implementa pods en el clúster, debe especificar el sistema operativo que utilizan si ejecuta una combinación de tipos de nodos.

Para Pods de Linux, use el siguiente texto del selector de nodos en sus manifiestos.

nodeSelector:
        kubernetes.io/os: linux
        kubernetes.io/arch: amd64

Para Pods de Windows, use el siguiente texto del selector de nodos en sus manifiestos.

nodeSelector:
        kubernetes.io/os: windows
        kubernetes.io/arch: amd64

Puede implementar una aplicación de muestra para ver los selectores de nodos en uso.

Compatibilidad con una mayor densidad de Pod en los nodos de Windows

En Amazon EKS, a cada Pod se le asigna una dirección de IPv4 desde su VPC. Debido a esto, la cantidad de Pods que puede implementar en un nodo está limitada por las direcciones IP disponibles, incluso si hay recursos suficientes para ejecutar más Pods en el nodo. Dado que un nodo de Windows solo admite una interfaz de red elástica, de forma predeterminada, la cantidad máxima de direcciones IP disponibles en un nodo de Windows es igual a:

Number of private IPv4 addresses for each interface on the node - 1

Se utiliza una dirección IP como dirección IP principal de la interfaz de red, por lo que no se puede asignar a Pods.

Puede habilitar una mayor densidad de Pod en los nodos de Windows si habilita la delegación de prefijos IP. Esta característica le permite asignar un prefijo /28 IPv4 a la interfaz de red principal, en lugar de asignar direcciones IPv4 secundarias. La asignación de un prefijo IP aumenta el número máximo de direcciones IPv4 disponibles en el nodo a:

(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16

Con esta cantidad significativamente mayor de direcciones IP disponibles, las direcciones IP disponibles no deberían limitar su capacidad para escalar la cantidad de Pods en sus nodos. Para obtener más información, consulte Aumentar la cantidad de direcciones IP disponibles para sus nodos de Amazon EC2.