Guía para actualizaciones del clúster EKS

El escenario de la computación cloud está en constante evolución y puede resultar difícil mantenerse al día con los últimos cambios. Sin embargo, mantenerse actualizado es esencial para garantizar la seguridad y confiabilidad de la infraestructura y, en concreto, de nuestro clúster EKS.

Amazon Elastic Kubernetes Service (EKS) es un servicio de Kubernetes administrado que facilita la implementación, administración y escalamiento de aplicaciones en contenedores. Una de las tareas más importantes para los administradores del clúster EKS es realizar actualizaciones periódicas. Esto garantiza que su clúster se ejecute en la última versión de Kubernetes, que incluye los últimos parches y funciones de seguridad.

Esta guía proporciona un recorrido paso a paso por el proceso de actualización del clúster EKS. Cubrimos todos los pasos esenciales, desde la planificación de la actualización hasta la prueba y la implementación de la nueva versión. Ya sea que esté trabajando con nodos autoadministrados, grupos de nodos administrados, nodos Karpenter o nodos Fargate, lo tenemos cubierto.

Si sigue las instrucciones de esta guía, podrá actualizar con confianza su clúster EKS sin interrumpir sus aplicaciones.

¡Entonces empecemos!

Traducción literal del artículo «EKS Cluster Upgrades: A Step-by-Step Guide to a Smooth and Secure Process«

Índice

• Mantenerse al día: Frecuencia de actualización de K8s
  • Programación estratégica de actualizaciones de K8s
  • Gestión de versiones de K8s: Un enfoque por etapas
    • Development cluster (dev): Estar en la vanguardia
    • Staging cluster (pre): Un paso por detrás de dev
    • Production cluster (pro): Alinear con staging
    • Nota crucial: Precaución con las actualizaciones de versiones menores
    • Equilibrio entre velocidad y seguridad: El delicado arte de la gestión de versiones
  • Buenas prácticas
• Cómo administra AWS las actualizaciones de EKS
• Rollback del EKS en caso de fallo de la actualización
• Actualice el Plano de control y el Plano de datos en secuencia
• Utilice la documentación de EKS para crear una lista de comprobación de actualización
• Verifique los requisitos básicos de EKS antes de actualizar
• Verifique las direcciones IP disponibles
• Kube-no-trouble
• Pluto
• Nova
• Kubepug
• EKsup: Asistente de prepación para la actualización de clústeres
• Diagrama de alto nivel
• GoNoGo
• Configure PodDistuptionBudgets y TopologySpreadConstraints durante la actualización del Plano de datos
• Utilice Managed Node Groups o Karpenter para simplificar las actualizaciones del Plano de datos
• Utilice eksctl para automatizar las actualizaciones de los grupos de nodos autogestionados
• Realice una copia de seguridad del clúster antes de actualizar
• Anticiparse a los principales cambios de Kubenetes – Mantenerse por delante de la curva
• Conclusión

📅 Mantenerse al día: frecuencia de actualización de Kubernetes

¿Con qué frecuencia debe realizar actualizaciones de Kubernetes? Este es un aspecto crucial que a menudo pasan por alto los recién llegados a Kubernetes. A diferencia de muchos proyectos de infraestructura tradicionales, Kubernetes evoluciona rápidamente a través de sus versiones. La actualización de Kubernetes no puede compararse con el cambio a una nueva versión de soporte a largo plazo (LTS) de una distribución de Linux; es un proceso continuo que exige una atención regular.

Para ser justos, el equipo de Kubernetes ha dado pasos significativos para hacer este proceso más manejable. Siguen una política de soporte N-2, garantizando que las tres versiones menores más recientes reciban correcciones de seguridad y parches de errores. Este enfoque le da tiempo suficiente para establecer un clúster e incorporar la planificación de actualizaciones en su diseño inicial del clúster. Esperar hasta que el clúster esté casi al final de su vida útil (EOL) para contemplar las actualizaciones no es una estrategia viable. Cada versión puede recibir parches durante 14 meses, lo que puede parecer un periodo prolongado, pero es poco probable que instale la última versión.

Entonces, ¿con qué frecuencia debe actualizar Kubernetes? La respuesta es con bastante frecuencia. El objetivo de Kubernetes es lanzar tres versiones al año, frente a las cuatro anteriores. Para evaluar las versiones de Kubernetes para su organización, es probable que tenga que gestionar varias versiones simultáneamente en varios entornos.

