IPv6 Ejecución de clústeres EKS

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.

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.

El IPv6 modo EKS resuelve el problema de IPv4 agotamiento que suele presentarse en los clústeres de EKS a gran escala. El apoyo de EKS IPv6 se centra en resolver el problema de IPv4 agotamiento, que se debe al tamaño limitado del espacio de IPv4 direcciones. Esta es una preocupación importante planteada por varios de nuestros clientes y es distinta de la función de doble pila de Kubernetes IPv4. IPv6 EKS/ también IPv6 proporcionará la flexibilidad necesaria para interconectar los límites de la red y, por lo tanto, minimizar las posibilidades de que se produzca una superposición de CIDR y, IPv6 CIDRs por lo tanto, resolverá un problema doble (dentro del clúster, entre clústeres). Cuando se despliegan clústeres EKS en IPv6 modo (--ip-family ipv6), la acción no es reversible. En pocas palabras, la IPv6 compatibilidad con EKS está habilitada durante toda la vida útil del clúster.

En un clúster de IPv6 EKS, los pods y los servicios recibirán IPv6 direcciones y, al mismo tiempo, mantendrán la compatibilidad con los IPv4 puntos finales antiguos. Esto incluye la posibilidad de que los IPv4 puntos de conexión externos accedan a los servicios del clúster y de los pods de acceder a los puntos de conexión externos. IPv4

El IPv6 soporte de Amazon EKS aprovecha las capacidades de IPv6 VPC nativas. A cada VPC se le asigna un prefijo de IPv4 dirección (el tamaño del bloque CIDR puede oscilar entre /16 y /28) y un prefijo de dirección /56 único (fijo) desde la GUA ( IPv6 dirección de unidifusión global) de Amazon; puede asignar un prefijo de dirección /64 a cada subred de la VPC. IPv4 las funciones, 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 IPv6 habilitada. A continuación, la VPC se denomina VPC de doble pila. A continuación, las subredes de doble pila, en el siguiente diagrama se muestra el patrón básico de la IPV4 IPv6 VPC que admite los clústeres basados en EKS/: IPv6

En el IPv6 mundo, todas las direcciones se pueden enrutar por Internet. De forma predeterminada, la VPC asigna el IPv6 CIDR del rango GUA público. Sin embargo, desde agosto de 2024, también puede usar IPv6 direcciones privadas VPCs y subredes con Amazon VPC IP Address Manager (IPAM). Consulte esta entrada del blog sobre redes de AWS y la documentación de VPC para obtener más información.

El siguiente diagrama muestra el flujo de salida de IPv6 Internet de un pod dentro de un clúster EKS/: IPv6

Las prácticas recomendadas para implementar IPv6 subredes se encuentran en la guía del usuario de VPC.

En un clúster de IPv6 EKS, los nodos y los pods reciben direcciones públicas IPv6 . EKS asigna IPv6 direcciones a los servicios en función de las direcciones de IPv6 unidifusión locales únicas (ULA). El CIDR del servicio ULA para un IPv6 clúster se asigna automáticamente durante la etapa de creación del clúster y no se puede especificar, a diferencia de lo que ocurre. IPv4 El siguiente diagrama muestra un patrón básico de un plan de datos del plano de control de clústeres IPv6 basado en EKS/:

Descripción general

EKS/ solo IPv6 se admite en el modo de prefijo (modo de asignación de IP ENI del complemento VPC-CNI). Más información sobre el modo de prefijo.

La asignación de prefijos solo funciona en EC2 instancias basadas en Nitro, por lo que EKS/ solo IPv6 se admite cuando el plano de datos del clúster utiliza instancias basadas en Nitro. EC2

En pocas palabras, un IPv6 prefijo /80 (por nodo trabajador) generará aproximadamente 10^14 IPv6 direcciones. El factor limitante ya no será sino la densidad de los pods (en términos de recursos). IPs

IPv6 la asignación de prefijos solo se produce durante el arranque del nodo de trabajo de EKS. Se sabe que este comportamiento mitiga los escenarios en los que los IPv4 clústeres EKS/ 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) con el objetivo de asignar direcciones privadas de manera oportuna. IPv4 También se sabe que los botones avanzados del complemento VPC-CNI ajustan WARM_IP/ENI y MINIMUM_IP innecesariamente.

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 IPv6 direcciones IPv4 y direcciones, junto con las entradas de DNS correspondientes. Para un nodo de trabajo determinado, solo se consume una IPv4 dirección de la subred de doble pila. El soporte de EKS IPv6 le permite comunicarse con IPv4 puntos de enlace (AWS, locales, Internet) a través de un modelo de salida altamente obstinado. IPv4 EKS implementa un complemento CNI local del host, secundario al complemento CNI de VPC, que asigna y configura una dirección para un pod. IPv4 El complemento CNI configura una dirección no enrutable específica del host para un pod del rango 169.254.172.0/22. IPv4 La IPv4 dirección asignada al pod es exclusiva del nodo de trabajo y no se anuncia fuera del nodo de trabajo. 169.254.172.0/22 proporciona hasta 1024 direcciones únicas que pueden admitir tipos de instancias grandes. IPv4

