¿Cómo puedo utilizar varios intervalos de CIDR con Amazon EKS?

Descripción corta

Para usar varios intervalos de CIDR en Amazon EKS, sigue estos pasos:

1. Agrega más intervalos de CIDR para expandir tu red de nube virtual privada (VPC).
2. Crea subredes con un nuevo intervalo de CIDR.
3. Asocia la nueva subred a una tabla de enrutamiento.
4. Configura el complemento de interfaz de red de contenedores (CNI) de Amazon Virtual Private Cloud (Amazon VPC) para usar un nuevo intervalo de CIDR.

Nota: Se recomienda usar CIDR (/16) desde el espacio de NAT de nivel de operador (CGN), como 100.64.0.0/10 o 198.19.0.0/16. Puedes usar un intervalo de VPC válido como intervalo de CIDR secundario en redes personalizadas. Sin embargo, es menos probable que estos intervalos se utilicen en un entorno corporativo. Para obtener más información acerca de los requisitos de red personalizados, consulta Consideraciones.

Resolución

Nota: Si se muestran errores al ejecutar comandos de la Interfaz de la línea de comandos de AWS (AWS CLI), consulta Solución de problemas de AWS CLI. Además, asegúrate de utilizar la versión más reciente de la AWS CLI.

Requisitos previos: Debes tener las siguientes configuraciones:

• Un clúster de Amazon EKS en ejecución
• Permisos de AWS Identity and Access Management (IAM) para administrar una Amazon VPC
• Un kubectl con permisos para crear recursos personalizados y editar el DaemonSet
• Una versión de jq instalada en tu sistema
  Nota: Para descargar e instalar jq, consulta Download jq (Descargar jq) en el sitio web de jq.
• Un sistema basado en Unix con un shell de Bash
• Una VPC configurada

Agregación de intervalos de CIDR adicionales para ampliar la red de VPC

Sigue estos pasos:

1. Para recuperar el ID de la VPC del clúster y almacenarlo en una variable, ejecuta el siguiente comando describe-cluster de la AWS CLI:

   VPC_ID=$(aws eks describe-cluster --name CLUSTER_NAME --region REGION_CODE --query "cluster.resourcesVpcConfig.vpcId" --output text)

   Nota: Sustituye CLUSTER_NAME por el nombre de tu clúster y REGION_CODE por la región de AWS en la que has desplegado el clúster.
2. Para asociar otro bloque de CIDR con el intervalo 100.64.0.0/16 a la VPC, ejecuta el siguiente comando associate-vpc-cidr-block:

   aws ec2 associate-vpc-cidr-block --vpc-id $VPC_ID --cidr-block 100.64.0.0/16

Creación de subredes con un nuevo intervalo de CIDR

Sigue estos pasos:

1. Para enumerar todas las zonas de disponibilidad de tu región, ejecuta el siguiente comando describe-availability-zones:

   aws ec2 describe-availability-zones --region REGION_CODE --query 'AvailabilityZones[*].ZoneName'

   Nota: Sustituye REGION_CODE por la región en la que has desplegado tus recursos.
2. Crea las subredes que quieras usar en cada zona de disponibilidad en la que se encuentren las subredes existentes. Para crear subredes nuevas en la VPC con el nuevo intervalo de CIDR, ejecuta los siguientes comandos create-subnet.

   CUST_SNET1=$(aws ec2 create-subnet --cidr-block 100.64.0.0/19 --vpc-id $VPC_ID --availability-zone AZ1 | jq -r .Subnet.SubnetId)
   CUST_SNET2=$(aws ec2 create-subnet --cidr-block 100.64.32.0/19 --vpc-id $VPC_ID --availability-zone AZ2 | jq -r .Subnet.SubnetId)
   CUST_SNET3=$(aws ec2 create-subnet --cidr-block 100.64.64.0/19 --vpc-id $VPC_ID --availability-zone AZ3 | jq -r .Subnet.SubnetId)

   Nota: Sustituye AZ1, AZ2 y AZ3 por las zonas de disponibilidad existentes de la subred.
3. (Opcional) Para establecer un par clave-valor para agregar una etiqueta de nombre a las subredes, ejecuta el siguiente comando create-tags:

   aws ec2 create-tags --resources $CUST_SNET1 --tags Key=KEY,Value=VALUE
   aws ec2 create-tags --resources $CUST_SNET2 --tags Key=KEY,Value=VALUE
   aws ec2 create-tags --resources $CUST_SNET3 --tags Key=KEY,Value=VALUE

   Nota: Sustituye KEY por la clave de la etiqueta y VALUE por el valor de la etiqueta.

Asociación de la nueva subred a una tabla de enrutamiento

De forma predeterminada, Amazon VPC asocia las nuevas subredes a la tabla de enrutamiento principal de la VPC. Esta tabla de enrutamiento permite la comunicación solo entre los recursos que están desplegados en la VPC. Para permitir la comunicación con direcciones IP que están fuera de los bloques de CIDR de la VPC, debes crear tu propia tabla de enrutamiento para tus subredes.