Como regla general, recomiendo dejar que una versión menor se cocine en un entorno de desarrollo durante al menos dos semanas, y lo mismo se aplica a las etapas posteriores, como los entornos staging o sandbox. Para las actualizaciones de producción, lo ideal es disponer de al menos un mes de datos sólidos que indiquen que la organización no tendrá problemas.

🤖 Programación estratégica de actualizaciones de Kubernetes

Una versión de Kubernetes abarca tanto el plano de control como el plano de datos. Para garantizar un funcionamiento sin problemas, tanto el plano de control como el plano de datos deben ejecutar la misma versión menor de Kubernetes, como la 1.24.

• Plano de control: la versión del plano de control la define el servidor API de Kubernetes. En los clústeres EKS, esto lo gestiona AWS. Las actualizaciones de la versión del plano de control se inician mediante la API de AWS.
• Plano de datos – La versión del plano de datos hace referencia a la versión del Kubelet que se ejecuta en sus nodos. Diferentes nodos en el mismo clúster pueden tener diferentes versiones. Consulte la versión de todos los nodos con `kubectl get nodes`.

💹 Gestión de versiones de Kubernetes: Un enfoque por etapas

Un trazado cuidadosamente planificado nos asegura el éxito.

Development Cluster (DEV): Estar en la vanguardia

• El clúster dev debe estar a la vanguardia, alineado con la última versión de Kubernetes. Este enfoque ayuda a establecer acuerdos de nivel de servicio para el entorno de desarrollo, centrándose en actualizaciones frecuentes. La estrategia de comunicación interna consiste en actualizar el entorno de desarrollo con frecuencia durante periodos de tiempo específicos, confiando en él para identificar y sacar a la luz los primeros problemas. Es habitual encontrar problemas críticos casi de inmediato, lo que proporciona tiempo suficiente para resolverlos y determinar la versión de actualización máxima segura el día de las pruebas.

Staging Cluster (PRE): Un paso por detrás de Dev

• Staging va un poco por detrás de dev, normalmente ejecutando una versión menor anterior. La preocupación aquí podría ser la posibilidad de archivos YAML incompatibles. Sin embargo, es una práctica extendida emplear YAMLs por entorno, permitiendo variaciones en las peticiones y límites de recursos. Si está explorando la configuración por entorno, considere herramientas como Kustomize.

Production Cluster (PRO): Alinear con Staging

• En producción, el objetivo es mantener la alineación de versiones lo más cerca posible de staging. Este enfoque simplifica la vida de los desarrolladores al evitar una fragmentación excesiva de las versiones. Los lanzamientos de parches de Kubernetes suelen ser conservadores con los cambios, lo que da lugar a problemas poco frecuentes. La cadencia de lanzamiento de parches en la misma versión menor sigue un ciclo de dos semanas en staging antes de ser desplegados a producción.

Nota crucial: precaución con las actualizaciones de versiones menores

• Una regla clave es no actualizar la versión menor hasta que alcance al menos el parche .2. Esto significa que la última versión de Kubernetes, como la 1.26.0, no se considera lista para una versión de desarrollo hasta que alcance la 1.26.2. Una vez que se alcanza este hito, la versión de desarrollo se puede actualizar a la 1.26.2. Una vez alcanzado este hito, comienza el proceso de actualización, que pasa de la fase de desarrollo a la de producción. Cuando se completa la actualización de desarrollo y se pasa a la fase de producción, a menudo se trata de la versión .3 (dependiendo de la época del año).

Equilibrio entre velocidad y seguridad: El delicado arte de la gestión de versiones

• Aunque este planteamiento pueda parecer lento, se basa en experiencias pasadas. Apresurarse a realizar actualizaciones demasiado pronto ha provocado problemas. Es difícil para el equipo de Kubernetes prever todos los casos de uso y evitar todas las regresiones. Esperar hasta al menos .2 garantiza la realización de pruebas exhaustivas, y la mayoría de los problemas se descubren en ese momento. Algunos optan por esperar hasta .5 para el camino más seguro, aunque es un enfoque más lento.

Buenas prácticas

• Mantenga actualizado su clúster

Mantenerse al día con las versiones de Kubernetes es vital dentro del modelo de responsabilidad compartida para la adopción de EKS y Kubernetes.

• Revise el calendario de versiones de EKS

