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.

Optimización del uso de direcciones IP

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

El complemento CNI de Amazon VPC asigna a cada pod una dirección IP desde 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 la VPC y otras soluciones de monitorización. En función del tipo de carga de trabajo, esto puede provocar que los pods consuman una cantidad considerable de direcciones IP.

Al diseñar la arquitectura de redes 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 propiedad intelectual y a aumentar la densidad de pods por nodo.

En esta sección, analizaremos las técnicas que pueden ayudarlo a lograr 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 asignar prefijos IPv4 o IPv6 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. La delegación de prefijos también es compatible con las redes personalizadas.

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.

Mitigación del riesgo de agotamiento de la IP

Para evitar que los clústeres consuman todas las direcciones IP disponibles, te recomendamos encarecidamente que dimensiones tus VPC y subredes teniendo en cuenta el crecimiento.

La adopción de IPv6 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 adoptar IPv6, la respuesta recomendada en caso de que se agoten las direcciones IP es mejorar el diseño de la VPC. La técnica más utilizada entre los clientes de Amazon EKS es añadir CIDR secundarios no enrutables a la VPC y configurar el 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. Redes personalizadas

Analizaremos qué variables del CNI de Amazon VPC puede utilizar para optimizar el conjunto de direcciones IP asignadas a sus nodos. Concluiremos esta sección con otros patrones arquitectónicos que no son intrínsecos a Amazon EKS, pero que pueden ayudar a mitigar el agotamiento de la propiedad intelectual.

Utilice IPv6 (recomendado)

Adoptar IPv6 es la forma más fácil de evitar las limitaciones de la RFC1918; le recomendamos encarecidamente que considere la posibilidad de adoptar 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 la migración y el escalado de las aplicaciones sin tener que dedicar esfuerzos a eludir los límites de IPv4.

Los clústeres de Amazon EKS admiten tanto IPv4 como IPv6. De forma predeterminada, los clústeres de EKS utilizan el espacio de direcciones IPv4. La especificación de un espacio de direcciones basado en IPv6 en el momento de la creación del clúster permitirá el uso de IPv6. En un clúster EKS de IPv6, los pods y los servicios reciben direcciones IPv6 y, al mismo tiempo, mantienen la capacidad de los terminales IPv4 antiguos de conectarse a los servicios que se ejecutan en clústeres de IPv6 y viceversa. Toda la comunicación de un pod a otro dentro de un clúster siempre se produce a través de IPv6. En una VPC (/56), el tamaño del bloque CIDR de IPv6 para las subredes IPv6 se fija en /64. Esto proporciona 2^64 (aproximadamente 18 trillones) de direcciones IPv6 que permiten escalar las implementaciones en EKS.

Para obtener información detallada, consulte la sección Cómo ejecutar clústeres EKS con IPv6 y, para obtener experiencia práctica, consulte la sección Cómo entender IPv6 en Amazon EKS del taller Cómo usar IPv6. https://catalog.workshops.aws/ipv6-on-aws/en-US

Optimice el consumo de IP en los clústeres IPv4

Esta sección está dedicada a los clientes que utilizan aplicaciones antiguas y no and/or están preparados para migrar a IPv6. Si bien alentamos a todas las organizaciones a migrar a IPv6 lo antes posible, reconocemos que es posible que algunas aún tengan que buscar enfoques alternativos para escalar sus cargas de trabajo de contenedores con IPv4. Por este motivo, también le explicaremos los patrones arquitectónicos necesarios para optimizar el consumo de espacio de IPv4 (RFC1918) con los clústeres de Amazon EKS.

Planifique el crecimiento

Como primera línea de defensa contra el agotamiento de la IP, recomendamos encarecidamente que dimensione sus VPC y subredes IPv4 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 a la inversa partiendo de la escala de carga de trabajo requerida. Por ejemplo, cuando los clústeres se crean con eksctl (una sencilla herramienta de 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í). Consideraciones sobre la VPC y la subred Durante las actualizaciones de los clústeres, Amazon EKS crea nuevos clústeres X-ENIs y elimina los antiguos 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 usar el ejemplo de hoja de cálculo de la calculadora de subredes de 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 de la ENI de la VPC. El uso de IP se compara con el de una subred IPv4 para determinar si la configuración y el tamaño de la subred son suficientes para su 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 de CIDR originales de la VPC. Tenga en cuenta que ahora Amazon EKS permite la modificación de las subredes y los grupos de seguridad del clúster.

Redes personalizadas

Si estás a punto de agotar el espacio IP de la RFC1918, puedes usar el patrón de red personalizado para conservar las IP enrutables programando los pods dentro de subredes adicionales dedicadas. Si bien las redes personalizadas aceptarán un rango de VPC válido para el rango de CIDR secundario, te recomendamos que utilices los CIDR del espacio de direcciones 100.64.0.0/10 compartido (RFC 6598), ya que es menos probable que se usen en un entorno corporativo que los rangos de la RFC1918. Por ejemplo, puedes usarlo 100.64.0.0/16 como un CIDR secundario para tu VPC. Consulta las restricciones de asociación de bloques de CIDR de IPv4 para conocer los rangos de CIDR secundarios permitidos.

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 optimizada para el agotamiento de la IP, ya que etiqueta las nuevas subredes para que el CNI de Amazon VPC las pueda detectar. CNI de Amazon VPC Con la detección de subredes mejorada, 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 sus clústeres de VPC y Amazon EKS, las nuevas interfaces de red elástica (ENI) se adjuntarán 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 de contenedores de AWS.

Optimice la piscina caliente de la IP

Con la configuración predeterminada, el CNI de la VPC mantiene una ENI completa (y las IP asociadas) en la piscina caliente. Esto puede consumir una gran cantidad de direcciones IP, especialmente en los tipos de instancias más grandes.

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

Puedes configurar el valor de MINIMUM_IP_TARGET para que coincida con la cantidad de pods que esperas que se ejecuten en tus nodos. De este modo, te asegurarás de que, a medida que se vayan creando los pods, el CNI pueda asignar direcciones IP desde el grupo activo sin necesidad de llamar a la API de EC2.

Ten en cuenta que si se establece un valor WARM_IP_TARGET demasiado bajo, se generarán más llamadas a la API de EC2, lo que podría provocar la limitación de las solicitudes. En el caso de clústeres grandes, utilízalo 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 versión más reciente se encuentra aquí. Compruebe que la versión del valor de configuración coincide con la versión CNI de la VPC instalada.

Puede ajustar los parámetros del CNI sobre la marcha sin tiempo de inactividad para sus aplicaciones actuales, 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 la configuración predeterminada WARM_ENI_TARGET para adaptarla a las necesidades de la escala de módulos. Si WARM_ENI_TARGET se establece un valor alto, siempre se mantiene el grupo de IP activo necesario para ejecutar grandes cargas de trabajo por lotes y, por lo tanto, evitar demoras 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 la 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 contribuir al agotamiento de la propiedad intelectual. Por ejemplo, puede optimizar la comunicación entre las VPC o compartir una VPC entre varias cuentas para limitar la asignación de direcciones IPv4.

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