Prácticas recomendadas para actualizar clústeres

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

También puede gestionar las actualizaciones automáticas de clústeres en entornos de producción organizados con flotas. Para ello, consulte el artículo Información sobre las actualizaciones de clústeres con secuenciación de lanzamientos.

Configurar varios entornos

Como parte del flujo de trabajo para publicar actualizaciones de software, te recomendamos que uses varios entornos. Los entornos múltiples te ayudan a minimizar los riesgos y los tiempos de inactividad no deseados, ya que te permiten probar las actualizaciones de software y de infraestructura por separado del entorno de producción. Como mínimo, debes tener un entorno de producción y un entorno de preproducción o de pruebas.

Te recomendamos los siguientes entornos:

Entorno Descripción
Producción Se usa para servir tráfico en directo a los usuarios finales de aplicaciones empresariales esenciales.
Staging Se usa para asegurarse de que todos los cambios nuevos implementados desde entornos anteriores funcionan correctamente antes de que se implementen en producción.
Pruebas Se usa para comparar el rendimiento, probar y controlar la calidad de las cargas de trabajo con la versión de GKE que utilizará en producción. En este entorno, puedes probar la actualización del plano de control y los nodos antes de hacerlo en producción.
Desarrollo Se usa para el desarrollo activo que depende de la misma versión que se ejecuta en producción. En este entorno, creas correcciones y cambios incrementales que se implementarán en producción.
Canary Se usa como entorno de desarrollo secundario para probar versiones, funciones y APIs de Kubernetes más recientes con el objetivo de reducir el tiempo de lanzamiento al mercado una vez que se promocionan estas versiones y se convierten en destinos de actualización automática.

Registrar clústeres en canales de lanzamiento

Kubernetes suele publicar actualizaciones para ofrecer actualizaciones de seguridad, corregir problemas conocidos e introducir nuevas funciones. Los canales de versiones de GKE te permiten equilibrar la estabilidad y el conjunto de funciones de la versión desplegada en el clúster. Cuando registras un nuevo clúster en un canal de lanzamiento, Google gestiona automáticamente la versión y la frecuencia de actualización del clúster y de sus grupos de nodos.

Para mantener los clústeres actualizados con las últimas novedades de GKE y Kubernetes, te recomendamos los siguientes entornos y los canales de lanzamiento en los que deberían registrarse los clústeres:

Entorno Canal de lanzamiento Descripción
Producción Estable o normal Para disfrutar de estabilidad y madurez de la versión, usa el canal Estable o Normal en las cargas de trabajo de producción.
Staging Igual que en producción Para asegurarte de que las pruebas sean indicativas de la versión a la que se actualizará tu canal de producción, usa el mismo canal de lanzamiento que el de producción.
Pruebas
Desarrollo
Canary Rápido Para probar las versiones más recientes de Kubernetes y adelantarte a los demás probando las nuevas funciones o APIs de GKE, usa el canal Rápido. Puedes reducir el tiempo de lanzamiento al mercado cuando la versión del canal Rápido se promociona al canal que usas en producción.
N/A Ampliada Para mantener tu clúster en una versión secundaria durante más tiempo y seguir recibiendo parches de seguridad después de la fecha de finalización del periodo de asistencia estándar, usa el canal ampliado. Para obtener más información, consulta Usar el canal ampliado cuando necesites asistencia a largo plazo.

Los planos de control de un clúster se actualizan periódicamente, independientemente de si el clúster esté registrado en un canal de lanzamiento o no.

Crear una estrategia de actualización continua

Una vez que hayas registrado tu clúster en un canal de lanzamiento, se actualizará periódicamente a la versión que cumpla los requisitos de calidad y estabilidad del canal. Estas actualizaciones incluyen correcciones de seguridad y de errores, que se aplican con un escrutinio cada vez mayor en cada canal:

  • Los parches se envían al plano de control y a los nodos de todos los canales de forma gradual, acumulando tiempo de prueba en los canales Rápido y Habitual antes de llegar al canal Estable.
  • Primero se actualiza el plano de control y, después, los nodos, de acuerdo con la política de OSS de Kubernetes, según la cual la versión kubelet no debe ser más reciente que la kube-apiserver.
  • GKE implementará automáticamente parches en los canales en función de su criticidad e importancia.
  • El canal Estable solo recibe parches críticos.

Recibir novedades sobre las nuevas versiones de GKE

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

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

