Configuración de la selección de subredes para las direcciones IP de los pods

Aplicación: en nodos de Linux con instancias de Amazon EC2

El complemento CNI de Amazon VPC para Kubernetes crea interfaces de red elástica (ENI) secundarias en los nodos y asigna direcciones IP de esas ENI a los pods. De forma predeterminada, CNI de VPC crea ENI secundarias en la misma subred que la interfaz de red principal del nodo. Puede controlar las subredes que utiliza CNI de VPC para las direcciones IP de pod con los siguientes métodos:

• Detección de subredes mejorada: CNI de VPC detecta y utiliza automáticamente las subredes etiquetadas con kubernetes.io/role/cni en la misma VPC y zona de disponibilidad. Requiere la versión 1.18.0 de CNI de VPC o una posterior. Recomendamos este método para la mayoría de los casos de uso.

• Redes personalizadas: especifique manualmente las subredes y los grupos de seguridad por zona de disponibilidad con recursos personalizados de ENIConfig. Para obtener más información, consulte Implementación de pods en subredes alternativas con redes personalizadas.

nota

Las redes personalizadas tienen prioridad cuando ambas características están habilitadas.

Detección de subredes mejorada

La versión 1.18.0 y posteriores de CNI de VPC permiten la detección mejorada de subredes de forma predeterminada (ENABLE_SUBNET_DISCOVERY=true). CNI de VPC detecta automáticamente las subredes en la misma VPC y zona de disponibilidad que el nodo y, a continuación, las utiliza para crear ENI secundarias y asignar direcciones IP de pod. Esto amplía el espacio de direcciones IP disponible sin la configuración de ENIConfig manual.

Para verificar que la característica esté habilitada:

kubectl describe ds aws-node -n kube-system | grep ENABLE_SUBNET_DISCOVERY

Para deshabilitar esta característica, configure ENABLE_SUBNET_DISCOVERY=false en el DaemonSet aws-node.

Comportamiento de las etiquetas de subred (kubernetes.io/role/cni)

La etiqueta kubernetes.io/role/cni controla la forma en que CNI de VPC trata las subredes para las operaciones de ENI y la asignación de IP de pod. La etiqueta tiene diferentes efectos en función de si CNI de VPC crea una nueva ENI o concilia una existente.

importante

Los mecanismos de etiquetado excluyente y basados en clústeres solo están disponibles a partir de la versión v1.22.2 de CNI de VPC. Antes de esta versión, solo el comportamiento de participación estándar estaba disponible a través de la etiqueta kubernetes.io/role/cni=1.

Tag value (Valor de etiqueta)

En la siguiente tabla, se resume cómo afecta cada valor de etiqueta al comportamiento de la subred:

Valor de etiqueta	Creación de una nueva ENI	Conciliación de una ENI existente
1	Suscripción: CNI de VPC crea nuevas ENI en esta subred.	La ENI sigue disponible para la asignación de IP de pod.
0	Excluido: CNI de VPC no crea nuevas ENI en esta subred.	Excluido: CNI de VPC excluye las ENI existentes en esta subred de la asignación de IP de pod. No se asignan nuevas IP de pod desde esta ENI.
Ausente (sin etiqueta)	No se utiliza para nuevas ENI: CNI de VPC no selecciona las subredes secundarias sin la etiqueta para la creación de nuevas ENI. La subred principal (la subred en la que se lanzó el nodo) se continúa utilizando para la creación de nuevas ENI, incluso sin la etiqueta, por motivos de compatibilidad con versiones anteriores.	Sin interrupción: las ENI existentes en las subredes no etiquetadas permanecen disponibles para la asignación de IP de pod. CNI de VPC no elimina ni excluye estas ENI.

Comportamiento de creación frente a conciliación

CNI de VPC aplica intencionadamente diferentes políticas al crear nuevas ENI y al conciliar las ENI existentes:

• Creación (cierre por error para subredes secundarias): cuando CNI de VPC necesita crear una nueva ENI secundaria, solo utiliza subredes secundarias etiquetadas explícitamente con kubernetes.io/role/cni=1. Las subredes secundarias sin etiquetar nunca se seleccionan para la creación de una nueva ENI. Esto garantiza que las nuevas interfaces de red solo se coloquen en las subredes que los administradores hayan aprobado explícitamente.

• Conciliación (apertura por error para subredes sin etiquetar): cuando CNI de VPC se inicia o concilia las ENI existentes que ya se han adjuntado al nodo, no excluye las ENI porque su subred carece de la etiqueta kubernetes.io/role/cni. Esto evita que se interrumpa la ejecución de los pods que ya utilizan direcciones IP de esas ENI.