Las actualizaciones frecuentes son la norma, ya que EKS suele lanzar tres versiones menores de Kubernetes al año, cada una de ellas con un soporte de unos 14 meses. Consulte siempre el [calendario de versiones de EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html#kubernetes-release-calendar) Kubernetes para obtener la información más reciente. (Ahora mismo la última versión es la 1.28)

• Comprender la responsabilidad compartida

Usted es responsable de iniciar las actualizaciones tanto del plano de control del clúster como del plano de datos. Mientras que AWS se encarga del plano de control durante las actualizaciones, el plano de datos, incluidos los pods y complementos de Fargate, queda bajo su responsabilidad. La planificación es crucial para garantizar la disponibilidad de la carga de trabajo.

• Actualizaciones de clúster in situ

EKS admite actualizaciones de clúster in situ, preservando los recursos y la coherencia de la configuración. Esto minimiza las interrupciones para los usuarios y conserva las cargas de trabajo y los recursos existentes. Tenga en cuenta que sólo se puede actualizar una versión menor cada vez.

• Planifique cuidadosamente las actualizaciones secuenciales

Para actualizar varias versiones, es necesario realizar actualizaciones secuenciales. Sin embargo, suponen un mayor riesgo de tiempo de inactividad. Considere la posibilidad de evaluar una estrategia de actualización de clúster azul/verde en estos casos.

Cómo administra AWS las actualizaciones del clúster EKS

El proceso de actualización de EKS está gestionado por AWS para garantizar una transición fluida y segura entre versiones de Kubernetes. A continuación se detallan los pasos que sigue AWS para actualizar el plano de control de EKS:

• Comprobaciones previas a la actualización: AWS realiza primero comprobaciones previas a la actualización, incluida la evaluación del estado actual del clúster y la evaluación de la compatibilidad de la nueva versión con sus cargas de trabajo. Si se detecta algún problema, el proceso de actualización no continuará.
• Copia de seguridad e instantánea: Antes de iniciar la actualización, AWS realiza una copia de seguridad de su plano de control existente y crea una instantánea de su almacén de datos etcd. Esto se hace para garantizar la coherencia de los datos y permitir la reversión en caso de que falle la actualización.

Para una protección adicional de los datos, considere el uso de Velero, una herramienta de código abierto que simplifica el proceso de copia de seguridad y recuperación de los recursos de clúster de Kubernetes y los volúmenes persistentes. Velero permite programar y gestionar las copias de seguridad, así como los procesos de restauración, lo que proporciona una capa adicional de seguridad para los datos.

• Creación de un nuevo plano de control: AWS crea un nuevo plano de control con la versión de Kubernetes deseada. Este nuevo plano de control se ejecuta en paralelo con el plano de control existente, lo que garantiza una interrupción mínima de la carga de trabajo.
• Prueba de compatibilidad: Se comprueba la compatibilidad del nuevo plano de control con sus cargas de trabajo, incluida la ejecución de pruebas automatizadas para verificar que sus aplicaciones siguen funcionando como se esperaba.

El objetivo es minimizar las posibles interrupciones durante el proceso de actualización y mantener la estabilidad de sus servicios. Es importante mencionar que esto sólo busca la salud de su aplicación y no las API que pueden ser eliminadas o obsoletas.

• Cambio de los puntos finales del plano de control: Una vez confirmada la compatibilidad, AWS cambia los puntos finales del plano de control (servidor API) al nuevo plano de control. Este cambio se produce de forma atómica, por lo que el tiempo de inactividad durante el proceso de actualización es mínimo.
• Finalización del plano de control antiguo: El plano de control antiguo se cierra una vez finalizada la actualización y se limpian todos los recursos asociados a él.

Rollback del clúster EKS en caso de fallo de la actualización

En caso de que falle una actualización de EKS, AWS dispone de medidas para minimizar las interrupciones y revertir el plano de control a su versión anterior:

1. Detección del fallo: AWS monitoriza constantemente el proceso de actualización para detectar cualquier problema. Si surge un problema durante la actualización, el proceso se detiene inmediatamente.
2. Restauración a partir de la copia de seguridad: AWS utiliza la copia de seguridad y el snapshot creados antes de la actualización para restaurar el plano de control y el almacén de datos etcd a su estado anterior.
3. Cambio de los puntos finales del plano de control: AWS cambia atómicamente los puntos finales del plano de control al plano de control anterior, garantizando un tiempo de inactividad mínimo.
4. Finalización del nuevo plano de control: Una vez completada la reversión, AWS finaliza el nuevo plano de control y limpia los recursos asociados.
5. Evaluación posterior a la reversión: Después de la reversión, AWS evaluará los motivos del fallo de la actualización y proporcionará orientación sobre cómo solucionar los problemas. Deberá solucionar los problemas antes de volver a intentar la actualización.

Actualice el plano de control y el plano de datos en secuencia

Para actualizar un clúster deberá realizar las siguientes acciones:

1. Revise las notas de la versión de Kubernetes y EKS.
2. Realice una copia de seguridad del clúster. (opcional)
3. Identifique y corrija el uso de API obsoletas y eliminadas en sus cargas de trabajo.
4. Asegúrese de que los grupos de nodos gestionados, si se utilizan, estén en la misma versión de Kubernetes que el plano de control. Los grupos de nodos gestionados EKS y los nodos creados por EKS Fargate Profiles solo admiten 1 desviación de versión menor entre el plano de control y el plano de datos.
5. Actualice el plano de control del clúster mediante la consola de AWS o cli.
6. Revise la compatibilidad de los complementos. Actualice sus complementos de Kubernetes y controladores personalizados, según sea necesario.
7. Actualice kubectl.
8. Actualice el plano de datos del clúster. Actualice sus nodos a la misma versión menor de Kubernetes que su clúster actualizado.

Utilice la documentación del clúster EKS para crear una lista de comprobación de actualización

La documentación de versiones de EKS Kubernetes incluye una lista detallada de cambios para cada versión. Cree una lista de comprobación para cada actualización.

Para obtener orientación específica sobre la actualización de la versión de EKS, revise la documentación para conocer los cambios notables y las consideraciones para cada versión.

• EKS 1.27
• EKS 1.26
• EKS 1.25
• EKS 1.24
• EKS 1.23

Actualización de complementos y componentes a través de la API de Kubernetes

Antes de iniciar la actualización de un clúster, es esencial tener un conocimiento exhaustivo de las versiones de los componentes de Kubernetes en uso. Realice un inventario de los componentes del clúster, centrándose específicamente en aquellos que interactúan directamente con la API de Kubernetes. Estos componentes críticos del clúster incluyen agentes de supervisión y registro, autoescaladores de clúster, controladores de almacenamiento de contenedores (por ejemplo, EBS CSI, EFS CSI), controladores de entrada, así como cualquier otra carga de trabajo o complemento que dependa de interacciones directas con la API de Kubernetes.

Consejo profesional:

Los componentes críticos del clúster se encuentran frecuentemente dentro de espacios de nombres que terminan en *-system:

kubectl get ns | grep '-system'

Una vez que haya identificado los componentes que dependen de la API de Kubernetes, consulte su documentación para determinar la compatibilidad de versiones y los requisitos previos para la actualización. Por ejemplo, consulte la documentación de AWS Load Balancer Controller para obtener información sobre la compatibilidad de versiones. Algunos componentes pueden requerir actualizaciones o ajustes de configuración antes de proceder a la actualización de un clúster. Es imprescindible prestar especial atención a componentes críticos como CoreDNS, kube-proxy, VPC CNI y controladores de almacenamiento.

Los clústeres suelen englobar multitud de cargas de trabajo que dependen de la API de Kubernetes, esencial para funcionalidades como el control de entrada, los sistemas de entrega continua y las herramientas de supervisión. Al embarcarse en la actualización de un clúster EKS, es igualmente crucial actualizar sus complementos y herramientas de terceros, garantizando su compatibilidad sin fisuras con el entorno actualizado.

Consulte los siguientes ejemplos de complementos comunes y su documentación de actualización correspondiente:

• Amazon VPC CNI: Para conocer la versión recomendada del complemento Amazon VPC CNI para cada versión de clúster, consulte Actualización del complemento autogestionado Amazon VPC CNI para Kubernetes. Cuando se instala como complemento de Amazon EKS, solo se puede actualizar una versión menor cada vez.
• kube-proxy: Consulte Actualización del complemento autogestionado kube-proxy para Kubernetes.
• CoreDNS: Consulte Actualización del complemento autogestionado CoreDNS.
• AWS Load Balancer Controller: AWS Load Balancer Controller debe ser compatible con la versión de EKS que haya implementado. Consulte la guía de instalación para obtener más información.
• Controlador de interfaz de almacenamiento de contenedores (CSI) de Amazon Elastic Block Store (Amazon EBS): Para obtener información sobre la instalación y actualización, consulte Administración del controlador CSI de Amazon EBS como complemento de Amazon EKS.
• Controlador de interfaz de almacenamiento de contenedores (CSI) de Amazon Elastic File System (Amazon EFS): Para obtener información sobre la instalación y actualización, consulte Controlador CSI de Amazon EFS.
• Servidor de métricas de Kubernetes: Para obtener más información, consulte metrics-server en GitHub.
• Kubernetes Cluster Autoscaler: Para actualizar la versión de Kubernetes Cluster Autoscaler, cambie la versión de la imagen en el despliegue. El autoescalador de clústeres está estrechamente vinculado al programador de Kubernetes. Siempre tendrá que actualizarlo cuando actualice el clúster. Revise las versiones de GitHub para encontrar la dirección de la última versión correspondiente a su versión menor de Kubernetes.
• Karpenter: Para obtener información sobre la instalación y actualización, consulte la documentación de Karpenter.
• Ingress: Es necesario comprender realmente cómo llega el tráfico al clúster y a través de qué sistemas.
• Service mesh: ¿Estás utilizando una, qué hace y qué versión tiene? Istio puede ser un OSO para actualizar, así que si usted puede cambiar a Linkerd es probable que sea mucho más feliz en el largo plazo. Sin embargo, entender qué controla el acceso a qué namespaces y pods es crítico para una actualización feliz.
• Certificados: Por defecto caducan al año. Usted obtiene unos nuevos con cada actualización, pero también puede activar una actualización manual cada vez que con kubeadm certs renew. Si está ejecutando un clúster antiguo POR FAVOR compruebe las fechas de caducidad de sus certificados de cliente con: kubeadm certs check-expiration now.
• ¿Tienes despliegues con estado? ¿Están almacenando algo, dónde lo están almacenando y cómo los gestionas? Esto sería bases de datos, redis, colas de mensajes, aplicaciones que mantienen el estado. Suelen ser las más difíciles de mover o con las que es más difícil interactuar durante una actualización. Puede revisar las opciones para moverlos aquí. Lo más importante es establecer el presupuesto de interrupción de pods para que haya un mínimo disponible durante el proceso de actualización, como se muestra aquí.

Verifique los requisitos básicos del clúster EKS antes de actualizar

Para ejecutar correctamente una actualización del plano de control, AWS necesita recursos específicos en su cuenta. Sin estos recursos, el proceso de actualización no puede llevarse a cabo. Los requisitos previos para una actualización del plano de control incluyen:

1. Direcciones IP disponibles: Para actualizar el clúster, Amazon EKS necesita hasta cinco direcciones IP disponibles de las subredes que especificó al crear su clúster.
2. Rol IAM de EKS: El rol IAM del plano de control sigue presente en la cuenta con los permisos necesarios.
3. Grupo de seguridad EKS: El grupo de seguridad primario del plano de control sigue estando disponible en la cuenta con las reglas de acceso necesarias.
4. Si su clúster tiene habilitado el cifrado secreto, asegúrese de que el rol IAM del clúster tiene permiso para utilizar la clave de AWS Key Management Service (AWS KMS).

Verifique las direcciones IP disponibles del clúster EKS

Para actualizar el clúster, Amazon EKS necesita hasta cinco direcciones IP disponibles de las subredes que especificó al crear el clúster.

Para verificar que sus subredes tienen suficientes direcciones IP para actualizar el clúster, puede ejecutar el siguiente comando:

CLUSTER=
aws ec2 describe-subnets --subnet-ids \
  $(aws eks describe-cluster --name ${CLUSTER} --query 'cluster.resourcesVpcConfig.subnetIds' --output text) \
  --query 'Subnets[*].[SubnetId,AvailabilityZone,AvailableIpAddressCount]' --output table --no-cli-pager

El VPC CNI Metrics Helper puede utilizarse para crear un cuadro de mandos de CloudWatch para las métricas de VPC.

Transición a los complementos de EKS:

Amazon EKS despliega sin problemas complementos esenciales como el complemento CNI de Amazon VPC para Kubernetes, kube-proxy y CoreDNS para cada clúster. Estos complementos se pueden autoadministrar o instalar a través de Amazon EKS Add-ons, lo que ofrece un enfoque alternativo a la administración de complementos a través de la API de EKS.

Con los complementos de Amazon EKS, puede actualizar las versiones con un solo comando. Por ejemplo:

aws eks update-addon —cluster-name my-cluster —addon-name vpc-cni —addon-version version-number \
--service-account-role-arn arn:aws:iam::111122223333:role/role-name —configuration-values '{}' —resolve-conflicts PRESERVE

Compruebe si tiene algún complemento EKS con:

aws eks list-addons --cluster-name ${CLUSTER} --no-cli-pager --output text --query 'addons[*]'

Los complementos EKS no se actualizan automáticamente durante una actualización del plano de control. Debe iniciar las actualizaciones de complementos EKS y seleccionar la versión deseada.

Usted es responsable de seleccionar una versión compatible entre todas las versiones disponibles. Revise la guía sobre compatibilidad de versiones de complementos.

Los complementos de Amazon EKS sólo pueden actualizarse una versión menor cada vez y a la hora de actualizar deberían estar en la versión compatible más actualizada. Se debe tener especial cuidado si tenemos en algún addon una configuración avanzada porque puede sobreescribirse con la actualización.

Kube-no-trouble

Kube-no-trouble es una utilidad de línea de comandos de código abierto con el comando kubent. Cuando ejecutas kubent sin ningún argumento, utilizará tu contexto KubeConfig actual y escaneará el clúster e imprimirá un informe con qué APIs serán obsoletas y eliminadas.

kubent

4:17PM INF >>> Kube No Trouble `kubent` <<< 4:17PM INF version 0.7.0 (git sha d1bb4e5fd6550b533b2013671aa8419d923ee042) 4:17PM INF Initializing collectors and retrieving data 4:17PM INF Target K8s version is 1.24.8-eks-ffeb93d 4:l INF Retrieved 93 resources from collector name=Cluster 4:17PM INF Retrieved 16 resources from collector name="Helm v3" 4:17PM INF Loaded ruleset name=custom.rego.tmpl 4:17PM INF Loaded ruleset name=deprecated-1-16.rego 4:17PM INF Loaded ruleset name=deprecated-1-22.rego 4:17PM INF Loaded ruleset name=deprecated-1-25.rego 4:17PM INF Loaded ruleset name=deprecated-1-26.rego 4:17PM INF Loaded ruleset name=deprecated-future.rego __________________________________________________________________________________________ >>> Deprecated APIs removed in 1.25 <<<
------------------------------------------------------------------------------------------
KIND                NAMESPACE     NAME             API_VERSION      REPLACE_WITH (SINCE)
PodSecurityPolicy      eks.privileged   policy/v1beta1    (1.21.0)

También puede utilizarse para analizar archivos de manifiesto estáticos y paquetes helm. Se recomienda ejecutar kubent como parte de un proceso de integración continua (CI) para identificar problemas antes de que se desplieguen los manifiestos. El escaneo de manifiestos también es más preciso que el escaneo de clusters en vivo.

Kube-no-trouble proporciona un ejemplo de Cuenta de Servicio y Rol con los permisos apropiados para escanear el cluster.

Pluto

Otra opción es Pluto que es similar a kubent porque soporta escanear un cluster en vivo, archivos de manifiesto, helm charts y tiene una Acción GitHub que puedes incluir en tu proceso CI.

Vea si puede actualizar de forma segura contra las rutas de la API. Yo uso Pluto. Esto comprobará si está llamando a rutas de API obsoletas o eliminadas en su configuración o helm charts. Ejecute Pluto contra archivos locales con: pluto detect-files -d. También puede comprobar Helm con: pluto detect-helm -owide. Agregar todo esto a CI es también bastante trivial y algo que recomiendo para las personas que manejan muchos clusters.

pluto detect-all-in-cluster

NAME             KIND                VERSION          REPLACEMENT   REMOVED   DEPRECATED   REPL AVAIL  
eks.privileged   PodSecurityPolicy   policy/v1beta1                 false     true         true

Una vez que haya identificado qué cargas de trabajo y manifiestos deben actualizarse, es posible que tenga que cambiar el tipo de recurso en sus archivos de manifiesto (por ejemplo, PodSecurityPolicies a PodSecurityStandards). Esto requerirá actualizar la especificación del recurso e investigaciones adicionales dependiendo de qué recurso se esté sustituyendo.

Si el tipo de recurso es el mismo pero hay que actualizar la versión de la API, puedes utilizar el comando kubectl-convert para convertir automáticamente tus archivos de manifiesto. Por ejemplo, para convertir un Deployment antiguo a apps/v1. Para obtener más información, consulte Install kubectl convert plugin en el sitio web de Kubernetes.

kubectl-convert -f  --output-version /

👷 Nova

Comprueba si hay actualizaciones en tus versiones de Helm. Dado que normalmente cosas como el CNI y otras dependencias como CoreDNS se instalan con Helm, esta es a menudo la forma más rápida de asegurarse de que está ejecutando la última versión (compruebe las notas de parche para asegurarse de que soportan la versión a la que está apuntando). Nova sirve para esto.

🌕 kubepug

KubePug está diseñado para funcionar como un plugin de kubectl con las siguientes capacidades:

1. Descarga datos de depreciación: Obtiene un archivo data.json que contiene información de desaprobación relacionada con las API de Kubernetes.
2. Comprobación de validación: Verifica el clúster actual de Kubernetes o los archivos de entrada para determinar si existen objetos en Versiones de API obsoletas. Esto permite a los usuarios evaluar y planificar la migración antes de proceder.

Características principales:

• Opera contra un clúster Kubernetes, utilizando kubeconfig o el clúster activo.
• Puede ejecutarse contra un conjunto distinto de manifiestos o archivos.
• Permite a los usuarios especificar la versión de Kubernetes de destino para la validación.
• Ofrece información sobre la API de sustitución que debe adoptarse.
• Ofrece detalles sobre la versión en la que la API quedó obsoleta o se eliminó, en función de la versión del clúster de destino.

Cómo instalarlo como un plugin de Krew:

kubectl krew install deprecations

📕 eksup: Asistente de preparación para la actualización de clústeres

eksup es una interfaz de línea de comandos (CLI) diseñada para proporcionar a los usuarios información y herramientas completas para preparar sus clústeres para una actualización. Agiliza el proceso de actualización proporcionando información y acciones críticas para una transición sin problemas.

Funciones clave:

1. Análisis de clústeres: eksup permite a los usuarios evaluar sus clústeres con respecto a la siguiente versión de Kubernetes, identificando cualquier problema potencial que pudiera afectar al proceso de actualización.
2. Generación de playbooks: Los usuarios pueden generar playbooks personalizados que describen los pasos de actualización específicos para los resultados del análisis de su clúster. Estas guías detallan las acciones y soluciones necesarias.
3. Flexibilidad y aprendizaje: El libro de jugadas generado es editable, lo que permite a los usuarios adaptar los pasos de actualización para alinearlos con las configuraciones de su clúster y sus necesidades empresariales. También proporciona una plataforma para documentar los conocimientos adquiridos durante el proceso de actualización.
4. Colaboración mejorada: Dado que las actualizaciones suelen iniciarse primero en clústeres que no son de producción, cualquier paso adicional o información descubierta durante esta fase puede capturarse y utilizarse para mejorar el proceso de actualización de los clústeres de producción.
5. Artefacto histórico: se anima a los usuarios a conservar sus libros de jugadas como referencias históricas. Esta práctica garantiza que cada ciclo de actualización se beneficie de un conocimiento más profundo del proceso, infundiendo confianza y eficiencia en futuras actualizaciones antes de que expire el soporte de versiones de Kubernetes.

Diagrama de alto nivel del cluster EKS

GoNoGo

GoNoGo es una herramienta de fase alfa para determinar la confianza de actualización de sus complementos de clúster.

Configure PodDisruptionBudgets y topologySpreadConstraints durante la actualización del plano de datos

Para salvaguardar la disponibilidad de sus cargas de trabajo durante una actualización del plano de datos, es crucial configurar PodDisruptionBudgets y topologySpreadConstraints adecuadamente. Recuerde que no todas las cargas de trabajo exigen el mismo nivel de disponibilidad. Por lo tanto, es imprescindible evaluar la escala y los requisitos de su carga de trabajo.

Asegurarse de que las cargas de trabajo se distribuyen entre varias zonas de disponibilidad y hosts con topology spreads aumenta la confianza en que las migraciones al nuevo plano de datos se producirán sin problemas y sin interrupciones.

A continuación se muestra un ejemplo ilustrativo de una configuración de carga de trabajo que garantiza que el 80% de las réplicas estén disponibles de forma constante y distribuye de forma eficiente las réplicas entre zonas y hosts:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp
spec:
  minAvailable: "80%"
  selector:
    matchLabels:
      app: myapp
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 10
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
        name: myapp
        resources:
          requests:
            cpu: "1"
            memory: 256M
      topologySpreadConstraints:
      - labelSelector:
          matchLabels:
            app: host-zone-spread
        maxSkew: 2
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
      - labelSelector:
          matchLabels:
            app: host-zone-spread
        maxSkew: 2
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule

AWS Resilience Hub ha añadido Amazon Elastic Kubernetes Service (Amazon EKS) como recurso compatible. Resilience Hub proporciona un lugar único para definir, validar y realizar un seguimiento de la resiliencia de sus aplicaciones, de manera que pueda evitar tiempos de inactividad innecesarios causados por interrupciones operativas, de software o de infraestructura.

Utilice Managed Node Groups o Karpenter para simplificar las actualizaciones del plano de datos

Tanto Managed Node Groups como Karpenter simplifican las actualizaciones de nodos, pero adoptan enfoques diferentes.

Los grupos de nodos gestionados automatizan el aprovisionamiento y la gestión del ciclo de vida de los nodos. Esto significa que puede crear, actualizar automáticamente o dar de baja nodos con una sola operación.

En la configuración por defecto, Karpenter crea automáticamente nuevos nodos utilizando la última AMI compatible de EKS Optimized. A medida que EKS publique AMI optimizadas para EKS actualizadas o se actualice el clúster, Karpenter empezará a utilizar automáticamente estas imágenes. Karpenter también implementa Node Expiry para actualizar los nodos.

Karpenter puede configurarse para utilizar AMIs personalizadas. Si utiliza AMIs personalizadas con Karpenter, usted es responsable de la versión de kubelet.

Utilice eksctl para automatizar las actualizaciones de los grupos de nodos autogestionados

Los grupos de nodos autogestionados son instancias EC2 que se desplegaron en su cuenta y se adjuntaron al clúster fuera del servicio EKS. Normalmente se despliegan y gestionan mediante algún tipo de herramienta de automatización. Para actualizar grupos de nodos autogestionados, consulte la documentación de sus herramientas.

Por ejemplo, eksctl permite eliminar y vaciar nodos autogestionados.

Algunas herramientas comunes incluyen

• eksctl
• kOps
• Planos EKS

Realice una copia de seguridad del clúster antes de actualizar

Las nuevas versiones de Kubernetes introducen cambios significativos en su clúster de Amazon EKS. Después de actualizar un clúster, no podrá degradarlo.

Velero es una herramienta de código abierto soportada por la comunidad que se puede utilizar para realizar copias de seguridad de los clústeres existentes y aplicar las copias de seguridad a un nuevo clúster.

Tenga en cuenta que sólo puede crear nuevos clústeres para las versiones de Kubernetes actualmente soportadas por EKS. Si la versión que ejecuta actualmente su clúster sigue siendo compatible y falla una actualización, puede crear un nuevo clúster con la versión original y restaurar el plano de datos. Tenga en cuenta que los recursos de AWS, incluyendo IAM, no están incluidos en la copia de seguridad por Velero. Sería necesario volver a crear estos recursos.

📌 Anticiparse a los principales cambios de Kubernetes – Mantenerse por delante de la curva

En lugar de centrarse únicamente en la próxima versión inmediata de Kubernetes, adopte un enfoque con visión de futuro. Supervise continuamente las nuevas versiones de Kubernetes y esté atento para identificar alteraciones significativas. Por ejemplo, ciertas aplicaciones interactuaban directamente con la API de Docker, y Kubernetes 1.24 introdujo un cambio fundamental al eliminar la compatibilidad con Container Runtime Interface (CRI) para Docker, comúnmente conocida como Dockershim. 🐳 Prepararse para cambios tan sustanciales exige tiempo y planificación adicionales.

Examine todas las modificaciones documentadas para la versión a la que planea actualizar, anotando meticulosamente cualquier procedimiento de actualización obligatorio. Además, preste atención a los requisitos o procesos específicos adaptados a los clústeres administrados de Amazon EKS. Esta actitud proactiva garantiza un proceso de actualización más fluido a la vez que mitiga las posibles interrupciones causadas por cambios imprevistos.

Asimismo, tenga en cuenta los requisitos o procedimientos específicos de los clústeres administrados por Amazon EKS.

• Registro de cambios de Kubernetes

🔚 Conclusión

Confío en que la información proporcionada ha sido valiosa para usted. El viaje de mantener Kubernetes constantemente actualizado se vuelve menos desalentador con la práctica regular. La clave es asignar tiempo suficiente para aclimatar su entorno con cada versión menor. Al adherirse a un calendario predecible, el proceso de actualización de los clústeres se vuelve notablemente indoloro y sencillo, incluso para los usuarios menos experimentados, siempre y cuando se realicen las comprobaciones necesarias.

Recuerde, la clave del éxito radica en la regularidad y la preparación minuciosa cuando se trata de actualizaciones de Kubernetes.

Esperamos que esta entrada del blog le haya resultado útil. Si tiene algún otro consejo o truco que le gustaría compartir, por favor deje un comentario a continuación.

Artículo original en inglés: «EKS Cluster Upgrades: A Step-by-Step Guide to a Smooth and Secure Process«