Cuando una nueva versión esté disponible, debes planificar una actualización antes de que la versión se convierta en el objetivo de actualización automática del clúster. Este enfoque ofrece más control y predictibilidad cuando es necesario, ya que GKE no actualiza automáticamente un clúster si la versión de destino de la actualización automática disponible es anterior o igual a la versión a la que ya has actualizado manualmente el clúster. Para obtener los destinos de actualización automática de un clúster específico, consulta Obtener información sobre las actualizaciones de un clúster.

Probar y verificar versiones nuevas de parches y versiones secundarias

Todas las versiones superan las pruebas internas, independientemente del canal en el que se publiquen. Sin embargo, debido a las frecuentes actualizaciones y parches de Kubernetes y GKE, te recomendamos que pruebes las nuevas versiones en entornos de prueba o de staging antes de implementarlas en tu entorno de producción, sobre todo en el caso de las actualizaciones de versiones secundarias de Kubernetes.

Cada canal de lanzamiento ofrece varias versiones disponibles, incluida una versión predeterminada para la creación de clústeres y objetivos de actualización automática:

  • Las nuevas versiones de parches están disponibles una semana antes de convertirse en destinos de actualización automática.
  • Las nuevas versiones secundarias de Kubernetes están disponibles cuatro semanas antes de convertirse en objetivos de actualización automática.

GKE actualiza automáticamente los clústeres a versiones más recientes. Si necesitas más control sobre el proceso de actualización, te recomendamos que actualices a una versión disponible con antelación. GKE no actualiza automáticamente los clústeres actualizados manualmente a la misma versión de destino de la actualización automática.

Un enfoque recomendado para automatizar y optimizar las actualizaciones sería el siguiente:

  • Un entorno de preproducción que usa la versión disponible.
  • Configura notificaciones de actualización en el clúster para informar a tu equipo sobre las nuevas versiones disponibles para probar y certificar.
  • Un entorno de producción suscrito a un canal de lanzamiento que usa una versión que ya has probado en tu entorno de preproducción.
  • Lanzamiento gradual de nuevas versiones disponibles en clústeres de producción. Por ejemplo, si hay varios clústeres de producción, un plan de actualización gradual empezaría actualizando una parte de estos clústeres a la versión disponible, mientras que el resto se mantendría en la versión actual. Después, se actualizarían otras partes pequeñas hasta que el 100% de los clústeres se hubiera actualizado.

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

Evento Acción recomendada
La nueva versión X está disponible en un canal. Actualiza manualmente tu clúster de pruebas, califica y prueba la nueva versión.
La versión X se convierte en el destino de actualización automática de la versión secundaria del clúster. GKE empieza a actualizarse automáticamente a la versión de destino de la actualización automática. Te recomendamos que actualices la producción antes de la flota.
GKE empieza a actualizar automáticamente los clústeres. Permitir que los clústeres se actualicen automáticamente o posponer la actualización mediante ventanas de exclusión de mantenimiento.

Estrategia de actualización para lanzamientos de parches

A continuación, se muestra una estrategia de actualización recomendada para las versiones de parche en un escenario en el que:

  • Todos los clústeres están suscritos al canal Estable.
  • Las nuevas versiones disponibles se lanzan primero en el clúster de staging.
  • El clúster de producción se actualiza automáticamente a la nueva versión de actualización automática.
  • Supervisar periódicamente las nuevas versiones disponibles de GKE.
Hora Evento ¿Qué debo hacer?
T - 1 semana Se publica una nueva versión del parche. Actualiza el entorno de staging.
B La versión del parche se convierte en el destino de la actualización automática. Para mejorar la predictibilidad, te recomendamos que actualices el plano de control de producción con antelación.
B GKE empezará a actualizar los planos de control a la versión de actualización automática. Para que sea más predecible, te recomendamos que actualices los grupos de nodos de producción con antelación.
T + 1 semana GKE empezará a actualizar los grupos de nodos del clúster a la versión de actualización automática. GKE actualizará automáticamente los clústeres, omitiendo los que se hayan actualizado manualmente.

Estrategia de actualización para nuevas versiones secundarias

A continuación, te proponemos una estrategia de actualización para las nuevas versiones secundarias:

Hora Evento ¿Qué debo hacer?
T - 3 semanas Hay una nueva versión secundaria disponible Actualizar el plano de control de las pruebas
T - 2 semanas
  1. Si la actualización del plano de control se ha completado correctamente, plantéate actualizar el plano de control de producción con antelación.
  2. Actualizar grupos de nodos de prueba.
