Optimización de la utilización de direcciones IP

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.

Gracias a la modernización de las aplicaciones, la escala de los entornos en contenedores está creciendo a un ritmo acelerado. Esto significa que se están desplegando cada vez más nodos y módulos de trabajo.

El complemento CNI de Amazon VPC asigna a cada pod una dirección IP de los CIDR de la VPC. Este enfoque proporciona una visibilidad total de las direcciones de los pods con herramientas como los registros de flujo de VPC y otras soluciones de monitoreo. Según el tipo de carga de trabajo, esto puede provocar que los pods consuman una cantidad considerable de direcciones IP.

Al diseñar la arquitectura de red de AWS, es importante optimizar el consumo de IP de Amazon EKS en la VPC y a nivel de nodo. Esto le ayudará a mitigar los problemas de agotamiento de la IP y a aumentar la densidad de los pods por nodo.

En esta sección, analizaremos las técnicas que pueden ayudarlo a alcanzar estos objetivos.

Optimice el consumo de IP a nivel de nodo

La delegación de prefijos es una función de Amazon Virtual Private Cloud (Amazon VPC) que le permite IPv4 asignar IPv6 o prefijos a sus instancias de Amazon Elastic Compute Cloud (Amazon EC2). Aumenta las direcciones IP por interfaz de red (ENI), lo que aumenta la densidad de pods por nodo y mejora la eficiencia informática. Las redes personalizadas también admiten la delegación de prefijos.

Para obtener información detallada, consulte las secciones Delegación de prefijos con nodos de Linux y Delegación de prefijos con nodos de Windows.

Mitigue el agotamiento de IP

Para evitar que sus clústeres consuman todas las direcciones IP disponibles, le recomendamos encarecidamente que ajuste el tamaño de sus subredes VPCs y de sus subredes teniendo en cuenta el crecimiento.

IPv6La adopción es una excelente manera de evitar estos problemas desde el principio. Sin embargo, para las organizaciones cuyas necesidades de escalabilidad superan la planificación inicial y no pueden adoptarlas IPv6, la respuesta recomendada al agotamiento de las direcciones IP es mejorar el diseño de la VPC. La técnica más utilizada entre los clientes de Amazon EKS consiste en añadir una dirección secundaria no enrutable CIDRs a la VPC y configurar la CNI de la VPC para que utilice este espacio IP adicional al asignar direcciones IP a los pods. Esto se conoce comúnmente como redes personalizadas.

Analizaremos qué variables del CNI de Amazon VPC puede utilizar para optimizar el pool caliente IPs asignado a sus nodos. Cerraremos esta sección con algunos otros patrones arquitectónicos que no son intrínsecos a Amazon EKS, pero que pueden ayudar a mitigar el agotamiento de la IP.

Uso IPv6 (recomendado)

La adopción IPv6 es la forma más sencilla de evitar las RFC1918 limitaciones; le recomendamos encarecidamente que considere la adopción IPv6 como primera opción a la hora de elegir una arquitectura de red. IPv6 proporciona un espacio total de direcciones IP considerablemente mayor, y los administradores de clústeres pueden centrarse en migrar y escalar las aplicaciones sin tener que esforzarse en evitar IPv4 los límites.

Los clústeres de Amazon EKS son compatibles IPv4 con y IPv6. De forma predeterminada, los clústeres EKS utilizan el espacio de IPv4 direcciones. Si se especifica un espacio de direcciones IPv6 basado en el momento de la creación del clúster, se permitirá el uso de IPv6. En un clúster de IPv6 EKS, los módulos y los servicios reciben IPv6 direcciones y, al mismo tiempo, mantienen la capacidad de los IPv4 puntos finales heredados de conectarse a los servicios que se ejecutan en IPv6 los clústeres y viceversa. Toda la pod-to-pod comunicación dentro de un clúster siempre se produce de forma interrumpida. IPv6 Dentro de una VPC (/56), el tamaño del bloque IPv6 CIDR para las IPv6 subredes se fija en /64. Esto proporciona 2^64 direcciones (aproximadamente 18 trillones), lo que permite escalar sus despliegues en EKS. IPv6

Para obtener información detallada, consulte la sección Cómo ejecutar clústeres de IPv6 EKS y, para obtener experiencia práctica, consulte la sección Comprensión IPv6 de Amazon EKS del taller Póngase manos a la obra. IPv6

Optimice el consumo de IP en IPv4 los clústeres

Esta sección está dedicada a los clientes que ejecutan aplicaciones antiguas o que no están preparados para migrar a ellas IPv6. Si bien animamos a todas las organizaciones a migrar a ellas lo antes IPv6 posible, reconocemos que es posible que algunas aún necesiten buscar enfoques alternativos para escalar sus cargas de trabajo en contenedores. IPv4 Por este motivo, también le mostraremos los patrones arquitectónicos para optimizar IPv4 (RFC1918) abordar el consumo de espacio con los clústeres de Amazon EKS.

Planifique su crecimiento

Como primera línea de defensa contra el agotamiento de la IP, recomendamos encarecidamente dimensionar las subredes IPv4 VPCs y las de sus subredes teniendo en cuenta el crecimiento, a fin de evitar que los clústeres consuman todas las direcciones IP disponibles. No podrás crear nuevos pods o nodos si las subredes no tienen suficientes direcciones IP disponibles.

Antes de crear la VPC y las subredes, se recomienda trabajar hacia atrás a partir de la escala de carga de trabajo requerida. Por ejemplo, cuando los clústeres se crean con eksctl (una sencilla herramienta CLI para crear y administrar clústeres en EKS), se crean 19 subredes de forma predeterminada. Una máscara de red de /19 es adecuada para la mayoría de los tipos de carga de trabajo, ya que permite asignar más de 8000 direcciones.

