Ayude a mejorar esta página
¿Quiere contribuir a esta guía del usuario? Desplácese hasta el final de esta página y seleccione Editar esta página en GitHub. Sus contribuciones ayudarán a que nuestra guía del usuario sea mejor para todos.
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 direccionesIPv4
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 familiaIPv6
en su lugar. Para obtener más información, consulte Direcciones IPv6 de clústeres, 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ón1.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
. Los administradores de paquetes tales comoaws --version | cut -d / -f2 | cut -d ' ' -f1
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 es1.29
, puede usar la versión1.28
,1.29
o1.30
dekubectl
con él. Para instalar o actualizarkubectl
, consulte Configuración de kubectl y eksctl. -
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
, excepto en los casos en que se indique que los reemplace. Puede reemplazar cualquier example
values
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.example value
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
a los comandos.region-code
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 Crear un clúster de Amazon EKS.
-
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)
-
Cree una VPC.
-
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
. -
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)
-
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)
-
-
Cree un rol de IAM de clúster.
-
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
-
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óniam:CreateRole
(permiso).aws iam create-role --role-name myCustomNetworkingAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
-
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
oiam:AttachRolePolicy
.aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy --role-name myCustomNetworkingAmazonEKSClusterRole
-
-
Cree un clúster de Amazon EKS y configure su dispositivo para que se comunique con él.
-
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.
-
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"
. -
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
con los suyos propios.example
values
-
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.
-
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
con el nombre de su clúster.my-custom-networking-cluster
vpc_id=$(aws eks describe-cluster --name
my-custom-networking-cluster
--query "cluster.resourcesVpcConfig.vpcId" --output text) -
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.
-
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 | +-----------------+--------------+ -
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
-
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 seaassociated
. -
-
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.
-
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-block192.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.
-
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 CIDR192.168.0.0
.
-
Paso 3: Configure los recursos de Kubernetes
Para configurar los recursos de Kubernetes
-
Establezca la variable de entorno de
AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG
entrue
en elaws-node
DaemonSet
.kubectl set env daemonset aws-node -n kube-system AWS_VPC_K8S_CNI_CUSTOM_NETWORK_CFG=true
-
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)
-
Cree un recurso personalizado
ENIConfig
para cada subred en la que desee programar Pods.-
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 dename
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 alENIConfig
.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
EOFcat >$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
EOFPara un clúster de producción, puede realizar los siguientes cambios en los comandos anteriores:
-
Reemplace
con el ID de un grupo de seguridad existente que desea utilizar para cada$cluster_security_group_id
ENIConfig
. -
Recomendamos nombrar su
ENIConfigs
igual que la zona de disponibilidad para la que utilizará elENIConfig
, siempre que sea posible. Es posible que tenga que utilizar nombres diferentes para suENIConfigs
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 variasENIConfigs
para la misma zona de disponibilidad. Dado que cadaENIConfig
requiere un nombre único, no puede nombrar más de una de susENIConfigs
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
y$az_1
con sus propios nombres en los comandos anteriores y anote los nodos con la ENIConfig más adelante en este tutorial.$az_2
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 laENIConfigs
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 laENIConfigs
. Para obtener más información, consulte Grupos de seguridad de Pods.
-
-
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
-
-
Confirmación de que se crearon
ENIConfigs
.kubectl get ENIConfigs
Un ejemplo de salida sería el siguiente.
NAME AGE
us-west-2a
117sus-west-2d
105s -
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.-
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 entornoENI_CONFIG_ANNOTATION_DEF
en la especificación del contenedor para elaws-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.
-
Actualice su
aws-node
DaemonSet
para aplicar automáticamente laENIConfig
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
-
Cree un rol de IAM de nodo.
-
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 -
Ejecute el siguiente comando para establecer una variable para el nombre de su rol. Puede reemplazar
con cualquier nombre que elija.myCustomNetworkingAmazonEKSNodeRole
export node_role_name=
myCustomNetworkingAmazonEKSNodeRole
-
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) -
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 de Amazon VPC CNI plugin for Kubernetes para utilizar los roles de IAM en las cuentas de servicio (IRSA).
-
-
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
. Para un grupo de nodos de producción, sustituya todos losexample 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.example values
aws eks create-nodegroup --cluster-name $cluster_name --nodegroup-name
my-nodegroup
\ --subnets$subnet_id_1
$subnet_id_2
--instance-typest3.medium
--node-role $node_role_arn -
Con plantilla de lanzamiento con un ID de AMI especificado
-
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
al paso tres de ese tema. Observe la salida de su uso en el siguiente paso.--cni-custom-networking-enabled
-
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.shen GitHub. Puede sustituir
por el valor del paso anterior (recomendado) o por un valor propio.20
/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
-
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
al paso tres de ese tema. Observe la salida de su uso en el siguiente paso.--cni-custom-networking-enabled
-
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
por el valor del paso anterior (recomendado) o por un valor propio.20
--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
al siguiente comando. Por ejemplo, se devuelve--cni-prefix-delegation-enabled
para un tipo de instancia110
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 textNo continúe con el paso siguiente hasta que la salida devuelta sea
ACTIVE
. -
-
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 deENIConfig
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 susENIConfigs
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 laENIConfig
correcta con el nodo para usted cuando lo habilitó para esto en un paso anterior.-
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 -
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
" } ] -
Anote cada nodo con la
ENIConfig
que creó para el ID de subred y la zona de disponibilidad. Solo puede anotar un nodo con unaENIConfig
, aunque se pueden anotar varios nodos con la mismaENIConfig
. Reemplace los
por los de su propiedad.example values
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
-
-
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:
-
Asegúrese de tener nodos disponibles que utilizan la característica de red personalizada.
-
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. -
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
por el nombre del clúster.my-cluster
-
Reemplace
por el nombre de su grupo de nodos.my-nodegroup
aws eks delete-nodegroup --cluster-name
my-cluster
--nodegroup-namemy-nodegroup
-
Solo los nodos nuevos que se registran con la etiqueta
k8s.amazonaws.com/eniConfig
utilizan la característica de redes personalizadas. -
-
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 CIDR192.168.1.0
que ha agregado a la VPC. Sin redes personalizadas, se les habrían asignado direcciones desde el bloque CIDR192.168.0.0
, porque era el único bloque CIDR asociado originalmente a la VPC.Si la
spec
de un Pod's contienehostNetwork=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 enfalse
. Este valor se establece entrue
para los Podskube-proxy
y Amazon VPC CNI plugin for Kubernetes (aws-node
) que se ejecutan en el clúster. Es por eso que alkube-proxy
y a los pods Pods deaws-node
del complemento no se les asignan direcciones192.168.1.x
de la salida anterior. Para obtener más información acerca de la configuración dehostNetwork
de Pod's, consulte Núcleo de PodSpec v1en 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
-
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.
-
Si el grupo de nodos que creó fue solo para pruebas, elimine el rol de IAM de nodo.
-
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
-
Elimine el rol.
aws iam delete-role --role-name myCustomNetworkingAmazonEKSNodeRole
-
-
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.
-
Elimine el rol de IAM del clúster.
-
Separe la política del rol.
aws iam detach-role-policy --role-name myCustomNetworkingAmazonEKSClusterRole --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy
-
Elimine el rol.
aws iam delete-role --role-name myCustomNetworkingAmazonEKSClusterRole
-
-
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
-
Elimine la VPC que ha creado.
aws cloudformation delete-stack --stack-name my-eks-custom-networking-vpc