IPv6EKSClústeres en ejecución - 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.

IPv6EKSClústeres en ejecución

EKSEl IPv6 modo in resuelve el desafío de IPv4 agotamiento que a menudo se manifiesta en EKS los clústeres a gran escala. EKSSu apoyo 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, lo que minimizará las posibilidades de que se produzcan CIDR solapamientos y, IPv6 CIDRs por lo tanto, resolverá un problema doble (dentro del clúster, entre clústeres). Cuando se despliegan EKS clústeres en IPv6 modo (--ip-family ipv6), la acción no es reversible. En pocas palabras, el EKS IPv6 soporte está habilitado durante toda la vida útil del clúster.

En un IPv6 EKS clúster, 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 EKS IPv6 soporte de Amazon aprovecha las VPC IPv6 capacidades nativas. A cada una de ellas VPC se le asigna un prefijo de IPv4 dirección (el tamaño del CIDR bloque puede oscilar entre /16 y /28) y un prefijo de IPv6 dirección único /56 (fijo) dentro de Amazon (dirección de unidifusión global); usted puede asignar un prefijo de dirección /64 a cada subred de su red. GUA VPC IPv4las funciones, como las tablas de enrutamiento, las listas de control de acceso a la red, el emparejamiento y DNS la resolución, funcionan de la misma manera si están habilitadas. IPv6 VPC En este VPC casoVPC, se denomina de doble pila. Después de las subredes de doble pila, el siguiente diagrama muestra el patrón IPV4 y IPv6 VPC base que admiten los clústeres basados en/: EKS IPv6

Pila doble VPC

En el IPv6 mundo, todas las direcciones son enrutables a Internet. De forma predeterminada, VPC se asigna IPv6 CIDR desde el rango público. GUA VPCsno admiten la asignación de IPv6 direcciones privadas del rango de direcciones locales únicas (ULA) definido en RFC 4193 (fd00: :/8 o fc00: :/8). Esto es cierto incluso si desea asignar una propiedad suya. IPv6 CIDR Se permite la salida a Internet desde subredes privadas mediante la implementación de una pasarela de Internet solo de salida (EIGW) en unVPC, que permite el tráfico saliente y bloquea todo el tráfico entrante. El siguiente diagrama muestra el flujo de salida de Internet de un pod dentro de un clúster/IPv6: EKS IPv6

Pila doble VPC

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

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

Pila doble VPC

Información general

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

La asignación de prefijos solo funciona en EC2 instancias basadas en Nitro, por lo queEKS/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

IPv6la asignación de prefijos solo se produce en el momento del arranque del nodo trabajador. EKS Se sabe que este comportamiento mitiga las situaciones en las que la alta rotación de los pods o IPv4 los EKS clústeres suelen retrasarse en la programación de los pods debido a la limitación de las API llamadas generadas por el VPC CNI complemento (ipamd) con el objetivo de asignar direcciones privadas de forma puntual. IPv4 También es conocido por hacer que los botones avanzados del CNI complemento WARM ajusten VPC _IP/, _IP innecesariamente. ENI MINIMUM

El siguiente diagrama amplía una interfaz de red elástica de nodo de IPv6 trabajo (): ENI

ilustración de una subred de trabajadores

A cada EKS nodo trabajador se le asignan IPv6 direcciones IPv4 y entradas correspondientes. DNS Para un nodo trabajador determinado, solo se consume una IPv4 dirección de la subred de doble pila. EKSEl soporte para IPv6 le permite comunicarse con los IPv4 puntos finales (localesAWS, por Internet) a través de un modelo muy obstinado de solo salida. IPv4 EKSimplementa un CNI complemento local del host, secundario al complemento, que asigna y configura una VPC CNI dirección para un pod. IPv4 El CNI complemento configura una dirección no IPv4 enrutable específica del host para un pod del rango 169.254.172.0/22. 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 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

EKS/IPv6

