Redes personalizadas para los pods - Amazon EKS

Redes personalizadas para los pods

De forma predeterminada, cuando el Amazon VPC CNI plugin for Kubernetes crea interfaces de red elásticas secundarias (interfaces de red) para su nodo Amazon EC2, las crea en la misma subred que la interfaz de red principal del nodo. También asocia los mismos grupos de seguridad a la interfaz de red secundaria asociada a la interfaz de red principal. Por uno o varios de los siguientes motivos, es posible que desee que el complemento cree interfaces de red secundarias en una subred diferente o desee asociar distintos grupos de seguridad a las interfaces de red secundarias, o ambas:

  • Hay un número limitado de direcciones IPv4 que están disponibles en la subred en la que se encuentra la interfaz de red principal. Esto podría limitar el número de Pods que puede crear en la subred. Si utiliza una subred diferente para las interfaces de red secundarias, puede aumentar el número de direcciones IPv4 disponibles para Pods.

  • Por motivos de seguridad, sus Pods podrían tener que utilizar distintos grupos de seguridad o subredes que la interfaz de red principal del nodo.

  • Los nodos se encuentran configurados en subredes públicas y debe ubicar los Pods en subredes privadas. La tabla de enrutamiento asociada a una subred pública incluye una puerta de enlace de Internet. La tabla de enrutamiento asociada a una subred privada no incluye ninguna puerta de enlace de Internet.

Consideraciones
  • Con las redes personalizadas habilitadas, no se asignan direcciones IP asignadas a la interfaz de red principal a los Pods. Solo se asignan direcciones IP de interfaces de red secundarias a Pods.

  • Si el clúster utiliza la familia IPv6, no puede utilizar redes personalizadas.

  • Si planea utilizar redes personalizadas solo para ayudar a aliviar el agotamiento de direcciones IPv4, puede crear un clúster mediante la familia IPv6 en su lugar. Para obtener más información, consulte Tutorial: Asignación de direcciones IPv6 a Pods y services.

  • Si bien los Pods implementados en las subredes especificadas para interfaces de red secundarias pueden utilizar subredes y grupos de seguridad diferentes a los de la interfaz de red principal del nodo, las subredes y los grupos de seguridad deben estar en la misma VPC que el nodo.

Requisitos previos
  • Estar familiarizado con cómo Amazon VPC CNI plugin for Kubernetes crea interfaces de red secundarias y asigna direcciones IP a los Pods. Para obtener más información, consulte Asignación de ENI en GitHub.

  • La versión 2.12.3 o posterior, o bien, la versión 1.27.160 o posterior de la AWS Command Line Interface (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 tales 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 Instalar, actualizar y desinstalar la AWS CLI y Configuración rápida con aws configure en la Guía del usuario de AWS Command Line Interface. 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 AWS CLI en el directorio de inicio 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. La versión puede ser la misma o hasta una versión secundaria anterior o posterior a la versión de Kubernetes de su clúster. Por ejemplo, si la versión del clúster es 1.28, puede usar la versión 1.27, 1.28 o 1.29 de kubectl con él. Para instalar o actualizar kubectl, consulte Instalación o actualización del kubectl.

  • 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 entrecomillado de cadenas en la AWS CLI de la Guía del usuario de la AWS Command Line Interface.

Para este tutorial, le recomendamos utilizar el example values, excepto en los casos en que se indique que los reemplace. Puede reemplazar cualquier example value al completar los pasos del 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 AWS CLI. 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 de la AWS CLI que está utilizando, tendrá que agregar --region region-code a los comandos.

Cuando desee implementar redes personalizadas en su clúster de producción, vaya a Paso 2: Configurar la VPC.

Paso 1: crear una VPC de prueba y un clúster

Pasos para crear un clúster

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

  1. Defina algunas variables para utilizarlas en los pasos restantes.

    export cluster_name=my-custom-networking-cluster account_id=$(aws sts get-caller-identity --query Account --output text)
  2. Cree una VPC.

    1. Cree una VPC mediante una plantilla de Amazon EKS AWS CloudFormation.

      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

      La pila 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.

    2. 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)
    3. 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)
  3. 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.

      cat >eks-cluster-role-trust-policy.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF
    2. 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 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"
    3. Adjunte la política administrada de IAM por Amazon EKS denominada AmazonEKSClusterPolicy al rol. Para adjuntar una política de IAM a una entidad principal de IAM, 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
  4. 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.

    2. 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".

    3. Configure kubectl para comunicarse con el clúster.

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

Paso 2: Configurar la VPC