T - 1 semana Si la actualización se realiza correctamente, plantéate actualizar los grupos de nodos de producción con antelación.
B La versión secundaria se convierte en el destino de la actualización automática.
B GKE empezará a actualizar los planos de control del clúster a la versión de destino de la actualización automática. Crea una ventana de exclusión si necesitas hacer más pruebas o mitigaciones antes de lanzar la versión de producción.
T + 1 semana GKE empezará a actualizar los grupos de nodos del clúster a la versión de destino de la actualización automática. GKE actualizará automáticamente los clústeres, omitiendo los que se hayan actualizado manualmente.

Reducir las interrupciones en las cargas de trabajo durante una actualización

Es fundamental mantener tus clústeres actualizados con parches de seguridad y correcciones de errores para asegurar su buen funcionamiento y la continuidad de tu negocio. Las actualizaciones periódicas protegen tus cargas de trabajo frente a vulnerabilidades y fallos.

Programar ventanas de mantenimiento y exclusiones

Para aumentar la predictibilidad de las actualizaciones y alinearlas con las horas de menor actividad empresarial, puedes controlar las actualizaciones automáticas del plano de control y de los nodos creando una ventana de mantenimiento. GKE respeta las ventanas de mantenimiento. Es decir, si el proceso de actualización se prolonga más allá de la ventana de mantenimiento definida, GKE intentará pausar la operación y la reanudará durante la siguiente ventana de mantenimiento.

GKE sigue una programación de lanzamiento de varios días para que las nuevas versiones estén disponibles, así como para actualizar automáticamente los planos de control y los nodos de los clústeres en diferentes regiones. El lanzamiento suele durar cuatro días o más e incluye un periodo de tiempo para observar y monitorizar si hay problemas. En un entorno de varios clústeres, puede usar una ventana de mantenimiento independiente para cada clúster con el fin de secuenciar el lanzamiento en todos los clústeres. Por ejemplo, puede que quieras controlar cuándo reciben mantenimiento los clústeres de diferentes regiones configurando ventanas de mantenimiento distintas para cada clúster.

Otra herramienta para reducir las interrupciones, sobre todo durante los periodos de alta demanda, son las exclusiones de mantenimiento. Utiliza las exclusiones de mantenimiento para evitar que se realice el mantenimiento automático durante estos periodos. Las exclusiones de mantenimiento se pueden definir en clústeres nuevos o ya creados. También puedes usar exclusiones junto con tu estrategia de actualización. Por ejemplo, puede que quieras posponer una actualización a un clúster de producción si un entorno de pruebas o de staging falla debido a una actualización.

Define tu tolerancia a las interrupciones

Puede que ya conozcas el concepto de réplicas en Kubernetes. Las réplicas aseguran la redundancia de tus cargas de trabajo para mejorar el rendimiento y la capacidad de respuesta. Cuando se define, las réplicas rigen el número de réplicas de Pod que se ejecutan en un momento dado. Sin embargo, durante el mantenimiento, Kubernetes elimina las VMs de nodo subyacentes, lo que puede reducir el número de réplicas. Para asegurarte de que tus cargas de trabajo tengan un número suficiente de réplicas para tus aplicaciones, incluso durante el mantenimiento, usa un presupuesto de interrupción de pods (PDB).

En un presupuesto de interrupción de pods, puedes definir un número (o un porcentaje) de pods que se pueden finalizar, aunque al hacerlo el número de réplicas actual sea inferior al valor deseado. Este proceso puede acelerar el drenaje de nodos, ya que no es necesario esperar a que los pods migrados estén totalmente operativos. En su lugar, la función Drain expulsa pods de un nodo siguiendo la configuración de PDB, lo que permite que la implementación implemente los pods que faltan en otros nodos disponibles. Una vez que se haya definido el PDB, GKE no cerrará los pods de tu aplicación si el número de pods es igual o inferior a un límite configurado. GKE sigue un PDB durante un máximo de 60 minutos.

Controlar las actualizaciones de grupos de nodos

Con GKE, puedes elegir una estrategia de actualización de nodos para determinar cómo se actualizan los nodos de tus grupos de nodos. De forma predeterminada, los grupos de nodos usan actualizaciones de picos. Con las actualizaciones de picos, el proceso de actualización de los grupos de nodos de GKE implica volver a crear todas las VMs del grupo de nodos. Se crea una nueva VM con la nueva versión (imagen actualizada) de forma gradual. A su vez, esto requiere cerrar todos los pods que se ejecutan en el nodo antiguo y trasladarlos al nuevo. Tus cargas de trabajo pueden ejecutarse con suficiente redundancia (réplicas) y puedes confiar en Kubernetes para mover y reiniciar pods según sea necesario. Sin embargo, una reducción temporal del número de réplicas puede seguir afectando a tu empresa y ralentizar el rendimiento de la carga de trabajo hasta que Kubernetes pueda volver al estado deseado (es decir, alcanzar el número mínimo de réplicas necesarias). Para evitar este tipo de interrupciones, puedes usar las actualizaciones de aumento de capacidad.

