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

Breve descripción

Antes de completar los pasos de la sección Solución, confirme si dispone de lo siguiente:

• Un clúster de Amazon EKS en ejecución
• La versión más reciente de la Interfaz de la línea de comandos de AWS (AWS CLI)
• Permisos de AWS Identity and Access Management (IAM) para administrar una Amazon Virtual Private Cloud (Amazon VPC)
• Un kubectl con permisos para crear recursos personalizados y editar el DaemonsSet
• Una versión de jq instalada en su sistema
  Nota: Para descargar e instalar jq, consulte Download jq en el sitio web de jq. 
• Un sistema basado en Unix con un shell de Bash
• Una VPC que ya esté configurada

Nota:

• Puede asociar bloques de CIDR privados (RFC 1918) y públicos (que no sean RFC 1918) a su VPC antes o después de crear el clúster.
• En escenarios con traducción de direcciones de red (NAT) en el nivel de operador, 100.64.0.0/10 es un intervalo de redes privadas. El intervalo de redes privadas se utiliza en el espacio de direcciones compartido para las comunicaciones entre un proveedor de servicios y sus suscriptores. Para que los pods se comuniquen con Internet, debe tener una puerta de enlace de NAT configurada en la tabla de enrutamiento. Los clústeres de AWS Fargate no admiten DaemonSets. Para añadir intervalos de CIDR secundarios a los perfiles de Fargate, utilice subredes de los bloques de CIDR secundarios de su VPC. A continuación, etiquete las nuevas subredes antes de añadirlas a su perfil de Fargate.

Importante: En algunos casos, Amazon EKS no puede comunicarse con los nodos que se lanzan en las subredes de los bloques de CIDR añadidos a una VPC después de crear un clúster. Cuando añada bloques de CIDR a un clúster existente, el intervalo actualizado puede tardar hasta 5 horas en aparecer.

Solución

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

En la siguiente solución, primero debe configurar la VPC. A continuación, configure el complemento CNI de modo que utilice un nuevo intervalo de CIDR.

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

Siga estos pasos:

1. Busque sus VPC.
   Si las VPC tienen una etiqueta, ejecute el siguiente comando para buscarlas:

   VPC_ID=$(aws ec2 describe-vpcs --filters Name=tag:Name,Values=yourVPCName | jq -r '.Vpcs[].VpcId')

   Si sus VPC no tienen una etiqueta, ejecute el siguiente comando para generar un listado de todas las VPC en su región de AWS:

   aws ec2 describe-vpcs --filters  | jq -r '.Vpcs[].VpcId'

2. Para asociar la VPC a una variable VPC_ID, ejecute el siguiente comando:

   export VPC_ID=vpc-xxxxxxxxxxxx

   Para asociar otro bloque de CIDR con el intervalo 100.64.0.0/16 a la VPC, ejecute el siguiente comando:

   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

Siga estos pasos:

1.  Para generar un listado de todas las zonas de disponibilidad en su región, ejecute el siguiente comando:

   aws ec2 describe-availability-zones --region us-east-1 --query 'AvailabilityZones[*].ZoneName'

   Nota: Sustituya us-east-1 por su región.

2. Elija la zona de disponibilidad a la que desee añadir las subredes y, a continuación, asígnela a una variable. Por ejemplo:

   export AZ1=us-east-1a
   export AZ2=us-east-1b
   export AZ3=us-east-1c

   Nota: Para añadir más zonas de disponibilidad, cree variables adicionales.

3. Para crear subredes nuevas en la VPC con el nuevo intervalo de CIDR, ejecute los siguientes comandos:

   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)

4. (Opcional) Defina un par clave-valor para añadir una etiqueta de nombre a las subredes. Por ejemplo:

   aws ec2 create-tags --resources $CUST_SNET1 --tags Key=Name,Value=SubnetA
   aws ec2 create-tags --resources $CUST_SNET2 --tags Key=Name,Value=SubnetB
   aws ec2 create-tags --resources $CUST_SNET3 --tags Key=Name,Value=SubnetC

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