Este tutorial requiere una VPC creada en Paso 1: crear una VPC de prueba y un clúster. En el caso de un clúster de producción, ajuste los pasos correspondientes a su VPC sustituyendo todos los example values con los suyos propios.

  1. Confirme que la versión de Amazon VPC CNI plugin for Kubernetes instalada actualmente sea la más reciente. 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. Para determinar la versión más reciente del tipo de complemento autoadministrado y actualizar su versión a ella, consulte Trabajar con el complemento Amazon VPC CNI plugin for Kubernetes de Amazon EKS.

  2. Recupere el ID de la VPC de su clúster y guárdelo en una variable para utilizarlo en un paso posterior. Para un clúster de producción, sustituya my-custom-networking-cluster con el nombre de su clúster.

    vpc_id=$(aws eks describe-cluster --name my-custom-networking-cluster --query "cluster.resourcesVpcConfig.vpcId" --output text)
  3. 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  |
      +-----------------+--------------+
    2. Asocie un bloque CIDR adicional a su VPC. Para obtener más información, consulte Asociar un bloque de CIDR IPv4 adicional a su VPC 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
    3. 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.

  4. 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. 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 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 en la Guía del usuario de Amazon VPC.

    2. 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: Configure los recursos de Kubernetes

Para configurar los recursos de Kubernetes
  1. Establezca la variable de entorno de AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG en true en el aws-node DaemonSet.

    kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
  2. Recupere el ID del grupo de seguridad del clúster 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 $cluster_name --query cluster.resourcesVpcConfig.clusterSecurityGroupId --output text)
  3. 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:

      • Reemplace $cluster_security_group_id con el ID de un grupo de seguridad existente que desea utilizar para cada ENIConfig.

      • Recomendamos nombrar su ENIConfigs igual que la zona de disponibilidad para la que utilizará el 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 sus ENIConfig no son todos iguales que los nombres de las zonas de disponibilidad, entonces reemplace $az_1 y $az_2 con sus propios nombres en los comandos anteriores y anote los nodos con la 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 Amazon VPC CNI plugin for de Kubernetes, entonces se utilizan los grupos de seguridad asociados a la principal interfaz de redes elástica del nodo.

      • una versión del Amazon VPC CNI plugin for Kubernetes anterior a 1.8.0, entonces 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 red principal del nodo. Las subredes y los grupos de seguridad definidos en la 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 SNAT para Pods.

      • Si también utiliza grupos de seguridad para Pods, el grupo de seguridad especificado en una SecurityGroupPolicy se utiliza en lugar del grupo de seguridad especificado en la ENIConfigs. Para obtener más información, consulte Grupos de seguridad de Pods.

    2. 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
  4. 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
  5. Si está habilitando redes personalizadas en un clúster de producción y da un nombre a su ENIConfigs que no sea la zona de disponibilidad para la que las utiliza, entonces pase al siguiente paso 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 siguiente paso.

      En caso de un clúster de producción, compruebe si existe una annotation con la clave k8s.amazonaws.com/eniConfig para la variable de entorno ENI_CONFIG_ANNOTATION_DEF en la especificación del contenedor para el aws-node DaemonSet.

      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.

    2. Actualice su aws-node DaemonSet para aplicar automáticamente la ENIConfig para una zona de disponibilidad para cualquier nuevo nodo de Amazon EC2 creado 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

