Aumentar la cantidad de direcciones IP disponibles para sus nodos de Amazon EC2 - Amazon EKS

Ayude a mejorar esta página

¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.

Aumentar la cantidad de direcciones IP disponibles para sus nodos de Amazon EC2

Cada instancia de Amazon EC2 admite una cantidad máxima de interfaces de red elásticas y una cantidad máxima de direcciones IP que se pueden asignar a cada interfaz de red. Cada nodo requiere una dirección IP para cada interfaz de red. Se pueden asignar todas las demás direcciones IP disponibles a Pods. Cada uno Pod requiere su propia dirección IP. Como resultado, es posible que tenga nodos que tengan recursos informáticos y de memoria disponibles, pero que no puedan acomodar Pods adicionales porque el nodo se quedó sin direcciones IP para asignar a Pods.

En este tema, aprenderá a aumentar significativamente la cantidad de direcciones IP que los nodos pueden asignar a Pods mediante la asignación de prefijos de IP, en lugar de asignar direcciones IP secundarias individuales a sus nodos. Cada prefijo incluye varias direcciones IP. Si no configura su clúster para la asignación de prefijos IP, debe realizar más llamadas a la interfaz de programación de aplicaciones (API) de Amazon EC2 para configurar las interfaces de red y las direcciones IP necesarias para la conectividad Pod. A medida que los clústeres crecen a tamaños más grandes, la frecuencia de estas llamadas a la API puede generar tiempos de lanzamiento de instancias y Pod más prolongados. Esto causa retrasos en el escalado para satisfacer la demanda de cargas de trabajo grandes y exigentes, y agrega costos y gastos generales de administración, ya que necesita aprovisionar clústeres y VPC adicionales para cumplir con los requisitos de escalado. Para obtener más información, consulte Umbrales de escalabilidad de Kubernetes en GitHub.

Consideraciones

  • Cada tipo de instancia de Amazon EC2 admite una cantidad máxima de Pods. Si el grupo de nodos administrado consta de varios tipos de instancias, el número de Pods máximo menor de una instancia del clúster se aplica a todos los nodos del clúster.

  • De forma predeterminada, el número máximo de Pods que puede ejecutar en un nodo es 110, pero puede cambiar ese número. Si cambia el número y tiene un grupo de nodos administrado existente, la siguiente AMI o la actualización de la plantilla de lanzamiento de su grupo de nodos generará nuevos nodos con el valor modificado.

  • Al pasar de la asignación de direcciones IP a la asignación de prefijos de IP, le recomendamos que cree nuevos grupos de nodos para aumentar la cantidad de direcciones IP disponibles, en lugar de realizar un reemplazo gradual de los nodos existentes. La ejecución de Pods en un nodo que tiene direcciones IP y prefijos asignados puede generar inconsistencias en la capacidad de direcciones IP anunciada, lo que afecta las futuras cargas de trabajo en el nodo. Para conocer la forma recomendada de realizar la transición, consulte Reemplazar todos los nodos durante la migración del modo de IP secundaria al modo de delegación de prefijo o viceversa en la guía de prácticas recomendadas de Amazon EKS.

  • Solo para clústeres con nodos Linux.

    • Una vez que configura el complemento para asignar prefijos a las interfaces de red, no puede degradar su complemento Amazon VPC CNI plugin for Kubernetes a una versión anterior a 1.9.0 (o 1.10.1) sin eliminar todos los nodos en todos los grupos de nodos en su clúster.

    • Si también utiliza grupos de seguridad para Pods, con POD_SECURITY_GROUP_ENFORCING_MODE = standard y AWS_VPC_K8S_CNI_EXTERNALSNAT =false, cuando se Pods comunica con puntos de conexión fuera de su VPC, se utilizan los grupos de seguridad del nodo, en lugar de cualquier grupo de seguridad que haya asignado a su Pods.

      Si también utiliza grupos de seguridad para Pods, con POD_SECURITY_GROUP_ENFORCING_MODE =strict, cuando su Pods se comunica con puntos de conexión fuera de su VPC, se utilizan los grupos de seguridad Pod's.