CNI de VPC utiliza este diseño de forma intencionada. Excluir por la fuerza una ENI ya adjunta de una subred sin etiquetar dañaría los pods que actualmente utilizan direcciones IP de esa ENI.

importante

Para evitar que una subred suministre nuevas IP de pod, incluidas las de ENI existentes, etiquete la subred con kubernetes.io/role/cni=0. La ausencia de una etiqueta solo impide la creación de nuevas ENI en esa subred. No excluye las ENI existentes de la asignación.

Gestión de subredes principales

CNI de VPC siempre incluye la subred principal del nodo (la subred en la que se lanzó el nodo) para la creación de ENI, incluso sin la etiqueta kubernetes.io/role/cni. Esto mantiene la compatibilidad con versiones anteriores de los clústeres existentes. Comportamiento de la subred principal:

• Se incluye para la creación de ENI, independientemente de la presencia de etiquetas (a menos que exista la etiqueta 0).

• Si se etiqueta con kubernetes.io/role/cni=0, CNI de VPC excluye la subred principal tanto de la creación de nuevas ENI como de la asignación de ENI existentes.

Filtrado de subredes basado en clústeres

Cuando se etiqueta una subred con kubernetes.io/role/cni=1, CNI de VPC comprueba además las etiquetas específicas del clúster mediante el formato de clave cni.networking.k8s.aws/cluster/<cluster-name>. Si una subred tiene etiquetas de clúster en este formato, solo el clúster cuyo nombre coincida usará esa subred. Las subredes con kubernetes.io/role/cni=1 y sin etiquetas específicas del clúster están disponibles para todos los clústeres de la VPC.

Por ejemplo, para restringir una subred a un clúster específico:

aws ec2 create-tags --resources subnet-example \
  --tags Key=kubernetes.io/role/cni,Value=1 Key=cni.networking.k8s.aws/cluster/my-cluster,Value=shared

Esto resulta útil cuando varios clústeres de EKS comparten una VPC y se desea que cada clúster utilice subredes diferentes para las direcciones IP de pod.

Flujo de trabajo recomendado

Para agregar nuevas subredes para las direcciones IP de pod:

1. Cree subredes nuevas en la misma VPC y zona de disponibilidad que los nodos.

2. Etiquete las subredes con kubernetes.io/role/cni=1.

3. Asegúrese de que las subredes tengan las tablas de enrutamiento y las ACL de red adecuadas.

4. Verifique que CNI de VPC detecte las nuevas subredes y comience a utilizarlas.

Para eliminar una subred de la asignación de IP de pod:

1. Etiquete la subred con kubernetes.io/role/cni=0.

2. Espere a que los pods que utilizan IP de esa subred terminen o se reprogramen de forma natural.

3. Verifique que CNI de VPC deje de asignar nuevas IP de pod desde las ENI de esa subred.

importante

No elimine la etiqueta kubernetes.io/role/cni para dejar de usar una subred. La eliminación de la etiqueta impide la creación de nuevas ENI, pero no excluye las ENI existentes de la asignación. Para excluir activamente una subred, etiquétela con kubernetes.io/role/cni=0.

Consideraciones

• La detección de subredes mejorada requiere la versión 1.18.0 o posterior de CNI de Amazon VPC.

• La característica requiere el permiso ec2:DescribeSubnets en el rol de IAM de CNI de VPC. La política administrada de AmazonEKS_CNI_Policy incluye este permiso. La política de IAM autoadministrada IPv6 no lo incluye. Si utiliza una política de IAM autoadministrada (por ejemplo, para clústeres IPv6), agregue ec2:DescribeSubnets manualmente para habilitar la detección de subredes.

• La característica funciona tanto con el modo de dirección IP secundaria como con el modo de delegación de prefijos.

• Todas las subredes detectadas deben estar en la misma VPC que el nodo.

• CNI de VPC solo crea ENI en subredes que se encuentran en la misma zona de disponibilidad que el nodo.

• CNI de VPC no elimina la asignación de ENI que aún tienen direcciones IP asignadas a pods, independientemente de los cambios de etiqueta.

• Cuando utilice VPC compartidas (subredes entre cuentas), etiquete las subredes de la cuenta del participante en la que se lanzó el clúster.

• Puede utilizar la detección mejorada de subredes junto con grupos de seguridad para los pods, las políticas de red, la delegación de prefijos y SNAT.