En el diagrama anterior, los Pods realizarán una DNS búsqueda del punto final y, al recibir una respuesta IPv4 «A», la IPv4 dirección única del Pod, exclusiva del nodo, se traducirá mediante la traducción de la dirección de red de origen (SNAT) a la dirección privada IPv4 (VPC) de la interfaz de red principal conectada al nodo de trabajo. EC2

EKS/IPv6Los 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, los Pods realizarán una DNS búsqueda del punto final y, al recibir una respuesta IPv4 «A», la IPv4 dirección única del Pod, exclusiva del nodo, se traducirá mediante la traducción de la dirección de red de origen (SNAT) a la dirección privada IPv4 (VPC) de la interfaz de red principal conectada al nodo de trabajo. EC2 Luego, la IPv4 dirección del pod (fuenteIPv4: IP EC2 principal) se enruta a la IPv4 NAT puerta de enlace, donde la IP EC2 principal se traduce (SNAT) en una dirección IP pública enrutable a Internet válida (IP IPv4 pública asignada a la NAT puerta de enlace).

Cualquier Pod-to-Pod comunicación entre los nodos siempre utiliza una IPv6 dirección. VPCCNIconfigura iptables para que gestione y IPv6 bloquee cualquier IPv4 conexión.

Los servicios de Kubernetes solo recibirán direcciones IPv6 (ClusteriP) de direcciones unidifusión locales únicas (). IPv6 ULA El ULA servicio de CIDR un IPv6 clúster se asigna automáticamente durante la etapa de creación del EKS clúster 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 carga. 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. Puedes 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 están en subredes privadas. El siguiente diagrama muestra a un IPv4 usuario de Internet que accede a un servicio basado en EKS IPv6 /Ingress:

IPv4Usuario de Internet al servicioEKS/Ingress IPv6
nota

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

EKSComunicación entre el plano de control y el plano de datos

EKSaprovisionará 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 un hostNetwork modo 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

Mantenga el acceso a IPv4 EKS APIs

EKSAPIsson accesibles IPv4 únicamente por. Esto también incluye el API punto final del clúster. No podrá acceder a los puntos finales del clúster ni IPv6 solo APIs desde una red. Es necesario que su red admita (1) un mecanismo de IPv6 transición, comoNAT64/, DNS64 que facilite la comunicación entre los IPv4 hosts IPv6 y (2) un DNS servicio que admita la traducción de los puntos IPv4 finales.

Programe en función de los recursos informáticos

Un solo IPv6 prefijo es suficiente para ejecutar varios pods en un solo nodo. Esto también elimina ENI eficazmente las limitaciones de IP en la cantidad máxima 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 el m5.large, es probable que se agoten los recursos de la instancia CPU y de memoria mucho antes de agotar sus direcciones IP. Debes establecer manualmente el valor máximo de pod EKS recomendado si utilizas grupos de nodos autogestionados o un grupo de nodos gestionado con un identificador personalizado. AMI

Puedes usar la siguiente fórmula para determinar la cantidad máxima de pods que puedes implementar en un nodo de un IPv6 EKS clúster.

((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 EKS el valor recomendado 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 conIPv6. Si ha optado por utilizar una red personalizada para solucionar el problema del IPv4 agotamiento, ya no es necesaria. IPv6 Si utilizas una red personalizada para cumplir un requisito de seguridad, como una red independiente para nodos y pods, te recomendamos que envíes una solicitud de EKS hoja de ruta.

Fargate Pods en /Cluster EKS IPv6

EKSes compatible con IPv6 los Pods que se ejecutan en Fargate. Los pods que se ejecuten en Fargate IPv6 consumirán IPv4 direcciones privadas VPC enrutables extraídas de los VPC CIDR rangos (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 AWS Load Balancer () LBC

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. Solo LBC implementará una pila doble NLB o una pila doble ALB si se 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"

AWSNetwork Load Balancer no admite tipos de direcciones de UDP protocolo 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 UDP los servicios, consulta la sección «Cómo dirigir el UDP tráfico a Kubernetes».

📝 Edita esta página en GitHub