Requisitos previos

  • Un clúster existente. Para implementar uno, consulte Creación de un clúster de Amazon EKS.

  • Las subredes en las que se encuentran sus nodos de Amazon EKS deben tener suficientes bloques contiguos /28 (para clústeres IPv4) o /80 (para clústeres IPv6) enrutamiento entre dominios sin clases (CIDR). Solo puede tener nodos Linux en un clúster IPv6. El uso de prefijos IP puede fallar si las direcciones IP están dispersas por toda la subred CIDR. Le recomendamos lo siguiente:

    • Utilizar una reserva CIDR de subred para que, aunque se siga utilizando alguna dirección IP dentro del rango reservado, una vez publicada, no se reasignen las direcciones IP. Esto garantiza que los prefijos estén disponibles para su asignación sin segmentación.

    • Utilice nuevas subredes que se usen específicamente para ejecutar las cargas de trabajo a las que se asignan los prefijos IP. Tanto las cargas de trabajo Windows como las Linux pueden ejecutarse en la misma subred cuando se asignan prefijos de IP.

  • Para asignar prefijos de IP a sus nodos, sus nodos deben estar basados en AWS Nitro. Las instancias que no están basadas en Nitro continúan asignando direcciones IP secundarias individuales, pero tienen una cantidad significativamente menor de direcciones IP para asignar a las instancias Pods que las instancias Nitro-based.

  • Solo para clústeres con nodos Linux: si su clúster está configurado para la familia IPv4, debe tener instalada la versión 1.9.0 o posterior del complemento Amazon VPC CNI plugin for Kubernetes. Puede comprobar su versión actual con el siguiente comando.

    kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

    Si su clúster está configurado para la familia IPv6, debe tener instalada la versión 1.10.1 o del complemento. Si la versión de su complemento es anterior a las versiones requeridas, debe actualizarlo. Para obtener más información, consulte las secciones de actualización de Trabajar con el complemento Amazon VPC CNI plugin for Kubernetes de Amazon EKS.

  • Solo para clústeres con nodos Windows.

    • El clúster y su versión de la plataforma deben ser iguales o posteriores a las versiones de la siguiente tabla. Para actualizar la versión de su clúster, utilice Actualización de una versión de Kubernetes de clúster de Amazon EKS. Si su clúster no tiene la versión mínima de la plataforma, no puede asignar prefijos IP a sus nodos hasta que Amazon EKS haya actualizado la versión de la plataforma.

      Versión de Kubernetes Versión de la plataforma
      1.27 eks.3
      1.26 eks.4
      1.25 eks.5

      Puede verificar su versión actual de Kubernetes y de la plataforma reemplazando my-cluster en el siguiente comando con el nombre de su clúster y luego ejecutando el comando modificado: aws eks describe-cluster --name my-cluster --query 'cluster.{"Kubernetes Version": version, "Platform Version": platformVersion}'.

    • Windows habilita la compatibilidad con su clúster. Para obtener más información, consulte Activación de la compatibilidad con Windows para su clúster de Amazon EKS.

