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 con frecuencia se manifiesta en los clústeres EKS de gran escala. El soporte de EKS para IPv6 se centra en resolver el problema de agotamiento de 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 de IPv6, los pods y los servicios recibirán direcciones IPv6 y, al mismo tiempo, mantendrán la compatibilidad con los terminales IPv4 antiguos. Esto incluye la posibilidad de que los terminales IPv4 externos accedan a los servicios del clúster y que los Pods accedan a puntos de enlace IPv4 externos.
La compatibilidad con IPv6 de Amazon EKS aprovecha las capacidades IPv6 nativas de las 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 único de /56 (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, la interconexión y la resolución de DNS, funcionan de la misma manera en una VPC habilitada para IPv6. La VPC se denomina entonces VPC de doble pila. Después de las subredes de doble pila, el siguiente diagrama muestra el patrón básico de las VPC IPv4/IPv6 que admiten clústeres basados en clústeres: EKS/IPv6
En el mundo de IPv6, todas las direcciones se pueden enrutar a Internet. De forma predeterminada, la VPC asigna el CIDR de IPv6 del rango GUA público. Sin embargo, desde agosto de 2024, también
El siguiente diagrama muestra el flujo de salida de Internet IPv6 de un pod dentro de un clúster: EKS/IPv6
Las prácticas recomendadas para implementar subredes IPv6 se encuentran en la guía del usuario de la 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 basándose en direcciones de unidifusión IPv6 locales únicas (ULA). El CIDR del servicio ULA para un clúster 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 del plan de datos del plano de control del clúster EKS/IPv6 basado en el plan de datos:
Descripción general de
EKS/IPv6 solo se admite en modo prefijo (modo de asignación de IP VPC-CNI Plug-in ENI). Más información sobre el modo prefijo.
La asignación de prefijos solo funciona en instancias Nitro-based EC2 y, por lo tanto, solo EKS/IPv6 se admite cuando el plano de datos del clúster usa instancias EC2. Nitro-based
En pocas palabras, un prefijo IPv6 de /80 (por nodo de trabajo) generará entre 10 y 14 direcciones IPv6. El factor limitante ya no serán las direcciones IP, sino la densidad de pods (en cuanto a los recursos).
La asignación del prefijo IPv6 solo se produce en el momento del arranque del nodo de trabajo de EKS. Se sabe que este comportamiento mitiga los casos en los que los EKS/IPv4 clústeres con alta tasa de abandono de pods suelen retrasar 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) para asignar direcciones IPv4 privadas de forma oportuna. También es conocido por hacer que los botones avanzados del VPC-CNI complemento ajusten innecesariamente MINIMUM_IP. WARM_IP/ENI
El siguiente diagrama amplía la interfaz de red elástica (ENI) de un nodo de trabajo de IPv6:
A cada nodo de trabajo de EKS se le asignan direcciones IPv4 e IPv6, junto con las entradas DNS correspondientes. Para un nodo de trabajo determinado, solo se consume una dirección IPv4 de la subred de doble pila. La compatibilidad de EKS con IPv6 le permite comunicarse con los puntos finales de IPv4 (AWS, in situ, Internet) mediante un modelo IPv4 que solo permite la salida, y que es 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 de trabajo y no se anuncia más allá del nodo de trabajo. 169.254.172. 0/22 proporciona hasta 1024 direcciones IPv4 únicas que pueden admitir tipos de instancias de gran tamaño.
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 (sin conexión a Internet):
En el diagrama anterior, los pods realizan una búsqueda de DNS para el punto final y, al recibir una respuesta «A» de IPv4, la dirección IPv4 exclusiva del nodo del Pod 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 IPv4-only terminales junto con una dirección IPv4. Como resultado, el tráfico se dirige 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 costos asociados.
EKS/IPv6 Los pods también deberán conectarse a los 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 por Internet):
En el diagrama anterior, los pods realizan una búsqueda de DNS para el punto final y, al recibir una respuesta «A» de IPv4, la dirección IPv4 exclusiva del nodo del Pod 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 La dirección IPv4 del pod (IPv4 de origen: IP principal de EC2) se enruta luego 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 a 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. El CNI de la VPC 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 de unidifusión IPv6 locales únicas (ULA). https://datatracker.ietf.org/doc/html/rfc4193
Los servicios se exponen a Internet mediante un balanceador de cargas de AWS. El balanceador de cargas recibe direcciones IPv4 e IPv6 públicas, también conocidas como balanceadores de cargas de doble pila. En el caso de los clientes IPv4 que acceden a los servicios de Kubernetes en clústeres IPv6, el balanceador de cargas traduce IPv4 a IPv6.
Amazon EKS recomienda ejecutar nodos de trabajo y pods en subredes privadas. Puede crear balanceadores de cargas públicos en las subredes públicas para equilibrar la carga del tráfico dirigido a los pods que se ejecutan en nodos que se encuentran en subredes privadas. En el siguiente diagrama, se 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 del plano de datos del plano de control de EKS
EKS suministrará Cross-Account eNIS (X-ENIs) en modo de doble pila (IPv4/IPv6). Los componentes de los nodos de Kubernetes, como kubelet y kube-proxy, están configurados para admitir la pila doble. 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 de API de Kubernetes se comunica con los Pods y los componentes del nodo a través de un servidor basado en IPv6. X-ENIs Los pods se comunican con los servidores de API a través del, y la comunicación entre el pod y el servidor de API siempre utiliza el X-ENIs modo IPv6.
Recomendaciones
Programación basada en los recursos informáticos
Un único prefijo IPv6 es suficiente para ejecutar varios pods en un solo nodo. Esto también elimina de manera efectiva las limitaciones de ENI e IP sobre la cantidad máxima de pods en un nodo. Si bien IPv6 elimina la dependencia directa de los Max-pods, si usas prefijos adjuntos en tipos de instancias más pequeñas, como la m5.large, es probable que agotes los recursos de CPU y memoria de la instancia mucho antes de agotar sus direcciones IP. Debes establecer manualmente el valor máximo de pod recomendado por EKS si utilizas 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 para un clúster de 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 administrados calculan automáticamente el número máximo de pods. Evita cambiar el valor recomendado por EKS para el número máximo de pods para evitar errores en la programación de los pods debido a las 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 de redes con IPv6. Si opta por utilizar redes personalizadas para solucionar el problema de agotamiento de IPv4, ya no es necesario con IPv6. Si utilizas redes personalizadas para cumplir un requisito de seguridad, como una red independiente para los nodos y los pods, te recomendamos que envíes una solicitud de hoja de ruta de EKS.
Fargate Pods en clúster EKS/IPv6
EKS admite IPv6 para los pods que se ejecutan en Fargate. Los pods que se ejecuten en Fargate consumirán direcciones IPv4 privadas enrutables de IPv6 y VPC extraídas de los rangos de CIDR de la VPC (). IPv4IPv6 En pocas palabras, la densidad de todo el clúster de EKS/Fargate Pods se limitará a las direcciones IPv4 e IPv6 disponibles. Se recomienda dimensionar los subnets/VPC CIDR de doble pila para su crecimiento futuro. 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 AWS Load Balancer Controller (LBC)
El controlador de servicios Kubernetes integrado en árbol de arriba no admite IPv6. Recomendamos usar la versión más reciente del complemento AWS Load Balancer "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"
