IPv6 Ejecución de clústeres de EKS - Amazon 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.

IPv6 Ejecución de clústeres de EKS

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 finales externos accedan a los servicios del clúster y los pods accedan a los puntos finales 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. En ese caso, la VPC se denomina VPC de doble pila. En el siguiente diagrama se muestra el patrón básico de la IPV4 IPv6 VPC que admite clústeres basados en EKS/: IPv6

VPC de doble pila

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

VPC de doble pila

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/:

VPC de doble pila

Descripción general de

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 instancias EC2 basadas en Nitro, por lo que solo se admite EKS/IPv6 cuando el plano de datos del clúster utiliza instancias EC2 basadas en Nitro.

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

ilustración de una subred de trabajadores

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 trabajador y no se anuncia fuera del nodo trabajador. 169.254.172.0/22 proporciona hasta 1024 direcciones únicas que admiten tipos de instancias grandes. IPv4

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

EKS/ IPv6

En el diagrama anterior, Pods realizará 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 nodo de trabajo de EC2.

nota

El patrón anterior requiere DNS64 que esté deshabilitado en las subredes en las que se estén ejecutando los EKS/ Pods. IPv6 Cuando DNS64 está activado, el solucionador de DNS devuelve una IPv6 dirección sintetizada para los puntos finales IPv4 exclusivos junto con una dirección. IPv4 Como resultado, el tráfico se enruta a través de la NAT64 funcionalidad 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.

Los IPv6 EKS/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):

EKS/ IPv6

En el diagrama anterior, Pods realizará 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 nodo de trabajo de EC2. 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 enrutable a 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:

EKS/ IPv6

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, es decir, 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:

IPv4 Usuario de Internet que utiliza el servicio EKS/ Ingress IPv6
nota

El patrón anterior requiere implementar la versión más reciente del controlador de balanceador de carga de AWS

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

ilustración del clúster que incluye X- ENIs

Recomendaciones

Programación basada en recursos de cómputo

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

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, la densidad de su clúster de EKS/Fargate Pods se limitará a las direcciones y direcciones disponibles. IPv4 IPv6 Se recomienda dimensionar su pila doble subnets/VPC CIDRs para un futuro crecimiento. 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 kubernetes correspondiente anotada con: y service/ingress "alb.ingress.kubernetes.io/ip-address-type: dualstack" "alb.ingress.kubernetes.io/target-type: ip"