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.

Reversión de clústeres del modo automático de EKS

Al iniciar una reversión de la versión en un clúster que ejecuta el modo automático de EKS, Amazon EKS administra automáticamente la reversión de los nodos de trabajo del modo automático antes de revertir el plano de control. En esta página, se explica cómo funciona la reversión de nodos en el modo automático, cómo acelerarla y cómo cancelarla si es necesario.

Para obtener información general sobre la reversión de la versión, incluidos los requisitos previos, las comprobaciones de información y el proceso general de reversión, consulte Reversión de un clúster a una versión anterior de Kubernetes.

Cómo funciona la reversión del modo automático

El modo automático de EKS utiliza un sistema basado en Karpenter para administrar la infraestructura de los nodos de trabajo, incluidas las actualizaciones y reversiones de la versión de Kubernetes. Cuando llama a UpdateClusterVersion con la versión anterior (N-1) en un clúster con el modo automático habilitado, EKS lleva a cabo la siguiente secuencia:

El plano de control permanece en la versión actual (la más reciente) y continúa atendiendo el tráfico con normalidad mientras los nodos se revierten. La política de sesgo de versiones de Kubernetes permite a los nodos ejecutar hasta tres versiones secundarias anteriores a kube-apiserver, por lo que este estado intermedio es válido.

Estado del clúster durante la reversión

El estado del clúster permanece como ACTIVE durante la fase de reversión de nodos. Utilice ListUpdates o DescribeUpdate para determinar si hay una reversión en curso. En la consola de Amazon EKS, vaya al clúster y abra la pestaña Historial de actualizaciones para ver el estado del ID de actualización asociado a la reversión.

Para hacer un seguimiento del progreso de los nodos individuales durante la reversión, consulte la versión de Kubernetes de los nodos del modo automático:

kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide

Controles de interrupción

La reversión del modo automático respeta todos los controles de interrupción existentes. Estos controles determinan la rapidez con la que se pueden reemplazar los nodos y pueden afectar significativamente a la duración de la reversión.

Presupuestos de interrupción de NodePool

Los presupuestos de interrupción de NodePool controlan cuántos nodos pueden interrumpirse simultáneamente. Durante la reversión, Karpenter respeta estos presupuestos al desviar los nodos a la versión anterior.

Ejemplo de NodePool con un presupuesto de interrupción que permite reemplazar el 10 % de los nodos a la vez:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
      - nodes: "10%"
        reasons:
          - Drifted

Para obtener más información sobre la configuración de los presupuestos de interrupción de NodePool, consulte Creación de un grupo de nodos para el modo automático de EKS y Presupuestos de interrupción de Karpenter.

PodDisruptionBudgets

Los PodDisruptionBudgets de Kubernetes se respetan durante el reemplazo de los nodos. Si un PDB impide la expulsión del pod, la interrupción del nodo se retrasa hasta el TerminationGracePeriod.

Para obtener más información, consulte Protección de las cargas de trabajo críticas con un PDB y la documentación de PDB de Kubernetes.

Anotaciones do-not-disrupt

La anotación karpenter.sh/do-not-disrupt se puede configurar en nodos o pods:

En nodos: bloquea la interrupción de los nodos de forma indefinida. Esto activa una información de ERROR y debe eliminarse antes de que la reversión pueda continuar en ese nodo.

En pods: retrasa la interrupción de los nodos hasta el TerminationGracePeriod. Esto activa una información de ADVERTENCIA, pero no bloquea permanentemente la reversión.

Para obtener más información sobre el comportamiento de interrupción de Karpenter, consulte la documentación sobre interrupciones de Karpenter.

Aceleración de la reversión

Si la reversión tarda más de lo esperado, puede ajustar los controles de interrupción mientras la reversión está en curso.

Aumento de los presupuestos de interrupción de NodePool

Edite el recurso NodePool para permitir más reemplazos de nodos simultáneos:

kubectl edit nodepool default

Cambie el presupuesto a un valor más alto:

spec:
  disruption:
    budgets:
      - nodes: "50%"
        reasons:
          - Drifted

Eliminación de las anotaciones do-not-disrupt de los nodos

Enumere los nodos con la anotación y elimínela:

# List nodes with the annotation
kubectl get nodes -o json | jq '.items[] | select(.metadata.annotations["karpenter.sh/do-not-disrupt"] == "true") | .metadata.name'

# Remove from a specific node
kubectl annotate node <node-name> karpenter.sh/do-not-disrupt-