Durante una actualización con la función de sobreaprovisionamiento para actualizaciones habilitada, GKE primero protege los recursos (máquinas) necesarios para la actualización, luego crea un nodo actualizado y, solo entonces, vacía el nodo antiguo y, por último, lo cierra. De esta forma, la capacidad esperada se mantiene intacta durante todo el proceso de actualización.

En los clústeres grandes, donde el proceso de actualización puede tardar más, puedes acelerar el tiempo de finalización de la actualización actualizando varios nodos a la vez. Usa el sobreaprovisionamiento para actualizaciones con maxSurge=20 y maxUnavailable=0 para indicar a GKE que actualice 20 nodos a la vez sin usar la capacidad actual.

Usa el canal Ampliado cuando necesites asistencia a largo plazo

Si quieres mantener tu clúster en una versión secundaria durante más tiempo, sigue la práctica recomendada de registrar tu clúster en el canal Extended. Con este canal, GKE admite una versión secundaria durante aproximadamente 24 meses. Para obtener más información, consulta Obtener asistencia a largo plazo con el canal Extended.

Para sacar el máximo partido al canal, le recomendamos que siga las prácticas recomendadas que se indican a continuación. Algunas de estas prácticas recomendadas requieren que realices alguna acción manual, como actualizar manualmente un clúster o cambiar el canal de lanzamiento de un clúster. Consulta los casos prácticos admitidos y cuándo no usar el canal ampliado.

Mantener temporalmente una versión secundaria durante más tiempo

Si necesitas mantener un clúster en una versión secundaria durante más tiempo que el periodo de asistencia estándar de 14 meses, por ejemplo, para mitigar el uso de APIs obsoletas que se han eliminado en la siguiente versión secundaria, sigue este proceso. Puedes mover temporalmente el clúster de otro canal de lanzamiento al canal Extended para seguir recibiendo parches de seguridad mientras te preparas para actualizar a la siguiente versión secundaria. Cuando quieras actualizar a la siguiente versión secundaria, actualiza el clúster manualmente y, a continuación, vuelve a colocarlo en el canal de lanzamiento original.

Actualizaciones de versiones secundarias 1 o 2 veces al año

Si quieres que tu clúster sufra las mínimas interrupciones posibles y, al mismo tiempo, recibir algunas funciones nuevas cuando esté listo para actualizarse a una nueva versión secundaria, haz lo siguiente:

  • Registra un clúster en el canal Extended.
  • Realiza dos actualizaciones de versión menores sucesivas entre una y dos veces al año. Por ejemplo, actualiza de la versión 1.30 a la 1.31 y, después, a la 1.32.

Este proceso asegura que el clúster se mantenga en una versión secundaria disponible, reciba funciones de nuevas versiones secundarias, pero solo reciba actualizaciones de versiones secundarias cuando decidas que el clúster está listo.

Cuándo no usar el canal ampliado

Para usar el canal ampliado con el fin previsto, se requiere una acción manual. En el siguiente ejemplo se ilustran las consecuencias de usar el canal Extended sin gestionar activamente la versión secundaria de tu clúster.

No hagas nada y recibe actualizaciones menores con la misma frecuencia

Si quieres que tu clúster se mantenga en una versión secundaria para siempre, regístralo en el canal ampliado y no hagas nada más. Todas las versiones secundarias dejan de tener asistencia y GKE actualiza automáticamente los clústeres de versiones secundarias no compatibles. Por lo tanto, GKE actualiza este clúster de una versión secundaria no admitida a otra que pronto dejará de estarlo, lo que supone una media de aproximadamente cada 4 meses. Esto significa que el clúster recibe actualizaciones de la versión secundaria con la misma frecuencia que en otros canales de lanzamiento, pero recibe las nuevas funciones más tarde.

Resumen de la lista de comprobación

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

Práctica recomendada Tasks
Configurar varios entornos
Registrar clústeres en canales de lanzamiento
Crear una estrategia de actualización continua
Reducir las interrupciones en las cargas de trabajo

Siguientes pasos