View a markdown version of this page

Modo prefijo para Linux - 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.

Modo prefijo para Linux

sugerencia

Explore las mejores prácticas a través de los talleres de Amazon EKS.

El CNI de Amazon VPC asigna prefijos de red a las interfaces de red de Amazon EC2 para aumentar la cantidad de direcciones IP disponibles para los nodos y aumentar la densidad de pods por nodo. Puede configurar la versión 1.9.0 o una versión posterior del complemento CNI de Amazon VPC para asignar CIDR de IPv4 e IPv6 en lugar de asignar direcciones IP secundarias individuales a las interfaces de red.

El modo de prefijo está habilitado de forma predeterminada en los clústeres de IPv6 y es la única opción admitida. El CNI de la VPC asigna un prefijo IPv6 /80 a una ranura de un ENI. Consulte la sección IPv6 de esta guía para obtener más información.

Con el modo de asignación de prefijos, el número máximo de interfaces de red elásticas por tipo de instancia sigue siendo el mismo, pero ahora puede configurar el CNI de Amazon VPC para asignar prefijos de dirección IPv4 de /28 (16 direcciones IP), en lugar de asignar direcciones IPv4 individuales a las ranuras de las interfaces de red. Cuando ENABLE_PREFIX_DELEGATION se establece en true, el CNI de VPC asigna una dirección IP a un pod a partir del prefijo asignado a un ENI. Siga las instrucciones que se mencionan en la guía del usuario de EKS para habilitar el modo Prefix IP.

ilustración de dos subredes de trabajo

El número máximo de direcciones IP que puede asignar a una interfaz de red depende del tipo de instancia. Cada prefijo que asigna a una interfaz de red cuenta como una dirección IP. Por ejemplo, una instancia c5.large tiene un límite de 10 direcciones IPv4 por interfaz de red. Cada interfaz de red de esta instancia tiene una dirección IPv4 principal. Si una interfaz de red no tiene direcciones IPv4 secundarias, puede asignar hasta 9 prefijos a la interfaz de red. Por cada dirección IPv4 adicional que asigne a una interfaz de red, puede asignar un prefijo menos a la interfaz de red. Consulte la documentación de AWS EC2 sobre las direcciones IP por interfaz de red por tipo de instancia y la asignación de prefijos a las interfaces de red.

Durante la inicialización del nodo de trabajo, el CNI de la VPC asigna uno o más prefijos al ENI principal. El CNI preasigna un prefijo para un inicio más rápido del pod, manteniendo un grupo activo. La cantidad de prefijos que deben guardarse en una piscina caliente se puede controlar configurando variables de entorno.

  • WARM_PREFIX_TARGET, el número de prefijos que se asignarán por encima de la necesidad actual.

  • WARM_IP_TARGET, el número de direcciones IP que se van a asignar por encima de las necesidades actuales.

  • MINIMUM_IP_TARGET, el número mínimo de direcciones IP que deben estar disponibles en cualquier momento.

  • WARM_IP_TARGETy MINIMUM_IP_TARGET si se establece, se WARM_PREFIX_TARGET anulará.

A medida que haya más Pods programados, se solicitarán prefijos adicionales para el ENI existente. En primer lugar, el CNI de la VPC intenta asignar un nuevo prefijo a un ENI existente. Si el ENI está al máximo de su capacidad, el CNI de la VPC intenta asignar un nuevo ENI al nodo. Se adjuntarán nuevos ENI hasta que se alcance el límite máximo de ENI (definido por el tipo de instancia). Cuando se adjunte un nuevo ENI, ipamd asignará uno o más prefijos necesarios para mantener la configuración WARM_PREFIX_TARGETWARM_IP_TARGET, y. MINIMUM_IP_TARGET

diagrama de flujo del procedimiento para asignar una IP a un pod

Recomendaciones

Utilice el modo de prefijo cuando

Utilice el modo prefijo si tiene problemas de densidad de pods en los nodos de trabajo. Para evitar errores de CNI de la VPC, te recomendamos examinar las subredes en busca de bloques de direcciones contiguos para ver si hay el prefijo /28 antes de migrar al modo prefijo. Consulte la sección «Utilice las reservas de subred para evitar la fragmentación de la subred (IPv4)» para obtener más información sobre las reservas de subred.

Para garantizar la compatibilidad con versiones anteriores, el límite máximo de pods está configurado para admitir el modo IP secundario. Para aumentar la densidad de pods, especifique el max-pods valor para Kubelet y --use-max-pods=false como datos de usuario de los nodos. Para obtener más información, consulte Cómo se determinan los MaxPods en la guía del usuario de Amazon EKS. Consulte la guía del usuario de EKS para ver, por ejemplo, los datos de usuario.

./max-pods-calculator.sh --instance-type m5.large --cni-version ``1.9``.0 --cni-prefix-delegation-enabled

El modo de asignación de prefijos es especialmente relevante para los usuarios de redes personalizadas del CNI, en las que el ENI principal no se utiliza para los pods. Con la asignación de prefijos, puedes seguir adjuntando más IP a casi todos los tipos de instancias de Nitro, incluso sin el ENI principal utilizado para los pods.

Evita el modo de prefijo cuando

Si la subred está muy fragmentada y no tiene suficientes direcciones IP disponibles para crear prefijos /28, evite usar el modo prefijo. Es posible que no se pueda adjuntar el prefijo si la subred desde la que se creó el prefijo está fragmentada (una subred muy utilizada con direcciones IP secundarias dispersas). Este problema se puede evitar creando una nueva subred y reservando un prefijo.

