Mejores prácticas para la reversión de versiones de clústeres

Amazon EKS gestiona: deshacer los componentes del plano de control y el servidor de API de Kubernetes. En el caso de los clústeres en modo automático, Amazon EKS también gestiona la reversión de los nodos de trabajo.

Usted es responsable de: deshacer los grupos de nodos gestionados, los nodos autogestionados y los nodos híbridos. También debes validar la compatibilidad de los complementos y asegurarte de que tus aplicaciones, controladores personalizados y herramientas de terceros funcionen correctamente con la versión anterior.

Actualizaciones independientes del plano de control y del plano de datos (clústeres que no están en modo automático). En el caso de los clústeres que utilizan grupos de nodos administrados o nodos autogestionados, considera actualizar primero el plano de control y permitir un período de inactividad antes de actualizar los nodos de trabajo. Mientras los nodos permanecen activados N-1, la información sesgada de la versión de kubelet permanece en estado pasajero. Esto mantiene despejada la ruta de reversión sin necesidad de deshacer primero los nodos.

Actualice los complementos a versiones compatibles entre sí. Antes de actualizar el plano de control, asegúrese de que todos los complementos (administrados y autogestionados) sean compatibles con las versiones actuales y de destino de Kubernetes. De este modo, la información sobre la compatibilidad de los complementos es clara tanto para la actualización como para la reversión.

Evita usar API específicas para cada versión durante el período de preparación. Si creas recursos que usan API o funciones disponibles solo en la nueva versión durante el período de 7 días, debes eliminarlos antes de revertirlos. Limite la adopción de API exclusivas para la nueva versión hasta que esté seguro de que la actualización es estable.

Actualice lo antes posible, no más tarde. Con la reversión disponible, puede actualizar con confianza poco después del lanzamiento de una nueva versión en lugar de esperar a que se amplíen los plazos de soporte. La actualización anterior le da más tiempo para validarla y reduce los cargos por soporte extendido.

Tenga en cuenta las restricciones de anulación del soporte extendido. Si el clúster se actualizó automáticamente al finalizar el soporte extendido, no podrás volver a la versión anterior. Si se actualizó automáticamente al finalizar el soporte estándar, puede revertirlo, pero primero debe cambiar la política de actualización aEXTENDED.

Revise la información inmediatamente después de la actualización. No esperes a que algo vaya mal. Después de la actualización, comprueba las estadísticas de preparación para la reversión para conocer tu postura actual.

Aborde la información sobre los errores de forma proactiva. Si la información muestra el estado de ERROR poco después de una actualización, resuélvala cuanto antes mientras el plazo de 7 días siga abierto. Cuanto más espere, es más probable que el estado de su clúster difiera y aparezcan nuevos bloqueadores.

Entiende lo que la información abarca y lo que no cubre. Las estadísticas comprueban las versiones de los complementos gestionados por Amazon EKS, el uso de las API, el sesgo de versiones y el estado de los clústeres. No comprueban los complementos autogestionados, los controladores personalizados ni la compatibilidad a nivel de aplicación. Mantén tu propia validación de compatibilidad para los complementos autogestionados (por ejemplo, el escalador automático de clústeres, los controladores de ingreso, los operadores personalizados y los agentes de supervisión).

Grupos de nodos administrados. Debes revertir los grupos de nodos administrados a la versión anterior antes de revertir el plano de control. Usa la UpdateNodegroupVersion operación con la versión anterior de Kubernetes. La reversión respeta los ajustes de actualización configurados (maxUnavailablela estrategia de actualización).

Self-managed y nodos híbridos. Actualice las AMI o configuraciones de sus nodos para usar la versión anterior de Kubernetes antes de revertir el plano de control.

Fargate. La reversión de versiones no es compatible con los nodos de trabajo de Fargate. Elimine los pods de Fargate que ejecuten la misma versión que el plano de control antes de iniciar la reversión, o utilícelos --force para evitar el sesgo de la versión (lo que puede provocar un comportamiento inesperado hasta que se reemplacen los pods).

Revise los presupuestos de disrupción antes de iniciar la reversión. Amazon EKS proporciona información sobre la preparación para la reversión para los presupuestos de NodePool disrupción. Los presupuestos configurados en 0 generan un error, que bloquea la reversión de forma indefinida. Los presupuestos y los PodDisruptionBudgets PDB restrictivos generan información de ADVERTENCIA, que puede retrasar la reversión, pero permitir el progreso. Aborde los errores antes de iniciar la reversión.

Prepárate para ajustar los presupuestos durante la reversión. Si la reversión tarda más de lo esperado, puede ajustar los presupuestos de NodePool disrupción y los PDB kubectl mientras la reversión esté en curso. Aumentar el presupuesto permite más reemplazos simultáneos de nodos.

