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 de prefijo para Windows
En Amazon EKS, el controlador de recursos de la VPC asigna de forma predeterminada una dirección IP secundaria a cada pod que se ejecuta en un host
Para aumentar la densidad de pods en los hosts de Windows, especialmente cuando se utilizan tipos de instancia más pequeños, puede habilitar la delegación de prefijos para los nodos de Windows. Cuando la delegación de prefijos está habilitada, los prefijos /28 IPv4 se asignan a las ranuras ENI en lugar de a las direcciones IP secundarias. La delegación de prefijos se puede habilitar agregando la enable-windows-prefix-delegation: "true" entrada al mapa de configuración. amazon-vpc-cni Este es el mismo mapa de configuración en el que debe configurar la enable-windows-ipam: "true" entrada para habilitar la compatibilidad con Windows.
Siga las instrucciones mencionadas en la guía del usuario de EKS para habilitar el modo de delegación de prefijos para los nodos de Windows.
Figura: Comparación del modo IP secundario con el modo de delegación de prefijos
La cantidad máxima de direcciones IP que puede asignar a una interfaz de red depende del tipo de instancia y de su tamaño. Cada prefijo asignado a una interfaz de red consume una ranura disponible. Por ejemplo, una c5.large instancia tiene un límite de 10 ranuras por interfaz de red. La primera ranura de una interfaz de red siempre la ocupa la dirección IP principal de la interfaz, lo que deja 9 ranuras para los prefijos de las direcciones IP and/or secundarias. Si a estas ranuras se les asignan prefijos, el nodo puede admitir 144 direcciones IP (9 x 16), mientras que si se les asignan direcciones IP secundarias, solo puede admitir 9 direcciones IP. Consulta la documentación sobre las direcciones IP por interfaz de red por tipo de instancia y sobre la asignación de prefijos a las interfaces de red para obtener más información.
Durante la inicialización de los nodos de trabajo, el controlador de recursos de la VPC asigna uno o más prefijos al ENI principal para acelerar el inicio del pod, ya que mantiene un conjunto activo de direcciones IP. La cantidad de prefijos que deben guardarse en un grupo activo se puede controlar mediante la configuración de los siguientes parámetros de configuración en el mapa de configuración. amazon-vpc-cni
-
warm-prefix-target, la cantidad de prefijos que se van a asignar supera 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-targetand/orminimum-ip-targetsi se establece, sewarm-prefix-targetanulará.
A medida que se programen más pods en el nodo, se solicitarán prefijos adicionales para el ENI existente. Cuando se programa un pod en el nodo, el controlador de recursos de la VPC primero intentará asignar una dirección IPv4 a partir de los prefijos existentes en el nodo. Si esto no es posible, se solicitará un nuevo prefijo IPv4 siempre que la subred tenga la capacidad requerida.
Figura: Flujo de trabajo durante la asignación de la dirección IPv4 al pod
Recomendaciones
Utilice la delegación de prefijos cuando
Usa la delegación de prefijos si tienes problemas de densidad de pods en los nodos de trabajo. Para evitar errores, recomendamos examinar las subredes en busca de bloques de direcciones contiguos con 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.
De forma predeterminada, los nodos de Windows max-pods están configurados en. 110 Para la gran mayoría de los tipos de instancias, esto debería ser suficiente. Si quieres aumentar o reducir este límite, agrega lo siguiente al comando bootstrap en tus datos de usuario:
-KubeletExtraArgs '--max-pods=example-value'
Para obtener más información sobre los parámetros de configuración del arranque para los nodos de Windows, consulta la documentación aquí.
Evite la delegación de prefijos 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.
Configure los parámetros de la delegación de prefijos para conservar las direcciones IPv4
warm-prefix-targetwarm-ip-target, y se minimum-ip-target puede usar para ajustar con precisión el comportamiento del preescalado y del escalado dinámico con prefijos. De forma predeterminada, se utilizan los siguientes valores:
warm-ip-target: "1" minimum-ip-target: "3"
Al ajustar con precisión estos parámetros de configuración, puedes lograr un equilibrio óptimo entre conservar las direcciones IP y garantizar una disminución de la latencia de los pods debido a la asignación de direcciones IP. Para obtener más información sobre estos parámetros de configuración, consulta la documentación aquí
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 se produzca el siguiente evento de nodo:
InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request
Para evitar la fragmentación y disponer de suficiente espacio contiguo para crear prefijos, usa las reservas CIDR de subred de la VPC para reservar el espacio IP dentro de una subred para que los prefijos lo usen exclusivamente. Una vez que hayas creado una reserva, las direcciones IP de los bloques reservados no se asignarán a otros recursos. De este modo, el controlador de recursos de la VPC podrá obtener los prefijos disponibles durante la llamada de asignación al ENI del nodo.
Se recomienda crear una subred nueva, reservar espacio para los prefijos y habilitar la asignación de prefijos 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 delegación de prefijos habilitada, puedes omitir el paso de reserva de prefijos.
Sustituya todos los nodos al migrar del modo de IP secundaria al modo de delegación de prefijos o viceversa
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.
Al usar grupos de nodos autogestionados, los pasos para la transición serían los siguientes:
-
Aumente la capacidad de su clúster para que los nuevos nodos puedan adaptarse a sus cargas de trabajo
-
Enable/Disable la función de delegación de prefijos para Windows
-
Acordona y drena todos los nodos existentes para desalojar de forma segura todos tus 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. -
Tras confirmar que los pods se están ejecutando, puedes eliminar los nodos y grupos de nodos antiguos. A los pods de los nodos nuevos se les asignará una dirección IPv4 a partir de un prefijo asignado al ENI del nodo.
Al usar grupos de nodos administrados, los pasos para la transición serían los siguientes:
-
Enable/Disable la función de delegación de prefijos para Windows
-
Actualice el grupo de nodos siguiendo los pasos que se mencionan aquí. Esto lleva a cabo pasos similares a los anteriores, pero son gestionados por EKS.
aviso
Ejecuta todos los pods de un nodo en el mismo modo
En el caso de Windows, te recomendamos que evites ejecutar los pods en el modo de IP secundaria y en el modo de delegación de prefijos al mismo tiempo. Esta situación puede producirse al migrar del modo de IP secundaria al modo de delegación de prefijos o viceversa con cargas de trabajo de Windows en ejecución.
Si bien esto no afectará a los pods en ejecución, puede haber incoherencias con respecto a la capacidad de direcciones IP del nodo. Por ejemplo, consideremos que un nodo t3.xlarge tiene 14 ranuras para direcciones IPv4 secundarias. Si tiene 10 pods, las direcciones IP secundarias consumirán 10 ranuras del ENI. Tras habilitar la delegación de prefijos, la capacidad anunciada en el servidor kube-api sería de 244 (14 ranuras * 16 direcciones IP por prefijo), pero la capacidad real en ese momento sería de 64 (4 ranuras restantes * 16 direcciones por prefijo). Esta incoherencia entre la cantidad de capacidad anunciada y la cantidad real de capacidad (ranuras restantes) puede provocar problemas si ejecutas más pods de los que hay direcciones IP disponibles para su asignación.
Dicho esto, puedes usar la estrategia de migración descrita anteriormente para hacer una transición segura de tus pods desde una dirección IP secundaria a direcciones obtenidas mediante prefijos. Al cambiar de un modo a otro, los Pods seguirán funcionando con normalidad y:
-
Al cambiar del modo IP secundario al modo de delegación de prefijos, no se publicarán las direcciones IP secundarias asignadas a los pods en ejecución. Se asignarán prefijos a los espacios libres. Una vez que un pod haya terminado, se liberarán la IP secundaria y la ranura que estaba usando.
-
Al cambiar del modo de delegación de prefijos al modo de IP secundaria, se liberará un prefijo cuando todas las IP de su rango dejen de estar asignadas a los pods. Si se asigna alguna IP del prefijo a un pod, ese prefijo se mantendrá hasta que los pods terminen.
Problemas de depuración relacionados con la delegación de prefijos
Puedes usar nuestra guía de depuración aquí
