¿Cómo planifico una actualización para mi clúster de Amazon EKS?

Resolución

Descripción del efecto de una actualización

Las nuevas versiones de Kubernetes pueden introducir cambios importantes en tu clúster de Amazon EKS. Después de actualizar el clúster, no puedes regresar a una versión anterior.

Si actualizas a una versión posterior de Kubernetes, no necesitas realizar una actualización local del clúster. En su lugar, puedes migrar a un nuevo clúster. Si migras a un clúster nuevo, se recomienda utilizar herramientas de copia de seguridad y restauración de clústeres, como Velero. Para obtener más información, consulta Velero en el sitio web de GitHub.

Para ver las versiones actuales y anteriores de Kubernetes, consulta el calendario de lanzamientos de Amazon EKS Kubernetes.

Cumplimiento de los requisitos de actualización

Para actualizar el clúster, debes cumplir los siguientes requisitos:

• Debes tener hasta cinco direcciones IP disponibles de las subredes que especificaste al crear el clúster.
• El rol y el grupo d seguridad de AWS Identity and Access Management (IAM) del clúster deben existir en tu cuenta de AWS.
• Si activas el cifrado de secretos, el rol de IAM del clúster debe tener los permisos de la clave de AWS Key Management Service (AWS KMS).

Revisión de las actualizaciones principales de Amazon EKS y Kubernetes

Haz lo siguiente:

• Revisa todos los cambios documentados de la versión de actualización y, a continuación, anota los pasos de actualización necesarios.
• Revisa cualquier requisito o procedimiento que sea específico de los clústeres administrados por Amazon EKS.

Para obtener información sobre las actualizaciones principales de las versiones de la plataforma de los clústeres de Amazon EKS y las versiones de Kubernetes, consulta la siguiente documentación:

• Descripción del ciclo de vida de las versiones de Kubernetes en Amazon EKS
• Visualización de las versiones de la plataforma Amazon EKS para cada versión de Kubernetes
• Actualización del clúster existente a la nueva versión de Kubernetes

Para obtener información sobre las versiones anteriores y las actualizaciones principales de Kubernetes, consulta la siguiente documentación:

• Kubernetes release notes (Notas de la versión de Kubernetes) en el sitio web de Kubernetes
• Kubernetes changelog (Registro de cambios de Kubernetes) en el sitio web de GitHub

Comprender y comprobar si hay API descontinuadas

Cuando Kubernetes actualiza una API, también elimina la API anterior.

Para administrar las API descontinuadas, lleva a cabo las siguientes acciones:

• Para entender cómo Kubernetes interrumpe las API en una versión posterior de Kubernetes, consulta la política de obsolescencia de Kubernetes en el sitio web de Kubernetes.
• Para comprobar si hay versiones de API descontinuadas en tu clúster, usa la herramienta Kube No Trouble (kubent). Para obtener más información, consulta kube-no-trouble en el sitio web de GitHub. Si utilizas versiones de la API descontinuadas, actualiza tus cargas de trabajo antes de actualizar tu clúster de Kubernetes.
• Para convertir archivos de manifiesto de Kubernetes entre diferentes versiones de la API, utiliza el complemento kubectl convert. Para obtener más información, consulta Instalar el plugin kubectl convert en el sitio web de Kubernetes.

Descripción de lo que se puede esperar durante una actualización de Kubernetes

Si actualizas el clúster, Amazon EKS inicia nuevos nodos de servidor de la API con la versión actualizada de Kubernetes para reemplazar los nodos existentes. Amazon EKS también ejecuta una serie de comprobaciones internas. Si falla una comprobación, Amazon EKS restaura el despliegue de la infraestructura y el clúster permanece en la versión anterior de Kubernetes. La restauración no afecta a las aplicaciones en ejecución y puedes recuperar los clústeres.

Nota: Durante el proceso de actualización, es posible que experimentes pequeñas interrupciones del servicio.