Configuración del complemento CNI de Amazon VPC de modo que utilice el nuevo intervalo de CIDR

Sigue estos pasos:

1. Asegúrate de ejecutar la versión correcta del complemento para tu versión de Kubernetes. Para verificar la versión, ejecuta el siguiente comando:

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

   Si no tienes la versión correcta del complemento, actualiza la CNI de Amazon VPC.

2. Para activar la configuración de red personalizada para el complemento CNI de Amazon VPC, ejecuta el siguiente comando:

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

3. Para agregar la etiqueta ENIConfig con el fin de identificar los nodos de trabajo, ejecuta el siguiente comando:

   kubectl set env daemonset aws-node -n kube-system ENI_CONFIG_LABEL_DEF=topology.kubernetes.io/zone

4. Para crear recursos personalizados de ENIConfig para todas las subredes y zonas de disponibilidad, ejecuta los siguientes comandos:

   cat <<EOF  | kubectl apply -f -apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ1
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET1
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ2
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET2
   EOF
   
   cat <<EOF | kubectl apply -f -
   apiVersion: crd.k8s.amazonaws.com/v1alpha1
   kind: ENIConfig
   metadata:
    name: $AZ3
   spec:
     securityGroups:
       - cluster_security_group_id
     subnet: $CUST_SNET3
   EOF

   Nota: Sustituye cluster_security_group_id por el ID del grupo de seguridad existente que quieres usar para cada recurso de ENIConfig. Los nombres de los recursos de ENIConfig son los mismos que los de la zona de disponibilidad en la que has creado las nuevas subredes.

5. Si utilizas un grupo de nodos autoadministrado, inicia nodos de trabajo autoadministrados para permitir que el complemento les asigne direcciones IP. Para las subredes, utiliza las subredes originales que elegiste al crear el clúster en lugar de las nuevas subredes que utilizaste en los recursos de ENIConfig. También puedes usar un grupo de nodos administrado con una plantilla de inicio para iniciar los nodos. En ambos casos, debes identificar el valor de max-pods correcto para tu tipo de instancia. Esto se debe a que las redes personalizadas de Amazon EKS no utilizan la interfaz de red principal para colocar los pods. Asegúrate de agregar el parámetro --cni-custom-networking-enabled al ejecutar el script max-pods-calculator.sh.
   A continuación, ejecuta el siguiente comando para especificar el valor de max-pods de los nodos autoadministrados:

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

   Nota: Sustituye 20 por el valor de max-pods que has calculado.
   Para un grupo de nodos administrado, agrega el siguiente script a los datos de usuario:

   #!/bin/bash
   /etc/eks/bootstrap.sh my-cluster-name --use-max-pods false --kubelet-extra-args '--max-pods=20'

   Nota: Sustituye my-cluster-name por el nombre de tu clúster y 20 por el valor de max-pods que has calculado. En la plantilla de inicio, especifica un ID de imagen de máquina de Amazon (AMI) optimizado para Amazon EKS o una AMI personalizada creada a partir de la AMI optimizada para Amazon EKS. Las AMI de Amazon Linux 2023 (AL2023) utilizan el proceso nodeadm. Para obtener información sobre cómo esto cambia la configuración de los datos de usuario, consulta Upgrade from Amazon Linux 2 to Amazon Linux 2023 (Actualización de Amazon Linux 2 a Amazon Linux 2023).
   Si utilizas un grupo de nodos administrado sin una plantilla de inicio ni un ID de AMI especificado, el grupo de nodos administrado calculará automáticamente el valor de max-pods.

6. Cuando los nuevos nodos estén listos, drena los nodos anteriores para cerrar los pods correctamente. Para obtener más información, consulta Safely drain a node (Drenar un nodo de forma segura) en el sitio web de Kubernetes. Si los nodos están en un grupo de nodos administrado existente, ejecuta el siguiente comando para eliminar el grupo de nodos:

   aws eks delete-nodegroup --cluster-name CLUSTER_NAME --nodegroup-name my-nodegroup

   Nota: Sustituye CLUSTER_NAME por el nombre de tu clúster y my-nodegroup por el nombre de tu grupo de nodos.

7. Para iniciar un nuevo despliegue para probar la configuración, ejecuta el siguiente comando:

   kubectl create deployment nginx-test --image=nginx --replicas=10   
   kubectl get pods -o wide --selector=app=nginx-test

   Nota: El comando anterior agrega 10 pods nuevos y los programa en el nuevo intervalo de CIDR en los nuevos nodos de trabajo.

Importante: Un clúster puede tardar hasta 5 horas en reconocer y permitir un nuevo bloque de CIDR asociado a una VPC. Durante ese tiempo, el plano de control de Amazon EKS no puede comunicarse con los pods que inicies en las nuevas subredes. Si api-server contacta pods con un webhook, un comando logs command o un comando kubectl exec, es posible que recibas el siguiente mensaje de error:

"failed calling webhook "linkerd-proxy-injector.linkerd.io": failed to call webhook: Post "https://linkerd-proxy-injector.linkerd.svc:443/?timeout=10s": Address is not allowed"