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.
Ejecución de clústeres EKS de IPv6
EKS en modo IPv6 resuelve el problema de agotamiento de IPv4 que suele presentarse en los clústeres EKS a gran escala. El soporte de EKS para IPv6 se centra en resolver el problema de agotamiento del IPv4, que se debe al tamaño limitado del espacio de direcciones IPv4. Esta es una preocupación importante planteada por varios de nuestros clientes y es distinta de la función de doble pila de IPv4/IPv6 Kubernetes.
En un clúster EKS para IPv6, los pods y los servicios recibirán direcciones IPv6 y, al mismo tiempo, mantendrán la compatibilidad con los puntos finales IPv4 antiguos. Esto incluye la posibilidad de que los puntos finales IPv4 externos accedan a los servicios del clúster y los pods accedan a los puntos finales IPv4 externos.
La compatibilidad con IPv6 de Amazon EKS aprovecha las capacidades IPv6 nativas de la VPC. A cada VPC se le asigna un prefijo de dirección IPv4 (el tamaño del bloque CIDR puede oscilar entre /16 y /28) y un prefijo de dirección IPv6 /56 único (fijo) desde la GUA (dirección de unidifusión global) de Amazon; puede asignar un prefijo de dirección /64 a cada subred de su VPC. Las funciones de IPv4, como las tablas de enrutamiento, las listas de control de acceso a la red, el emparejamiento y la resolución de DNS, funcionan de la misma manera en una VPC habilitada para IPv6. A continuación, la VPC se denomina VPC de doble pila. A partir de las subredes de doble pila, el siguiente diagrama muestra el patrón básico de la VPC IPv4-IPv6 que admite clústeres basados: EKS/IPv6
En el mundo de IPv6, todas las direcciones se pueden enrutar por Internet. De forma predeterminada, la VPC asigna el CIDR de IPv6 del rango GUA público. Sin embargo, desde agosto de 2024
El siguiente diagrama muestra el flujo de salida de Internet de un pod IPv6 dentro de un clúster: EKS/IPv6
Las prácticas recomendadas para implementar subredes IPv6 se encuentran en la guía del usuario de VPC.
En un clúster EKS de IPv6, los nodos y los pods reciben direcciones IPv6 públicas. EKS asigna direcciones IPv6 a los servicios en función de las direcciones de unidifusión IPv6 locales únicas (ULA). El CIDR del servicio ULA para un clúster de IPv6 se asigna automáticamente durante la etapa de creación del clúster y no se puede especificar, a diferencia de IPv4. El siguiente diagrama muestra un patrón básico de un plan de datos EKS/IPv6 basado en el plano de control del clúster:
Descripción general de
EKS/IPv6 solo se admite en el modo de prefijo (modo de asignación de IP de VPC-CNI Plug-in ENI). Obtenga más información sobre el modo de prefijo.
La asignación de prefijos solo funciona en instancias de Nitro-based EC2, por lo que solo EKS/IPv6 se admite cuando el plano de datos del clúster utiliza instancias de EC2. Nitro-based
En pocas palabras, un prefijo IPv6 de /80 (por nodo trabajador) generará aproximadamente 10 ^ 14 direcciones IPv6. El factor limitante ya no serán las IP sino la densidad de los pods (en términos de recursos).
La asignación de prefijos de IPv6 solo se realiza durante el arranque del nodo de trabajo de EKS. Se sabe que este comportamiento mitiga los escenarios en los que los EKS/IPv4 clústeres con una alta tasa de abandono de pods suelen retrasarse en la programación de los pods debido a la limitación de las llamadas a la API generadas por el complemento CNI de la VPC (ipamd), cuyo objetivo es asignar direcciones IPv4 privadas de forma oportuna. También se sabe que hace que los botones avanzados del VPC-CNI complemento, MINIMUM_IP, se ajusten innecesariamente. WARM_IP/ENI
El siguiente diagrama amplía una interfaz de red elástica (ENI) de nodo de trabajo IPv6:
A cada nodo de trabajo de EKS se le asignan direcciones IPv4 e IPv6, junto con las entradas de DNS correspondientes. Para un nodo de trabajo determinado, solo se consume una dirección IPv4 de la subred de doble pila. El soporte de EKS para IPv6 le permite comunicarse con los puntos de enlace de IPv4 (AWS, locales, Internet) a través de un modelo de IPv4 de solo salida muy obstinado. EKS implementa un complemento CNI local del host, secundario al complemento CNI de VPC, que asigna y configura una dirección IPv4 para un pod. El complemento CNI configura una dirección IPv4 no enrutable específica del host para un pod a partir del 169.254.172. 0/22 rango. La dirección IPv4 asignada al pod es exclusiva del nodo trabajador y no se anuncia más allá del nodo trabajador. 169.254.172. 0/22 proporciona hasta 1024 direcciones IPv4 únicas que pueden admitir tipos de instancias grandes.
El siguiente diagrama muestra el flujo de un pod IPv6 que se conecta a un punto final IPv4 situado fuera de los límites del clúster (excepto Internet):
En el diagrama anterior, los Pods realizarán una búsqueda de DNS para el punto final y, al recibir una respuesta IPv4 «A», la dirección IPv4 única del Pod, exclusiva del nodo, se traduce mediante la traducción de direcciones de red de origen (SNAT) a la dirección IPv4 privada (VPC) de la interfaz de red principal conectada al EC2. Worker-node
nota
El patrón anterior requiere que DNS64 esté deshabilitado en las subredes en las que se ejecutan los pods. EKS/IPv6 Cuando DNS64 está habilitado, el solucionador de DNS devuelve una dirección IPv6 sintetizada para los puntos IPv4-only finales junto con una dirección IPv4. Como resultado, el tráfico se enruta a través de la funcionalidad NAT64 de la puerta de enlace NAT (si está incluida en la arquitectura) en lugar de permanecer dentro de la VPC, como se muestra en el patrón anterior. Esto puede provocar un uso inesperado de la puerta de enlace NAT y los costes asociados.
EKS/IPv6 Los pods también deberán conectarse a puntos finales IPv4 a través de Internet mediante direcciones IPv4 públicas para lograr que exista un flujo similar. El siguiente diagrama muestra el flujo de un pod IPv6 que se conecta a un punto final IPv4 fuera del límite del clúster (enrutable a Internet):
En el diagrama anterior, los Pods realizarán una búsqueda de DNS para el punto final y, al recibir una respuesta IPv4 «A», la dirección IPv4 única del Pod, exclusiva del nodo, se traduce mediante la traducción de direcciones de red de origen (SNAT) a la dirección IPv4 privada (VPC) de la interfaz de red principal conectada al EC2. Worker-node A continuación, la dirección IPv4 del pod (IPv4 de origen: IP principal de EC2) se enruta a la puerta de enlace NAT IPv4, donde la IP principal de EC2 se traduce (SNAT) en una dirección IP pública IPv4 válida y enrutable por Internet (IP pública asignada a la puerta de enlace NAT).
Cualquier Pod-to-Pod comunicación entre los nodos siempre utiliza una dirección IPv6. La VPC CNI configura iptables para gestionar IPv6 y, al mismo tiempo, bloquea cualquier conexión IPv4.
Los servicios de Kubernetes solo recibirán direcciones IPv6 (ClusteriP) de direcciones unidifusión IPv6 locales únicas (ULA).
Los servicios se exponen a Internet mediante un balanceador de cargas de AWS. El balanceador de cargas recibe direcciones IPv4 e IPv6 públicas, es decir, balanceador de cargas de doble pila. En el caso de los clientes de IPv4 que acceden a los servicios de kubernetes de clústeres de IPv6, el balanceador de cargas traduce de IPv4 a IPv6.
Amazon EKS recomienda ejecutar nodos de trabajo y pods en subredes privadas. Puede crear balanceadores de carga públicos en las subredes públicas que equilibren la carga del tráfico hacia los pods que se ejecutan en nodos que se encuentran en subredes privadas. El siguiente diagrama muestra a un usuario de IPv4 de Internet que accede a un servicio basado en Ingress: EKS/IPv6
nota
El patrón anterior requiere implementar la versión más reciente del controlador
Comunicación con el plano de datos del plano de control EKS
EKS aprovisionará los Cross-Account ENI (X-ENIs) en modo de doble pila (IPv4/IPv6). Los componentes del nodo de Kubernetes, como kubelet y kube-proxy, están configurados para admitir la doble pila. Kubelet y kube-proxy se ejecutan en modo HostNetwork y se enlazan a las direcciones IPv4 e IPv6 conectadas a la interfaz de red principal de un nodo. El servidor API de Kubernetes se comunica con los pods y los componentes del nodo mediante el protocolo IPv6. X-ENIs Los pods se comunican con los servidores de API a través del modo IPv6, y la comunicación de un pod a un servidor de API X-ENIs siempre utiliza el modo IPv6.
Recomendaciones
Programación basada en recursos de cómputo
Un único prefijo de IPv6 es suficiente para ejecutar varios pods en un solo nodo. Esto también elimina eficazmente las limitaciones de ENI e IP en cuanto al número máximo de pods en un nodo. Si bien IPv6 elimina la dependencia directa de los Max-Pods, cuando se utilizan adjuntos de prefijo con tipos de instancias más pequeños, como la m5.large, es probable que se agoten los recursos de CPU y memoria de la instancia mucho antes de agotar sus direcciones IP. Debe establecer manualmente el valor máximo de pod recomendado por EKS si utiliza grupos de nodos autogestionados o un grupo de nodos gestionado con un ID de AMI personalizado.
Puedes usar la siguiente fórmula para determinar la cantidad máxima de pods que puedes implementar en un nodo de un clúster EKS de IPv6.
((Number of network interfaces for instance type (number of prefixes per network interface-1)* 16) + 2
((3 ENIs)_((10 secondary IPs per ENI-1)_ 16)) + 2 = 460 (real)
Los grupos de nodos gestionados calculan automáticamente la cantidad máxima de pods por ti. Evita cambiar el valor recomendado por EKS para la cantidad máxima de pods para evitar errores en la programación de los pods debido a limitaciones de recursos.
Evalúe el propósito de las redes personalizadas existentes
Si las redes personalizadas están habilitadas actualmente, Amazon EKS recomienda volver a evaluar su necesidad con IPv6. Si optó por utilizar redes personalizadas para solucionar el problema de agotamiento del IPv4, ya no es necesario con IPv6. Si utiliza una red personalizada para cumplir con un requisito de seguridad, como una red independiente para nodos y pods, le recomendamos que envíe una solicitud de hoja de ruta de EKS
Fargate Pods en racimo EKS/IPv6
EKS admite IPv6 para los pods que se ejecutan en Fargate. Los pods que se ejecutan en Fargate consumirán direcciones IPv4 privadas enrutables de IPv6 y VPC extraídas de los rangos CIDR de la VPC (). IPv4IPv6 En pocas palabras, la densidad de su clúster de EKS/Fargate Pods se limitará a las direcciones IPv4 e IPv6 disponibles. Se recomienda dimensionar los CIDR de doble pila para subnets/VPC un futuro crecimiento. No podrás programar nuevos Fargate Pods si la subred subyacente no contiene una dirección IPv4 disponible, independientemente de las direcciones IPv6 disponibles.
Implemente el controlador Load Balancer Controller (LBC) de AWS
El controlador de servicios de Kubernetes integrado en el árbol original no es compatible con IPv6. Recomendamos utilizar la versión más reciente del complemento"alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
