En este documento, se proporcionan prácticas recomendadas para que los administradores de plataformas administren las actualizaciones de clústeres de Google Kubernetes Engine (GKE). De forma predeterminada, GKE actualiza automáticamente la versión del plano de control y los nodos de tu clúster para proporcionar nuevas funciones, correcciones de errores y parches de seguridad que mantienen tu entorno seguro y con un buen rendimiento.
Para garantizar que estas actualizaciones automáticas se alineen con tus necesidades operativas y minimizar las interrupciones en las cargas de trabajo, GKE ofrece herramientas para que puedas ejercer el máximo control. En esta guía, se explica cómo usar estas herramientas de manera eficaz para mantener un alto rendimiento y disponibilidad. Para obtener una comprensión básica, consulta Acerca de las actualizaciones de clústeres de GKE.
Además de las actualizaciones del clúster, que solo son actualizaciones de la versión de GKE del plano de control y los nodos, GKE realiza periódicamente actualizaciones adicionales en el clúster. Implementar las prácticas recomendadas que se describen en este documento puede ayudarte a prepararte para algunos de estos tipos de cambios. Para obtener más información, consulta Administra los cambios en el ciclo de vida del clúster para minimizar las interrupciones.
Para obtener una descripción general consolidada de todas las prácticas recomendadas de GKE, consulta Prácticas recomendadas para GKE.Lista de tareas
En la siguiente tabla, se resumen las tareas que se explican en detalle en las secciones posteriores. Te recomendamos que realices estas tareas cuando prepares tu entorno para las actualizaciones de clústeres.
Elige el equilibrio entre la velocidad de las funciones y la estabilidad de las actualizaciones con los canales de versiones
Con los canales de versiones, puedes elegir un equilibrio entre la velocidad de las funciones y la estabilidad de las actualizaciones. De forma predeterminada, los clústeres de GKE se inscriben en el canal de versiones regular. Cuando GKE actualiza el plano de control y los nodos de tu clúster para entregar parches de seguridad, corregir problemas conocidos y presentar funciones nuevas, el canal de versiones determina qué versiones de GKE ejecuta tu clúster. Por ejemplo, si quieres obtener funciones nuevas antes, puedes elegir el canal rápido y, si quieres versiones con más estabilidad demostrada, elige el canal estable. Para obtener más información sobre cómo elegir entre canales específicos, consulta Qué canales están disponibles.
Si deseas actualizar tus clústeres de forma manual, puedes beneficiarte de la elección de tu canal de versiones revisando las versiones disponibles y los objetivos de actualización automática del canal antes de seleccionar una versión nueva.
Además, si deseas obtener versiones de parches en un canal de versiones lo antes posible (por ejemplo, para recibir parches de seguridad críticos), consulta Acerca de cómo obtener versiones de parches antes.
Elige el nivel de asistencia que necesitas para una versión secundaria
GKE proporciona un total de hasta 24 meses de asistencia para una versión secundaria después de que esta esté disponible en el canal regular. Esta asistencia incluye 14 meses de asistencia estándar y aproximadamente 10 meses de asistencia extendida disponibles con el canal Extended. Para obtener más información sobre cómo GKE admite una versión secundaria, consulta Compatibilidad con versiones secundarias.
Si necesitas mantener tu clúster en una versión secundaria por más tiempo mientras sigues recibiendo parches de seguridad después de la fecha de finalización de la asistencia estándar, o si deseas evitar la aplicación de la finalización de la asistencia estándar, también puedes usar el canal extendido. Para obtener más información, consulta la sección posterior Usa el canal extendido cuando necesites asistencia a largo plazo.
Cuando la versión secundaria llega al final de la asistencia, según el canal de versiones en el que esté inscrito el clúster, GKE actualiza automáticamente tu clúster para garantizar que siga siendo eficiente y seguro. Para obtener más información, consulta Actualizaciones automáticas de clústeres para mayor seguridad y compatibilidad. Si usas las herramientas que se describen en este documento para evitar o retrasar las actualizaciones automáticas de clústeres, te recomendamos que actualices tus clústeres de forma manual antes de que la versión secundaria en la que se ejecutan llegue al final de su ciclo de asistencia. De lo contrario, GKE actualizará automáticamente tu clúster.
Elige el momento de las actualizaciones con las políticas de mantenimiento
Para controlar cuándo se pueden realizar las actualizaciones y cuándo no, usa lo siguiente:
- Períodos de mantenimiento: Elige un período recurrente durante el cual GKE puede actualizar tu clúster, como el horario de atención de menor demanda. Si el proceso de actualización se ejecuta más allá del período de mantenimiento, GKE intenta pausar la operación y reanudarla durante el siguiente período de mantenimiento.
- Exclusiones de mantenimiento: Elige un período específico en el que GKE no pueda actualizar tu clúster, por ejemplo, durante un evento de ventas importante para una empresa minorista. También puedes usar exclusiones de mantenimiento para posponer temporalmente las actualizaciones automáticas de un clúster cuando, por ejemplo, notes un problema con otros clústeres que se actualizan a una versión nueva.
- Para casos de uso avanzados, es posible que debas realizar manualmente ciertos tipos de actualizaciones en lugar de que GKE las realice. Puedes usar exclusiones de mantenimiento para inhabilitar estos tipos de actualizaciones automáticas. Por ejemplo, puedes usar el permiso “Sin actualizaciones secundarias ni de nodos” para inhabilitar todas las actualizaciones secundarias y todas las actualizaciones de nodos. Debes realizar esas actualizaciones de forma manual o GKE actualizará tus clústeres al final del período de asistencia para la versión secundaria.
- Frecuencia de mantenimiento: Para casos de uso avanzados, controla el intervalo mínimo entre dos actualizaciones automáticas consecutivas con el presupuesto de interrupción del clúster.
Si configuras políticas de mantenimiento, puedes aumentar la previsibilidad de las actualizaciones y asegurarte de que se realicen cuando sea más conveniente para tus cargas de trabajo.
Controla el lanzamiento de las actualizaciones en los clústeres
Te recomendamos que uses varios entornos para minimizar los riesgos y el tiempo de inactividad no deseado. Para ello, prueba los cambios de infraestructura y software por separado de tu entorno de producción. Como mínimo, te recomendamos que tengas un entorno de producción y uno de preproducción o de prueba.
Considera los siguientes entornos recomendados:
| Entorno | Descripción |
|---|---|
| Producción | Entrega tráfico en vivo a los usuarios finales para aplicaciones comerciales esenciales. |
| Canary | Prueba una pequeña fracción del entorno de producción antes de actualizar todos los clústeres. |
| Etapa de pruebas | Comprueba que todos los cambios nuevos implementados en entornos anteriores funcionen según lo previsto antes de que los cambios se implementen en producción. |
| Prueba | Realiza comparativas, pruebas y control de calidad (QA) para las cargas de trabajo con la versión de GKE que usarás en producción. |
| Desarrollo | Usa la misma versión que se ejecuta en producción para el desarrollo activo. En este entorno, crearás correcciones y cambios incrementales para implementar en la producción. |
GKE proporciona funciones como la secuenciación de lanzamiento para ayudarte a controlar cómo se implementan las actualizaciones en estos diferentes entornos, como se detalla en la siguiente sección.
Usa la secuenciación de lanzamientos para realizar lanzamientos en diferentes entornos
Para lanzar progresivamente versiones nuevas de GKE dentro de estos entornos y entre ellos, te recomendamos que uses la secuencia de lanzamiento. Con la secuenciación de lanzamiento, todos los clústeres usan el mismo canal de versiones y la misma versión secundaria en todas las etapas de implementación. GKE lanza progresivamente nuevas versiones en la secuencia que configures. Cuando GKE lance la nueva versión en tus entornos, podrás verificar que el entorno y las cargas de trabajo de tu clúster se ejecuten según lo previsto con la nueva versión.
Si configuras un entorno nuevo, usa la secuenciación de lanzamiento con etapas personalizadas (versión preliminar). Esta versión más reciente de la secuenciación de lanzamientos te permite dividir el lanzamiento de una versión nueva en una flota en varias etapas. Con este enfoque, GKE puede, por ejemplo, actualizar un entorno de versión canary en producción antes de actualizar el resto de la producción. O bien, para obtener una versión disponible de forma general de la función que usa un modelo más lineal sin etapas personalizadas, consulta Acerca de las actualizaciones de clústeres con secuenciación de lanzamientos.
Prueba de actualizaciones secundarias y de parches de GKE
GKE actualiza automáticamente los clústeres a un parche nuevo todas las semanas. Sin embargo, las actualizaciones de versiones secundarias solo ocurren aproximadamente tres veces al año. Las versiones secundarias nuevas de Kubernetes introducen un mayor volumen de cambios en comparación con los parches de la misma versión secundaria. Te recomendamos que apliques un análisis adicional durante el lanzamiento de las actualizaciones de versiones secundarias en tus entornos para asegurarte de que la nueva versión secundaria funcione según lo previsto con tus clústeres y cargas de trabajo.
Realiza verificaciones antes de actualizar tu clúster
Antes de realizar actualizaciones automáticas del clúster, GKE califica las versiones nuevas durante un período que depende del canal de versiones y revisa la preparación del clúster.
Antes de actualizar los clústeres, te recomendamos que hagas lo siguiente:
- Para todas las actualizaciones, incluidas las actualizaciones secundarias y de parches, haz lo siguiente:
- Consulta las notas de la versión de GKE para conocer los problemas y encontrar el registro de cambios de las nuevas versiones secundarias y de parches.
- Consulta los problemas conocidos de GKE para detectar cualquier problema relevante para el entorno de tu clúster y la versión nueva.
- En el caso de las actualizaciones secundarias, revisa también lo siguiente:
- Verifica las bajas de las APIs. Para obtener más información, consulta la nota de la versión de GKE para la versión nueva, el registro de cambios de Kubernetes y Bajas de funciones y APIs.
- Asegúrate de que la diferencia de versión entre el plano de control y los nodos sea compatible. GKE admite la ejecución de nodos hasta dos versiones secundarias anteriores a la del plano de control. Para obtener más información, consulta la política de sesgo de versión de GKE.
- Para las actualizaciones de nodos, haz lo siguiente:
- Verifica que tengas suficientes recursos para la estrategia de actualización de nodos que usan tus nodos. Para obtener más información, consulta Garantiza recursos para las actualizaciones de nodos.
Controla cómo se activan las actualizaciones
De forma predeterminada, GKE actualiza automáticamente los clústeres a versiones nuevas de forma periódica. Sin embargo, también puedes usar actualizaciones manuales para actualizar tu clúster exactamente cuando lo desees y controlar la versión que ejecuta tu clúster.
También puedes realizar las siguientes acciones:
- Actualiza tu clúster de forma manual.
Realiza acciones para las actualizaciones de nodos automáticas o manuales en curso, incluidas las siguientes:
- Cancela una actualización.
- Reanuda una actualización.
- Revierte una actualización.
- Completar una actualización en curso
Si quieres tener más control sobre el proceso de actualización, te recomendamos que configures exclusiones de mantenimiento y, luego, realices las actualizaciones manuales según sea necesario. Para obtener más información sobre las actualizaciones manuales y otras acciones que puedes realizar para las actualizaciones en curso, consulta Actualiza un clúster o grupo de nodos de forma manual.
Supervisa las actualizaciones de clústeres
Para garantizar que las actualizaciones de GKE se realicen según lo previsto y que el entorno del clúster siga teniendo un buen rendimiento y esté disponible, usa las siguientes herramientas para supervisar las actualizaciones del clúster. Para mantenerte al tanto del estado de tus clústeres, usa herramientas como notificaciones, estadísticas y recomendaciones, y registros. En particular, te recomendamos que prestes atención a las notificaciones de fin de asistencia, las notificaciones de inicio de actualización y las notificaciones de actualización programada con aceptación para las actualizaciones de versiones secundarias. Configura políticas de alertas para asegurarte de ver estas notificaciones.
Usa los siguientes recursos para obtener detalles sobre las actualizaciones actuales:
- Para obtener información sobre las actualizaciones de clústeres específicos, incluidos los destinos de actualización automática actuales, consulta Obtén visibilidad de las actualizaciones de clústeres.
- Para recuperar los destinos generales de actualización automática, consulta la tabla de versiones actuales. Para obtener una asignación específica a la versión secundaria de un clúster, consulta las notas de la versión de Actualizaciones de versión.
- Consulta el programa de lanzamientos de GKE para obtener una estimación del mejor caso posible sobre cuándo estarán disponibles las versiones secundarias para las actualizaciones y cuándo finalizará la asistencia.
- Usa las notificaciones de clúster para mantenerte informado sobre los eventos de actualización, como las actualizaciones programadas de clústeres (versión preliminar), para tus clústeres con Cloud Logging o Pub/Sub.
Usa las estadísticas y recomendaciones para obtener las siguientes recomendaciones específicas del clúster:
Minimiza las interrupciones en las cargas de trabajo existentes durante las actualizaciones de nodos
Además de las prácticas recomendadas generales que se describen en las secciones anteriores, te recomendamos que consideres una configuración avanzada adicional para personalizar aún más el proceso de actualización y adaptarlo al entorno de tu clúster y a las necesidades de tus cargas de trabajo.
Consideraciones adicionales para perfiles de carga de trabajo específicos
Algunos tipos de cargas de trabajo y entornos de clúster requieren preparación adicional para las actualizaciones del clúster. Si tu carga de trabajo se ajusta a una o más de las siguientes categorías, ten en cuenta estas consideraciones adicionales:
- Cargas de trabajo que se ejecutan en máquinas que no se migran en vivo: Los nodos de GKE, que son instancias de Compute Engine que GKE crea en tu nombre, requieren mantenimiento periódico en la infraestructura subyacente. La mayoría de las instancias de Compute Engine se pueden migrar en vivo, lo que significa que las cargas de trabajo en ejecución no experimentan interrupciones cuando se realiza este mantenimiento. Sin embargo, ciertos tipos de máquinas no pueden migrar en vivo, lo que significa que las cargas de trabajo que se ejecutan en los nodos de GKE pueden interrumpirse. Es fundamental tener en cuenta que los aceleradores, como las GPU y las TPU para las cargas de trabajo de IA/AA, no se pueden migrar en vivo. Para obtener más información, consulta Administra las interrupciones en los nodos de GKE que no se migran en vivo.
- Cargas de trabajo con restricciones de capacidad: Si tus cargas de trabajo usan tipos de máquinas con restricciones de capacidad, se requiere una consideración adicional cuando se realizan actualizaciones del clúster. Para obtener más información, consulta Garantiza recursos para las actualizaciones de nodos.
- Cargas de trabajo con estado: Si tus cargas de trabajo tienen estado y requisitos específicos para el apagado y el reinicio correctos, se requiere una consideración adicional cuando se realizan actualizaciones del clúster. Para obtener más información, consulta Cómo garantizar que las cargas de trabajo estén listas para las interrupciones.
Revisa las siguientes secciones para comprender cómo puedes usar las herramientas disponibles para actualizar estos tipos de cargas de trabajo.
Elige una estrategia de actualización de nodos
En el modo GKE Standard, GKE ofrece diferentes estrategias de actualización de nodos que determinan cómo se actualizan los nodos individuales de tu grupo de nodos. Si eliges una estrategia de actualización para tu grupo de nodos estándar, puedes seleccionar el proceso con el equilibrio adecuado entre velocidad, interrupción de la carga de trabajo, mitigación de riesgos y optimización de costos. También puedes configurar los parámetros de la estrategia para que se adapten mejor a tus necesidades. En el modo Autopilot de GKE, GKE administra las actualizaciones de nodos y no es necesario que elijas la estrategia específica que se usa. Para obtener más información, consulta Acerca de las estrategias de actualización de nodos.
Establece tu tolerancia a las interrupciones
Usa presupuestos de interrupción de Pods (PDB) para garantizar que, cuando GKE vuelva a crear los nodos durante las actualizaciones, lo que puede reducir temporalmente la cantidad de réplicas de una carga de trabajo, tus cargas de trabajo mantengan la redundancia suficiente.
Si se establece un PDB, GKE no cerrará los Pods en tu aplicación si la cantidad de Pods es igual o inferior a un límite configurado. Las actualizaciones de GKE respetan un PDB durante un máximo de 60 minutos. Además, GKE te notifica si un PDB bloquea el vaciado de un nodo o si se alcanza el tiempo de espera del PDB y los Pods se borrarán de forma forzada a pesar del incumplimiento del PDB. Para obtener más información, consulta Eventos disruptivos durante una actualización del grupo de nodos.
Usa la finalización ordenada para cerrar una aplicación
Puedes configurar la finalización correcta para asegurarte de que las cargas de trabajo tengan tiempo suficiente para prepararse para el cierre. Durante las actualizaciones de nodos, GKE respeta la configuración de finalización correcta durante un máximo de 60 minutos con las actualizaciones de aumento predeterminadas y hasta 24 horas con las actualizaciones azul-verde y las actualizaciones azul-verde con ajuste de escala automático (vista previa).
Para obtener más información sobre cómo configurar los parámetros de configuración de la finalización correcta, consulta Configura GKE para finalizar tus cargas de trabajo de forma ordenada.
Usa el canal extendido cuando necesites asistencia a largo plazo
Si deseas mantener tu clúster en una versión secundaria durante más tiempo, sigue la práctica recomendada para inscribir tu clúster en el canal extendido. Con este canal, GKE admite una versión secundaria durante aproximadamente 24 meses. Con el canal extendido, controlas las actualizaciones de versiones secundarias, y GKE solo realiza actualizaciones automáticas al final de la asistencia, si no inicias la actualización por tu cuenta. Para obtener más información, consulta Obtén asistencia a largo plazo con el canal extendido.
Si no necesitas permanecer en una versión secundaria por más tiempo que el período de asistencia estándar, pero aún quieres controlar las actualizaciones de versiones secundarias, usa exclusiones de mantenimiento con el permiso “Sin actualizaciones secundarias”.
Para aprovechar al máximo el canal, te recomendamos que cumplas con las siguientes prácticas recomendadas. Algunas de estas prácticas recomendadas requieren realizar acciones manuales, como actualizar un clúster de forma manual y cambiar el canal de versiones de un clúster. Revisa las siguientes situaciones compatibles, así como Cuándo no usar el canal extendido.
Permanece temporalmente en una versión secundaria durante más tiempo
Si necesitas mantener de forma temporal un clúster en una versión secundaria por más tiempo que el período de asistencia estándar de 14 meses, por ejemplo, para mitigar el uso de APIs obsoletas que se quitan en la próxima versión secundaria, usa el siguiente proceso. Puedes mover de forma temporal el clúster de otro canal de versiones al canal extendido para seguir recibiendo parches de seguridad mientras te preparas para actualizar a la siguiente versión secundaria. Cuando estés listo para actualizar a la siguiente versión secundaria, actualiza el clúster de forma manual y, luego, vuelve a moverlo al canal de versiones original.
Actualizaciones de versiones secundarias una o dos veces al año
Si deseas una interrupción mínima para tu clúster mientras recibes algunas funciones nuevas cuando tu clúster esté listo para actualizarse a una versión secundaria nueva, haz lo siguiente:
- Inscribe un clúster en el canal extendido.
- Realiza dos actualizaciones sucesivas de versiones secundarias una o dos veces al año. Por ejemplo, actualiza de la versión 1.33 a la 1.34 y, luego, a la 1.35.
Este proceso ayuda a garantizar que el clúster permanezca en una versión secundaria disponible y reciba funciones de versiones secundarias nuevas, pero solo reciba actualizaciones de versiones secundarias cuando decidas que el clúster está listo.
Cuándo no usar el canal extendido
Para usar el canal extendido para su propósito previsto, se requiere una acción manual. En la siguiente situación, se ilustran las consecuencias de usar el canal extendido sin una administración activa de la versión secundaria del clúster.
No hacer nada y recibir actualizaciones menores con la misma frecuencia
Si deseas mantener tu clúster en una versión secundaria por siempre, inscribe tu clúster en el canal extendido y no realizas ninguna otra acción. Todas las versiones secundarias dejarán de ser compatibles con el tiempo y GKE actualiza los clústeres de las versiones secundarias no compatibles de forma automática. Por lo tanto, GKE actualiza este clúster de una versión secundaria no compatible a una versión secundaria que pronto dejará de ser compatible, lo que en promedio es aproximadamente cada cuatro meses. Este enfoque significa que el clúster recibe actualizaciones de versiones secundarias con la misma frecuencia en otros canales de versiones, pero recibe características nuevas más adelante.
¿Qué sigue?
- Para obtener más información sobre los diferentes modos de GKE, consulta Compara las características de los clústeres de Autopilot y Standard.