Siga estos pasos:

1. Para generar un listado con toda la tabla de enrutamiento en la VPC, ejecute el siguiente comando:

   aws ec2 describe-route-tables --filters Name=vpc-id,Values=$VPC_ID |jq -r '.RouteTables[].RouteTableId'

2. Para exportar la tabla de enrutamiento a la variable, ejecute el siguiente comando:

   export RTASSOC_ID=rtb-abcabcabc

   Nota: Sustituya rtb-abcabcabc por los valores del paso anterior.

3. Asocie la tabla de enrutamiento a todas las subredes nuevas. Por ejemplo:

   aws ec2 associate-route-table --route-table-id $RTASSOC_ID --subnet-id $CUST_SNET1
   aws ec2 associate-route-table --route-table-id $RTASSOC_ID --subnet-id $CUST_SNET2
   aws ec2 associate-route-table --route-table-id $RTASSOC_ID --subnet-id $CUST_SNET3

   Para obtener más información, consulte la sección Routing en Example: VPC with servers in private subnets and NAT.

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

Siga estos pasos:

1. Añada la versión más reciente del complemento vpc-cni plugin al clúster. Para comprobar la versión en el clúster, ejecute el siguiente comando:

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

   Para activar la configuración de red personalizada para el complemento CNI, ejecute el siguiente comando:

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

2. Para añadir la etiqueta ENIConfig con el fin de identificar los nodos de trabajo, ejecute el siguiente comando:

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

3. Para crear un recurso personalizado de ENIConfig para todas las subredes y zonas de disponibilidad, ejecute los siguientes comandos:

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

   Nota: La etiqueta ENIConfig debe coincidir con la zona de disponibilidad de sus nodos de trabajo.

4. Lance los nodos de trabajo para que el complemento CNI (ipamd) pueda asignar las direcciones IP del nuevo intervalo de CIDR a los nuevos nodos de trabajo.
   Si utiliza redes personalizadas, la interfaz de red principal no se utiliza para ubicar los pods. En este caso, primero debe actualizar max-pods con la siguiente fórmula:

   maxPods = (number of interfaces - 1) \* (max IPv4 addresses per interface - 1) + 2

   Si utiliza un grupo de nodos autoadministrados, siga los pasos que se indican en Lanzar nodos autoadministrados de Amazon Linux. No especifique las subredes que ha utilizado en los recursos de ENIConfig. En su lugar, especifique lo siguiente para el parámetro BootstrapArguments:

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

   Si utiliza un grupo de nodos de administrador sin una plantilla de lanzamiento ni un ID de imagen de máquina de Amazon (AMI) especificado, los grupos de nodos administrados calcularán automáticamente el valor máximo de los pods. Siga los pasos que se indican en Creación de un grupo de nodos administrados. Como alternativa, utilice la CLI de Amazon EKS para crear el grupo de nodos administrados:

   aws eks create-nodegroup --cluster-name <sample-cluster-name> --nodegroup-name <sample-nodegroup-name> --subnets <subnet-123 subnet-456> --node-role <arn:aws:iam::123456789012:role/SampleNodeRole>

   Si utiliza una plantilla de lanzamiento para el grupo de nodos administrados con un ID de AMI específico, indique un ID de AMI optimizada para Amazon EKS en su plantilla de lanzamiento. Como alternativa, utilice una AMI personalizada basada en la AMI optimizada para Amazon EKS. A continuación, utilice una plantilla de lanzamiento para desplegar el grupo de nodos y proporcione los siguientes datos de usuario en la plantilla de lanzamiento:

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

5. Anote el grupo de seguridad de la subred y aplíquelo a la ENIConfig asociada:

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

   Nota: Sustituya sg-xxxxxxxxxxxx por su grupo de seguridad.

6. Termine los nodos de trabajo antiguos.

7. Lance un nuevo despliegue para probar la configuración:

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

   Nota: En el despliegue de prueba anterior, se han añadido diez nuevos pods y el nuevo intervalo de CIDR se ha programado en los nuevos nodos de trabajo.