**Ayude a mejorar esta página** Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página. # Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos **Aplicación**: en nodos de Linux y Windows con instancias de Amazon EC2 **Aplicación**: en subredes públicas y privadas 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`. Puede aumentar 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, deberá hacer más llamadas desde su clúster 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 de los pods. 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 pods 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](https://github.com/kubernetes/community/blob/master/sig-scalability/configs-and-limits/thresholds.md) en GitHub. ## Compatibilidad con las características del complemento CNI de Amazon VPC para Kubernetes Puede utilizar prefijos de IP con las siguientes características: + Traducción de direcciones de red de origen IPv4 (para obtener más información, consulte [Habilitación del acceso a Internet saliente para pods](external-snat.md)). + Direcciones IPv6 para clústeres, pods y servicios (para obtener más información, consulte [Información sobre la asignación de direcciones IPv6 a clústeres, pods y servicios](cni-ipv6.md)). + Restricción del tráfico con políticas de red de Kubernetes. Para obtener más información, consulte [Limitación del tráfico de un pod con políticas de red de Kubernetes](cni-network-policy.md). La siguiente lista proporciona información sobre la configuración del complemento de CNI de Amazon VPC que se aplica. Para obtener más información acerca de cada configuración, consulte [amazon-vpc-cni-k8s](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) en GitHub. + `WARM_IP_TARGET` + `MINIMUM_IP_TARGET` + `WARM_PREFIX_TARGET` ## Consideraciones Cuando utilice esta característica, tenga en cuenta lo siguiente: + 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 incoherencias en la capacidad de direcciones IP anunciada, lo que afecta a las futuras cargas de trabajo en el nodo. Para conocer la forma recomendada de efectuar la transición, consulte [Prefix Delegation mode for Linux](https://docs.aws.amazon.com/eks/latest/best-practices/prefix-mode-linux.html) en la *Guía de prácticas recomendadas de Amazon EKS*. + El alcance del grupo de seguridad se encuentra en el nivel del nodo. Para obtener más información, consulte [Grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html). + Los prefijos de IP asignados a una interfaz de red admiten una alta densidad de pods por nodo y tienen el mejor tiempo de lanzamiento. + Los prefijos IP y las direcciones IP están asociados a las interfaces de red elásticas estándar de Amazon EC2. A los pods que requieren grupos de seguridad específicos se les asigna la dirección IP principal de una interfaz de red de ramificación. Puede mezclar pods que obtengan direcciones IP o direcciones IP de prefijos IP con pods que obtengan interfaces de red de ramificación en el mismo nodo. + Solo para clústeres con nodos Linux. + Luego de configurar el complemento para asignar prefijos a las interfaces de red, no podrá degradar el complemento CNI de Amazon VPC para Kubernetes a una versión anterior a `1.9.0` (o `1.10.1`) sin eliminar todos los nodos de todos los grupos de nodos en el 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 los pods se comunican con los 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 sus pods. Si también utiliza [grupos de seguridad para pods](security-groups-for-pods.md), con `POD_SECURITY_GROUP_ENFORCING_MODE`=`strict`, cuando los `Pods` se comunican con los puntos de conexión fuera de la VPC, se utilizan los grupos de seguridad de `Pod’s`. # Aumento de las direcciones IP disponibles para su nodo de Amazon EKS Puede aumentar 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. ## Requisitos previos + Necesita un clúster existente. Para implementar uno, consulte [Creación de un clúster de Amazon EKS](create-cluster.md). + 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 de CIDR. Le recomendamos lo siguiente: + Utilizar una reserva de 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 de Windows como las de 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 se basan en Nitro continúan asignando direcciones IP secundarias individuales, pero tienen un número significativamente menor de direcciones IP para asignar a los pods que las instancias basadas en Nitro. + **Solo para clústeres con nodos de Linux**: si su clúster está configurado para la familia `IPv4`, debe tener instalada la versión `1.9.0` o posterior del complemento CNI de Amazon VPC para 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 del artículo [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md). + **Solo para clústeres con nodos de Linux** + Debe tener la compatibilidad con Windows habilitada para el clúster. Para obtener más información, consulte [Implementación de nodos de Windows en clústeres de EKS](windows-support.md). ## Asignación de prefijos de direcciones IP a los nodos Configure el clúster para asignar prefijos de direcciones IP a los nodos. Complete el procedimiento 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 clúster, la versión `1.10.1` o posterior del complemento CNI de Amazon VPC para 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 del complemento CNI de Amazon VPC para 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 de 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](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) en la Guía del usuario de Amazon VPC. 1. 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 utiliza una versión del complemento CNI de Amazon VPC para 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 que aparecen en , y con la adición de `--cni-prefix-delegation-enabled` al paso 3. 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. 1. Si utiliza un clúster 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 la adecuada y qué valor debe proporcionarle, consulte [WARM\$1PREFIX\$1TARGET, WARM\$1IP\$1TARGET, and MINIMUM\$1IP\$1TARGET](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/docs/prefix-and-ip-target.md) em GitHub. Puede reemplazar 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 ``` 1. Cree uno de los siguientes tipos de grupos de nodos con al menos un tipo de instancia Nitro de Amazon Linux 2023 de Amazon EC2. A fin de obtener una lista de los tipos de instancias de Nitro, consulte [Instancias integradas en el sistema Nitro](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#ec2-nitro-instances) 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 que aparecen en [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md). Antes de crear la pila de CloudFormation, abra el archivo de plantilla y ajuste `UserData` en la `NodeLaunchTemplate` para que sea como se muestra a continuación. ``` ... apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: ${ClusterName} apiServerEndpoint: ${ApiServerEndpoint} certificateAuthority: ${CertificateAuthorityData} cidr: ${ServiceCidr} kubelet: config: maxPods: 110 ... ``` Si utiliza `eksctl` para crear el grupo de nodos, utilice 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 para un clúster](create-managed-node-group.md). 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](launch-templates.md) y proporcione los siguientes datos de usuario en la plantilla de lanzamiento. Estos datos de usuario se transfieren a un objeto `NodeConfig` para que la herramienta `nodeadm` los lea en el nodo. Para obtener más información acerca de `nodeadm`, consulte la [documentación de nodeadm](https://awslabs.github.io/amazon-eks-ami/nodeadm). ``` MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="//" --// Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: apiServerEndpoint: [.replaceable]`my-cluster` certificateAuthority: [.replaceable]`LS0t...` cidr: [.replaceable]`10.100.0.0/16` name: [.replaceable]`my-cluster kubelet: config: maxPods: [.replaceable]`110` --//-- ``` Si utiliza `eksctl` para crear el grupo de nodos, utilice 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 [Implementación de pods en subredes alternativas con redes personalizadas](cni-custom-network.md). ### 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 ``` 1. Añada la siguiente línea a la sección `data`: ``` enable-windows-prefix-delegation: "true" ``` 1. Guarde el archivo y cierre el editor. 1. 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 ocurrido un error. Intente completar el paso de nuevo. **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 del complemento CNI de Amazon VPC para 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 de 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](https://docs.aws.amazon.com/vpc/latest/userguide/subnet-cidr-reservation.html) en la Guía del usuario de Amazon VPC. 1. (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](https://github.com/aws/amazon-vpc-resource-controller-k8s/blob/master/docs/windows/prefix_delegation_config_options.md) en GitHub. 1. Abra el `ConfigMap` de `amazon-vpc-cni` para editar. ``` kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml ``` 1. Sustituya los valores de ejemplo por un valor superior a 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" ``` 1. Guarde el archivo y cierre el editor. 1. Cree grupos de nodos de Windows con al menos un tipo de instancia Nitro de Amazon EC2. A fin de obtener una lista de los tipos de instancias de Nitro, consulte [Instancias integradas en el sistema Nitro](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/instance-types.html#ec2-nitro-instances) 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](launch-templates.md). Para obtener más información sobre los parámetros de configuración para el script de arranque de Windows, consulte [Parámetros de configuración del script de arranque](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters). ## Cómo determinar el número máximo de pods y las direcciones IP disponibles 1. 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 19m v1.XX.X-eks-6b7464 ip-192-168-97-94.region-code.compute.internal Ready 19m v1.XX.X-eks-6b7464 ``` 1. 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.