Habilitación de la compatibilidad con Windows Implementación de pods de Windows Compatibilidad con una mayor densidad de Pod en los nodos de Windows

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

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

El modo automático de EKS no es compatible con los nodos de Windows
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 EKS Windows y se establecen en un límite de 200 MB.
No puede usar Asignar grupos de seguridad a pods individuales con Pods que se ejecuten en nodos de Windows.
No puede utilizar redes personalizadas con los nodos de Windows.
No puede usar IPv6 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 utilizar Nodos híbridos de Amazon EKS con Windows como sistema operativo del host.
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.
Un clúster existente.
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 heredada con Windows, debe utilizar un nodo de Linux (no puede usar un Pod de Fargate) para ejecutar CoreDNS.
Un rol de IAM de clúster de Amazon EKS existente.

Habilitación de la compatibilidad con Windows

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

Agregue la política de administrada AmazonEKSVPCResourceController al rol de IAM asociado a su clúster de Amazon EKS. Reemplace eksClusterRole por el nombre del rol del clúster.
```
aws iam attach-role-policy \
  --role-name eksClusterRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController
```

Cree un archivo llamado 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"

Aplique el ConfigMap en su clúster.


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

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 Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Configuración del acceso al punto de conexión

Deshabilitación del soporte con Windows