En esta página, se explica cómo tú y Google Kubernetes Engine (GKE) administran los cambios durante el ciclo de vida de un clúster para maximizar el rendimiento y la disponibilidad, a la vez que se minimizan las interrupciones de las cargas de trabajo.
Esta página está dirigida a los administradores de plataformas que desean planificar y optimizar su entorno de clúster para minimizar las interrupciones en sus cargas de trabajo. Puedes leer esta página antes o después de aprender a realizar las tareas básicas de administración de clústeres que se describen en Administra clústeres y Descripción general de la administración de clústeres.
Una plataforma administrada y responsabilidad compartida
GKE es una implementación administrada por Google de la plataforma de organización de contenedores de código abierto de Kubernetes. Como se menciona en Cómo funciona GKE, un clúster de GKE consta de un plano de control, que incluye nodos de administración que ejecutan componentes del sistema, y nodos trabajadores, en los que implementas las cargas de trabajo.
Crear un entorno de clúster óptimo para que se ejecuten tus cargas de trabajo, con el máximo rendimiento, disponibilidad y una interrupción mínima, es una responsabilidad compartida:
- La responsabilidad de GKE es mantener un entorno de clúster confiable, disponible, seguro y con buen rendimiento. Para ello, GKE administra el plano de control, los componentes del sistema y, en el modo Autopilot, los nodos trabajadores.
- Como administrador de la plataforma, tu responsabilidad es configurar el clúster y administrar las cargas de trabajo, lo que incluye prepararlas para controlar las interrupciones. Con el modo Estándar, también creas y administras los nodos trabajadores, que se agrupan en grupos de nodos.
Para obtener más información, consulta Responsabilidad compartida de GKE.
Cómo GKE administra los cambios durante el ciclo de vida de un clúster
Como implementación de Kubernetes, un clúster de GKE es una red de procesos y sistemas que actúan en conjunto para mantener el entorno óptimo para ejecutar tus cargas de trabajo. Para administrar el clúster, GKE realiza tareas de mantenimiento, hace cambios, inicia operaciones, actualiza componentes y actualiza la versión del plano de control y los nodos.
La mayor parte de la ejecución diaria de tu aplicación se produce de forma silenciosa en segundo plano, lo que mantiene tus cargas de trabajo en ejecución sin interrupciones. Sin embargo, algunos cambios críticos deben completarse de maneras que podrían interrumpir temporalmente tus cargas de trabajo, como se describe en la siguiente sección.
Algunos cambios en el clúster pueden interrumpir las cargas de trabajo
Si bien GKE se esfuerza por mantener tus cargas de trabajo en ejecución sin problemas, algunos tipos de cambios esenciales pueden requerir interrupciones temporales en tus cargas de trabajo, principalmente cambios que reinician los nodos que ejecutan tus cargas de trabajo. Con las funciones de GKE y Kubernetes, puedes especificar cuándo y cómo quieres que se produzca la interrupción, de modo que, cuando ocurra, tus cargas de trabajo puedan controlar los cambios de forma correcta.
En las siguientes secciones, se explican los tipos de cambios que GKE realiza en los clústeres, el tipo de interrupción que causan y cómo puedes prepararte.
Actualizaciones con la administración del ciclo de vida de clúster de GKE
En GKE, las actualizaciones y las mejoras de los clústeres tienen significados relacionados.
En GKE, el término actualizaciones de clústeres, o solo actualizaciones, se refiere a la actualización de la versión de Kubernetes del plano de control (actualizaciones del plano de control) o de los nodos (actualizaciones de nodos), o ambos. Cuando se usan clústeres de Standard, las actualizaciones de nodos también se pueden denominar actualizaciones de grupos de nodos porque GKE usa una sola operación para actualizar un grupo de nodos.
El término actualizaciones del clúster, o solo actualizaciones, es un término más general que se refiere a cualquier tipo de cambio en el plano de control o en los nodos, incluida la actualización de sus versiones. GKE administra de forma activa el entorno de tu clúster realizando actualizaciones, otros tipos de actualizaciones y las operaciones de mantenimiento necesarias. Estas acciones garantizan que tu clúster siga siendo eficiente, seguro y esté actualizado con las funciones y correcciones de errores más recientes. GKE usa herramientas como las estrategias de actualización de nodos y las políticas de mantenimiento para minimizar las interrupciones durante estos procesos.
Planifica las interrupciones de las actualizaciones de nodos
Ciertos tipos de cambios en los clústeres, en su mayoría cambios en los nodos, pueden causar interrupciones.
GKE usa estrategias de actualización de nodos para actualizar los nodos, tanto los de Autopilot como los grupos de nodos de clústeres de Standard, de una manera optimizada para las necesidades de tu carga de trabajo. Estas estrategias se aplican a las actualizaciones de versión y también a algunos otros tipos de cambios de nodos. Las estrategias permiten que GKE minimice las interrupciones mientras realiza actualizaciones de nodos, que son importantes para mantener los clústeres funcionales y con buen rendimiento.
Usa períodos de mantenimiento y exclusiones para elegir cuándo se realiza el mantenimiento del clúster y, en el caso de los clústeres de Standard, elige la estrategia de actualización de nodos que mejor se adapte a tu perfil de carga de trabajo y a las restricciones de recursos.
En el caso de los cambios manuales y automáticos en los nodos, GKE realiza cambios con las siguientes características generales:
Por lo general, los cambios respetan las políticas de mantenimiento: Cuando GKE realiza cambios en los nodos, estos suelen respetar las políticas de mantenimiento de GKE. Algunas excepciones incluyen el mantenimiento del host para ciertos tipos de nodos, como aquellos con GPU y TPU.
Ten en cuenta lo siguiente si inicias cambios manuales que requieren que se vuelvan a crear todos los nodos de un grupo de nodos:
- Para algunos cambios, GKE respeta las políticas de mantenimiento y no aplica el cambio que enviaste hasta que haya disponibilidad de mantenimiento. Si GKE está esperando la disponibilidad de mantenimiento y el cambio es urgente, puedes aplicar manualmente los cambios para aplicar la configuración nueva de inmediato.
- Para otros cambios manuales, incluidas las actualizaciones manuales, GKE no respeta las políticas de mantenimiento. Para estos cambios manuales, asegúrate de que tus cargas de trabajo estén preparadas para una interrupción inmediata.
Por lo general, los cambios usan estrategias de actualización de nodos: Cuando GKE aplica la mayoría de los cambios automáticos o iniciados de forma manual a los nodos, incluidas las actualizaciones de nodos que no sean actualizaciones de versión, GKE elige una estrategia de actualización de nodos: actualizaciones de aumento, actualizaciones azul-verde o azul-verde con ajuste de escala automático (versión preliminar). Autopilot siempre usa actualizaciones de aumento. Los cambios en los grupos de nodos de clústeres de Standard suelen usar actualizaciones de aumento, excepto cuando configuraste actualizaciones azul-verde o azul-verde con ajuste de escala automático y realizas ciertos tipos de cambios. Para obtener más información sobre qué estrategia se configura para un grupo de nodos, consulta Inspecciona la configuración de actualización de un grupo de nodos.
Los cambios requieren recursos suficientes: Cuando GKE aplica un cambio con una estrategia de actualización de nodos, este cambio requiere una cierta cantidad de recursos según la estrategia y su configuración. El proyecto de tu clúster debe tener suficiente cuota de recursos, disponibilidad de recursos y capacidad de reserva (para grupos de nodos con afinidad de reserva específica). Para obtener más información, consulta Garantiza recursos para las actualizaciones de nodos.
Para obtener una lista detallada de los cambios específicos y sus características, consulta Tipos de cambios en un clúster de GKE en esta página.
Maximiza la disponibilidad de las cargas de trabajo preparándote para los cambios disruptivos
Para maximizar la disponibilidad de tus cargas de trabajo que se ejecutan en un clúster de GKE, te recomendamos que realices las acciones que se describen en las siguientes secciones:
Elige la disponibilidad de tu clúster
Si la disponibilidad del plano de control es una prioridad, elige un clúster de Autopilot o un clúster de Standard regional en lugar de un clúster de Standard zonal. Para obtener más información, consulta Acerca de las opciones de configuración del clúster.
Controla las actualizaciones con las herramientas de GKE
Puedes usar las siguientes herramientas para controlar cuándo y cómo GKE actualiza tu clúster, lo que permite implementar las prácticas recomendadas:
- Canales de versiones: Elige un canal de versiones para obtener versiones de clústeres con el equilibrio que elijas entre la disponibilidad y la estabilidad de las funciones.
- Períodos de mantenimiento: Especifica un período recurrente en el que se puedan realizar ciertos tipos de mantenimiento de clústeres de GKE, como las actualizaciones.
- Exclusiones de mantenimiento: Evita que se realice el mantenimiento del clúster durante un período específico.
- Presupuestos de interrupción del clúster: personaliza el intervalo de tiempo mínimo entre tipos específicos de actualizaciones del clúster, incluidas las actualizaciones de parches o secundarias.
- Estrategias de actualización de nodos: Si usas un grupo de nodos de Standard, elige cómo se actualizan tus nodos: actualizaciones de aumento, azul-verde o azul-verde con ajuste de escala automático (versión preliminar) para minimizar las interrupciones en tus cargas de trabajo. Además, elige cuántos grupos de nodos actualiza GKE automáticamente al mismo tiempo en un clúster.
- Secuencia de lanzamiento: Califica las actualizaciones en un entorno de preproducción antes de que GKE actualice tus clústeres de producción.
- Actualizaciones manuales: Actualiza tu clúster de forma manual y realiza acciones como cancelar, reanudar, revertir y completar las actualizaciones automáticas o manuales en curso.
Administra y supervisa tu clúster
Para administrar las posibles interrupciones en tus clústeres, realiza las siguientes tareas de forma continua:
- Supervisa tu clúster con el paquete de observabilidad de GKE.
- Sigue las notas de la versión de GKE para ver anuncios.
- Consulta las notificaciones del clúster, como cuándo se inician o completan las actualizaciones, cuándo hay versiones nuevas disponibles, los boletines de seguridad y las fechas de finalización de la asistencia.
- Obtén visibilidad de las actualizaciones de los clústeres para comprender el estado de las actualizaciones de tus clústeres.
- Consulta el programa de lanzamientos de GKE para obtener una estimación óptima de cuándo estarán disponibles las versiones secundarias para las actualizaciones y cuándo alcanzarán el final de la asistencia.
- Usa la guía prescriptiva que identifica posibles oportunidades de optimización y explica cómo optimizar el uso de tu clúster, incluida la guía para las bajas de funciones y APIs.
Prepara tus cargas de trabajo
Administra las interrupciones haciendo que tus cargas de trabajo sean lo más resilientes posible a las interrupciones:
- Ejecuta réplicas de tus cargas de trabajo para garantizar la redundancia y evitar un punto único de fallo.
- Especifica un presupuesto de interrupción para tu aplicación con un presupuesto de interrupción de Pods.
- Establece un período de gracia de finalización de la duración correcta para que tu carga de trabajo se cierre de forma ordenada.
- Si tu carga de trabajo usa GPU o TPU, sigue las instrucciones para administrar las interrupciones de nodos de GKE para GPU y TPU.
- Para las aplicaciones con estado, que a menudo necesitan tiempo para detener la E/S de forma correcta y desactivar el almacenamiento, sigue los pasos que se indican en Asegúrate de que las cargas de trabajo con estado estén listas para las interrupciones.
Para ver un análisis general de estos temas, consulta la sección Administra las interrupciones de la entrada de blog Prácticas recomendadas de GKE: Operaciones del día 2 para la continuidad del negocio.
Tipos de cambios en un clúster de GKE
En las siguientes tablas, se muestran los tipos más comunes de cambios importantes en un clúster, incluidas las características de estos cambios, como la frecuencia y el nivel de interrupción.
Tipos de actualizaciones
Revisa la siguiente tabla para comprender cómo las actualizaciones pueden interrumpir un entorno de clúster.
| Cambiar | Automático o iniciado de forma manual | Respeta las políticas de mantenimiento. | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
| Actualización del plano de control | Automática o manual |
Las actualizaciones automáticas respetan las políticas de mantenimiento hasta que finaliza la asistencia, excepto en el caso de correcciones de emergencia extremadamente raras, según sea necesario. Las actualizaciones manuales no están bloqueadas por las políticas de mantenimiento. |
Actualizaciones de parches, con una frecuencia de hasta una vez por semana, según el canal de versiones Actualizaciones secundarias aproximadamente cada cuatro meses. En el caso de los clústeres del canal extendido, las actualizaciones secundarias solo se realizan cuando la versión secundaria se acerca al final de la asistencia. |
Plano de control |
En el caso de los clústeres de Autopilot y Standard regionales, el plano de control sigue disponible. En el caso de los clústeres de Standard zonales, hay varios minutos en los que no puedes comunicarte con el plano de control, lo que significa que no puedes configurar el clúster, los nodos ni las cargas de trabajo durante ese tiempo. |
| Actualización de nodos | Automática o manual |
Las actualizaciones automáticas respetan las políticas de mantenimiento hasta que finaliza la asistencia, excepto en el caso de correcciones de emergencia extremadamente raras, según sea necesario. Las actualizaciones manuales no están bloqueadas por las políticas de mantenimiento. |
Por lo general, son las mismas que las actualizaciones del plano de control. Si tu clúster no está inscrito en un canal de versiones y, además, inhabilitas las actualizaciones automáticas de nodos, eres responsable de actualizar manualmente los grupos de nodos del clúster. |
Todos los nodos de los clústeres de Autopilot o uno o más grupos de nodos de clústeres de Standard. |
Los nodos deben cerrarse para volver a crearse, y los Pods deben reemplazarse. GKE usa actualizaciones de aumento para Autopilot o la estrategia de actualización de nodos configurada (aumento, azul-verde o azul-verde con ajuste de escala automático [versión preliminar]) para los clústeres de Standard. |
Cambios manuales que vuelven a crear los nodos con una estrategia de actualización de nodos y respetan las políticas de mantenimiento
Revisa la siguiente tabla para comprender cómo estos cambios manuales pueden interrumpir un entorno de clúster. Esta lista incluye, entre otros cambios, cambios manuales que respetan las políticas de mantenimiento de GKE.
| Cambiar | Automático o iniciado de forma manual | Respeta las políticas de mantenimiento. | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
| Inhabilita el puerto de solo lectura de kubelet | Iniciada manualmente | No respeta las políticas de mantenimiento y realiza cambios de inmediato. | Una vez por cada cambio de este tipo. | Todos los nodos de un clúster de Autopilot Todos los nodos de un grupo de nodos de un clúster de Standard |
Los nodos deben cerrarse para volver a crearse. Los Pods deben reemplazarse. GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos, sin importar las políticas de mantenimiento activas. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
| Rota las credenciales del clúster | Automática si las credenciales del clúster vencen en un plazo de 30 días; también se puede iniciar de forma manual. | Respeta las políticas de mantenimiento. Sin embargo, GKE podría anular las políticas de mantenimiento en un plazo de 30 días a partir del vencimiento de las credenciales. En un plazo de 30 días, GKE ignora la disponibilidad de mantenimiento para el primer paso, que es iniciar la rotación. Además, si activas de forma manual operaciones específicas después del primer paso, esa operación no respetará las políticas de mantenimiento. | Una vez por cambio manual de este tipo o depende de la vida útil de las credenciales del clúster para el inicio automático. Puedes invocar operaciones de forma manual para pasos específicos en el proceso de rotación. | En algunos pasos, el plano de control. Para otros pasos, todos los nodos de los clústeres de Autopilot y todos los nodos de cada grupo de nodos del clúster de Standard. |
Cuando inicias la rotación y la completas, el nivel de interrupción es el siguiente:
Cuando se vuelven a crear los nodos, el nivel de interrupción es el siguiente:
|
| Rotación de la dirección IP del plano de control | Iniciada manualmente | Respeta las políticas de mantenimiento; sin embargo, si activas de forma manual operaciones específicas después del primer paso, esa operación no respeta las políticas de mantenimiento. | Una vez por cada cambio manual de este tipo. Puedes invocar operaciones de forma manual para pasos específicos en el proceso de rotación. | En algunos pasos, el plano de control. Para otros pasos, todos los nodos de los clústeres de Autopilot y todos los nodos de cada grupo de nodos del clúster de Standard. |
Cuando inicias la rotación y la completas, el nivel de interrupción es el siguiente:
Cuando se vuelven a crear los nodos, el nivel de interrupción es el siguiente:
|
| Configura nodos protegidos | Iniciada manualmente |
Volver a crear el plano de control no respeta las políticas de mantenimiento, ya que aplica los cambios de inmediato. La recreación de los nodos respeta las políticas de mantenimiento. |
Una vez por cambio de este tipo |
Se actualiza el plano de control. Después de actualizar el plano de control, se deben volver a crear todos los nodos de cada grupo de nodos del clúster de Standard. |
Cuando se vuelve a crear el plano de control, el nivel de interrupción es el siguiente:
Cuando se vuelven a crear los nodos, el nivel de interrupción es el siguiente:
|
| Configura políticas de red | Iniciada manualmente | Respeta las políticas de mantenimiento | Una vez por cambio de este tipo | Todos los nodos de los clústeres de Autopilot y todos los nodos de cada grupo de nodos de clústeres de Standard. |
Los nodos deben cerrarse para volver a crearse, y los Pods deben reemplazarse. GKE usa actualizaciones de aumento para volver a crear los nodos. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
| Configura la visibilidad dentro de los nodos | Iniciada manualmente | Respeta las políticas de mantenimiento | Una vez por cambio de este tipo | Todos los nodos de los clústeres de Autopilot y todos los nodos de cada grupo de nodos de clústeres de Standard. |
Los nodos deben cerrarse para volver a crearse, y los Pods deben reemplazarse. GKE usa actualizaciones de aumento para volver a crear los nodos. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
| Configura NodeLocal DNSCache | Iniciada manualmente | Respeta las políticas de mantenimiento | Una vez por cambio de este tipo | Se deben actualizar todos los nodos del grupo de nodos del clúster de Standard que se está actualizando. |
Los nodos deben cerrarse para volver a crearse, y los Pods deben reemplazarse. GKE usa actualizaciones de aumento para volver a crear los nodos. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
| Habilita la transmisión de imágenes | Iniciada manualmente |
Cuando se actualiza a nivel del clúster, se respetan las políticas de mantenimiento. Cuando se actualizan grupos de nodos individuales, no se respetan las políticas de mantenimiento. |
Una vez por cambio de este tipo |
Si se activa a nivel del grupo de nodos, todos los nodos del grupo de nodos del clúster de Standard. Si se activa a nivel del clúster, los nodos de cualquier grupo de nodos del clúster de Standard en el que no hayas habilitado o inhabilitado de forma individual el parámetro de configuración para el grupo de nodos. |
GKE usa actualizaciones de aumento para volver a crear los nodos de un grupo de nodos. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
Mantenimiento automático que no respeta las políticas de mantenimiento
Revisa la siguiente tabla para comprender cómo el mantenimiento automático que no respeta las políticas de mantenimiento puede interrumpir un entorno de clúster.
| Cambiar | Automático o iniciado de forma manual | Respeta las políticas de mantenimiento. | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
| Reparación o cambio de tamaño del plano de control | Automático | No respeta las políticas de mantenimiento |
La frecuencia de reparación del plano de control es aleatoria, pero no tiene impacto en los clústeres de Autopilot ni en los clústeres regionales de Standard. El cambio de tamaño del plano de control es poco frecuente, pero aumenta su frecuencia con los eventos de escalamiento del clúster y tampoco tiene impacto en los clústeres de Autopilot y regionales de Standard. |
Plano de control |
En el caso de los clústeres de Autopilot y Standard regionales, el plano de control sigue disponible. En el caso de los clústeres de Standard zonales, hay varios minutos en los que no puedes comunicarte con el plano de control, lo que significa que no puedes configurar el clúster, los nodos ni las cargas de trabajo durante ese tiempo. |
| Evento de mantenimiento del host | Automático | No respeta las políticas de mantenimiento | Consulta Eventos de mantenimiento para conocer la frecuencia aproximada. | Un nodo |
Para la mayoría de los tipos de nodos, el efecto es mínimo. Algunos nodos, incluidos aquellos con GPU o TPU, podrían experimentar una mayor interrupción. Para obtener más información, consulta Otro mantenimiento de Google Cloud . |
| Reparación automática de nodos | Automático | No respeta las políticas de mantenimiento | La frecuencia de reparación automática de nodos es aleatoria. |
Un nodo | El nodo se reinicia, por lo que se interrumpen todos los Pods que se ejecutan en él. |
| Recupera VMs Spot y VMs interrumpibles | Automático | No respeta las políticas de mantenimiento |
En el caso de las VMs interrumpibles, al menos una vez cada 24 horas. En el caso de las VMs Spot, cuando Compute Engine necesita los recursos en otro lugar. |
Un nodo | Consulta los detalles sobre la rescisión y el cierre ordenado de las VMs Spot, y la rescisión y el cierre ordenado de las VMs interrumpibles. |
| Mantenimiento de la base de datos de estado del clúster basada en Spanner | Automático | No respeta las políticas de mantenimiento | Los eventos son aleatorios y no afectan los clústeres ni las cargas de trabajo. | Ninguno La base de datos basada en Spanner se ejecuta de forma independiente del plano de control del clúster y de los nodos en la infraestructura de Google. | Ninguno La base de datos basada en Spanner se replica para todos los tipos de clústeres y permanece disponible durante el mantenimiento. |
Cambios manuales que vuelven a crear los nodos con una estrategia de actualización de nodos sin respetar las políticas de mantenimiento
Revisa la siguiente tabla para comprender cómo estos cambios manuales pueden interrumpir un entorno de clúster. Esta lista incluye cambios de cuando GKE usa actualizaciones de aumento y cuando GKE usa actualizaciones azul-verde que no se incluyen en la otra sección, ya que no respetan las políticas de mantenimiento.
| Cambiar | Automático o iniciado de forma manual | Respeta las políticas de mantenimiento. | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
| Cambios en la recopilación de registros del plano de control | Iniciada manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cambio de este tipo | Se actualiza el plano de control. | Cuando se vuelve a crear el plano de control, el nivel de interrupción es el siguiente:
|
| Actualización de la etiqueta del grupo de nodos | Iniciada manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster de Standard | GKE usa de inmediato las actualizaciones de aumento para volver a crear el grupo de nodos cuando actualizas las etiquetas de nodo en un grupo de nodos existente, sin importar las políticas de mantenimiento activas. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
| Escala verticalmente los nodos cambiando sus atributos de máquina | Iniciada manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster de Standard | GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos en un grupo de nodos existente, sin importar las políticas de mantenimiento activas. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
| Cambios de tipos de imágenes | Iniciada manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster de Standard |
Los nodos deben cerrarse para volver a crearse, y los Pods deben reemplazarse. GKE usa la estrategia de actualización de nodos configurada (de aumento, azul-verde o azul-verde con ajuste de escala automático [versión preliminar]) para los clústeres de Standard. |
| Agrega o reemplaza grupos de almacenamiento en un grupo de nodos de un clúster de Standard | Iniciada manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster de Standard |
Los nodos deben cerrarse para volver a crearse, y los Pods deben reemplazarse. GKE usa la estrategia de actualización de nodos configurada (de aumento, azul-verde o azul-verde con ajuste de escala automático [versión preliminar]) para los clústeres de Standard. |
| Habilita la transmisión de imágenes | Iniciada manualmente |
Cuando se actualiza a nivel del clúster, se respetan las políticas de mantenimiento. Cuando se actualizan grupos de nodos individuales, no se respetan las políticas de mantenimiento. |
Una vez por cambio de este tipo |
Si se activa a nivel del grupo de nodos, todos los nodos del grupo de nodos del clúster de Standard. Si se activa a nivel del clúster, los nodos de cualquier grupo de nodos del clúster de Standard en el que no hayas habilitado o inhabilitado de forma individual el parámetro de configuración para el grupo de nodos. |
GKE usa actualizaciones de aumento para volver a crear los nodos de un grupo de nodos. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
| Actualizaciones de la configuración de rendimiento de la red | Iniciada manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster de Standard |
Los nodos deben cerrarse para volver a crearse, y los Pods deben reemplazarse. GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos en un grupo de nodos existente, sin importar las políticas de mantenimiento activas. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
| Habilitación de gVNIC | Iniciada manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster de Standard |
Los nodos deben cerrarse para volver a crearse, y los Pods deben reemplazarse. GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos en un grupo de nodos existente, sin importar las políticas de mantenimiento activas. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
| Cambios en la configuración del sistema de nodos (con la estrategia de actualización estándar) | Iniciada manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster de Standard |
Los nodos deben cerrarse para volver a crearse, y los Pods deben reemplazarse. GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos en un grupo de nodos existente, sin importar las políticas de mantenimiento activas. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
| Nodos confidenciales | Iniciada manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster de Standard |
Los nodos deben cerrarse para volver a crearse, y los Pods deben reemplazarse. GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos en un grupo de nodos existente, sin importar las políticas de mantenimiento activas. GKE usa actualizaciones de aumento, independientemente de si se configura una estrategia de actualización de nodos diferente, como las actualizaciones azul-verde. |
Cambios que no requieren que se vuelvan a crear los nodos
Revisa la siguiente tabla para comprender qué cambios en la configuración de los nodos no requieren que se vuelvan a crear. Estos cambios no son disruptivos, pero es posible que se produzcan interrupciones si la configuración actualizada del nodo afecta tu carga de trabajo.
| Cambiar | Automático o iniciado de forma manual | Respeta las políticas de mantenimiento. | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
|
Actualiza los siguientes parámetros de configuración:
|
Iniciada manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cambio de este tipo | Se actualizan todos los nodos relevantes. | No es necesario reemplazar los Pods porque la configuración de los nodos se actualiza sin volver a crearlos. |
¿Qué sigue?
- Descripción general de GKE
- Arquitectura de clústeres de GKE
- Responsabilidad compartida de GKE
- Control de versiones y asistencia de GKE
- Acuerdo de Nivel de Servicio de GKE
- Actualizaciones de clústeres de GKE