Para implementar nodos de Amazon EC2
  1. Cree un rol de IAM de nodo.

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

      cat >node-role-trust-relationship.json <<EOF { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF
    2. Ejecute el siguiente comando para establecer una variable para el nombre de su rol. Puede reemplazar myCustomNetworkingAmazonEKSNodeRole con cualquier nombre que elija.

      export node_role_name=myCustomNetworkingAmazonEKSNodeRole
    3. Cree el 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 $node_role_name --assume-role-policy-document file://"node-role-trust-relationship.json" \ --query Role.Arn --output text)
    4. 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 $node_role_name aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly \ --role-name $node_role_name aws iam attach-role-policy \ --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy \ --role-name $node_role_name
      importante

      Para simplificar este tutorial, la política AmazonEKS_CNI_Policy 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 Amazon VPC CNI plugin for Kubernetes. Para obtener más información, consulte Configuración del Amazon VPC CNI plugin for Kubernetes para utilizar los roles de IAM en las cuentas de servicio.

  2. 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 Amazon EC2. Para este tutorial, complete la opción Administrado, Sin plantilla de lanzamiento o con plantilla de lanzamiento sin un ID de AMI especificado. Si va a utilizar el grupo de nodos para cargas de trabajo de producción, le recomendamos que se familiarice con todas las opciones de grupo de nodos administrados y autoadministrados antes de implementar el grupo de nodos.

    • 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, usaremos los example values. Para un grupo de nodos de producción, sustituya todos los example values con los suyos propios. 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 $cluster_name --nodegroup-name my-nodegroup \ --subnets $subnet_id_1 $subnet_id_2 --instance-types t3.medium --node-role $node_role_arn
      • Con 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 de Número máximo de Pods recomendado por Amazon EKS para cada tipo de instancia de Amazon EC2, agregando --cni-custom-networking-enabled al paso tres de ese tema. Observe la salida de su uso en el siguiente paso.

        2. 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 y proporcione los siguientes datos de usuario en la plantilla de lanzamiento. Estos datos de usuario pasan los argumentos en el archivo bootstrap.sh. Para obtener más información acerca del archivo del proceso de arranque, consulte bootstrap.sh en GitHub. Puede sustituir 20 por el valor del paso anterior (recomendado) o por un valor propio.

          /etc/eks/bootstrap.sh my-cluster --use-max-pods false --kubelet-extra-args '--max-pods=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 Número máximo de Pods recomendado por Amazon EKS para cada tipo de instancia de Amazon EC2, agregando --cni-custom-networking-enabled al paso tres de ese tema. Observe la salida de su uso en el siguiente paso.

      2. Implemente el grupo de nodos con las instrucciones en Lanzar nodos autoadministrados de Amazon Linux. Especifique el siguiente texto para el parámetro BootstrapArguments. Puede sustituir 20 por el valor del paso anterior (recomendado) o por un valor propio.

        --use-max-pods false --kubelet-extra-args '--max-pods=20'
    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 Número máximo de Pods recomendado por Amazon EKS para cada tipo de instancia de Amazon EC2 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 Aumentar la cantidad de direcciones IP disponibles para sus nodos de Amazon EC2. Puede utilizar esta capacidad con redes personalizadas.

    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 $cluster_name --nodegroup-name my-nodegroup --query nodegroup.status --output text

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

  3. 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 solo tiene una subred en cada zona de disponibilidad y ha dado nombre a sus ENIConfigs con los mismos nombres que las zonas de disponibilidad. Esto se debe a que el Amazon VPC CNI plugin for de Kubernetes asocia automáticamente la ENIConfig correcta con el nodo para usted cuando lo habilitó para esto en un paso anterior.

    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
    2. Determine en qué zona de disponibilidad se encuentra cada nodo. Ejecute el siguiente comando para cada nodo que se devolvió en el paso 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" } ]
    3. 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. Reemplace los example values por los de su propiedad.

      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
  4. Si tenía nodos en un clúster de producción con ejecución Pods antes de cambiar para utilizar la característica de redes personalizadas, realice las siguientes tareas:

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

    2. Acordone y drene los nodos para apagar con gracia el Pods. Para obtener más información, consulte Drene un nodo de manera segura en la documentación de Kubernetes.

    3. Termine los nodos. Si los nodos se encuentran en un grupo de nodos administrado existente, puede eliminar el grupo de nodos. Copie el comando que sigue en su dispositivo. Realice las siguientes modificaciones en el comando según sea necesario y, a continuación, ejecute el comando modificado:

      • Reemplace my-cluster por el nombre del clúster.

      • Reemplace my-nodegroup por el nombre de su grupo de nodos.

      aws eks delete-nodegroup --cluster-name my-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.

  5. Confirme que los Pods estén asignados en una dirección IP de un bloque 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 coredns Pods se les asignan direcciones IP desde el bloque 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's 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 los Pods kube-proxy y Amazon VPC CNI plugin for Kubernetes (aws-node) que se ejecutan en el clúster. Es por eso que al kube-proxy y a los pods Pods de aws-node del complemento no se les asignan direcciones 192.168.1.x de la salida anterior. Para obtener más información acerca de la configuración de hostNetwork de Pod's, consulte Núcleo de PodSpec v1 en la referencia de API de Kubernetes.

Paso 5: eliminar recursos del tutorial

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.

Para eliminar los recursos del tutorial
  1. Si el grupo de nodos que creó fue solo para pruebas, bórrelo.

    aws eks delete-nodegroup --cluster-name $cluster_name --nodegroup-name my-nodegroup

    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 $cluster_name --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.
  2. 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 myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSNodeRole --policy-arn arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
    2. Elimine el rol.

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSNodeRole
  3. Eliminar el clúster.

    aws eks delete-cluster --name $cluster_name

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

    aws eks describe-cluster --name $cluster_name --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-cluster.
  4. 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
    2. Elimine el rol.

      aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
  5. 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
  6. Elimine la VPC que ha creado.

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