Actualización del plano de control y el plano de datos

Para actualizar un clúster, debes actualizar el plano de control y el plano de datos.

Para actualizar los planos, elige uno de los métodos siguientes:

• Actualización locales de clústeres
• Actualización azul/verde o de valor controlado
• Actualización de grupos de nodos administrados

Actualización locales de clústeres

Importante: Para las actualizaciones locales, solo puedes actualizar a la siguiente versión secundaria más reciente de Kubernetes. Si hay varias versiones entre la versión actual del clúster y la versión de destino, debes actualizar a cada versión de forma secuencial.

Para cada actualización local del clúster de Kubernetes, sigue estos pasos:

1. Actualiza tus manifiestos de Kubernetes y las API descontinuadas.
2. Actualiza el plano de control del clúster.
3. Actualiza los nodos de tu clúster.
4. Actualiza tus complementos y controladores personalizados de Kubernetes.

Para obtener más información, consulta la sección Planning and executing Kubernetes version upgrades in Amazon EKS (Planificación y ejecución de actualizaciones de versiones de Kubernetes en Amazon EKS) en Planning Kubernetes upgrades with Amazon EKS (Planificación de actualizaciones de Kubernetes con Amazon EKS). Consulta también Best practices for cluster upgrades (Prácticas recomendadas para las actualizaciones de clústeres).

Actualización azul/verde o de valor controlado

Para completar una actualización azul/verde o de valor controlado, consulta Blue/green or canary Amazon EKS clusters migration for stateless ArgoCD workloads (Migración azul/verde o de valor controlado de clústeres de Amazon EKS para cargas de trabajo de ArgoCD sin estado).

Actualización de grupos de nodos administrados

Importante: El kubelet de un nodo no puede ser posterior a kube-apiserver. Además, el kubelet no puede tener más de dos versiones secundarias anteriores a kube-apiserver. Por ejemplo, si kube-apiserver está en la versión 1.24, Amazon EKS solo admite un kubelet en las versiones 1.24, 1.23 y 1.22.

Para actualizar un grupo de nodos administrado, actualiza los nodos del grupo de nodos administrado.

Migración a un grupo de nodos administrado por Amazon EKS

Si utilizas grupos de nodos autoadministrados, puedes migrar tu carga de trabajo a grupos de nodos administrados por Amazon EKS sin tiempo de inactividad.

Identificación y actualización de las dependencias posteriores

Los clústeres pueden contener complementos y herramientas de terceros, como controladores de entrada, sistemas de entrega continua, herramientas de supervisión y otros flujos de trabajo. Si actualizas el clúster, también debes actualizar los complementos y las herramientas de terceros. Asegúrate de entender cómo funcionan los complementos con tu clúster y cómo se actualizan.

Nota: Se recomienda utilizar complementos administrados en lugar de complementos autoadministrados.

Revisa los siguientes ejemplos de complementos comunes y la documentación de actualización:

