**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. # Actualización de los nodos autoadministrados para un clúster Cuando se lanza una nueva AMI optimizada para Amazon EKS, considere la posibilidad de reemplazar los nodos del grupo de nodos autoadministrados con la nueva AMI. Asimismo, si ha actualizado la versión de Kubernetes del clúster de Amazon EKS, actualice los nodos para utilizarlos con la misma versión de Kubernetes. **importante** En este tema, se explican las actualizaciones de los nodos autoadministrados. Si utiliza [grupos de nodos administrados](managed-node-groups.md), consulte [Actualización de un grupo de nodos administrados para un clúster](update-managed-node-group.md). Existen dos formas básicas de actualizar grupos de nodos autoadministrados en los clústeres para utilizar una nueva AMI: ** [Migre sus aplicaciones a un nuevo grupo de nodos](migrate-stack.md) ** Cree un nuevo grupo de nodos y migre los pods a ese grupo. La migración a un nuevo grupo de nodos es más sencilla que simplemente actualizar el ID de la AMI en una pila de AWS CloudFormation existente. Esto se debe a que el proceso de migración [marca](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) al antiguo grupo de nodos como `NoSchedule` y drena los nodos después de que una nueva pila esté lista para aceptar la carga de trabajo del pod existente. ** [Actualizar una pila de nodos de AWS CloudFormation](update-stack.md) ** Actualice la pila de AWS CloudFormation para que un grupo de nodos existente utilice la nueva AMI. Este método no es compatible con los grupos de nodos creados con `eksctl`. # Migración de aplicaciones a un nuevo grupo de nodos En este tema, se describe cómo crear un nuevo grupo de nodos, migrar de forma correcta las aplicaciones existentes al nuevo grupo y eliminar el antiguo grupo de nodos del clúster. Puede migrar a un nuevo grupo de nodos mediante `eksctl` o la Consola de administración de AWS. + [`eksctl`](#eksctl_migrate_apps) + [Consola de administración de AWS y AWS CLI](#console_migrate_apps) ## `eksctl` **Migre sus aplicaciones a un nuevo grupo de nodos con `eksctl` ** Para obtener más información sobre el uso de eksctl para la migración, consulte [Nodos no administrados](https://eksctl.io/usage/nodegroup-unmanaged/) en la documentación de `eksctl`. En este procedimiento, se requiere la versión `0.215.0` o posterior de `eksctl`. Puede verificar la versión con el siguiente comando: ``` eksctl version ``` Para obtener instrucciones sobre cómo instalar o actualizar `eksctl`, consulte [Instalación](https://eksctl.io/installation) en la documentación de `eksctl`. **nota** Este procedimiento solo funciona para los clústeres y grupos de nodos que se crearon con `eksctl`. 1. Recupere el nombre de los grupos de nodos existentes al sustituir *mi clúster* por el nombre del clúster. ``` eksctl get nodegroups --cluster=my-cluster ``` Un ejemplo de salida sería el siguiente. ``` CLUSTER NODEGROUP CREATED MIN SIZE MAX SIZE DESIRED CAPACITY INSTANCE TYPE IMAGE ID default standard-nodes 2019-05-01T22:26:58Z 1 4 3 t3.medium ami-05a71d034119ffc12 ``` 1. Lance un nuevo grupo de nodos con `eksctl` mediante el siguiente comando. En el comando, sustituya cada *valor de ejemplo* por sus valores propios. El número de versión no puede ser posterior a la versión de Kubernetes del plano de control. Además, no puede ser más de dos versiones secundarias anteriores a la versión de Kubernetes para el plano de control. Recomendamos que utilice la misma versión que el plano de control. Se recomienda bloquear el acceso al pod a IMDS si se cumplen las siguientes condiciones: + Tiene previsto asignar roles de IAM a todas sus cuentas de servicio de Kubernetes para que los pods solo tengan los permisos mínimos que necesitan. + Ninguno de los pods del clúster requiere acceso al servicio de metadatos de instancias (IMDS) de Amazon EC2 por otros motivos, como la recuperación de la región de AWS actual. Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). Si desea bloquear el acceso del pod a IMDS, agregue la opción `--disable-pod-imds` al siguiente comando. **nota** Para obtener más marcadores disponibles y sus descripciones, consulte https://eksctl.io/. ``` eksctl create nodegroup \ --cluster my-cluster \ --version 1.35 \ --name standard-nodes-new \ --node-type t3.medium \ --nodes 3 \ --nodes-min 1 \ --nodes-max 4 \ --managed=false ``` 1. Cuando se complete el comando anterior, verifique con el siguiente comando que todos los nodos tengan el estado `Ready` (Listo): ``` kubectl get nodes ``` 1. Elimine el grupo de nodos original con el siguiente comando. En el comando, sustituya cada *valor de ejemplo* con los nombres del clúster y el grupo de nodos: ``` eksctl delete nodegroup --cluster my-cluster --name standard-nodes-old ``` ## Consola de administración de AWS y AWS CLI **Migre sus aplicaciones a un nuevo grupo de nodos con la Consola de administración de AWS y la AWS CLI** 1. Lance un nuevo grupo de nodos mediante los pasos que se indican en [Creación de nodos autoadministrados de Amazon Linux](launch-workers.md). 1. Una vez completada la creación de la pila, selecciónela en la consola y elija **Salidas**. 1. Anote el valor de **NodeInstanceRoles** correspondiente al grupo de nodos creado. Lo necesita para agregar los nuevos nodos de Amazon EKS al clúster. **nota** Si ha adjuntado políticas de IAM adicionales al rol de IAM del grupo de nodos anterior, debe adjuntar esas mismas políticas al rol de IAM del nuevo grupo de nodos para mantener esa funcionalidad en el nuevo grupo. Esto se aplica si ha agregado permisos para el [escalador automático del clúster](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) de Kubernetes, por ejemplo. 1. Actualice los grupos de seguridad de ambos grupos de nodos para que puedan comunicarse entre sí. Para obtener más información, consulte [Revisión de requisitos de grupos de seguridad de Amazon EKS para clústeres](sec-group-reqs.md). 1. Anote los ID de grupo de seguridad de ambos grupos de nodos. Esto se muestra como el valor **NodeSecurityGroup** en los resultados de la pila de AWS CloudFormation. Puede utilizar los siguientes comandos de la AWS CLI para obtener los ID de grupo de seguridad de los nombres de pilas. En estos comandos, `oldNodes` es el nombre de pila de AWS CloudFormation de la pila de nodos antigua y `newNodes` es el nombre de la pila a la que migrará. Reemplace todos los *valores de ejemplo* por sus propios valores. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) ``` 1. Agregue reglas de entrada a cada grupo de seguridad de nodos para que acepten tráfico de los otros grupos. Los siguientes comandos de la AWS CLI agregan reglas de entrada a cada grupo de seguridad que permiten todo el tráfico en todos los protocolos del otro grupo de seguridad. Esta configuración permite que los pods de cada grupo de nodos se comuniquen entre ellos mientras migra la carga de trabajo al nuevo grupo. ``` aws ec2 authorize-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 authorize-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Edite el mapa de configuración de `aws-auth` para asignar el rol de la instancia del nuevo nodo en RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Agregue una nueva entrada `mapRoles` para el nuevo grupo de nodos. ``` apiVersion: v1 data: mapRoles: | - rolearn: ARN of instance role (not instance profile) username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes ``` Sustituya el fragmento *ARN of instance role (not instance profile)* por el valor de **NodeInstanceRole** anotado en el [procedimiento anterior](#node-instance-role-step). A continuación, guarde y cierre el archivo para aplicar el configmap actualizado. 1. Examine el estado de los nodos y espere a que los nuevos nodos se unan al clúster y tengan el estado `Ready` (Listo). ``` kubectl get nodes --watch ``` 1. (Opcional) Si utiliza el [escalador automático del clúster de Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), escale la implementación a cero (0) réplicas para evitar acciones de escalado en conflicto. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Utilice el siguiente comando para agregar taints en cada uno de los nodos que desee eliminar con `NoSchedule`. Esto es para que los nuevos pods no se programen ni se vuelvan a programar en los nodos que va a reemplazar. Para obtener más información, consulte [Taints y toleraciones](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) en la documentación de Kubernetes. ``` kubectl taint nodes node_name key=value:NoSchedule ``` Si va a actualizar los nodos a una nueva versión de Kubernetes, puede identificar todos los nodos de una determinada versión de Kubernetes (en este caso, `1.33`) y aplicarles una taint con el siguiente fragmento de código. El número de versión no puede ser posterior a la versión de Kubernetes del plano de control. Además, no puede ser más de dos versiones secundarias anteriores a la versión de Kubernetes del plano de control. Recomendamos que utilice la misma versión que el plano de control. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Tainting $node" kubectl taint nodes $node key=value:NoSchedule done ``` 1. Identifique el proveedor de DNS del clúster. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Un ejemplo de salida sería el siguiente. Este clúster utiliza CoreDNS para la resolución de DNS, pero el clúster puede devolver `kube-dns` en su lugar: ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Si su implementación actual está ejecutando menos de dos réplicas, escale la implementación a dos réplicas. Cambie *coredns* por `kubedns` si el resultado del comando anterior ha devuelto ese valor. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. Vacíe cada uno de los nodos que desea eliminar de su clúster con el siguiente comando: ``` kubectl drain node_name --ignore-daemonsets --delete-local-data ``` Si va a actualizar los nodos a una nueva versión de Kubernetes, identifique y drene todos los nodos de una determinada versión de Kubernetes (en este caso *1.33*) con el siguiente fragmento de código. ``` K8S_VERSION=1.33 nodes=$(kubectl get nodes -o jsonpath="{.items[?(@.status.nodeInfo.kubeletVersion==\"v$K8S_VERSION\")].metadata.name}") for node in ${nodes[@]} do echo "Draining $node" kubectl drain $node --ignore-daemonsets --delete-local-data done ``` 1. Una vez que haya terminado de vaciar los nodos antiguos, revoque las reglas de entrada del grupo de seguridad que autorizó anteriormente. A continuación, elimine la pila de AWS CloudFormation para terminar las instancias. **nota** Si ha adjuntado políticas de IAM adicionales al rol de IAM del grupo de nodos anterior, como agregar permisos para el [escalador automático del clúster de Kubernetes](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), desconecte esas políticas adicionales del rol antes de eliminar la pila de AWS CloudFormation. 1. Revoque las reglas de entrada que creó anteriormente para los grupos de seguridad de nodos. En estos comandos, `oldNodes` es el nombre de pila de AWS CloudFormation de la pila de nodos antigua y `newNodes` es el nombre de la pila a la que migrará. ``` oldNodes="old_node_CFN_stack_name" newNodes="new_node_CFN_stack_name" oldSecGroup=$(aws cloudformation describe-stack-resources --stack-name $oldNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) newSecGroup=$(aws cloudformation describe-stack-resources --stack-name $newNodes \ --query 'StackResources[?ResourceType==`AWS::EC2::SecurityGroup`].PhysicalResourceId' \ --output text) aws ec2 revoke-security-group-ingress --group-id $oldSecGroup \ --source-group $newSecGroup --protocol -1 aws ec2 revoke-security-group-ingress --group-id $newSecGroup \ --source-group $oldSecGroup --protocol -1 ``` 1. Abra la [AWS consola de CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Seleccione la pila de nodos antigua. 1. Elija **Eliminar**. 1. En el cuadro de diálogo de confirmación **Eliminar pila**, elija **Eliminar pila**. 1. Edite el mapa de configuración de `aws-auth` para eliminar el rol de la instancia del nodo anterior de RBAC. ``` kubectl edit configmap -n kube-system aws-auth ``` Elimine la entrada `mapRoles` del grupo de nodos antiguo. ``` apiVersion: v1 data: mapRoles: | - rolearn: arn:aws:iam::111122223333:role/nodes-1-16-NodeInstanceRole-W70725MZQFF8 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes - rolearn: arn:aws:iam::111122223333:role/nodes-1-15-NodeInstanceRole-U11V27W93CX5 username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes> ``` Guarde y cierre el archivo para aplicar el mapa de configuración actualizado. 1. (Opcional) Si utiliza el [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) de Kubernetes, vuelva a escalar la implementación a una réplica. **nota** También debe etiquetar el nuevo grupo de Auto Scaling de forma correcta (por ejemplo, `k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster`) y actualizar el comando de implementación del escalador automático del clúster para que señale el grupo de Auto Scaling recién etiquetado. Para obtener más información, consulte [Escalador automático de clústeres en AWS](https://github.com/kubernetes/autoscaler/tree/cluster-autoscaler-release-1.3/cluster-autoscaler/cloudprovider/aws). ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Opcional) Verifique que utiliza la última versión del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Es posible que tenga que actualizar la versión de CNI para utilizar los tipos de instancia admitidos más recientes. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md). 1. Si el clúster utiliza `kube-dns` para la resolución DNS (consulte [[migrate-determine-dns-step]](#migrate-determine-dns-step)), reduzca horizontalmente la implementación de `kube-dns` a una réplica. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` # Actualización de una pila de nodos de AWS CloudFormation En este tema, se describe cómo puede actualizar una pila existente de nodos autoadministrados de AWS CloudFormation con una nueva AMI. Puede utilizar este procedimiento para actualizar los nodos a una nueva versión de Kubernetes después de la actualización de un clúster. De lo contrario, puede actualizar a la última AMI optimizada de Amazon EKS para una versión existente de Kubernetes. **importante** En este tema, se explican las actualizaciones de los nodos autoadministrados. Para obtener información sobre el uso de la [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md), consulte [Actualización de un grupo de nodos administrados para un clúster](update-managed-node-group.md). La última plantilla de AWS CloudFormation de nodos de Amazon EKS predeterminada está configurada para lanzar una instancia con la nueva AMI en el clúster antes de eliminar una antigua, una por vez. Esta configuración garantiza que siempre tenga el número deseado de instancias activas del grupo de Auto Scaling en el clúster durante la actualización progresiva. **nota** Este método no es compatible con los grupos de nodos creados con `eksctl`. Si ha creado su clúster o un grupo de nodos con `eksctl`, consulte [Migración de aplicaciones a un nuevo grupo de nodos](migrate-stack.md). 1. Determine el proveedor de DNS para el clúster. ``` kubectl get deployments -l k8s-app=kube-dns -n kube-system ``` Un ejemplo de salida sería el siguiente. Este clúster utiliza CoreDNS para la resolución de DNS, pero el clúster puede devolver `kube-dns` en su lugar. El resultado puede tener un aspecto diferente según la versión de `kubectl` que utilice. ``` NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE coredns 1 1 1 1 31m ``` 1. Si su implementación actual está ejecutando menos de dos réplicas, escale la implementación a dos réplicas. Cambie *coredns* por `kube-dns` si el resultado del comando anterior ha devuelto ese valor. ``` kubectl scale deployments/coredns --replicas=2 -n kube-system ``` 1. (Opcional) Si utiliza el [escalador automático del clúster de Kubernetes](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md), escale la implementación a cero (0) réplicas para evitar acciones de escalado en conflicto. ``` kubectl scale deployments/cluster-autoscaler --replicas=0 -n kube-system ``` 1. Determine el tipo de instancia y el número de instancias deseado del grupo de nodos actual. Ingrese estos valores más tarde cuando actualice la plantilla de AWS CloudFormation del grupo. 1. Abra la consola de Amazon EC2 en https://console.aws.amazon.com/ec2/. 1. En el panel de navegación izquierdo, elija **Configuraciones de lanzamiento** (Configuraciones de lanzamiento) y anote el tipo de instancia de la configuración de lanzamiento de nodos existente. 1. En el panel de navegación izquierdo, elija **Auto Scaling Groups** (Grupos de Auto Scaling) y anote el recuento de instancias **deseado** para el grupo de Auto Scaling de nodos existente. 1. Abra la [AWS consola de CloudFormation](https://console.aws.amazon.com/cloudformation/). 1. Seleccione la pila del grupo de nodos y, a continuación, seleccione **Update (Actualizar)**. 1. Seleccione **Replace current template (Reemplazar plantilla actual)** y seleccione **Amazon S3 URL**. 1. Para **URL de Amazon S3**, pegue la siguiente URL en el área de texto a fin de asegurarse de que utiliza la versión más reciente de la plantilla de AWS Cloud Formation de nodos. A continuación, elija **Siguiente**: ``` https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml ``` 1. En la página **Especificar detalles**, rellene los parámetros siguientes y seleccione **Siguiente**: + **NodeAutoScalingGroupDesiredCapacity**: ingrese el recuento de instancias deseado que registró en un [paso anterior](#existing-worker-settings-step). O bien, ingrese el nuevo número deseado de nodos para escalar cuando se actualice la pila. + **NodeAutoScalingGroupMaxSize**: ingrese el número máximo de nodos al que pueda llegar el grupo de Auto Scaling de nodos. Este valor debe ser al menos un nodo más que la capacidad deseada. Es para que pueda realizar una actualización continua de los nodos sin que se reduzca el número durante la actualización. + **NodeInstanceType**: elija el tipo de instancia que registró en un [paso anterior](#existing-worker-settings-step). Por otra parte, puede elegir un tipo de instancia diferente para los nodos. Antes de elegir un tipo de instancia diferente, vea [Elección de un tipo de instancia de nodo de Amazon EC2 óptimo](choosing-instance-type.md). Cada tipo de instancia de Amazon EC2 admite un número máximo de interfaces de redes elásticas (interfaz de red) y cada interfaz de red admite un número máximo de direcciones IP. Dado que a cada nodo de trabajo y pod se les asigna su propia dirección IP, es importante elegir un tipo de instancia que admita el número máximo de pods que desea ejecutar en cada nodo de Amazon EC2. Para obtener una lista del número de interfaces de red y direcciones IP admitidas por los tipos de instancias, consulte [Direcciones IP por interfaz de red por tipo de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#AvailableIpPerENI). Por ejemplo, el tipo de instancia `m5.large` admite un máximo de 30 direcciones IP para el nodo de trabajo y los pods. **nota** Los tipos de instancias compatibles con la versión más reciente del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s) se muestran en [vpc\$1ip\$1resource\$1limit.go](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/pkg/vpc/vpc_ip_resource_limit.go) en GitHub. Es posible que tenga que actualizar la versión del complemento CNI de Amazon VPC para Kubernetes a fin de utilizar los tipos de instancia admitidos más recientes. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md). **importante** Algunos tipos de instancias podrían no estar disponibles en todas las regiones de AWS. + **NodeImageIdSSMParam**: el parámetro de Amazon EC2 Systems Manager del ID de AMI al que desee actualizar. El siguiente valor utiliza la última AMI optimizada para Amazon EKS para la versión  de Kubernetes `1.35`. ``` /aws/service/eks/optimized-ami/1.35/amazon-linux-2/recommended/image_id ``` Puede reemplazar *1.35* por una [versión de la plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) que sea igual. O bien, debería ser hasta una versión anterior a la versión de Kubernetes que se ejecuta en el plano de control. Le recomendamos que los nodos tengan la misma versión que el plano de control. También puede sustituir *amazon-linux-2* por un tipo de AMI diferente. Para obtener más información, consulte [Obtención de los ID de AMI de Amazon Linux recomendados](retrieve-ami-id.md). **nota** El uso del parámetro de Amazon EC2 Systems Manager lo habilita a actualizar los nodos en el futuro sin tener que buscar y especificar un ID de AMI. Si la pila de AWS CloudFormation utiliza este valor, cualquier actualización de la pila lanzará siempre la última AMI optimizada para Amazon EKS recomendada en función de la versión de Kubernetes especificada. Este es el caso incluso si no cambia ningún valor en la plantilla. + **NodeImageId**: para utilizar su propia AMI personalizada, introduzca el ID de la AMI que va a utilizar. **importante** Este valor anula cualquier valor especificado para **NodeImageIdSSMParam**. Si desea utilizar el valor **NodeImageIdSSMParam** asegúrese de que el valor de **NodeImageId** esté vacío. + **DisableIMDSv1**: cada nodo admite de forma predeterminada la versión 1 (IMDSv1) e IMDSv2 del servicio de metadatos de la instancia. Sin embargo, puede desactivar IMDSv1. Seleccione **verdadero** si no desea que ningún nodo o ningún pod programado en el grupo de nodos utilice IMDSv1. Para obtener más información, consulte [Configuración del servicio de metadatos de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Si ha implementado roles de IAM para cuentas de servicio, asigne los permisos necesarios de forma directa a todos los pods que requieren acceso a servicios de AWS. De esta manera, ningún pod del clúster requiere el acceso a IMDS por otros motivos, como la recuperación de la región de AWS actual. A continuación, también puede deshabilitar el acceso a IMDSv2 para los pods que no utilizan redes de host. Para obtener más información, consulte [Restringir el acceso al perfil de instancias asignado al nodo de trabajo](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). 1. (Opcional) En la página **Options (Opciones)**, marque los recursos de la pila. Elija **Siguiente**. 1. En la página **Review** (Revisar), revise la información, confirme la advertencia de que la pila puede crear recursos de IAM y elija **Update stack** (Actualizar pila). **nota** La actualización de cada nodo del clúster tarda varios minutos. Espere a que se complete la actualización de todos los nodos antes de realizar los siguientes pasos. 1. Si su proveedor DNS del clúster es `kube-dns`, reduzca horizontalmente la implementación de `kube-dns` a una réplica. ``` kubectl scale deployments/kube-dns --replicas=1 -n kube-system ``` 1. (Opcional) Si utiliza el [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) de Kubernetes, vuelva a escalar la implementación a la cantidad de réplicas deseada. ``` kubectl scale deployments/cluster-autoscaler --replicas=1 -n kube-system ``` 1. (Opcional) Verifique que utiliza la última versión del [complemento CNI de Amazon VPC para Kubernetes](https://github.com/aws/amazon-vpc-cni-k8s). Es posible que tenga que actualizar la versión del complemento CNI de Amazon VPC para Kubernetes a fin de utilizar los tipos de instancia admitidos más recientes. Para obtener más información, consulte [Asignación de direcciones IP a pods con CNI de Amazon VPC](managing-vpc-cni.md).