¿Cómo puedo planificar una estrategia de actualización para un clúster de Amazon EKS?

Breve descripción

Las nuevas versiones de Kubernetes pueden introducir cambios importantes en su clúster de Amazon EKS. Después de actualizar un clúster, no puede regresar a una versión anterior. Cuando se actualiza a una versión más reciente de Kubernetes, puede migrar a nuevos clústeres en lugar de realizar actualizaciones de clústeres locales. Si decide migrar a nuevos clústeres, las herramientas de copia de seguridad y restauración de clústeres, como Velero de VMware, pueden ayudarle a realizar la migración. Para obtener más información, consulte Velero en el sitio web de GitHub.

Para ver las versiones actuales y anteriores de Kubernetes que están disponibles para Amazon EKS, consulte el Calendario de lanzamientos de Amazon EKS de Kubernetes.

Solución

Preparación para una actualización

Antes de comenzar la actualización del clúster, tenga en cuenta los siguientes requisitos:

• Amazon EKS requiere hasta cinco direcciones IP disponibles de las subredes que especificó al crear el clúster.
• El rol y el grupo de seguridad de AWS Identity and Access Management (IAM) del clúster deben existir en su cuenta de AWS.
• Si activa el cifrado de secretos, el rol de IAM del clúster debe tener los permisos de clave de AWS Key Management Service (AWS KMS).

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

Revise todos los cambios documentados de la versión de actualización y anote los pasos de actualización necesarios. Además, anote cualquier requisito o procedimiento que sea específico de los clústeres administrados por Amazon EKS.

Consulte los siguientes recursos para ver las actualizaciones importantes de las versiones de la plataforma de clústeres de Amazon EKS y las versiones de Kubernetes:

• Actualización de una versión de Kubernetes de clúster de Amazon EKS
• Versiones de Amazon EKS de Kubernetes
• Versiones de la plataforma de Amazon EKS

Para obtener más información sobre las versiones anteriores y las actualizaciones principales de Kubernetes, consulte la siguiente documentación:

• Kubernetes release notes en el sitio web de Kubernetes
• Changelog el sitio web de GitHub

Información sobre la política de obsolescencia de Kubernetes

Cuando se actualiza una API, la API anterior queda obsoleta y, finalmente, se elimina. Para entender por qué las API pueden quedar obsoletas en una versión más reciente de Kubernetes, lea la política de obsolescencia en el sitio web de Kubernetes.

Para comprobar si utiliza alguna versión de API obsoleta en tu clúster, utilice Kube No Trouble (kubent) en el sitio web de GitHub. Si utiliza versiones de la API obsoletas, actualice sus cargas de trabajo antes de actualizar su clúster de Kubernetes.

Para convertir archivos de manifiesto de Kubernetes entre diferentes versiones de la API, utilice el complemento kubectl convert. Para obtener más información, consulte Install kubectl convert plugin en el sitio web de Kubernetes.

Qué se puede esperar durante una actualización de Kubernetes

Al actualizar el clúster, Amazon EKS lanza nuevos nodos de servidor de la API con la versión actualizada de Kubernetes para reemplazar los nodos existentes. Si falla alguna de estas comprobaciones, Amazon EKS restaura el despliegue de la infraestructura y el clúster permanece en la versión anterior de Kubernetes. Sin embargo, esta restauración no afecta a ninguna aplicación que se esté ejecutando y puede recuperar cualquier clúster, si fuera necesario. Durante el proceso de actualización, es posible que experimente pequeñas interrupciones del servicio.

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

Para actualizar un clúster de Amazon EKS, debe actualizar dos componentes principales: el plano de control y el plano de datos. Cuando actualice estos componentes, tenga en cuenta las siguientes consideraciones.

Actualizaciones del clúster de Amazon EKS local

Para las actualizaciones locales, solo puede actualizar a la siguiente versión secundaria más alta de Kubernetes. Si hay varias versiones entre la versión actual del clúster y la versión de destino, debe actualizar a cada versión de forma secuencial. Para cada actualización local del clúster de Kubernetes, realice las siguientes tareas:

• Actualice sus manifiestos de Kubernetes y actualice las API obsoletas o eliminadas, según sea necesario.
• Actualice el plano de control del clúster.
• Actualice los nodos de su clúster.
• Actualice tus complementos y controladores personalizados de Kubernetes, según sea necesario.

Para obtener más información, consulte Planning and executing Kubernetes version upgrades in Amazon EKS en Planning Kubernetes upgrades with Amazon EKS. Consulte también Best practices for cluster upgrades en el sitio web de GitHub.

Migración de clústeres Amazon EKS azul/verde o de valor controlado

Una estrategia de actualización azul/verde o de valor controlado puede resultar más compleja, pero la estrategia permite realizar actualizaciones con una capacidad de restauración sencilla y sin tiempo de inactividad. Para obtener información sobre actualizaciones azul/verde o de valor controlado, consulte Blue/green or canary Amazon EKS clusters migration for stateless ArgoCD workloads.