• Determina el complemento Container Network Interface de Amazon Virtual Private Cloud (CNI de Amazon VPC) que se utilizará en cada versión del clúster. Para obtener más información, consulta Asignación de direcciones IP a pods con CNI de Amazon VPC. Consulta también Configuración del complemento de CNI de Amazon VPC para utilizar roles de IAM para cuentas de servicio IRSA.
• Para un complemento de kube-proxy autogestionado, actualiza a la última versión de imagen de contenedor de kube-proxy disponible para cada versión del clúster. Para obtener más información, consulta Administración de kube-proxy en clústeres de Amazon EKS.
• En el caso de CoreDNS, actualiza a la última versión de imagen de contenedor CoreDNS disponible para cada versión del clúster. Para obtener más información, consulta Administración de CoreDNS para DNS en clústeres de Amazon EKS.
• La versión 2.5.0 o posterior de AWS Load Balancer Controller requiere la versión 1.22 o posterior de Kubernetes. Para obtener más información, consulta AWS Load Balancer Controller releases (Versiones de AWS Load Balancer Controller) en el sitio web de GitHub. Para obtener información sobre la instalación, consulta Enrutamiento del tráfico de Internet con AWS Load Balancer Controller.
• La versión 1.25.0 o posterior del controlador CSI de Amazon Elastic Block Store (Amazon EBS) requiere la versión 1.23 o posterior de Kubernetes. Para obtener más información, consulta aws-ebs-csi-driver en el sitio web de GitHub. Para obtener información sobre la instalación y la actualización, consulta Paso 2: obtención del controlador de CSI de Amazon EBS.
• La versión 1.5.8 o posterior del controlador CSI de Amazon Elastic File System (Amazon EFS) requiere la versión 1.22 o posterior de Kubernetes. Para obtener más información, consulta aws-efs-csi-driver en el sitio web de GitHub. Para obtener información sobre la instalación y la actualización, consulta Uso del almacenamiento del sistema de archivos elástico con Amazon EFS.

Actualización de los nodos de Fargate

Para actualizar un nodo de AWS Fargate, sigue estos pasos:

1. Elimina el pod que representa tu nodo.
2. Actualiza tu plano de control.
3. Vuelve a desplegar el pod.

Todos los pods nuevos que inicies en Fargate tienen una versión de kubelet que coincide con la versión de tu clúster. La actualización no afecta a los pods existentes de Fargate.

Nota: Amazon EKS debe aplicar parches periódicos a los pods de Fargate para mantenerlos seguros. Cuando actualizas los pods, Amazon EKS minimiza los efectos del parche. Si Amazon EKS no puede quitar los pods, Amazon EKS los elimina. Para minimizar las interrupciones, consulta Definición de acciones para los eventos de aplicación de parches del sistema operativo de AWS Fargate.

Actualización de los nodos no administrados que crea Karpenter

El valor que definas para ttlSecondsUntilExpired activa el vencimiento del nodo. Cuando los nodos alcanzan la antigüedad especificada en segundos, Amazon EKS los elimina. La eliminación se produce incluso cuando las cargas de trabajo o las aplicaciones de Amazon EKS utilizan los nodos. Usa ttlSecondsUntilExpired para reemplazar los nodos por instancias recién aprovisionadas, de modo que puedas actualizarlas. Karpenter utiliza las últimas imágenes de máquina de Amazon (AMI) optimizadas para Amazon EKS para los nodos reemplazados. Para obtener más información sobre cómo Karpenter interrumpe los nodos, consulta Disruption (Interrupción) en el sitio web de Karpenter.

En el siguiente ejemplo, se muestra un nodo que se desaprovisiona con ttlSecondsUntilExpired y, a continuación, se reemplaza por una instancia actualizada:

apiVersion: karpenter.sh/v1alpha5kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.sh/capacity-type         # optional, set to on-demand by default, spot if both are listed
      operator: In
      values: ["spot"]
  limits:
    resources:
      cpu: 1000                               # optional, recommended to limit total provisioned CPUs
      memory: 1000Gi
  ttlSecondsAfterEmpty: 30                    # optional, but never scales down if not set
  ttlSecondsUntilExpired: 2592000             # optional, nodes are recycled after 30 days but never expires if not set
  provider:
        subnetSelector:
      karpenter.sh/discovery/CLUSTER_NAME: '*'
    securityGroupSelector:
      kubernetes.io/cluster/CLUSTER_NAME: '*'

Nota: Karpenter no agrega automáticamente fluctuación al valor ttlSecondsUntilExpired. Si creas varias instancias en poco tiempo, las instancias vencen al mismo tiempo. Para evitar una interrupción excesiva de la carga de trabajo, define un presupuesto para interrupciones de pods. Para obtener más información, consulta Specifying a disruption budget for your application (Especificación de un presupuesto de interrupción para una aplicación) en el sitio web de Kubernetes.