Ayude a mejorar esta página
¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.
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 unHostProcess
Pod de Windowsen 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
ykube-proxy
se redirigen al registro de eventos de Windows deEKS
y se establecen en un límite de 200 MB. -
No puede utilizar Asigne los grupos de seguridad a pods individuales con Pods en ejecución en nodos de Windows.
-
No puede utilizar redes personalizadas con 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 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ónIPv4
debido a reglas caducadas dekube-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.
Versión de Kubernetes Versión de la plataforma 1.31 eks.1 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
Para habilitar la compatibilidad con Windows en su clúster
-
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
por el nombre de rol del clúster.eksClusterRole
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.
-
Adjunte la política administrada AmazonEKSVPCResourceController al Rol de IAM del clúster de Amazon EKS. Reemplace
por el nombre de rol del clúster.eksClusterRole
aws iam attach-role-policy \ --role-name
eksClusterRole
\ --policy-arn arn:aws:iam::aws:policy/AmazonEKSVPCResourceController -
Cree un archivo denominado
con el siguiente contenido.vpc-resource-controller-configmap.yaml
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
deaws-auth
contenga una asignación para que el rol de instancia del nodo Windows incluya el grupo de permisos RBAC deeks: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 actualizarConfigMap
o crearlo para incluir el grupo requerido. Para obtener más información sobreConfigMap
deaws-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.