El siguiente diagrama muestra el flujo de un IPv6 pod que se conecta a un punto final situado fuera del límite del clúster (sin conexión a Internet): IPv4

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 IPv4 dirección única del nodo del Pod se traduce mediante la traducción de direcciones de red de origen (SNAT) a la dirección privada ( IPv4 VPC) de la interfaz de red principal conectada al nodo de trabajo. EC2

Los EKS/ IPv6 Pods también deberán conectarse a los IPv4 puntos finales a través de Internet mediante IPv4 direcciones públicas para lograr que exista un flujo similar. El siguiente diagrama muestra el flujo de un IPv6 pod que se conecta a un IPv4 punto final situado fuera del límite del clúster (se puede enrutar por 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 IPv4 dirección única del nodo del Pod se traduce mediante la traducción de direcciones de red de origen (SNAT) a la dirección privada ( IPv4 VPC) de la interfaz de red principal conectada al nodo de trabajo. EC2 La IPv4 dirección del pod (fuente IPv4: IP EC2 principal) se enruta luego a la puerta de enlace IPv4 NAT, donde la IP EC2 principal se traduce (SNAT) en una dirección IP pública enrutable por Internet válida (IP IPv4 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 que gestione y bloquee cualquier conexión. IPv6 IPv4

Los servicios de Kubernetes solo recibirán direcciones IPv6 (ClusteriP) de direcciones unidifusión locales únicas (ULA). IPv6 El CIDR del servicio ULA para un IPv6 clúster se asigna automáticamente durante la etapa de creación del clúster de EKS y no se puede modificar. El siguiente diagrama muestra el flujo del servicio Pod a Kubernetes:

Los servicios se exponen a Internet mediante un balanceador de cargas de AWS. El balanceador de cargas recibe IPv6 direcciones IPv4 y direcciones públicas, lo que se conoce como balanceador de cargas de doble pila. En el caso de IPv4 los clientes que acceden a los servicios de Kubernetes en IPv6 clústeres, el balanceador de cargas se encarga de la traducción. IPv4 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 IPv4 usuario de Internet que accede a un servicio basado en IPv6 EKS/Ingress:

Comunicación con el plano de datos del plano de control EKS

EKS suministrará Cross-Account ENIs (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 ambos y a las direcciones conectadas a la interfaz de red principal de un nodo. IPv4 IPv6 El servidor api de Kubernetes se comunica con los pods y los componentes del nodo a través de la interfaz X-. ENIs IPv6 Los pods se comunican con los servidores de API a través de la XENIs, y la comunicación de un pod a un servidor de API siempre utiliza el modo. IPv6

Recomendaciones

Programación basada en recursos informáticos

Un solo IPv6 prefijo 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, al usar 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 de IPv6 EKS.

((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 para 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 una red personalizada para solucionar el problema del IPv4 agotamiento, ya no será necesaria con IPv6 ella. 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.

Cápsulas Fargate en EKS/Cluster IPv6

EKS es compatible con IPv6 los pods que se ejecutan en Fargate. Los pods que se ejecutan en Fargate consumirán direcciones privadas enrutables de IPv6 VPC extraídas de los rangos CIDR IPv4 de la VPC (). IPv4 IPv6 En pocas palabras, estás a EKS/Fargate Pods cluster wide density will be limited to the available IPv4 and IPv6 addresses. It is recommended to size your dual-stack subnets/VPC CIDRs favor del crecimiento futuro. No podrás programar nuevos Fargate Pods si la subred subyacente no contiene una dirección disponible, independientemente de IPv6 las IPv4 direcciones disponibles.

Implemente el controlador Load Balancer Controller (LBC) de AWS

El controlador de servicios de Kubernetes integrado en el árbol original no es compatible. IPv6 Recomendamos utilizar la versión más reciente del complemento AWS Load Balancer Controller. El LBC solo implementará un NLB de doble pila o un ALB de doble pila si consume la definición de servicio/ingreso de Kubernetes correspondiente anotada con: y "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"

AWS Network Load Balancer no admite los tipos de direcciones de protocolo UDP de doble pila. Si tiene requisitos estrictos de baja latencia, transmisión en tiempo real, juegos en línea e IoT, le recomendamos que ejecute IPv4 clústeres. Para obtener más información sobre la gestión de las comprobaciones de estado de los servicios UDP, consulta la sección «Cómo enrutar el tráfico UDP a Kubernetes».