Editor Top
|
|
Actualizar un Kubernetes El avión de control ha sido durante mucho tiempo una puerta de un solo sentido. Kubernetes de código abierto no admite la reversión del plano de control, por lo que una vez que actualiza, no hay vuelta atrás. La comunidad está logrando avances reales aquí y KEP-4330 Introduce versiones emuladas para facilitar la reversión. Pero en la práctica, esta limitación ha empujado a las organizaciones a crear elaborados mecanismos de compensación, como períodos de preparación, grupos escalonados, aprobaciones automatizadas y ciclos de actualización de meses de duración. Dado que Kubernetes lanza tres versiones menores por año, los equipos que administran cientos de clústeres, especialmente en entornos regulados, a menudo retrasan las actualizaciones por completo porque no están seguros de poder recuperarse si algo sale mal. El resultado es que los clústeres se atascan en versiones anteriores, les faltan parches de seguridad y, finalmente, se enfrentan a plazos de soporte extendidos.
Hoy anunciamos reversiones de versiones de Kubernetes para Amazon Elastic Kubernetes Service (Amazon EKS), una nueva característica que brinda a los administradores de clústeres una red de seguridad al realizar actualizaciones de clústeres. Con las reversiones de versión, puede revertir una actualización de la versión de Kubernetes dentro de los siete días si encuentra problemas después de la actualización, devolviendo su clúster a su estado de funcionamiento anterior.
Mientras que enfoques como las versiones emuladas mantienen un clúster en un estado de retención transitorio, la reversión de la versión de EKS devuelve su clúster a una versión anterior completamente validada que se ejecutó en producción, no a una emulación de la misma. Ahora, si actualiza un clúster de, digamos, Kubernetes 1.34 a 1.35 y descubre un problema de compatibilidad, puede volver a 1.34 en siete días. No es necesario reconstruir su clúster ni luchar para solucionar problemas bajo presión. Piense en ello como un botón para deshacer las actualizaciones de la versión de Kubernetes.
La característica admite revertir una versión secundaria a la vez, coincidiendo con el mismo enfoque incremental que utiliza EKS para las actualizaciones. Y para ayudarle a revertir de forma segura, EKS evalúa automáticamente la preparación de su clúster para la reversión a través de información del clúster, marcando elementos como la compatibilidad de la versión del nodo o las dependencias de complementos antes de continuar. Si ya ha evaluado la situación y desea actuar rápidamente, puede utilizar el --force bandera para eludir esos controles. Lo anterior se aplica a todos los clústeres de EKS, ya sea que administre sus propios nodos o deje que AWS los maneje. Pero para los clientes que han adoptado una infraestructura totalmente gestionada, la reversión va un paso más allá.
Reversión para el modo automático EKS
El modo automático de EKS le brinda la implementación con un solo clic de clústeres de Kubernetes listos para producción, automatizando la administración de computación, redes y almacenamiento para que pueda concentrarse en sus aplicaciones en lugar de en la infraestructura. El modo automático de EKS introduce consideraciones adicionales para las reversiones de versiones porque tanto el plano de control como los nodos administrados deben revertirse juntos. Dado que las reversiones de nodos respetan sus presupuestos de interrupción de pods, el proceso puede llevar tiempo dependiendo de su configuración.
Para darle control sobre este proceso, hemos introducido un cancelar API que le permite detener la reversión de un nodo en cualquier momento. Si decide que la reversión está tardando demasiado o desea cambiar su enfoque, puede cancelar y ajustar sus presupuestos de disrupción para acelerar las cosas, o elegir un camino diferente a seguir.
De forma predeterminada, EKS nunca pasa por alto sus presupuestos de interrupción durante una reversión porque priorizamos la estabilidad de la carga de trabajo. Siempre puedes optar por modificar o eliminar los presupuestos de interrupción tú mismo para acelerar el proceso si es necesario.
Probemoslo
Para probar las reversiones de versiones, navegué hasta la consola de Amazon EKS y seleccioné uno de mis clústeres que había actualizado recientemente.
Desde la página de configuración del clúster, puedo ver la opción para iniciar una reversión de la versión, junto con información sobre mi ventana de reversión actual.
Antes de iniciar la reversión, revisé las ideas de reversión para verificar si había problemas potenciales. Los conocimientos me mostraron el estado de mis nodos y marcaron todo lo que debía abordar antes de continuar.
Después de confirmar, comenzó la reversión. Mi clúster permaneció funcional durante todo el proceso. La reversión del plano de control tomó unos 20 minutos, similar a una actualización estándar. Para mi clúster de modo automático EKS, los nodos se revertieron correctamente de acuerdo con mi configuración de presupuesto de interrupción.
Una vez completado, mi clúster volvió a la versión anterior de Kubernetes y se ejecutó como se esperaba.
Ahora disponible
Las reversiones de la versión de Kubernetes para Amazon EKS están disponibles hoy sin costo adicional en todas las regiones comerciales de AWS donde Amazon EKS está disponible. Solo paga por el EKS estándar y los costos de cálculo en los que normalmente incurriría. No hay cargos adicionales por utilizar la capacidad de reversión.
Las reversiones del plano de control están disponibles para todos los clústeres de EKS y las reversiones de nodos están disponibles para los clústeres que ejecutan el modo automático de EKS. Las reversiones de versiones admiten clústeres que ejecutan versiones de Kubernetes disponibles en soporte estándar y soporte extendido de EKS.
Para comenzar, visite la documentación de Amazon EKS o pruébelo directamente en la consola de Amazon EKS.
