**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.

# Personalización de la interfaz de red secundaria en los nodos de Amazon EKS
<a name="cni-custom-network-tutorial"></a>

Antes de comenzar este tutorial, complete lo siguiente:
+ Revisión de las consideraciones
+ Haberse familiarizado con cómo el complemento CNI de Amazon VPC para Kubernetes crea interfaces de red secundarias y asigna direcciones IP a los pods. Para obtener más información, consulte [Asignación de ENI](https://github.com/aws/amazon-vpc-cni-k8s#eni-allocation) en GitHub.
+ La versión `2.12.3` o posterior, o bien, la versión `1.27.160` o posterior de la AWS interfaz de la línea de comandos (AWS CLI) instalada y configurada en su dispositivo o AWS CloudShell. Para comprobar su versión actual, utilice `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Los administradores de paquetes, como `yum`, `apt-get` o Homebrew para macOS, suelen estar atrasados varias versiones respecto de la versión de la AWS CLI más reciente. Para instalar la versión más reciente, consulte [Instalación](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) y [Configuración rápida con aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) en la *Guía del usuario de la interfaz de la línea de comandos de AWS*. La versión de AWS CLI instalada en AWS CloudShell también puede estar atrasada varias versiones respecto de la versión más reciente. Para actualizarla, consulte [Instalación de la CLI de AWS en su directorio principal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) en la *Guía del usuario de AWS CloudShell*.
+ La herramienta de línea de comandos de `kubectl` está instalada en su dispositivo o AWS CloudShell. Para instalar o actualizar `kubectl`, consulte [Configuración de `kubectl` y `eksctl`](install-kubectl.md).
+ Le recomendamos que siga los pasos de este tema en un intérprete de comandos Bash. Si no está utilizando un intérprete de comandos Bash, algunos comandos de script, como los caracteres de continuación de línea y la forma en que se establecen y utilizan las variables, requieren ajustes para su intérprete de comandos. Además, las reglas de entrecomillado y escape de su intérprete de comandos pueden ser diferentes. Para obtener más información, consulte [Uso de la AWS CLI con Amazon SNS](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) en la Guía del usuario de la interfaz de línea de comandos de AWS.

Para este tutorial, le recomendamos utilizar los valores de ejemplo, excepto en los casos en que se indique que se los debe reemplazar. Puede reemplazar cualquier ejemplo de valor al completar los pasos de un clúster de producción. Recomendamos completar todos los pasos en la misma terminal. Esto se debe a que las variables se establecen y utilizan a lo largo de los pasos y no existirán en terminales diferentes.

Los comandos de este tema se formatean según las convenciones que se indican en [Uso de los ejemplos de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/welcome-examples.html). Si ejecuta comandos desde la línea de comandos con recursos que se encuentran en una región de AWS diferente a la región de AWS predeterminada definida en el [perfil](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-profiles) de la AWS CLI que está utilizando, tendrá que agregar `--region us-west-2` a los comandos, después de sustituir `us-west-2` por la región de AWS.

Cuando desee implementar redes personalizadas en su clúster de producción, vaya a [Paso 2: Configurar la VPC](#custom-networking-configure-vpc).

## Paso 1: crear una VPC de prueba y un clúster
<a name="custom-networking-create-cluster"></a>

Los siguientes procedimientos le ayudan a crear una VPC de prueba y un clúster, y a configurar redes personalizadas para ese clúster. No recomendamos utilizar el clúster de pruebas para cargas de trabajo de producción porque en este tema no se cubren varias características no relacionadas que podría utilizar en el clúster de producción. Para obtener más información, consulte [Creación de un clúster de Amazon EKS](create-cluster.md).

1. Ejecute el siguiente comando para definir la variable `account_id`.

   ```
   account_id=$(aws sts get-caller-identity --query Account --output text)
   ```

1. Cree una VPC.

   1. Si va a realizar la implementación en un sistema de prueba, cree una VPC con una plantilla AWS CloudFormation de Amazon EKS.

      ```
      aws cloudformation create-stack --stack-name my-eks-custom-networking-vpc \
        --template-url https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/amazon-eks-vpc-private-subnets.yaml \
        --parameters ParameterKey=VpcBlock,ParameterValue=192.168.0.0/24 \
        ParameterKey=PrivateSubnet01Block,ParameterValue=192.168.0.64/27 \
        ParameterKey=PrivateSubnet02Block,ParameterValue=192.168.0.96/27 \
        ParameterKey=PublicSubnet01Block,ParameterValue=192.168.0.0/27 \
        ParameterKey=PublicSubnet02Block,ParameterValue=192.168.0.32/27
      ```

   1. La pila de AWS CloudFormation tarda unos minutos en crearse. Para verificar el estado de implementación de la pila, ejecute el siguiente comando.

      ```
      aws cloudformation describe-stacks --stack-name my-eks-custom-networking-vpc --query Stacks\[\].StackStatus  --output text
      ```

      No continúe con el siguiente paso hasta que la salida del comando sea `CREATE_COMPLETE`.

   1. Defina variables con los valores de los ID de subred privada creados por la plantilla.

      ```
      subnet_id_1=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
          --query "StackResources[?LogicalResourceId=='PrivateSubnet01'].PhysicalResourceId" --output text)
      subnet_id_2=$(aws cloudformation describe-stack-resources --stack-name my-eks-custom-networking-vpc \
          --query "StackResources[?LogicalResourceId=='PrivateSubnet02'].PhysicalResourceId" --output text)
      ```

   1. Defina variables con las zonas de disponibilidad de las subredes recuperadas en el paso anterior.

      ```
      az_1=$(aws ec2 describe-subnets --subnet-ids $subnet_id_1 --query 'Subnets[*].AvailabilityZone' --output text)
      az_2=$(aws ec2 describe-subnets --subnet-ids $subnet_id_2 --query 'Subnets[*].AvailabilityZone' --output text)
      ```

1. Cree un rol de IAM de clúster.

   1. Ejecute el siguiente comando para crear un archivo de política de confianza JSON de IAM.

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
      ```

   1. Cree el rol de IAM del clúster de Amazon EKS. Si es necesario, prefacio `eks-cluster-role-trust-policy.json` con la ruta del equipo en la que escribió el archivo en el paso anterior. El comando asocia la política de confianza creada en el paso anterior al rol. Para crear un rol de IAM, a la [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que está creando el rol se le debe asignar la acción `iam:CreateRole` (permiso).

      ```
      aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
      ```

   1. Adjunte la política administrada de Amazon EKS llamada [AmazonEKSClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) al rol. Para adjuntar una política de IAM a una [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), se debe asignar una de las siguientes acciones de IAM (permisos) a la entidad principal que adjunta la política: `iam:AttachUserPolicy` o `iam:AttachRolePolicy`.

      ```
      aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
      ```

1. Cree un clúster de Amazon EKS y configure su dispositivo para que se comunique con él.

   1. Cree un clúster.

      ```
      aws eks create-cluster --name my-custom-networking-cluster \
         --role-arn arn:aws:iam::$account_id:role/myCustomNetworkingAmazonEKSClusterRole \
         --resources-vpc-config subnetIds="$subnet_id_1","$subnet_id_2"
      ```
**nota**  
Es posible que reciba un error que indique que una de las zonas de disponibilidad de la solicitud no tiene capacidad suficiente para crear un clúster de Amazon EKS. Si esto ocurre, el mensaje de error indicará las zonas de disponibilidad que admiten un clúster nuevo. Intente crear el clúster de nuevo con al menos dos subredes ubicadas en las zonas de disponibilidad admitidas para su cuenta. Para obtener más información, consulte [Capacidad insuficiente](troubleshooting.md#ice).

   1. El clúster tarda varios minutos en crearse. Ejecute el siguiente comando para verificar el estado de implementación del clúster.

      ```
      aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status
      ```

      No continúe con el siguiente paso hasta que la salida del comando sea `"ACTIVE"`.

   1. Configure `kubectl` para comunicarse con el clúster.

      ```
      aws eks update-kubeconfig --name my-custom-networking-cluster
      ```

## Paso 2: Configurar la VPC
<a name="custom-networking-configure-vpc"></a>

Este tutorial requiere una VPC creada en [Paso 1: crear una VPC de prueba y un clúster](#custom-networking-create-cluster). En el caso de un clúster de producción, ajuste los pasos correspondientes a su VPC sustituyendo todos los valores de ejemplo con los suyos propios.

1. Confirme que el complemento CNI de Amazon VPC para Kubernetes instalado actualmente es la última versión. Para determinar la versión más reciente del tipo de complemento de Amazon EKS y actualizar su versión a ella, consulte [Actualización de un complemento de Amazon EKS](updating-an-add-on.md). Para determinar la versión más reciente del tipo de complemento autoadministrado y actualizar su versión a ella, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md).

1. Recupere el ID de la VPC de su clúster y guárdelo en una variable para utilizarlo en un paso posterior.

   ```
   vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
   ```

1. Asocie un bloque de enrutamiento entre dominios sin clases (CIDR) con la VPC de su clúster. El bloque CIDR no se puede solapar con ningún bloque CIDR asociado existente.

   1. Vea los bloques CIDR actuales asociados a la VPC.

      ```
      aws ec2 describe-vpcs --vpc-ids $vpc_id \
          --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
      ```

      Un ejemplo de salida sería el siguiente.

      ```
      ----------------------------------
      |          DescribeVpcs          |
      +-----------------+--------------+
      |    CIDRBlock    |    State     |
      +-----------------+--------------+
      |  192.168.0.0/24 |  associated  |
      +-----------------+--------------+
      ```

   1. Asocie un bloque CIDR adicional a su VPC. Sustituya el valor del bloque de CIDR en el siguiente comando. Para obtener más información, consulte [Asociar un bloque adicional de CIDR IPv4 a su VPC](https://docs.aws.amazon.com/vpc/latest/userguide/modify-vpcs.html#add-ipv4-cidr) en la Guía del usuario de Amazon VPC.

      ```
      aws ec2 associate-vpc-cidr-block --vpc-id $vpc_id --cidr-block 192.168.1.0/24
      ```

   1. Confirme que el nuevo bloque está asociado.

      ```
      aws ec2 describe-vpcs --vpc-ids $vpc_id --query 'Vpcs[*].CidrBlockAssociationSet[*].{CIDRBlock: CidrBlock, State: CidrBlockState.State}' --out table
      ```

      Un ejemplo de salida sería el siguiente.

      ```
      ----------------------------------
      |          DescribeVpcs          |
      +-----------------+--------------+
      |    CIDRBlock    |    State     |
      +-----------------+--------------+
      |  192.168.0.0/24 |  associated  |
      |  192.168.1.0/24 |  associated  |
      +-----------------+--------------+
      ```

   No continúe con el siguiente paso hasta que el `State` del nuevo bloque CIDR sea `associated`.

1. Cree tantas subredes como desee utilizar en cada zona de disponibilidad en la que se encuentran las subredes existentes. Especifique un bloque CIDR que se encuentra dentro del bloque CIDR que asoció a la VPC en un paso anterior.

   1. Crea nuevas subredes. Sustituya los valores del bloque de CIDR en el siguiente comando. Las subredes deben crearse en un bloque CIDR de VPC diferente al que están las subredes existentes, pero en las mismas zonas de disponibilidad que las subredes existentes. En este ejemplo, se crea una subred en el nuevo bloque CIDR de cada zona de disponibilidad en la que existen las subredes privadas actuales. Los ID de las subredes creadas se almacenan en variables para usarlas en los pasos posteriores. Los valores `Name` coinciden con los valores asignados a las subredes creadas mediante la plantilla de Amazon EKS VPC en un paso anterior. No se requieren nombres. Puede utilizar diferentes nombres.

      ```
      new_subnet_id_1=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_1 --cidr-block 192.168.1.0/27 \
          --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet01},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
          --query Subnet.SubnetId --output text)
      new_subnet_id_2=$(aws ec2 create-subnet --vpc-id $vpc_id --availability-zone $az_2 --cidr-block 192.168.1.32/27 \
          --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=my-eks-custom-networking-vpc-PrivateSubnet02},{Key=kubernetes.io/role/internal-elb,Value=1}]' \
          --query Subnet.SubnetId --output text)
      ```
**importante**  
De forma predeterminada, las nuevas subredes están asociadas implícitamente con su [tabla de enrutamiento principal](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#RouteTables) de VPC. Esta tabla de enrutamiento permite la comunicación entre todos los recursos que se implementan en la VPC. Sin embargo, no permite la comunicación con recursos que tienen direcciones IP que están fuera de los bloques CIDR asociados a la VPC. Puede asociar su propia tabla de enrutamiento a las subredes para cambiar este comportamiento. Para obtener más información, consulte [Tablas de enrutamiento de subredes](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#subnet-route-tables) en la Guía del usuario de Amazon VPC.

   1. Para ver las subredes actuales en su VPC.

      ```
      aws ec2 describe-subnets --filters "Name=vpc-id,Values=$vpc_id" \
          --query 'Subnets[*].{SubnetId: SubnetId,AvailabilityZone: AvailabilityZone,CidrBlock: CidrBlock}' \
          --output table
      ```

      Un ejemplo de salida sería el siguiente.

      ```
      ----------------------------------------------------------------------
      |                           DescribeSubnets                          |
      +------------------+--------------------+----------------------------+
      | AvailabilityZone |     CidrBlock      |         SubnetId           |
      +------------------+--------------------+----------------------------+
      |  us-west-2d      |  192.168.0.0/27    |     subnet-example1        |
      |  us-west-2a      |  192.168.0.32/27   |     subnet-example2        |
      |  us-west-2a      |  192.168.0.64/27   |     subnet-example3        |
      |  us-west-2d      |  192.168.0.96/27   |     subnet-example4        |
      |  us-west-2a      |  192.168.1.0/27    |     subnet-example5        |
      |  us-west-2d      |  192.168.1.32/27   |     subnet-example6        |
      +------------------+--------------------+----------------------------+
      ```

      Puede ver que las subredes en el bloque CIDR `192.168.1.0` que ha creado se encuentran en las mismas zonas de disponibilidad que las subredes del bloque CIDR `192.168.0.0`.

## Paso 3: Configurar los recursos de Kubernetes
<a name="custom-networking-configure-kubernetes"></a>

1. Establezca la variable de entorno de `AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG` a `true` en el DaemonSet de `aws-node`.

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

1. Recupere el ID del [grupo de seguridad del clúster](sec-group-reqs.md) y guárdelo en una variable para utilizarlo en un paso posterior. Amazon EKS crea automáticamente este grupo de seguridad cuando crea el clúster.

   ```
   cluster_security_group_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
   ```

1.  Cree un recurso personalizado `ENIConfig` para cada subred en la que desee programar pods.

   1. Cree un archivo único para cada configuración de interfaz de red.

      Los siguientes comandos crean archivos `ENIConfig` por separado de las dos subredes que se han creado en un paso anterior. El valor de `name` debe ser único. El nombre es el mismo que la zona de disponibilidad en la que se encuentra la subred. El grupo de seguridad del clúster está asignado al `ENIConfig`.

      ```
      cat >$az_1.yaml <<EOF
      apiVersion: crd.k8s.amazonaws.com/v1alpha1
      kind: ENIConfig
      metadata:
        name: $az_1
      spec:
        securityGroups:
          - $cluster_security_group_id
        subnet: $new_subnet_id_1
      EOF
      ```

      ```
      cat >$az_2.yaml <<EOF
      apiVersion: crd.k8s.amazonaws.com/v1alpha1
      kind: ENIConfig
      metadata:
        name: $az_2
      spec:
        securityGroups:
          - $cluster_security_group_id
        subnet: $new_subnet_id_2
      EOF
      ```

      Para un clúster de producción, puede realizar los siguientes cambios en los comandos anteriores:
      + Sustituya \$1cluster\$1security\$1group\$1id por el ID de un [grupo de seguridad](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) existente que quiera usar para cada `ENIConfig`.
      + Recomendamos nombrar su `ENIConfigs` igual que la zona de disponibilidad para la que utilizará la `ENIConfig`, siempre que sea posible. Es posible que tenga que utilizar nombres diferentes para su `ENIConfigs` que los nombres de las zonas de disponibilidad por diversas razones. Por ejemplo, si tiene más de dos subredes en la misma zona de disponibilidad y desea utilizarlas con redes personalizadas, necesita varias `ENIConfigs` para la misma zona de disponibilidad. Dado que cada `ENIConfig` requiere un nombre único, no puede nombrar más de una de sus `ENIConfigs` utilizando el nombre de zona de disponibilidad.

        Si los nombres de `ENIConfig` no son todos iguales que los nombres de las zonas de disponibilidad, reemplace \$1az\$11 y \$1az\$12 por sus propios nombres en los comandos anteriores y [anote los nodos con ENIConfig](#custom-networking-annotate-eniconfig) más adelante en este tutorial.
**nota**  
Si no especifica un grupo de seguridad válido para utilizarlo con un clúster de producción y utiliza:
      + la versión `1.8.0` o posterior del complemento CNI de Amazon VPC para Kubernetes, se utilizan los grupos de seguridad asociados a la principal interfaz de redes elástica del nodo.
      + una versión del complemento CNI de Amazon VPC para Kubernetes anterior a `1.8.0`, el grupo de seguridad predeterminado para la VPC se asignará a interfaces de red elásticas secundarias.
**importante**  
 `AWS_VPC_K8S_CNI_EXTERNALSNAT=false` es un ajuste predeterminado de la configuración del complemento CNI de Amazon VPC para Kubernetes. Si utiliza la configuración predeterminada, el tráfico destinado a direcciones IP que no se encuentran dentro de uno de los bloques CIDR asociados a la VPC utiliza los grupos de seguridad y las subredes de la interfaz de la red principal del nodo. Las subredes y los grupos de seguridad definidos en las `ENIConfigs` que se utilizan para crear interfaces de red secundarias no se utilizan para este tráfico. Para obtener más información sobre esta configuración, consulte [Habilitación del acceso a Internet saliente para pods](external-snat.md).
Si también utiliza grupos de seguridad para pods, el grupo de seguridad especificado en `SecurityGroupPolicy` se utiliza en lugar del grupo de seguridad especificado en `ENIConfigs`. Para obtener más información, consulte [Asignación de los grupos de seguridad a pods individuales](security-groups-for-pods.md).

   1. Aplique al clúster cada archivo de recursos personalizados que creó anteriormente con los siguientes comandos:

      ```
      kubectl apply -f $az_1.yaml
      kubectl apply -f $az_2.yaml
      ```

1. Confirmación de que se crearon `ENIConfigs`.

   ```
   kubectl get ENIConfigs
   ```

   Un ejemplo de salida sería el siguiente.

   ```
   NAME         AGE
   us-west-2a   117s
   us-west-2d   105s
   ```

1. Si va a habilitar redes personalizadas en un clúster de producción y da un nombre a `ENIConfigs` que no sea el de la zona de disponibilidad para la que las utiliza, entonces pase al [siguiente paso](#custom-networking-deploy-nodes) para implementar nodos de Amazon EC2.

   Habilite Kubernetes para aplicar automáticamente la `ENIConfig` para una zona de disponibilidad en cualquier nuevo nodo de Amazon EC2 creado en su clúster.

   1. Para ver el clúster de pruebas de este tutorial, vaya al [paso siguiente](#custom-networking-automatically-apply-eniconfig).

      En el caso de un clúster de producción, compruebe si existe una anotación con la clave `k8s.amazonaws.com/eniConfig` para la variable de entorno ` [ENI\$1CONFIG\$1ANNOTATION\$1DEF](https://github.com/aws/amazon-vpc-cni-k8s#eni_config_annotation_def) ` en la especificación del contenedor para el DaemonSet `aws-node`.

      ```
      kubectl describe daemonset aws-node -n kube-system | grep ENI_CONFIG_ANNOTATION_DEF
      ```

      Si se devuelve la salida, la anotación existe. Si no se devuelve ninguna salida, entonces la variable no se establece. Para un clúster de producción, puede utilizar esta configuración o la configuración del siguiente paso. Si utiliza este ajuste, anule el ajuste en el siguiente paso. En este tutorial, se utiliza la configuración del siguiente paso.

   1.  Actualice su DaemonSet `aws-node` para aplicar automáticamente la `ENIConfig` específica de la zona de disponibilidad en cualquier nuevo nodo de Amazon EC2 que se cree en su clúster.

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

## Paso 4: Implementar nodos de Amazon EC2
<a name="custom-networking-deploy-nodes"></a>

1. Creación de un rol de IAM de nodo.

   1. Ejecute el siguiente comando para crear un archivo de política de confianza JSON de IAM.

      ```
      {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": {
              "Service": "ec2.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
          }
        ]
      }
      ```

   1. Cree un rol de IAM y almacene el nombre de recurso de Amazon (ARN) devuelto en una variable para usarla en un paso posterior.

      ```
      node_role_arn=$(aws iam create-role --role-name myCustomNetworkingNodeRole --assume-role-policy-document file://"node-role-trust-relationship.json" \
          --query Role.Arn --output text)
      ```

   1. Adjunte al rol de IAM las tres políticas administradas por IAM necesarias.

      ```
      aws iam attach-role-policy \
        --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy \
        --role-name myCustomNetworkingNodeRole
      aws iam attach-role-policy \
        --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \
        --role-name myCustomNetworkingNodeRole
      aws iam attach-role-policy \
          --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \
          --role-name myCustomNetworkingNodeRole
      ```
**importante**  
Para simplificar este tutorial, la política [AmazonEKS\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html) se adjunta al rol de IAM de nodo. Sin embargo, en un clúster de producción, recomendamos adjuntar la política a un rol de IAM independiente que se usa solo con el complemento CNI de Amazon VPC para Kubernetes. Para obtener más información, consulte [Configuración del complemento de CNI de Amazon VPC para utilizar IRSA](cni-iam-role.md).

1. Cree uno de los siguientes tipos de grupos de nodos. Para determinar el tipo de instancia que desea implementar, consulte [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md). Para este tutorial, complete la opción **Administrado**, **Sin plantilla de lanzamiento o con plantilla de lanzamiento sin un ID de AMI especificado**. Si planea utilizar el grupo de nodos para cargas de trabajo en entornos de producción, se recomienda familiarizarse con todas las opciones disponibles para grupos de nodos [administrados](create-managed-node-group.md) y [autoadministrados](worker.md) antes de proceder con su implementación.
   +  **Administrado**: implemente el grupo de nodos mediante una de las siguientes opciones:
     +  **Sin plantilla de lanzamiento o con plantilla de lanzamiento sin un ID de AMI especificado**: complete el procedimiento indicado. Para este tutorial, utilice los valores de ejemplo. Para un grupo de nodos de producción, reemplace todos los valores de ejemplo con sus propios valores. El nombre del grupo de nodos no puede tener más de 63 caracteres. Debe empezar por una letra o un dígito, pero también puede incluir guiones y guiones bajos como caracteres no iniciales.

       ```
       aws eks create-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup \
           --subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
       ```
     +  **Con una plantilla de lanzamiento con un ID de AMI especificado** 

       1. Determine el número máximo de pods que recomienda Amazon EKS para sus nodos. Siga las instrucciones que aparecen en , con la adición de `--cni-custom-networking-enabled` al paso 3 de ese tema. Observe la salida de su uso en el siguiente paso.

       1. En la plantilla de lanzamiento, especifique un ID de AMI optimizado para Amazon EKS o una AMI personalizada creada a partir de la AMI optimizada para Amazon EKS y, luego, [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 pasan los argumentos a la especificación `NodeConfig`. Para obtener más información sobre NodeConfig, consulte la [referencia de la API de NodeConfig](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfig). Puede sustituir `20` por el valor del paso anterior (recomendado) o por un valor propio.

          ```
          ---
          MIME-Version: 1.0
          Content-Type: multipart/mixed; boundary="BOUNDARY"
          --BOUNDARY
          Content-Type: application/node.eks.aws
          
          ---
          apiVersion: node.eks.aws/v1alpha1
          kind: NodeConfig
          spec:
            cluster:
              name: my-cluster
              ...
              kubelet:
                config:
                  maxPods: 20
          ```

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

     1. Determine el número máximo de pods que recomienda Amazon EKS para sus nodos. Siga las instrucciones de , agregando `--cni-custom-networking-enabled` al paso tres de ese tema. Observe la salida de su uso en el siguiente paso.

     1. Implemente el grupo de nodos con las instrucciones en [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md).
**nota**  
Si desea que los nodos de un clúster de producción admitan un número significativamente mayor de pods, ejecute el script en  de nuevo. Además, agregue la opción `--cni-prefix-delegation-enabled` al siguiente comando. Por ejemplo, se devuelve `110` para un tipo de instancia `m5.large`. Para obtener instrucciones sobre cómo habilitar esta capacidad, consulte [Asignación de más direcciones IP a los nodos de Amazon EKS con prefijos](cni-increase-ip-addresses.md). Puede utilizar esta capacidad con redes personalizadas.

1. La creación de grupos de nodos tarda varios minutos. Puede comprobar el estado de la creación de un grupo de nodos administrados con el siguiente comando.

   ```
   aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
   ```

   No continúe con el siguiente paso hasta que la salida devuelta sea `ACTIVE`.

1.  Para ver el tutorial, puede omitir este paso.

   En caso de un clúster de producción, si no ha nombrado su `ENIConfigs` con el mismo nombre que la zona de disponibilidad para la que la utiliza, entonces debe anotar sus nodos con el nombre de `ENIConfig` que debe utilizarse con el nodo. Este paso no es necesario si tiene solo una subred en cada zona de disponibilidad y ha nombrado sus `ENIConfigs` con los mismos nombres que dichas zonas. Esto se debe a que el complemento CNI de Amazon VPC para Kubernetes asocia automáticamente la `ENIConfig` correcta con el nodo cuando lo habilitó para esto en un [paso anterior](#custom-networking-automatically-apply-eniconfig).

   1. Obtenga la lista de nodos del clúster.

      ```
      kubectl get nodes
      ```

      Un ejemplo de salida sería el siguiente.

      ```
      NAME                                          STATUS   ROLES    AGE     VERSION
      ip-192-168-0-126.us-west-2.compute.internal   Ready    <none>   8m49s   v1.22.9-eks-810597c
      ip-192-168-0-92.us-west-2.compute.internal    Ready    <none>   8m34s   v1.22.9-eks-810597c
      ```

   1. Determine en qué zona de disponibilidad se encuentra cada nodo. Ejecute el siguiente comando para cada nodo que se devolvió en el paso anterior y reemplace las direcciones IP en función del resultado anterior.

      ```
      aws ec2 describe-instances --filters Name=network-interface.private-dns-name,Values=ip-192-168-0-126.us-west-2.compute.internal \
      --query 'Reservations[].Instances[].{AvailabilityZone: Placement.AvailabilityZone, SubnetId: SubnetId}'
      ```

      Un ejemplo de salida sería el siguiente.

      ```
      [
          {
              "AvailabilityZone": "us-west-2d",
              "SubnetId": "subnet-Example5"
          }
      ]
      ```

   1. Anote cada nodo con la `ENIConfig` que creó para el ID de subred y la zona de disponibilidad. Solo puede anotar un nodo con una `ENIConfig`, aunque se pueden anotar varios nodos con la misma `ENIConfig`. Sustituya los valores de ejemplo por sus propios valores.

      ```
      kubectl annotate node ip-192-168-0-126.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName1
      kubectl annotate node ip-192-168-0-92.us-west-2.compute.internal k8s.amazonaws.com/eniConfig=EniConfigName2
      ```

1.  Si tenía nodos en un clúster de producción con pods en ejecución antes de comenzar a utilizar la característica de redes personalizadas, lleve a cabo las siguientes tareas:

   1. Asegúrese de tener nodos disponibles que utilizan la característica de red personalizada.

   1. Acordone y drene los nodos para apagar correctamente los pods. Para obtener más información, consulte [Drene un nodo de manera segura](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) en la documentación de Kubernetes.

   1. Termine los nodos. Si los nodos se encuentran en un grupo de nodos administrado existente, puede eliminar el grupo de nodos. Ejecute el siguiente comando.

      ```
      aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
      ```

   Solo los nodos nuevos que se registran con la etiqueta `k8s.amazonaws.com/eniConfig` utilizan la característica de redes personalizadas.

1. Confirme que los pods estén asignados en una dirección IP de un bloque de CIDR asociado a una de las subredes que creó en un paso anterior.

   ```
   kubectl get pods -A -o wide
   ```

   Un ejemplo de salida sería el siguiente.

   ```
   NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE     IP              NODE                                          NOMINATED NODE   READINESS GATES
   kube-system   aws-node-2rkn4             1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   aws-node-k96wp             1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>
   kube-system   coredns-657694c6f4-smcgr   1/1     Running   0          56m     192.168.1.23    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   coredns-657694c6f4-stwv9   1/1     Running   0          56m     192.168.1.28    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   kube-proxy-jgshq           1/1     Running   0          7m19s   192.168.0.92    ip-192-168-0-92.us-west-2.compute.internal    <none>           <none>
   kube-system   kube-proxy-wx9vk           1/1     Running   0          7m15s   192.168.0.126   ip-192-168-0-126.us-west-2.compute.internal   <none>           <none>
   ```

   Puede ver que a los pods de CoreDNS se les asignan direcciones IP desde el bloque de CIDR `192.168.1.0` que ha agregado a la VPC. Sin redes personalizadas, se les habrían asignado direcciones desde el bloque CIDR `192.168.0.0`, porque era el único bloque CIDR asociado originalmente a la VPC.

   Si la `spec` de un pod contiene `hostNetwork=true`, se le asigna la dirección IP principal del nodo. No se le asigna una dirección de las subredes que ha agregado. De forma predeterminada, este valor se establece en `false`. Este valor se establece en `true` para `kube-proxy` y los pods del complemento CNI de Amazon VPC para Kubernetes (`aws-node`) que se ejecutan en su clúster. Esta es la razón por la que a `kube-proxy` y a los pods de `aws-node` del complemento no se les asignan direcciones 192.168.1.x en la salida anterior. Para obtener más información acerca de la configuración de `hostNetwork` del pod, consulte [PodSpec v1 core](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.35/#podspec-v1-core) en la referencia de API de Kubernetes.

## Paso 5: eliminar recursos del tutorial
<a name="custom-network-delete-resources"></a>

Una vez completado el tutorial, le recomendamos que elimine los recursos que creó. Puede ajustar los pasos para habilitar las redes personalizadas para un clúster de producción.

1. Si el grupo de nodos que creó fue solo para pruebas, bórrelo.

   ```
   aws eks delete-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup
   ```

1. Incluso después de que la salida de la AWS CLI indica que el clúster se ha eliminado, es posible que el proceso de eliminación no esté completo. El proceso de eliminación tarda unos minutos. Confirme que se ha completado al ejecutar el siguiente comando.

   ```
   aws eks describe-nodegroup --cluster-name my-custom-networking-cluster --nodegroup-name my-nodegroup --query nodegroup.status --output text
   ```

   No continúe hasta que la salida devuelta sea similar a la siguiente.

   ```
   An error occurred (ResourceNotFoundException) when calling the DescribeNodegroup operation: No node group found for name: my-nodegroup.
   ```

1. Si el grupo de nodos que creó fue solo para pruebas, elimine el rol de IAM de nodo.

   1. Separe la política del rol.

      ```
      aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
      aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
      aws iam detach-role-policy --role-name myCustomNetworkingNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
      ```

   1. Elimine el rol.

      ```
      aws iam delete-role --role-name myCustomNetworkingNodeRole
      ```

1. Elimine el clúster.

   ```
   aws eks delete-cluster --name my-custom-networking-cluster
   ```

   Confirme que el clúster se elimine con el siguiente comando.

   ```
   aws eks describe-cluster --name my-custom-networking-cluster --query cluster.status --output text
   ```

   Cuando se devuelve un resultado similar al siguiente, el clúster se eliminará correctamente.

   ```
   An error occurred (ResourceNotFoundException) when calling the DescribeCluster operation: No cluster found for name: my-custom-networking-cluster.
   ```

1. Elimine el rol de IAM del clúster.

   1. Separe la política del rol.

      ```
      aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
      ```

   1. Elimine el rol.

      ```
      aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
      ```

1. Elimine las subredes que creó en un paso anterior.

   ```
   aws ec2 delete-subnet --subnet-id $new_subnet_id_1
   aws ec2 delete-subnet --subnet-id $new_subnet_id_2
   ```

1. Elimine la VPC que ha creado.

   ```
   aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc
   ```