Actualización de los grupos de nodos administrados por Amazon EKS

Importante: El kubelet de un nodo no puede ser más nuevo que kube-apiserver. Además, no puede haber más de dos versiones menores anteriores a kube-apiserver. Por ejemplo, supongamos que la versión de kube-apiserver es la 1.24. En este caso, solo se admite un kubelet de las versiones 1.24, 1.23 y 1.22.

Para actualizar por completo sus grupos de nodos administrados, siga estos pasos:

1. Actualice los componentes del plano de control del clúster de Amazon EKS a la versión más reciente.
2. Actualice sus nodos en el grupo de nodos administrado.

Migración a grupos de nodos administrados por Amazon EKS

Si utiliza grupos de nodos autoadministrados, puede migrar su carga de trabajo a grupos de nodos administrados por Amazon EKS sin tiempo de inactividad. Para obtener más información, consulte Seamlessly migrate workloads from EKS self-managed node group to EKS-managed node groups.

Identificación y actualización de las dependencias posteriores (complementos)

Los clústeres suelen contener productos externos, como controladores de entrada, sistemas de entrega continua, herramientas de supervisión y otros flujos de trabajo. Al actualizar el clúster de Amazon EKS, también debe actualizar los complementos y las herramientas de terceros. Asegúrese de entender cómo funcionan los complementos con su clúster y cómo se actualizan.

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

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

• CNI de Amazon VPC: para ver la versión sugerida del complemento CNI de Amazon VPC para su uso en cada versión del clúster, consulte Trabajar con el complemento Amazon VPC CNI plugin for Kubernetes de Amazon EKS. Consulte también Update the aws-node daemonset to use IRSA en el sitio web de GitHub.
• Complemento autoadministrado kube-proxy: actualice a la última versión de imagen de contenedor kube-proxy disponible para cada versión del clúster de Amazon EKS. Para obtener más información, consulte Trabajar con el complemento kube-proxy Kubernetes.
• CoreDNS: actualice a la última versión de imagen de contenedor CoreDNS disponible para cada versión del clúster de Amazon EKS. Para obtener más información, consulte Actualizar el complemento autoadministrado.
• AWS Load Balancer Controller: las versiones 2.5.0 o posteriores de AWS Load Balancer Controller requieren la versión 1.22 o posterior de Kubernetes. Para obtener más información, consulte AWS Load Balancer Controller releases en el sitio web de GitHub. Para obtener información sobre la instalación, consulte Instalación del complemento AWS Load Balancer Controller.
• Controlador de la interfaz de almacenamiento de contenedores (CSI) de Amazon Elastic Block Store (Amazon EBS): las versiones 1.25.0 o posteriores del controlador CSI de Amazon EBS requieren la versión 1.23 o posterior de Kubernetes. Para obtener más información, consulte Amazon EBS CSI driver releases en el sitio web de GitHub. Para obtener información sobre la instalación y la actualización, consulte Administración del controlador de CSI de Amazon EBS como complemento de Amazon EKS.
• Controlador de la interfaz de almacenamiento de contenedores (CSI) de Amazon Elastic File System (Amazon EFS): las versiones 1.5.8 o posteriores del controlador CSI de Amazon EFS requieren la versión 1.22 o posterior de Kubernetes. Para obtener más información, consulte Amazon EFS CSI driver releases en el sitio web de GitHub. Para obtener información sobre la instalación y la actualización, consulte Controlador CSI de Amazon EFS.

Actualización de los nodos de AWS Fargate

Para actualizar un nodo de Fargate, borre el pod que representa el nodo. A continuación, después de actualizar el plano de control, vuelva a desplegar el pod. Todos los pods nuevos que lance en Fargate tienen una versión de kubelet que coincide con la versión de su clúster. Los pods de Fargate existentes no se modifican.

Nota: Para proteger los pods de Fargate, Amazon EKS debe aplicarles parches periódicamente. Amazon EKS intenta actualizar los pods de forma que se reduzcan sus efectos. Sin embargo, si los pods no se pueden expulsar correctamente, Amazon EKS los elimina. Para minimizar las interrupciones, consulte Parches de SO de Fargate.

Actualización de los nodos sin grupo que crea Karpenter

Al establecer un valor para ttlSecondsUntilExpired, este valor activa la caducidad del nodo. Cuando los nodos alcanzan la antigüedad definida en segundos, Amazon EKS los elimina. Esta eliminación se produce incluso si los nodos están en uso. Este proceso le permite reemplazar los nodos por instancias recién aprovisionadas y, por lo tanto, actualizarlos. Cuando se reemplaza un nodo, Karpenter usa las últimas AMI optimizadas de Amazon EKS. Para obtener más información, consulte Disruption 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 añade automáticamente fluctuación a este valor. Si crea varias instancias en poco tiempo, las instancias caducan casi al mismo tiempo. Para evitar una interrupción excesiva de la carga de trabajo, defina un presupuesto para interrupciones de pods. Para obtener más información, consulte Specifying a disruption budget for your application en el sitio web de Kubernetes.