En el modo de prefijo, los pods comparten el grupo de seguridad asignado a los nodos de trabajo. Considera la posibilidad de usar grupos de seguridad para los pods si tienes algún requisito de seguridad para lograr el cumplimiento mediante la ejecución de aplicaciones con distintos requisitos de seguridad de red en recursos informáticos compartidos.

Usa tipos de instancias similares en el mismo grupo de nodos

Tu grupo de nodos puede contener instancias de muchos tipos. Si una instancia tiene un número máximo de pods bajo, ese valor se aplica a todos los nodos del grupo de nodos. Considera la posibilidad de usar tipos de instancias similares en un grupo de nodos para maximizar el uso de los nodos. Recomendamos configurar node.kubernetes. io/instance-escribe la parte de requisitos de la API de aprovisionamiento si utilizas Karpenter para el escalado automático de nodos.

aviso

El número máximo de pods para todos los nodos de un grupo de nodos determinado se define por el número máximo de pods más bajo de cualquier tipo de instancia individual del grupo de nodos.

Configure WARM_PREFIX_TARGET para conservar las direcciones IPv4

El valor predeterminado del manifiesto de instalación es 1. WARM_PREFIX_TARGET En la mayoría de los casos, el valor recomendado de 1 para WARM_PREFIX_TARGET proporcionará una buena combinación de tiempos de lanzamiento rápidos del pod y minimizará las direcciones IP no utilizadas asignadas a la instancia.

Si necesitas conservar aún más las direcciones IPv4 por nodo, el uso WARM_IP_TARGET y la MINIMUM_IP_TARGET configuración se anulan WARM_PREFIX_TARGET cuando se configuran. Si lo WARM_IP_TARGET estableces en un valor inferior a 16, puedes evitar que el CNI mantenga adjunto todo un prefijo sobrante.

Prefiere asignar nuevos prefijos en lugar de adjuntar un nuevo ENI

Asignar un prefijo adicional a un ENI existente es una operación más rápida de la API de EC2 que crear y adjuntar un ENI nuevo a la instancia. El uso de prefijos mejora el rendimiento y, al mismo tiempo, ahorra costes en la asignación de direcciones IPv4. La colocación de un prefijo normalmente se completa en menos de un segundo, mientras que la conexión de un nuevo ENI puede tardar hasta 10 segundos. En la mayoría de los casos de uso, el CNI solo necesitará un ENI por nodo de trabajo cuando se ejecute en modo prefijo. Si puede permitirse (en el peor de los casos) un máximo de 15 direcciones IP no utilizadas por nodo, le recomendamos encarecidamente que utilice el modo de red de asignación de prefijos más reciente y aproveche las ventajas de rendimiento y eficiencia que ello conlleva.

Utilice las reservas de subred para evitar la fragmentación de la subred (IPv4)

Cuando EC2 asigna un prefijo IPv4 /28 a un ENI, tiene que ser un bloque contiguo de direcciones IP de la subred. Si la subred desde la que se genera el prefijo está fragmentada (una subred muy utilizada con direcciones IP secundarias dispersas), es posible que no se pueda adjuntar el prefijo y que aparezca el siguiente mensaje de error en los registros CNI de la VPC:

failed to allocate a private IP/Prefix address: InsufficientCidrBlocks: There are not enough free cidr blocks in the specified subnet to satisfy the request.

Para evitar la fragmentación y disponer de suficiente espacio contiguo para crear prefijos, puedes usar las reservas CIDR de subred de la VPC para reservar el espacio de IP dentro de una subred para que lo usen exclusivamente los prefijos. Una vez que hayas creado una reserva, el complemento CNI de la VPC llamará a las API de EC2 para asignar prefijos que se asignan automáticamente desde el espacio reservado.

Se recomienda crear una subred nueva, reservar espacio para los prefijos y habilitar la asignación de prefijos con el CNI de la VPC a los nodos de trabajo que se ejecuten en esa subred. Si la nueva subred está dedicada solo a los pods que se ejecutan en tu clúster de EKS con la asignación de prefijos CNI de VPC habilitada, puedes omitir el paso de reserva de prefijos.

Evita degradar el CNI de la VPC

El modo Prefix funciona con la versión 1.9.0 y posteriores de VPC CNI. Debe evitarse cambiar el complemento CNI de Amazon VPC a una versión inferior a la 1.9.0 una vez que el modo de prefijo esté habilitado y los prefijos estén asignados a los ENI. Debe eliminar y volver a crear los nodos si decide cambiar el CNI de la VPC a una versión inferior.

Sustituya todos los nodos durante la transición a Prefix Delegation

Se recomienda encarecidamente crear nuevos grupos de nodos para aumentar la cantidad de direcciones IP disponibles, en lugar de reemplazar progresivamente los nodos de trabajo existentes. Acordona y drena todos los nodos existentes para desalojar de forma segura todos los pods existentes. Para evitar interrupciones en el servicio, te sugerimos implementar los presupuestos de interrupción de los módulos en tus clústeres de producción para las cargas de trabajo críticas. A los pods de los nodos nuevos se les asignará una IP a partir de un prefijo asignado a un ENI. Tras confirmar que los pods se están ejecutando, puedes eliminar los nodos y grupos de nodos antiguos. Si utilizas grupos de nodos gestionados, sigue los pasos que se mencionan aquí para eliminar un grupo de nodos de forma segura.