Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Prácticas recomendadas para la reversión de versiones de clústeres
Con la reversión de la versión de Amazon Elastic Kubernetes Service (Amazon EKS), puede revertir el plano de control de Kubernetes del clúster a la versión secundaria anterior en un plazo de 7 días a partir de la actualización local. En esta página, se describen las prácticas recomendadas para planificar, ejecutar y poner en marcha la reversión como parte del flujo de trabajo de actualización.
Para obtener información sobre los requisitos previos, los procedimientos paso a paso y la referencia sobre la API, consulte Reversión del clúster a una versión anterior de Kubernetes.
Comprenda cómo se aplica el modelo de responsabilidad compartida a la reversión
Al iniciar una reversión de la versión de un clúster, Amazon EKS gestiona la reversión del plano de control. Usted es responsable del plano de datos, los complementos y la compatibilidad de las aplicaciones. A continuación se describen las responsabilidades:
-
Amazon EKS gestiona: hacer retroceder los componentes del plano de control y del servidor API de Kubernetes. En el caso de los clústeres de modo automático, Amazon EKS también gestiona la reversión de los nodos de trabajo.
-
Usted es responsable de: reducir 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.
Para obtener más información sobre el modelo de responsabilidad compartida para las actualizaciones, consulte Comprenda cómo se aplica el modelo de responsabilidad compartida a las actualizaciones de clústeres.
Planifique las actualizaciones teniendo en cuenta la reversión
La reversión de versiones funciona mejor cuando el flujo de trabajo de actualización está diseñado para mantener abierta la ventana de reversión.
-
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 gestionados o nodos autogestionados, considere actualizar primero el plano de control y dejar pasar un tiempo antes de actualizar los nodos de trabajo. Mientras los nodos permanezcan activados N-1, la información sesgada de la versión de Kubelet permanece pasajera. Esto mantiene la ruta de reversión despejada sin necesidad de revertir primero los nodos.
-
Actualice los complementos a versiones compatibles entre sí. Antes de actualizar el plano de control, asegúrate de que todos los complementos (gestionados y autogestionados) sean compatibles con la versión actual y la de destino de Kubernetes. Esto permite que la información sobre la compatibilidad de los complementos sea clara tanto para la actualización como para la reversión.
-
Utilice los complementos gestionados por Amazon EKS para beneficiarse de información sobre la preparación para la reversión que comprueba automáticamente la compatibilidad de las versiones de los complementos.
-
Evite la autogestión de un complemento administrado (por ejemplo, sustituyendo la versión fuera del ciclo de vida del complemento de EKS). Durante la reversión, los expertos consideran que la configuración de los complementos gestionados es la fuente de la verdad y no detectan las desviaciones de versión que se hayan introducido.
-
-
Evite el uso de API específicas de cada versión durante el período de inactividad. Si crea recursos que utilizan API o funciones disponibles solo en la nueva versión durante el período de 7 días, debe eliminarlos antes de revertirlos. Limite la adopción de las API que solo estén disponibles en versiones nuevas hasta que esté seguro de que la actualización es estable.
-
Actualice cuanto antes, no más tarde. Con la opción de 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. Si actualiza antes, dispondrá de más tiempo para realizar la validación y reducirá los gastos de soporte prolongados.
-
Tenga en cuenta las restricciones de reversión del soporte extendido. Si tu clúster se actualizó automáticamente al finalizar el período de 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 a
EXTENDED.
Para obtener instrucciones generales sobre la planificación de las actualizaciones, incluidas las políticas de obsolescencia, las notas de la versión y la compatibilidad de los complementos, consulte las prácticas recomendadas para las actualizaciones de clústeres.
Revise la información sobre la preparación para la reversión antes de revertirla
Amazon EKS incluye información sobre la preparación para la reversión en un momento dado en la ROLLBACK_READINESS categoría de información sobre clústeres. Estas comprobaciones son su principal herramienta para evaluar la seguridad de las reversiones.
-
Revise la información inmediatamente después de la actualización. No esperes a que algo vaya mal. Tras la actualización, consulte la información sobre la preparación para la reversión para conocer su postura actual de reversión.
-
Aborde la información sobre los ERRORES de forma proactiva. Si los datos muestran un estado de ERROR poco después de una actualización, resuélvalos cuanto antes mientras el plazo de 7 días siga abierto. Cuanto más espere, es más probable que el estado del clúster varíe y aparezcan nuevos bloqueadores.
-
Comprenda lo que abarca y lo que no cubre la información. 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 del clúster. 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 entrada, los operadores personalizados o los agentes de supervisión).
Prepara los nodos que no estén en modo automático para su reversión
En el caso de los clústeres que utilizan grupos de nodos gestionados, nodos autogestionados o AWS Fargate, usted es responsable de garantizar que los nodos de trabajo sean compatibles con la versión de reversión de destino.
-
Grupos de nodos administrados. Debe revertir los grupos de nodos gestionados a la versión anterior antes de revertir el plano de control. Usa la
UpdateNodegroupVersionoperación con la versión anterior de Kubernetes. La reversión respeta los ajustes de actualización configurados (maxUnavailableo la estrategia de actualización). -
Self-managed y nodos híbridos. Actualice las AMI o las configuraciones de sus nodos para usar la versión anterior de Kubernetes antes de revertir el plano de control.
-
Fargate. Los nodos de trabajo de Fargate no admiten la reversión de versiones. 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
--forcepara evitar la visión sesgada de la versión (lo que podría provocar un comportamiento inesperado hasta que se sustituyan los pods).
Para obtener una PodDisruptionBudget guía de configuración distribuida por topología para garantizar la disponibilidad de la carga de trabajo durante las actualizaciones de los nodos, consulte las prácticas recomendadas para las actualizaciones de clústeres.
Administre los controles de interrupción del modo automático Amazon EKS para su reversión
Para los clústeres que ejecutan Amazon EKS Auto Mode, la fase de reversión del nodo puede ser la parte más larga de la operación. Sus controles de interrupción determinan directamente la rapidez con la que se completa la reversión.
-
Revise los presupuestos de interrupciones antes de iniciar la reversión. Amazon EKS proporciona información sobre la preparación para la reversión de los presupuestos de NodePool disrupción. Los presupuestos establecidos en 0 generan un indicador de 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 permite avanzar. Aborde la información sobre los ERRORES antes de iniciar la reversión.
-
Prepárese para ajustar los presupuestos durante la reversión. Si la reversión tarda más de lo esperado, puede ajustar los presupuestos y los PDB relacionados con las NodePool disrupciones
kubectlmientras la reversión esté en curso. Si se aumenta el presupuesto, se pueden sustituir más nodos de forma simultánea. -
Elimine las anotaciones que no interrumpan de los nodos bloqueantes. La
karpenter.sh/do-not-disruptanotación en los nodos bloquea la reversión indefinidamente. Retírela de los nodos que deben reemplazarse. -
Realice un seguimiento del progreso de la reversión de los nodos. Se utiliza
kubectl get nodes -l karpenter.sh/nodepool=<nodepool-name> -o widepara supervisar qué nodos se han sustituido 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, cancela la reversión. Tras la cancelación, los nodos vuelven a converger en la versión actual y puedes adoptar un enfoque diferente.
-
Establece un tiempo de espera adecuado. Utilice el
timeoutMinutesparámetro inrollbackConfigpara adaptarlo a sus expectativas operativas. El valor predeterminado es 720 minutos (12 horas). En el caso de los clústeres con presupuestos conservadores, considere aumentarlo. En el caso de IaC-managed los clústeres, ajústelo al tiempo de espera de la herramienta.
Para obtener información completa sobre los procedimientos de reversión del modo automático y la CancelUpdate operación, consulte Reversión de los clústeres del modo automático Amazon EKS.
Supervise el progreso de la reversión
Durante una reversión, utilice lo siguiente para realizar un seguimiento del estado y detectar problemas:
-
DescribeUpdate operación. Se utiliza
describe-updatepara 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 elcancellationobjeto en la respuesta. -
Información sobre clústeres. Amazon EKS vuelve a comprobar la información antes de proceder a la reversión del plano de control (una vez finalizada la reversión del nodo para el modo automático). Supervise los nuevos datos de ERROR 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
ACTIVEdurante la reversión de nodos yUPDATINGsolo cambia durante la reversión del plano de control. No confíe únicamente en el estado del clúster para saber si se está realizando una reversión: úselo.DescribeUpdate -
Versiones de nodos. Para el modo automático, compruebe las versiones de Kubernetes de los nodos para realizar un seguimiento del progreso de sustitución de los nodos. En el caso de los grupos de nodos gestionados, supervisa el estado de actualización del grupo de nodos.
Gestione la infraestructura como clústeres gestionados por código (IaC)
Las herramientas de infraestructura como código (IaC) tienen limitaciones de tiempo de espera que pueden entrar en conflicto con la duración de la reversión del modo automático.
-
AWS CloudFormation admite hasta 36 horas por recurso. Si la reversión supera esta cifra, la CloudFormation considera una operación no operativa, lo que puede dejar al clúster en un estado de desviación en el que la plantilla no refleje la versión real del clúster. El tiempo de espera predeterminado para la reversión 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.
-
Alinee
timeoutMinutescon el tiempo de espera de la herramienta iAC para evitar que se agote el tiempo de espera de la herramienta iAC antes de que Amazon EKS complete la reversión. -
Considere la posibilidad de iniciar la reversión a través CLI/API de clústeres en modo automático con presupuestos restringidos, en lugar de hacerlo a través de iAC. Úselo
CancelUpdatedirectamente si se agota el tiempo de espera de la capa iAc. -
La reversión de la CloudFormation pila de AWS no desencadena 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 de plantilla anterior 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.
Utilice la reversión como una red de seguridad, no como un flujo de trabajo rutinario
La reversión de versiones está diseñada para ayudarle a recuperarse de los problemas posteriores a la actualización. Funciona mejor cuando se combina con sus prácticas de actualización actuales.
-
La reversión complementa las pruebas, no las reemplaza. Siga utilizando la información sobre los clústeres, las pruebas previas a la actualización en entornos que no son de producción y las implementaciones por etapas. Rollback se ocupa de los casos que las pruebas no pueden detectar: los problemas que solo aparecen en la producción.
-
La reversión reduce la necesidad de recurrir a procedimientos manuales de copias de seguridad e instantáneas como principal mecanismo de seguridad. Con la reversión nativa disponible, ya no tendrá que 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.
-
La información se obtiene con el máximo esfuerzo y en un momento dado. 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 validar sus aplicaciones, configuraciones y dependencias con respecto a la versión anterior.
La reversión reduce la necesidad de realizar actualizaciones en azul y verde
Las organizaciones que anteriormente utilizaban las actualizaciones de clústeres azul-verde principalmente para tener una «ruta de reversión» ahora pueden considerar las actualizaciones locales con la reversión de versiones como alternativa. In-place las actualizaciones con reversión ofrecen un menor costo de infraestructura (sin clústeres duplicados), una identidad de clúster coherente (el mismo punto final de API, el mismo proveedor de OpenID Connect (OIDC) e interfaces de red elásticas (ENI)) y operaciones más sencillas.
Blue-green podría seguir siendo la opción preferida cuando necesite cambiar varias versiones a la vez, probar exhaustivamente las migraciones de cargas de trabajo o mantener un aislamiento total del tráfico durante la validación. Para obtener más información, consulte las prácticas recomendadas para evaluar Blue/Green los clústeres en las actualizaciones de clústeres.
Recursos relacionados
