Actualización de una pila de nodos de AWS CloudFormation - Amazon EKS

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.

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 más información sobre del uso de Simplificación del ciclo de vida de los nodos con grupos de nodos administrados, consulte Actualización de un grupo de nodos administrados para un clúster.

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.

Para actualizar un grupo de nodos existente

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

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

  3. (Opcional) Si utiliza el escalador automático del clúster de Kubernetes, 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

  4. 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/.

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

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

  5. Abra la consola de AWS CloudFormation en https://console.aws.amazon.com/cloudformation.

  6. Seleccione la pila del grupo de nodos y, a continuación, seleccione Update (Actualizar).

  7. Seleccione Replace current template (Reemplazar plantilla actual) y seleccione Amazon S3 URL.

  8. Para Amazon S3 URL (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 CloudFormation de nodos. A continuación, elija Siguiente:

    https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-12-23/amazon-eks-nodegroup.yaml

  9. 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. 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. Por otra parte, puede elegir un tipo de instancia diferente para los nodos. Antes de elegir un tipo de instancia diferente, revise Elección de un tipo de instancia de nodo de Amazon EC2 óptimo. 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. 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 de Amazon VPC CNI plugin for Kubernetes se muestran en vpc_ip_resource_limit.go en GitHub. Es posible que tenga que actualizar la versión de Amazon VPC CNI plugin for Kubernetes 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.

      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 1.31 de Kubernetes.

      /aws/service/eks/optimized-ami/1.31/amazon-linux-2/recommended/image_id

      Puede reemplazar 1.31 con una versión de Kubernetes admitida que sea la misma. 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 se 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.

      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 true (verdadero) si no desea que ningún nodo o ningún Pods programado en el grupo de nodos utilice IMDSv1. Para obtener más información, consulte Configuración del servicio de metadatos de instancia. 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 Pods en el clúster requiere el acceso a IMDS por otros motivos, como la recuperación de los datos actuales de la Región de AWS. A continuación, también puede desactivar el acceso a IMDSv2 para los Pods que no utilizan redes alojadas. Para obtener más información, consulte Restringir el acceso al perfil de instancias asignado al nodo de trabajo.

  10. (Opcional) En la página Options (Opciones), marque los recursos de la pila. Elija Siguiente.

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

  12. Si su proveedor DNS del clúster es kube-dns, escale la implementación de kube-dns a una réplica.

    kubectl scale deployments/kube-dns --replicas=1 -n kube-system

  13. (Opcional) Si utiliza el Autoescalador de clúster 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

  14. (Opcional) Verifique que utiliza la última versión de Amazon VPC CNI plugin for Kubernetes. Es posible que tenga que actualizar la versión de Amazon VPC CNI plugin for Kubernetes 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.