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, y minimizar 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 Administración de 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 mencionó 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 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 la mínima interrupción, 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, para el modo Autopilot, los nodos trabajadores.
- Tu responsabilidad como administrador de la plataforma es configurar el clúster y administrar las cargas de trabajo, lo que incluye prepararlas para que puedan controlar las interrupciones. Con el modo Standard, 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 del funcionamiento diario de tu aplicación se produce de forma silenciosa en segundo plano, lo que permite que tus cargas de trabajo se ejecuten 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 los 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 deseas que se produzca la interrupción, de modo que, cuando suceda, 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 actualizaciones de clúster tienen significados relacionados.
En GKE, el término actualizaciones de clúster, o simplemente 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 de 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 simplemente 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 operaciones de mantenimiento necesarias. Estas acciones garantizan que tu clúster siga teniendo un buen rendimiento, sea 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.
Planificación de interrupciones en las actualizaciones de nodos
Ciertos tipos de cambios en el clúster, principalmente los cambios en los nodos, pueden causar interrupciones.
GKE usa estrategias de actualización de nodos para actualizar los nodos (ya sean nodos de Autopilot o grupos de nodos de clústeres estándar) de una manera optimizada para las necesidades de tu carga de trabajo. Estas estrategias se aplican a las actualizaciones de versiones y a 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 un buen rendimiento.
Usa períodos de mantenimiento y exclusiones para elegir cuándo se realiza y cuándo no el mantenimiento de algunos clústeres y, en el caso de los clústeres estándar, elige una estrategia de actualización de nodos que se adapte mejor a tu perfil de carga de trabajo y a las restricciones de recursos.
En el caso de los cambios iniciados de forma manual y automática 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 cambios suelen respetar las políticas de mantenimiento de GKE.
Ten en cuenta lo siguiente si inicias cambios manuales que requieren que se vuelvan a crear todos los nodos de un grupo de nodos:
- En el caso de 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 los cambios de forma manual para aplicar la nueva configuración de inmediato.
- En el caso de otros cambios manuales, incluidos los actualizaciones manuales, GKE no respeta las políticas de mantenimiento. En el caso de estos cambios manuales, asegúrate de que tus cargas de trabajo estén preparadas para interrupciones inmediatas.
- Los cambios suelen usar estrategias de actualización de nodos: Cuando GKE aplica la mayoría de los cambios automáticos o iniciados de forma manual en los nodos (incluidas las actualizaciones de nodos que no son actualizaciones de versión), GKE elige una estrategia de actualización de nodos: actualizaciones de aumento o actualizaciones azul-verde. Autopilot siempre usa actualizaciones de aumento. Los cambios en los grupos de nodos de los clústeres estándar suelen usar actualizaciones de aumento, excepto cuando configuraste actualizaciones azul-verde y realizas ciertos tipos de cambios.
- 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 estándar regional en lugar de un clúster estándar 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 te permite implementar las prácticas recomendadas:
- Canales de versiones: Elige un canal de versiones para obtener versiones del clúster 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 pueden ocurrir ciertos tipos de mantenimiento del clúster de GKE, como las actualizaciones.
- Exclusiones de mantenimiento: Evita que se realice el mantenimiento del clúster durante un período específico.
- Estrategias de actualización de nodos: Si usas clústeres estándar, elige cómo se actualizan tus nodos (actualizaciones de aumento o actualizaciones azul-verde) para minimizar las interrupciones en tus cargas de trabajo.
- Secuenciación de lanzamientos: 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 actualizaciones automáticas o manuales en curso.
Administra y supervisa tu clúster
Para administrar 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 cuando comienzan o finalizan las actualizaciones, cuando hay versiones nuevas disponibles, los boletines de seguridad y las fechas de finalización de la compatibilidad.
- Obtén visibilidad de las actualizaciones de 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 del mejor caso posible de cuándo estarán disponibles las versiones secundarias para las actualizaciones y cuándo finalizará la asistencia.
- Usa orientación prescriptiva que identifica posibles oportunidades de optimización y explica cómo optimizar el uso de tu clúster, incluida la orientación para las obsolescencias de funciones y APIs.
Prepara tus cargas de trabajo
Administra las interrupciones haciendo que tus cargas de trabajo sean lo más resistentes posible a las interrupciones:
- Ejecuta réplicas de tus cargas de trabajo para garantizar la redundancia y evitar un único punto 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 adecuada para que tu carga de trabajo se cierre de forma ordenada.
- Si tu carga de trabajo usa GPUs o TPUs, sigue las instrucciones para administrar las interrupciones de nodos de GKE para GPUs y TPUs.
- En el caso de las aplicaciones con estado, que a menudo necesitan tiempo para detener E/S de forma correcta y desactivar el almacenamiento, sigue los pasos que se indican en Cómo garantizar que las cargas de trabajo con estado estén listas para las interrupciones.
Para obtener 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 manualmente | Respeta las políticas de mantenimiento | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
| Actualización del plano de control | Automático o manual |
Las actualizaciones automáticas respetan las políticas de mantenimiento hasta el final de la asistencia, excepto en el caso de correcciones de emergencia extremadamente raras, según sea necesario. Las políticas de mantenimiento no bloquean las actualizaciones manuales. |
Actualizaciones de parches, con una frecuencia de hasta una vez por semana, según el canal de versiones. Actualizaciones menores 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 permanece disponible. En el caso de los clústeres zonales estándar, 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ático o manual |
Las actualizaciones automáticas respetan las políticas de mantenimiento hasta el final de la asistencia, excepto en el caso de correcciones de emergencia extremadamente raras, según sea necesario. Las políticas de mantenimiento no bloquean las actualizaciones manuales. |
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 estándar |
Los nodos se deben apagar para volver a crearlos, y los Pods se deben reemplazar. GKE usa actualizaciones de aumento para Autopilot o la estrategia de actualización de nodos configurada (aumento o azul-verde) para los clústeres Standard. |
Cambios manuales que recrean 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, los cambios manuales que respetan las políticas de mantenimiento de GKE.
| Cambiar | Automático o iniciado manualmente | Respeta las políticas de mantenimiento | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
| Inhabilita el puerto de solo lectura de kubelet | Se inició 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 se deben apagar para volver a crearse. Se deben reemplazar los pods. GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos, independientemente de las políticas de mantenimiento activas. |
| 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, es posible que GKE anule 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 manualmente operaciones específicas después del primer paso, esa operación no respetará las políticas de mantenimiento. | Una vez por cada cambio manual de este tipo o según la duración de las credenciales del clúster para la iniciación automática Puedes invocar operaciones de forma manual para pasos específicos en el proceso de rotación. | Para 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 de clústeres 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 | Se inició manualmente | Sin embargo, si activas manualmente operaciones específicas después del primer paso, esa operación no respetará 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. | Para 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 de clústeres 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 | Se inició manualmente |
La recreación del plano de control no respeta las políticas de mantenimiento y realiza los cambios de inmediato. La recreación de los nodos respeta las políticas de mantenimiento. |
Una vez por cada 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 en 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 | Se inició manualmente | Respeta las políticas de mantenimiento | Una vez por cada cambio de este tipo | Todos los nodos de los clústeres de Autopilot y todos los nodos de cada grupo de nodos de los clústeres Standard |
Los nodos se deben apagar para volver a crearlos, y los Pods se deben reemplazar. GKE usa actualizaciones de aumento para volver a crear los nodos. |
| Configura la visibilidad dentro de los nodos | Se inició manualmente | Respeta las políticas de mantenimiento | Una vez por cada cambio de este tipo | Todos los nodos de los clústeres de Autopilot y todos los nodos de cada grupo de nodos de los clústeres Standard |
Los nodos se deben apagar para volver a crearlos, y los Pods se deben reemplazar. GKE usa actualizaciones de aumento para volver a crear los nodos. |
| Configura NodeLocal DNSCache | Se inició manualmente | Respeta las políticas de mantenimiento | Una vez por cada 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 se deben apagar para volver a crearlos, y los Pods se deben reemplazar. GKE usa actualizaciones de aumento para volver a crear los nodos. |
| Cómo habilitar la transmisión de imágenes | Se inició 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 cada cambio de este tipo |
Si se activa a nivel del grupo de nodos, se aplica a 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 estándar en el que no hayas habilitado o inhabilitado individualmente 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. |
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 manualmente | 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 estándar regionales. El cambio de tamaño del plano de control es poco frecuente, pero aumenta con los eventos de ajuste de escala del clúster y tampoco tiene impacto en los clústeres de Autopilot y estándar regionales. |
Plano de control |
En el caso de los clústeres de Autopilot y Standard regionales, el plano de control permanece disponible. En el caso de los clústeres zonales estándar, 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 los que tienen GPU o TPU, pueden experimentar una mayor interrupción. Para obtener más información, consulta Otro Google Cloud mantenimiento. |
| 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 | Se reinicia el nodo, por lo que se interrumpen todos los Pods que se ejecutan en él. |
| Cómo recuperar 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 finalización y el cierre ordenado de las VMs Spot, y la finalizació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 tienen impacto en los clústeres ni en las cargas de trabajo. | Ninguno La base de datos basada en Spanner se ejecuta por separado del plano de control y los nodos del clúster 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 recrean 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 los 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 manualmente | Respeta las políticas de mantenimiento | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
| Actualización de la etiqueta del grupo de nodos | Se inició manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar | 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, independientemente de las políticas de mantenimiento activas. |
| Cómo escalar verticalmente los nodos cambiando los atributos de la máquina de los nodos | Se inició manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar | GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos en un grupo de nodos existente, independientemente de las políticas de mantenimiento activas. |
| Cambios de tipos de imágenes | Se inició manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos se deben apagar para volver a crearlos, y los Pods se deben reemplazar. GKE usa la estrategia de actualización de nodos configurada (de aumento o azul-verde) para los clústeres estándar. |
| Agrega o reemplaza grupos de almacenamiento en un grupo de nodos de un clúster Standard | Se inició manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos se deben apagar para volver a crearlos, y los Pods se deben reemplazar. GKE usa la estrategia de actualización de nodos configurada (de aumento o azul-verde) para los clústeres estándar. |
| Cómo habilitar la transmisión de imágenes | Se inició 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 cada cambio de este tipo |
Si se activa a nivel del grupo de nodos, se aplica a 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 estándar en el que no hayas habilitado o inhabilitado individualmente 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. |
| Actualizaciones de la configuración de rendimiento de la red | Se inició manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos se deben apagar para volver a crearlos, y los Pods se deben reemplazar. GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos en un grupo de nodos existente, independientemente de las políticas de mantenimiento activas. |
| Habilitación de gVNIC | Se inició manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos se deben apagar para volver a crearlos, y los Pods se deben reemplazar. GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos en un grupo de nodos existente, independientemente de las políticas de mantenimiento activas. |
| Cambios en la configuración del sistema de nodos | Se inició manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos se deben apagar para volver a crearlos, y los Pods se deben reemplazar. GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos en un grupo de nodos existente, independientemente de las políticas de mantenimiento activas. |
| Nodos confidenciales | Se inició manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos se deben apagar para volver a crearlos, y los Pods se deben reemplazar. GKE usa de inmediato las actualizaciones de aumento para volver a crear los nodos en un grupo de nodos existente, independientemente de las políticas de mantenimiento activas. |
Cambios que no requieren que se vuelvan a crear los nodos
Revisa la siguiente tabla para comprender qué cambios en la configuración del nodo no requieren que se vuelvan a crear los nodos. Estos cambios no son disruptivos, pero es posible que lo sean si la configuración del nodo actualizada afecta tu carga de trabajo.
| Cambiar | Automático o iniciado manualmente | Respeta las políticas de mantenimiento | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
|
Actualiza los siguientes parámetros de configuración:
|
Se inició manualmente | No respeta las políticas de mantenimiento y realiza los cambios de inmediato. | Una vez por cada cambio de este tipo | Se actualizan todos los nodos pertinentes. | No es necesario reemplazar los pods porque la configuración del nodo se actualiza sin recrear los nodos. |
¿Qué sigue?
- Descripción general de GKE
- Arquitectura del clúster 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