Elimine las anotaciones que no interrumpan de los nodos de bloqueo. La karpenter.sh/do-not-disrupt anotación en los nodos bloquea la reversión indefinidamente. Elimínelo de los nodos que se deben reemplazar.

Realice un seguimiento del progreso de la reversión de los nodos. Se utiliza kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o wide para supervisar qué nodos se han reemplazado por la AMI de la versión anterior.

Úselo CancelUpdate si es necesario. Si la reversión tarda demasiado o causa más problemas de los que resuelve, cancele la reversión. Tras la cancelación, los nodos vuelven a la versión actual y puedes adoptar un enfoque diferente.

Establece un tiempo de espera adecuado. Utilice el timeoutMinutes parámetro rollbackConfig para alinearlo con sus expectativas operativas. El valor predeterminado es de 720 minutos (12 horas). Para los clústeres con presupuestos conservadores, considera la posibilidad de aumentarlo. En el caso de IaC-managed los clústeres, alinéalo con el tiempo de espera de la herramienta.

DescribeUpdate operación. Se utiliza describe-update para comprobar el estado actual de la operación de reversión (InProgress,, SuccessfulFailed,Cancelled). Para realizar un seguimiento del progreso de la cancelación, compruebe el cancellation objeto de la respuesta.

Información sobre el clúster. Amazon EKS vuelve a comprobar la información antes de continuar con la reversión del plano de control (una vez finalizada la reversión de los nodos para el modo automático). Supervise los nuevos errores que puedan haber aparecido.

Estado del clúster. En el caso de los clústeres en modo automático, el estado del clúster permanece ACTIVE durante la reversión de los nodos y cambia a UPDATING solo durante la reversión del plano de control. No te fíes únicamente del estado del clúster para saber si hay una reversión en curso: úsalo. DescribeUpdate

Versiones de nodos. Para el modo automático, comprueba las versiones de Kubernetes de los nodos para realizar un seguimiento del progreso del reemplazo de nodos. En el caso de los grupos de nodos gestionados, supervisa el estado de actualización de los grupos de nodos.

AWS CloudFormation admite hasta 36 horas por recurso. Si la reversión supera este límite, CloudFormation la considera no operativa, lo que puede dejar al clúster en un estado de deriva en el que la plantilla no refleja la versión real del clúster. El tiempo de espera de reversión predeterminado es de 720 minutos (12 horas).

Terraform Enterprise/Cloud tiene tiempos de espera de aproximadamente 24 horas, aunque los tiempos de espera del lado del cliente varían.

timeoutMinutesAlinéelo con el tiempo de espera de la herramienta iAC para evitar que se agote el tiempo de espera antes de que Amazon EKS complete la reversión.

Considere la posibilidad de iniciar la reversión CLI/API para los clústeres en modo automático con presupuestos restrictivos, en lugar de hacerlo mediante IaC. CancelUpdateUtilízalo directamente si se agota el tiempo de espera de la capa iAC.

La reversión de AWS CloudFormation Stack no activa la reversión de la versión. Si se produce un error en la actualización de una CloudFormation pila de AWS, la reversión automática de la pila a una versión anterior de la plantilla no inicia una reversión de la versión del clúster. Debe iniciar de forma explícita una reversión de la versión.

La reversión complementa las pruebas, no las reemplaza. Siga utilizando la información sobre clústeres, las pruebas previas a la actualización en entornos que no son de producción y las implementaciones por etapas. La reversión se ocupa de los casos que las pruebas no pueden detectar, es decir, los problemas que solo surgen en la producción.

La reversión reduce la necesidad de utilizar procedimientos manuales de copia de seguridad e instantáneas como mecanismo de seguridad principal. Con la reversión nativa disponible, ya no es necesario confiar únicamente en las instantáneas de etcd o en los scripts de reversión personalizados para la recuperación ante desastres durante las actualizaciones.

Los conocimientos son el máximo esfuerzo y son puntuales. Amazon EKS los evalúa cuando se activa la reversión. Los cambios realizados después de esa comprobación (por ejemplo, la creación de recursos con nuevas API) no se capturan y pueden provocar problemas una vez finalizada la reversión.

La reversión no garantiza la recuperación de las aplicaciones. Amazon EKS revierte el plano de control de forma segura, pero es su responsabilidad validarlas con respecto a la versión anterior de sus aplicaciones, configuraciones y dependencias.

Revierte el clúster a la versión anterior de Kubernetes

Revierta los clústeres de Amazon EKS Auto Mode

Prácticas recomendadas para las actualizaciones de clústeres

Información sobre clústeres

Ciclo de vida de la versión de Kubernetes en EKS