Ajuste de PodDisruptionBudgets

Si los PDB ralentizan la expulsión de pods, ajústelos temporalmente:

kubectl edit pdb <pdb-name> -n <namespace>

Para obtener más información sobre la administración de los controles de interrupción, consulte Cómo evitar la interrupción de pods y nodos en el modo automático de Amazon EKS.

Cancelación de una reversión

El estado de una reversión es cancelable solo mientras los nodos se estén revirtiendo. Puede utilizar CancelUpdate durante esta fase para detener la operación.

aws eks cancel-update \
  --name my-cluster \
  --update-id <update-id> \
  --region us-west-2

Comportamiento de cancelación

Después de la cancelación

Si la cancelación se efectúa correctamente, los nodos desvían a la versión actual del clúster, como de costumbre. La actualización pasa de Cancelling a Cancelled.

Después de la cancelación, puede hacer lo siguiente de forma inmediata:

Cuando la cancelación no es posible

La cancelación falla si la reversión de los nodos ya se ha completado y se ha iniciado la reversión del plano de control, o si la actualización ya se ha completado con un estado Successful o Failed.

Tiempo de espera de la reversión

La reversión de nodos del modo automático tiene un tiempo de espera configurable controlado por el parámetro timeoutMinutes en rollbackConfig. El tiempo de espera predeterminado es 720 minutos (12 horas). Puede establecer un valor entre 120 minutos (2 horas) y 10 080 minutos (7 días). El tiempo de espera es una propiedad con un límite mínimo, lo que significa que comienza a partir del momento que especifique, no antes, pero también puede producirse poco después.

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --rollback-config timeoutMinutes=1440 \
  --region us-west-2

Si todos los nodos no han completado la reversión dentro del tiempo de espera especificado:

Después del tiempo de espera, puede reintentar la reversión si aún se encuentra dentro del plazo de 7 días desde la actualización original. En la práctica, si se agota el tiempo de espera para la reversión del nodo al séptimo día, es probable que el periodo de aptitud para la reversión también haya vencido, ya que ambos son de 7 días.

Para evitar que se agoten los tiempos de espera, revise la información de preparación para la reversión antes de iniciarla. Esta información advierte sobre la posibilidad de que los presupuestos de interrupciones o las anotaciones puedan ralentizar el proceso de reversión de los nodos.

El indicador --force y el modo automático

El indicador --force en UpdateClusterVersion solo omite las comprobaciones de información de los clústeres. No tiene ningún efecto en el comportamiento de interrupción de los nodos del modo automático.

Acaba con --force:

La única forma de acelerar la reversión de los nodos es ajustar los propios controles de interrupción. Para obtener más información, consulte Aceleración de la reversión.

Conflictos de tiempo de espera de IaC

Las herramientas de infraestructura como código tienen limitaciones de tiempo de espera que pueden entrar en conflicto con la duración de la reversión del modo automático. CloudFormation permite hasta 36 horas por recurso. Si se agota el tiempo de espera de la operación, CloudFormation considera que la operación no se ha completado, lo que puede dejar el clúster en un estado de desviación en el que la plantilla no refleje la versión real del clúster. La reversión de la versión debe iniciarse de forma explícita. Terraform Enterprise y Cloud tienen un tiempo de espera de aproximadamente 24 horas, aunque los tiempos de espera del cliente pueden variar según el vencimiento de las credenciales y otros factores.

Para alinear la duración de la reversión a la de la herramienta de IaC, utilice el parámetro timeoutMinutes en rollbackConfig para establecer un tiempo de espera adecuado. Si se agota el tiempo de espera de la herramienta de IaC, utilice directamente la API CancelUpdate para recuperar el control. Si tiene presupuestos de interrupción restrictivos, considere la posibilidad de iniciar la reversión directamente a través de la CLI o la API en lugar de IaC.

Actualizaciones del sistema durante la reversión de nodos

Mientras los nodos del modo automático se revierten, EKS continúa manteniendo el plano de control seguro y disponible.

Las actualizaciones activadas por el cliente (como UpdateClusterVersion o UpdateClusterConfig) se bloquean mientras se lleva a cabo la reversión del nodo. Si necesita llevar a cabo una actualización de alta prioridad, cancele antes la reversión con CancelUpdate y, a continuación, lleve a cabo la actualización y vuelva a iniciarla si aún está dentro del plazo de aptitud.

Recursos relacionados