Además, Amazon EKS puede crear hasta 4 interfaces de red elásticas (X-ENI) necesarias para permitir la comunicación con el plano de control (más información aquí). Durante las actualizaciones de clústeres, Amazon EKS crea una nueva X ENIs y elimina las antiguas cuando la actualización se realiza correctamente. Por este motivo, recomendamos una máscara de red de al menos /28 (16 direcciones IP) para las subredes asociadas a un clúster de EKS.

Puede utilizar el ejemplo de la hoja de cálculo de la calculadora de subredes EKS para planificar su red. La hoja de cálculo calcula el uso de IP en función de las cargas de trabajo y la configuración ENI de la VPC. El uso de IP se compara con el de una IPv4 subred para determinar si la configuración y el tamaño de la subred son suficientes para la carga de trabajo. Tenga en cuenta que, si las subredes de su VPC se quedan sin direcciones IP disponibles, le sugerimos que cree una nueva subred con los bloques CIDR originales de la VPC. Observe que ahora Amazon EKS permite la modificación de subredes de clústeres y grupos de seguridad.

Redes personalizadas

Si estás a punto de agotar el espacio RFC1918 IP, puedes usar el patrón de redes personalizadas para conservar la capacidad de enrutamiento IPs programando los pods dentro de subredes adicionales dedicadas. Si bien las redes personalizadas aceptan un rango de VPC válido como rango de CIDR secundario, le recomendamos que utilice CIDRs (/16) desde el espacio CG-NAT, es decir100.64.0.0/10, 198.19.0.0/16 ya que es menos probable que se usen en un entorno corporativo que los rangos. RFC1918

Para obtener información detallada, consulte la sección dedicada a las redes personalizadas.

Descubrimiento de subredes mejorado

La detección de subredes mejorada ofrece una alternativa de configuración de red simplificada para el agotamiento de la IP, ya que etiqueta las nuevas subredes para que el CNI de Amazon VPC las pueda detectar. Con la detección mejorada de subredes, las cargas de trabajo actuales pueden seguir ejecutándose en las mismas subredes y Amazon Elastic Kubernetes Service (Amazon EKS) ahora puede programar pods adicionales en las nuevas «subredes utilizables».

Si las subredes actuales de su clúster se están quedando sin direcciones IP, simplemente puede añadir subredes adicionales a su clúster de Amazon EKS de la siguiente manera:

Una vez que la detección mejorada de subredes esté habilitada en los clústeres de Amazon EKS y VPC, se conectarán nuevas interfaces de red elásticas ENIs () a los nodos de Amazon EKS, tal y como se describe en el siguiente diagrama:

Para obtener más información, consulte Amazon VPC CNI presenta la detección mejorada de subredes en el blog sobre contenedores de AWS.

Optimice la piscina caliente IPs

Con la configuración predeterminada, el CNI de VPC mantiene un ENI completo (y el asociado IPs) en la piscina caliente. Esto puede consumir una gran cantidad de IPs, especialmente en los tipos de instancias más grandes.

Si la subred de su clúster tiene un número limitado de direcciones IP disponibles, analice estas variables del entorno de configuración de la CNI de la VPC:

Puedes configurar el valor de MINIMUM_IP_TARGET para que coincida estrechamente con la cantidad de pods que esperas ejecutar en tus nodos. Si lo haces, te asegurarás de que, a medida que se creen los pods, el CNI pueda asignar direcciones IP desde el pool caliente sin necesidad de llamar a la EC2 API.

Ten en cuenta que si estableces un valor WARM_IP_TARGET demasiado bajo, se generarán más llamadas a la EC2 API y se podrían limitar las solicitudes. En el caso de clústeres grandes, úsalo junto con MINIMUM_IP_TARGET para evitar la limitación de las solicitudes.

Para configurar estas opciones, puedes descargar el aws-k8s-cni.yaml manifiesto y configurar las variables de entorno. En el momento de escribir este artículo, la última versión se encuentra aquí. Compruebe que la versión del valor de configuración coincida con la versión CNI de la VPC instalada.

Puede ajustar los parámetros de la CNI sobre la marcha sin tiempo de inactividad para sus aplicaciones existentes, pero debe elegir valores que se adapten a sus necesidades de escalabilidad. Por ejemplo, si trabajas con cargas de trabajo por lotes, te recomendamos actualizar los valores predeterminados WARM_ENI_TARGET para que se ajusten a las necesidades de la báscula de Pod. Si WARM_ENI_TARGET se establece un valor alto, siempre se mantiene el conjunto de IP caliente necesario para ejecutar grandes cargas de trabajo por lotes y, por lo tanto, se evitan retrasos en el procesamiento de datos.

Supervise el inventario de direcciones IP

Además de las soluciones descritas anteriormente, también es importante tener visibilidad sobre la utilización de IP. Puede supervisar el inventario de direcciones IP de las subredes mediante CNI Metrics Helper. Algunas de las métricas disponibles son:

También puede configurar CloudWatch alarmas para recibir notificaciones si una subred se está quedando sin direcciones IP.

Consideraciones adicionales

Existen otros patrones arquitectónicos que no son intrínsecos a Amazon EKS y que pueden ayudar a reducir la IP. Por ejemplo, puede optimizar la comunicación VPCs o compartir una VPC entre varias cuentas para limitar la asignación de IPv4 direcciones.

Obtenga más información sobre estos patrones aquí: