Prácticas recomendadas para actualizar clústeres

En esta página, se proporcionan pautas para mantener tu clúster de Google Kubernetes Engine (clúster de GKE) actualizado sin problemas y recomendaciones para crear una estrategia de actualización que se adapte a tus necesidades y aumente la disponibilidad y confiabilidad de tus entornos. Puedes usar esta información a fin de mantener tus clústeres actualizados para lograr una mayor estabilidad y seguridad con interrupciones mínimas en tus cargas de trabajo.

Como alternativa, para administrar las actualizaciones automáticas de clústeres en entornos de producción organizados con flotas, consulta Acerca de las actualizaciones de clústeres con secuencia de lanzamiento.

Configura varios entornos

Como parte de tu flujo de trabajo para entregar actualizaciones de software, te recomendamos que uses varios entornos. Usar varios entornos te ayuda a minimizar los riesgos y el tiempo de inactividad no deseado. Para ello, prueba las actualizaciones de infraestructura y software por separado de tu entorno de producción. Como mínimo, debes tener un entorno de producción y uno de preproducción o de prueba.

Considera los siguientes entornos recomendados:

Entorno Descripción
Producción Se usa para entregar tráfico en vivo a los usuarios finales para aplicaciones comerciales esenciales.
Etapa de pruebas Se usa para garantizar que todos los cambios nuevos implementados en entornos anteriores funcionen según lo previsto antes de que los cambios se implementen a la producción.
Prueba Se usa para comparativas de rendimiento, cargas de trabajo de pruebas y control de calidad en la versión de GKE que usarás en la producción. En este entorno, puedes probar la actualización del plano de control y los nodos antes de hacerlo en la producción.
Desarrollo Se usa para el desarrollo activo que depende de la misma versión que se ejecuta en la producción. En este entorno, crearás correcciones y cambios incrementales para implementar en la producción.
Canary Se usa como un entorno de desarrollo secundario para probar versiones más recientes de Kubernetes, funciones y API de GKE a fin de mejorar el tiempo de salida al mercado una vez que estas versiones se promocionen y se convierten en las predeterminadas.

Inscribe clústeres en canales de versiones

Kubernetes lanza actualizaciones con frecuencia para entregar actualizaciones de seguridad, solucionar problemas conocidos e ingresar características nuevas. Los canales de versiones de GKE te permiten balancear entre la estabilidad y el conjunto de funciones de la versión implementada en el clúster. Cuando inscribes un clúster nuevo en un canal de versiones, Google administra automáticamente la versión y la cadencia de actualización del clúster y sus grupos de nodos.

Para mantener los clústeres actualizados con las últimas actualizaciones de GKE y Kubernetes, estos son algunos entornos recomendados y los respectivos canales de versiones en los que se deben inscribir:

Entorno Canal de versiones Descripción
Producción Estable o regular A fin de obtener la estabilidad y la madurez de la versión, usa el canal estable o regular para las cargas de trabajo de producción.
Etapa de pruebas Es igual que en la producción. Para garantizar que tus pruebas indiquen la versión a la que se actualizará tu producción, usa el mismo canal de versiones que en la producción.
Prueba
Desarrollo
Canary Rápido Para probar las últimas actualizaciones de Kubernetes y ser innovador mediante prueba a nuevas funciones o la API de GKE, usa el canal rápido. Puedes mejorar tu tiempo de salida al mercado cuando la versión rápida cambie al canal que estás usando para la producción.
N/A Extendido Para 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, usa el canal extendido. Para obtener más información, consulta Usa el canal extendido cuando necesites asistencia a largo plazo.

Los planos de control de clúster siempre se actualizan de forma periódica, sin importar si tu clúster está inscrito en un canal de versiones o no.

Crea una estrategia de actualización continua

Después de inscribir tu clúster en un canal de versiones, se actualiza con regularidad a la versión que cumple con la barra de calidad y estabilidad para el canal. Estas actualizaciones incluyen seguridad y correcciones de errores, que se aplican con un nivel de análisis creciente en cada canal:

  • Los parches se envían para controlar el plano y los nodos en todos los canales de forma gradual, lo que acumula un tiempo de asimilación en canales regulares y rápidos antes de llegar al canal estable.
  • El plano de control se actualiza primero, seguido de los nodos para cumplir con la política de OSS de Kubernetes que indica que kubelet no debe ser más reciente que kube-apiserver.
  • GKE lanzará automáticamente parches en canales según su gravedad y su importancia.
  • El canal estable solo recibe parches fundamentales.

Recibe actualizaciones sobre las versiones nuevas de GKE

La información sobre las versiones nuevas se publica en la página principal de las notas de la versión de GKE y en un feed RSS. Cada canal de versiones tiene una página de notas de la versión simplificada y dedicada (por ejemplo, Notas de la versión para el canal estable) con información sobre la versión de GKE recomendada para ese canal.

Para recibir actualizaciones de forma proactiva sobre las actualizaciones de GKE antes de que se apliquen, usa Pub/Sub y suscríbete para las notificaciones de actualización.

Una vez que una versión nueva esté disponible, debes planificar una actualización antes de que la versión se convierta en la predeterminada en la flota. Este enfoque proporciona más control y capacidad de predicción cuando es necesario, ya que GKE omitirá la actualización automática de los clústeres que ya se actualizaron con anticipación.

Prueba y verifica el parche nuevo y las versiones secundarias

Todas las versiones pasan las pruebas internas, independientemente del canal en el que se lancen. Sin embargo, con las actualizaciones y parches frecuentes de Kubernetes ascendentes y GKE, te recomendamos que pruebes versiones nuevas en entornos o de etapa de pruebas antes de que las versiones se lancen en tu entorno de producción, especialmente en actualizaciones de versiones secundarias de Kubernetes.

Cada canal de versiones ofrece dos versiones: predeterminada y disponible.

  • Las nuevas versiones de parches están disponibles una semana antes de que se convierta en predeterminadas.
  • Las nuevas versiones secundarias de Kubernetes estarán disponibles cuatro semanas antes de la fecha en que se vuelven predeterminada.

GKE actualiza automáticamente los clústeres a la versión predeterminada de manera gradual. Si se necesita más control sobre el proceso de actualización, recomendamos actualizar con anticipación a una versión disponible. La actualización automática de GKE omite los clústeres actualizados de forma manual.

Un enfoque recomendado para automatizar y optimizar las actualizaciones implica lo siguiente:

  • Un entorno de preproducción que use la versión disponible
  • Notificaciones de actualización configuradas en el clúster para informar a tu equipo sobre versiones nuevas disponibles que se pueden probar y certificar
  • Un entorno de producción suscrito a un canal de versiones que use la versión predeterminada en el canal
  • El lanzamiento gradual de nuevas versiones disponibles para los clústeres de producción. Por ejemplo, si hay varios clústeres de producción, un plan de actualización gradual se inicia mediante la actualización de una parte de estos clústeres a la versión disponible, mientras se mantienen los demás en la versión predeterminada, seguida de actualizaciones adicionales de partes pequeñas hasta que se actualice el 100% de los clústeres.

En la siguiente tabla, se resumen los eventos de lanzamiento y las acciones recomendadas:

Evento Acción recomendada
La nueva versión X se vuelve disponible en un canal. Actualiza el clúster de prueba de forma manual, y califica y prueba la versión nueva.
La versión X se convierte en la versión predeterminada. GKE comienza a actualizarse automáticamente a la versión predeterminada. Considera actualizar la producción antes de la flota.
GKE inicia la actualización automática de los clústeres. Permita que los clústeres se actualicen de forma automática o posterga la actualización mediante períodos de exclusión de mantenimiento.

Estrategia de actualización para lanzamientos de parches

Esta es una estrategia de actualización recomendada para las actualizaciones de parches si usa una situación en la que ocurre lo siguiente:

  • Todos los clústeres están suscritos al canal estable.
  • Las nuevas versiones disponibles se lanzan primero en el clúster de etapa de pruebas.
  • El clúster de producción se actualiza automáticamente con versiones predeterminadas nuevas.
  • Supervisa de manera periódica las nuevas versiones disponibles para GKE.
Tiempo Evento ¿Qué debo hacer?
T - 1 semana La nueva versión del parche comienza a estar disponible. Actualiza el entorno de etapa de pruebas
T La versión del parche comienza a ser la opción predeterminada. Considera actualizar el plano de control de producción con anticipación para aumentar la capacidad de predicción.
T GKE comenzará a actualizar los planos de control a la versión predeterminada. Considera actualizar los grupos de nodos de producción con anticipación para aumentar la capacidad de predicción.
T + 1 semana GKE comenzará a actualizar los grupos de nodos del clúster a la versión predeterminada. GKE actualizará automáticamente los clústeres. Para ello, omitirá los clústeres actualizados de forma manual.

Estrategia de actualización para nuevos lanzamientos secundarios

A continuación, te presentamos una estrategia de actualización recomendada para nuevos versiones secundarias:

Tiempo Evento ¿Qué debo hacer?
T - 3 semanas La nueva versión secundaria comienza a estar disponible Actualiza el plano del control de prueba
T - 2 semanas
  1. Si se actualiza correctamente el plano de control, considera actualizar el plano de control de producción con anticipación.
  2. Actualiza los grupos de nodos de prueba.
T - 1 semana Si se realizó una actualización exitosa, considera actualizar los grupos de nodos de producción con anticipación.
T La versión secundaria comienza a ser la versión predeterminada.
T GKE comenzará a actualizar los planos de control del clúster a la versión predeterminada. Crea una ventana de exclusión si se necesitan más pruebas o mitigaciones antes del lanzamiento de producción.
T + 1 semana GKE comenzará a actualizar los grupos de nodos del clúster a la versión predeterminada. GKE actualizará automáticamente los clústeres. Para ello, omitirá los clústeres actualizados de forma manual.

Reduce las interrupciones en las cargas de trabajo existentes durante una actualización

Mantener tus clústeres actualizados con parches de seguridad y correcciones de errores es fundamental para garantizar la vitalidad de los clústeres y la continuidad empresarial. Las actualizaciones regulares protegen las cargas de trabajo de las vulnerabilidades y las fallas.

Programa exclusiones y períodos de mantenimiento

A fin de aumentar la capacidad de predicción y de alinear las actualizaciones con horarios de atención de menor demanda, puedes controlar las actualizaciones automáticas del plano de control y de los nodos mediante la creación de un período de mantenimiento. GKE respeta los períodos de mantenimiento. Es decir, si el proceso de actualización se ejecuta más allá del período de mantenimiento definido, GKE intenta pausar la operación y la reanuda durante el siguiente período de mantenimiento.

GKE sigue un programa de lanzamiento predecible de varios días para que las versiones nuevas estén disponibles, así como la actualización automática de los planos de control y los nodos del clúster en regiones diferentes. Por lo general, la implementación se extiende durante cuatro días o más y se incluye un período para observar y supervisar los problemas. En un entorno de varios clústeres, puedes usar un período de mantenimiento independiente para cada clúster a fin de secuenciar el lanzamiento en todos tus clústeres. Por ejemplo, es posible que desees controlar cuándo los clústeres en diferentes regiones reciben mantenimiento mediante el establecimiento de diferentes períodos de mantenimiento para cada clúster.

Otra herramienta para reducir las interrupciones, en especial durante los períodos de alta demanda de la empresa, son las exclusiones de mantenimiento. Usa las exclusiones de mantenimiento para impedir que se lleve a cabo el mantenimiento automático durante estos períodos. Las exclusiones de mantenimiento se pueden configurar en clústeres nuevos o existentes. También puedes usar las exclusiones junto con tu estrategia de actualización. Por ejemplo, es posible que desees posponer una actualización de un clúster de producción si un entorno de prueba o de etapa de pruebas falla debido a una actualización.

Establece tu tolerancia a las interrupciones

Puede que estés familiarizado con el concepto de réplicas en Kubernetes. Las réplicas garantizan la redundancia de tus cargas de trabajo para un mejor rendimiento y capacidad de respuesta. Cuando se configuran, las réplicas rigen la cantidad de réplicas de Pod que se ejecutan en un momento determinado. Sin embargo, durante el mantenimiento, Kubernetes quita las VM de nodo subyacentes, lo que puede reducir la cantidad de réplicas. A fin de garantizar que tus cargas de trabajo tengan una cantidad suficiente de réplicas para tus aplicaciones, incluso durante el mantenimiento, usa un presupuesto de interrupción de Pod (PDB).

En un presupuesto de interrupción de Pod, puedes definir una cantidad (o porcentaje) de Pods que se puedan finalizar, incluso si finalizarlos lleva la cantidad de réplicas actual por debajo del valor deseado. Este proceso puede acelerar el desvío de nodos eliminando la necesidad de esperar que los pods migrados funcionen por completo. En cambio, desvía los pods de un nodo después de la configuración del PDB, lo que permite la implementación de los Pods faltantes en otros nodos disponibles. Una vez que se establece el PDB, GKE no cerrará los Pods en tu aplicación si la cantidad de Pods es igual o inferior a un límite configurado. GKE sigue un PDB durante un máximo de 60 minutos.

Controla las actualizaciones de los grupos de nodos

Con GKE, puedes elegir una estrategia de actualización de nodos para determinar cómo se actualizan los nodos en tus grupos de nodos. De forma predeterminada, los grupos de nodos usan actualizaciones de aumento. Con las actualizaciones de aumento, el proceso de actualización para los grupos de nodos de GKE implica volver a crear todas las VM del grupo de nodos. Se crea una VM nueva con la versión nueva (imagen actualizada) en forma de actualización progresiva. A su vez, esto requiere apagar todos los Pods que se ejecutan en el nodo anterior y cambiar los Pods al nuevo nodo. Tus cargas de trabajo pueden ejecutarse con redundancia suficiente (réplicas), y puedes confiar en Kubernetes para mover y reiniciar los Pods según sea necesario. Sin embargo, una cantidad reducida de réplicas aún puede ser perjudicial para tu empresa y puede ralentizar el rendimiento de las cargas de trabajo hasta que Kubernetes pueda alcanzar con el estado deseado otra vez (es decir, alcanzar la cantidad mínima de las réplicas necesarias). Puedes evitar esta interrupción mediante el uso de actualizaciones de aumento.

Durante una actualización con la opción de actualización de aumento habilitada, GKE primero protege los recursos (máquinas) necesarios para la actualización, luego crea un nodo actualizado nuevo y, solo entonces, desvía el nodo anterior y, por último, lo cierra. De esta manera, la capacidad prevista permanece intacta durante el proceso de actualización.

Para clústeres grandes en los que el proceso de actualización puede demorar más, puedes acelerar el tiempo de finalización de la actualización si actualizas varios nodos a la vez. Usa la actualización de aumento con maxSurge=20, maxUnavailable=0 para indicarle a GKE que actualice 20 nodos a la vez, sin usar ninguna capacidad existente.

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. Para obtener más información, consulta Obtén asistencia a largo plazo con el canal extendido.

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 de 1 a 2 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 1 o 2 veces al año. Por ejemplo, actualiza de la versión 1.30 a la 1.31 a la 1.32.

Este proceso garantiza 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 4 meses. Esto 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.

Resumen de la lista de tareas

En la siguiente tabla, se resumen las tareas recomendadas para una estrategia de actualización a fin de mantener actualizados tus clústeres de GKE sin problemas:

Práctica recomendada Tasks
Configura varios entornos
Inscribe clústeres en canales de versiones
Crea una estrategia de actualización continua
Reduce las interrupciones en las cargas de trabajo existentes

¿Qué sigue?