A fin de aumentar la cantidad de direcciones IP disponibles para sus nodos de Amazon EC2

  1. Configure el clúster para asignar prefijos de direcciones IP a los nodos. Complete el procedimiento en la pestaña que coincida con el sistema operativo de su nodo.

    Linux

    1. Habilite el parámetro a fin de asignar prefijos a las interfaces de red para el DaemonSet de CNI de Amazon VPC. Cuando implementa un 1.21 clúster posterior, la versión 1.10.1 o posterior del complemento Amazon VPC CNI plugin for Kubernetes se implementa con él. Si ha creado el clúster con la familia IPv6, este ajuste se configuró en true de forma predeterminada. Si ha creado el clúster con la familia IPv4, este ajuste se configuró en false de forma predeterminada.

      kubectl set env daemonset aws-node -n kube-system ENABLE_PREFIX_DELEGATION=true
      importante

      Incluso si la subred tiene direcciones IP disponibles, si la subred no tiene disponible ningún bloque /28 contiguo, verá el siguiente error en los registros Amazon VPC CNI plugin for Kubernetes.

      InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request

      Esto puede ocurrir debido a la fragmentación de las direcciones IP secundarias existentes distribuidas por una subred. Para resolver este error, cree una nueva subred y lance Pods allí, o utilice una reserva CIDR de subred de Amazon EC2 para reservar espacio dentro de una subred para utilizarla con la asignación de prefijos. Para obtener más información, consulte Reservas de la subred de CIDR en la Guía del usuario de Amazon VPC.

    2. Si planea implementar un grupo de nodos administrado sin una plantilla de lanzamiento o con una plantilla de lanzamiento en la que no ha especificado un ID de AMI, y está utilizando una versión del Amazon VPC CNI plugin for Kubernetes igual o posterior a las versiones enumeradas en los requisitos previos, continúe con el siguiente paso. Los grupos de nodos administrados calculan automáticamente el número máximo de Pods.

      Si va a implementar un grupo de nodos autoadministrado o un grupo de nodos administrado con una plantilla de lanzamiento en la que ha especificado un ID de AMI, debe determinar el número máximo de Pods recomendados por Amazon EKS para los nodos. Siga las instrucciones de Número máximo de Pods recomendado por Amazon EKS para cada tipo de instancia de Amazon EC2, agregando --cni-prefix-delegation-enabled al paso tres. Observe la salida de su uso en un paso posterior.

      importante

      Los grupos de nodos administrados aplican un número máximo en el valor maxPods. Para las instancias con menos de 30 vCPU, el número máximo es 110 y para todas las demás instancias el número máximo es 250. Este número máximo se aplica independientemente de si la delegación de prefijos está habilitada o no.

    3. Si utiliza un clúster 1.21 o posterior configurado para IPv6, continúe con el siguiente paso.

      Especifique los parámetros en una de las siguientes opciones. Para determinar qué opción es adecuada para usted y qué valor debe proporcionarle, consulte WARM_PREFIX_TARGET, WARM_IP_TARGET y MINIMUM_IP_TARGET en GitHub.

      Puede reemplazar el example values por un valor mayor a cero.

      • WARM_PREFIX_TARGET 

        kubectl set env ds aws-node -n kube-system WARM_PREFIX_TARGET=1

      • WARM_IP_TARGET o MINIMUM_IP_TARGET: si se establece este valor, sustituye a cualquier valor establecido para WARM_PREFIX_TARGET.

        kubectl set env ds aws-node -n kube-system WARM_IP_TARGET=5

        kubectl set env ds aws-node -n kube-system MINIMUM_IP_TARGET=2

    4. Cree uno de los siguientes tipos de grupos de nodos con al menos un tipo de instancia Nitro Amazon Linux 2 de Amazon EC2. A fin de obtener una lista de los tipos de instancias de Nitro, consulte Instancias integradas en el sistema Nitro en la Guía del usuario de Amazon EC2. Esta capacidad no es compatible con Windows. En el caso de las opciones que incluyen 110, reemplácelo por el valor del paso tres (recomendado) o un valor propio.

      • Autoadministrado: implementa el grupo de nodos según las instrucciones en Lanzar nodos autoadministrados de Amazon Linux. Especifique el siguiente texto para el parámetro BootstrapArguments.

        --use-max-pods false --kubelet-extra-args '--max-pods=110'

        Si utiliza eksctl para crear el grupo de nodos, puede usar el siguiente comando.

        eksctl create nodegroup --cluster my-cluster --managed=false --max-pods-per-node 110

      • Administrado: implemente el grupo de nodos mediante una de las siguientes opciones:

        • Sin una plantilla de lanzamiento o con una plantilla de lanzamiento sin un ID de AMI especificado: complete el procedimiento indicado en Creación de un grupo de nodos administrados. Los grupos de nodos administrados calculan automáticamente el valor max-pods recomendados por Amazon EKS.

        • Con una plantilla de lanzamiento con un ID de AMI especificado: en la plantilla de lanzamiento, especifique un ID de AMI optimizada para Amazon EKS o una AMI personalizada creada a partir de la AMI optimizada para Amazon EKS y, a continuación, implemente el grupo de nodos mediante una plantilla de lanzamiento y proporcione los siguientes datos de usuario en la plantilla de lanzamiento. Estos datos de usuario pasan los argumentos en el archivo bootstrap.sh. Para obtener más información acerca del archivo del proceso de arranque, consulte bootstrap.sh en GitHub.

          /etc/eks/bootstrap.sh my-cluster \
  --use-max-pods false \
  --kubelet-extra-args '--max-pods=110'

          Si utiliza eksctl para crear el grupo de nodos, puede usar el siguiente comando.

          eksctl create nodegroup --cluster my-cluster --max-pods-per-node 110

          Si ha creado una AMI personalizada, pero no a partir de la AMI optimizada de Amazon EKS, debe crear personalmente la configuración.

        nota

        Si también desea asignar direcciones IP a Pods de una subred diferente a la de la instancia, debe habilitar la capacidad en este paso. Para obtener más información, consulte Redes personalizadas para los pods.

    Windows

    1. Habilite la asignación de prefijos IP.

      1. Abra el ConfigMap de amazon-vpc-cni para editar.

        kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml

      2. Añada la siguiente línea a la sección data:

          enable-windows-prefix-delegation: "true"

      3. Guarde el archivo y cierre el editor.

      4. Confirme que la línea se agregó a ConfigMap.

        kubectl get configmap -n kube-system amazon-vpc-cni -o "jsonpath={.data.enable-windows-prefix-delegation}"

        Si la salida devuelta no es true, es posible que haya habido un error. Intente completar el paso de nuevo.

        importante

        Incluso si su subred tiene direcciones IP disponibles, si la subred no tiene bloques /28 contiguos disponibles, verá el siguiente error en los eventos del nodo. 

        "failed to allocate a private IP/Prefix address: InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request"

        Esto puede ocurrir debido a la fragmentación de las direcciones IP secundarias existentes distribuidas por una subred. Para resolver este error, cree una nueva subred y lance Pods allí, o utilice una reserva CIDR de subred de Amazon EC2 para reservar espacio dentro de una subred para utilizarla con la asignación de prefijos. Para obtener más información, consulte Reservas de la subred de CIDR en la Guía del usuario de Amazon VPC.

    2. (Opcional) Especifique una configuración adicional para controlar el comportamiento de escalado previo y dinámico del clúster. Para obtener más información, consulte Opciones de configuración con modo de delegación de prefijo en Windows en GitHub.

      1. Abra el ConfigMap de amazon-vpc-cni para editar. 

        kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml

      2. Reemplace el example values con un valor mayor que cero y agregue las entradas que necesite a la sección data de ConfigMap. Si establece un valor para warm-ip-target o minimum-ip-target, el valor anula cualquier valor establecido para warm-prefix-target.

          warm-prefix-target: "1" 
  warm-ip-target: "5"
  minimum-ip-target: "2"

      3. Guarde el archivo y cierre el editor.

    3. Cree grupos de nodos Windows con al menos un tipo de instancia Nitro de Amazon EC2. Para obtener una lista de los tipos de instancias Nitro, consulte Instancias creadas en el sistema Nitro en la Guía del usuario de Amazon EC2. De forma predeterminada, la cantidad máxima de Pods que puede implementar en un nodo es 110. Si desea aumentar o disminuir ese número, especifique lo siguiente en los datos de usuario para la configuración de arranque. Reemplace max-pods-quantity con su valor máximo de pods.

      -KubeletExtraArgs '--max-pods=max-pods-quantity'

      Si está implementando grupos de nodos administrados, esta configuración debe agregarse en la plantilla de lanzamiento. Para obtener más información, consulte Personalización de nodos administrados con plantillas de lanzamiento. Para obtener más información sobre los parámetros de configuración para el script de arranque Windows, consulte Parámetros de configuración del script de arranque.

  2. Una vez que se implementan los nodos, consulte los nodos del clúster.

    kubectl get nodes

    Un ejemplo de salida sería el siguiente.

    NAME                                             STATUS     ROLES    AGE   VERSION
ip-192-168-22-103.region-code.compute.internal   Ready      <none>   19m   v1.XX.X-eks-6b7464
ip-192-168-97-94.region-code.compute.internal    Ready      <none>   19m   v1.XX.X-eks-6b7464

  3. Describa uno de los nodos para determinar el valor de max-pods para el nodo y el número de direcciones IP disponibles. Reemplace 192.168.30.193 con la dirección IPv4 en el nombre de uno de sus nodos devueltos en la salida anterior. 

    kubectl describe node ip-192-168-30-193.region-code.compute.internal | grep 'pods\|PrivateIPv4Address'

    Un ejemplo de salida sería el siguiente.

    pods:                                  110
vpc.amazonaws.com/PrivateIPv4Address:  144

    En el resultado anterior, 110 es el número máximo de Pods que Kubernetes implementará en el nodo, aunque haya 144 direcciones IP disponibles.