Descripción de cada fase de las actualizaciones de los nodos - Amazon EKS
Fase de configuraciónFase de escaladoFase de actualizaciónFase de reducción vertical

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.

Descripción de cada fase de las actualizaciones de los nodos

La estrategia de actualización del nodo de trabajo administrado de Amazon EKS tiene cuatro fases diferentes descritas en las siguientes secciones.

Fase de configuración

La fase de configuración incluye los siguientes pasos:

  1. Crea una nueva versión de plantilla de lanzamiento de Amazon EC2 para el grupo de escalado automático asociado al grupo de nodos. La nueva versión de la plantilla de lanzamiento utiliza la AMI de destino o la versión de plantilla de lanzamiento personalizada para la actualización.

  2. El grupo de escalado automático se actualiza para utilizar la versión más reciente de la plantilla de lanzamiento.

  3. Determina la cantidad máxima de nodos que se van a actualizar en paralelo mediante la propiedad de updateConfig para el grupo de nodos. El máximo no disponible tiene una cuota de 100 nodos. El valor predeterminado es un nodo. Para obtener más información, consulte la propiedad updateConfig en la Referencia de la API de Amazon EKS.

Fase de escalado

Al actualizar los nodos de un grupo de nodos administrados, los nodos actualizados se lanzan en la misma zona de disponibilidad que los que se están actualizando. Para garantizar esta ubicación, utilizamos el reequilibrio de la zona de disponibilidad de Amazon EC2. Para obtener más información, consulte Reequilibrio de la zona de disponibilidad en la Guía del usuario de Amazon EC2 Auto Scaling. Para cumplir este requisito, es posible que lancemos hasta dos instancias por zona de disponibilidad en su grupo de nodos administrado.

La fase de escalado incluye los siguientes pasos:

  1. Aumenta el tamaño máximo del grupo de escalado automático y el tamaño deseado en el mayor:

    • Hasta el doble del número de zonas de disponibilidad en la que se implementa el grupo de Auto Scaling.

    • El máximo no disponible de actualización.

      Por ejemplo, si el grupo de nodos tiene cinco zonas de disponibilidad y maxUnavailable como uno solo, el proceso de actualización puede lanzar un máximo de 10 nodos. Sin embargo, cuando maxUnavailable es 20 (o cualquier número superior a 10), el proceso puede lanzar 20 nuevos nodos.

  2. Después de escalar el grupo de escalado automático, compruebe si los nodos que utilizan la configuración más reciente están presentes en el grupo de nodos. Este paso solo se efectúa correctamente cuando cumple estos criterios:

    • Se lanza al menos un nuevo nodo en cada zona de disponibilidad en la que existe el nodo.

    • Todos los nuevos nodos deberían estar en estado Ready.

    • Los nuevos nodos deben tener etiquetas aplicadas de Amazon EKS.

      Estas son las etiquetas aplicadas de Amazon EKS en los nodos de trabajo de un grupo de nodos normal:

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      Estas son las etiquetas aplicadas de Amazon EKS en los nodos de trabajo en una plantilla de lanzamiento personalizado o grupo de nodos de AMI:

      • eks.amazonaws.com/nodegroup-image=$amiName

      • eks.amazonaws.com/nodegroup=$nodeGroupName

      • eks.amazonaws.com/sourceLaunchTemplateId=$launchTemplateId

      • eks.amazonaws.com/sourceLaunchTemplateVersion=$launchTemplateVersion

  3. Marca los nodos como no programables para evitar programar nuevos Pods. También etiqueta los nodos con el node.kubernetes.io/exclude-from-external-load-balancers=true para eliminarlos de los equilibradores de carga antes de terminar los nodes.

Las siguientes son las razones conocidas que llevan a un error de NodeCreationFailure en esta fase:

Capacidad insuficiente en la zona de disponibilidad

Existe la posibilidad de que la zona de disponibilidad no tenga la capacidad de los tipos de instancias solicitados. Se recomienda configurar varios tipos de instancias al crear un grupo de nodos administrados.

Límites de instancias de EC2 en su cuenta

Es posible que tenga que aumentar el número de instancias de Amazon EC2 que su cuenta puede ejecutar simultáneamente mediante Service Quotas. Para obtener más información, consulte EC2 Service Quotas en la Guía del usuario de Amazon Elastic Compute Cloud para instancias de Linux.

Datos de usuario personalizados

Los datos de usuario personalizados a veces pueden interrumpir el proceso de arranque. Este escenario puede llevar a que la kubelet no se inicie en el nodo o que los nodos no reciban etiquetas de Amazon EKS esperadas en ellos. Para obtener más información, consulte Especificación de una AMI.

Cualquier cambio que haga que un nodo no esté en buen estado o no esté preparado

La presión del disco del nodo, la presión de la memoria y condiciones similares pueden provocar que un nodo no funcione en estado Ready.

Fase de actualización

La fase de actualización incluye los siguientes pasos:

  1. Selecciona aleatoriamente un nodo que necesita una actualización hasta el máximo no disponible configurado para el grupo de nodos.

  2. Drena los Pods del nodo. Si los Pods no salen del nodo en 15 minutos y no hay un indicador de fuerza, la fase de actualización falla con un error PodEvictionFailure. Para este escenario, puede aplicar el indicador de fuerza con la solicitud update-nodegroup-version para eliminar los Pods.

  3. Acordona el nodo después de expulsar todos los Pod y esperar 60 segundos. Esto se hace para que el controlador del servicio no envíe ninguna solicitud nueva a este nodo y elimine este nodo de su lista de nodos activos.

  4. Envía una solicitud de terminación al grupo de escalado automático para el nodo acordonado.

  5. Repite los pasos anteriores de actualización hasta que no haya nodos en el grupo de nodos que se implementen con la versión anterior de la plantilla de lanzamiento.

Las siguientes son las razones conocidas que llevan a un error de PodEvictionFailure en esta fase:

PDB agresivo

El PDB agresivo se define en el Pod o hay varios PDB que apuntan al mismo Pod.

Implementación que tolera todas las taints

Una vez expulsado cada Pod, se espera que el nodo esté vacío porque el nodo se marcó como taint en los pasos anteriores. Sin embargo, si la implementación tolera todas las taints, es más probable que el nodo no esté vacío, lo que provoca un error en la expulsión del Pod.

Fase de reducción vertical

La fase de reducción vertical disminuye el tamaño máximo del grupo de Auto Scaling y el tamaño deseado en uno para volver a los valores antes de que se inicie la actualización.

Si el flujo de trabajo de actualización determina que el escalador automático del clúster realiza el escalado vertical del grupo de nodos durante la fase de reducción vertical del flujo de trabajo, se cierra inmediatamente sin que el grupo de nodos vuelva a su tamaño original.