En esta página se explica cómo gestionáis tú y Google Kubernetes Engine (GKE) 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 administradores de plataformas que quieran 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 gestión de clústeres que se describen en Gestionar clústeres y Información general sobre la administración de clústeres.
Una plataforma gestionada y una responsabilidad compartida
GKE es una implementación gestionada por Google de la plataforma de orquestación de contenedores de código abierto Kubernetes. Como se menciona en Cómo funciona GKE, un clúster de GKE consta de un plano de control, que incluye nodos de gestión que ejecutan componentes del sistema, y nodos de trabajador, en los que se implementan cargas de trabajo.
Crear un entorno de clúster óptimo para que se ejecuten tus cargas de trabajo, con el máximo rendimiento y disponibilidad, y con las mínimas interrupciones, es una responsabilidad compartida:
- La responsabilidad de GKE es mantener un entorno de clúster fiable, disponible, seguro y con buen rendimiento. Para ello, GKE gestiona el plano de control, los componentes del sistema y, en el modo Autopilot, los nodos de trabajador.
- Como administrador de la plataforma, debes configurar tu clúster y gestionar tus cargas de trabajo, incluida la preparación para afrontar interrupciones. En el modo Estándar, también puedes crear y gestionar los nodos de trabajador, que se agrupan en grupos de nodos.
Para obtener más información, consulta Responsabilidad compartida de GKE.
Cómo gestiona GKE 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 conjuntamente para mantener el entorno óptimo para ejecutar tus cargas de trabajo. Para gestionar 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 formas que podrían interrumpir temporalmente tus cargas de trabajo, tal como se describe en la siguiente sección.
Algunos cambios en el clúster pueden interrumpir las cargas de trabajo
Aunque GKE se esfuerza por mantener tus cargas de trabajo en funcionamiento 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 quieres que se produzcan las interrupciones para que, cuando se produzcan, tus cargas de trabajo puedan gestionar los cambios correctamente.
En las siguientes secciones se explica qué tipos de cambios realiza GKE en los clústeres, qué tipo de interrupción provocan y cómo puedes prepararte.
Actualizaciones con la gestión del ciclo de vida de los clústeres de GKE
En GKE, las actualizaciones y las versiones de los clústeres tienen significados relacionados.
En GKE, el término actualizaciones de clúster (o simplemente actualizaciones) hace referencia 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 estándar, las actualizaciones de nodos también se denominan actualizaciones de grupos de nodos, ya que GKE usa una sola operación para actualizar un grupo de nodos.
El término actualizaciones de clúster (o simplemente actualizaciones) es un término más general que hace referencia a cualquier tipo de cambio en el plano de control o en los nodos, incluida la actualización de sus versiones. GKE gestiona activamente tu entorno de clúster realizando actualizaciones y otras operaciones de mantenimiento necesarias. Estas acciones aseguran que tu clúster siga funcionando correctamente, sea seguro y esté actualizado con las últimas funciones y correcciones de errores. GKE usa herramientas como las estrategias de actualización de nodos y las políticas de mantenimiento para minimizar las interrupciones durante estos procesos.
Planificar las interrupciones de las actualizaciones de nodos
Algunos tipos de cambios en el clúster (principalmente en los nodos) pueden provocar interrupciones.
GKE usa estrategias de actualización de nodos para actualizar los nodos (tanto los de Autopilot como los de los grupos de nodos de clústeres estándar) de forma optimizada para las necesidades de tu carga de trabajo. Estas estrategias se aplican a las actualizaciones de versión y a otros tipos de cambios de nodos. Las estrategias permiten a GKE minimizar las interrupciones al realizar actualizaciones de nodos, que son importantes para que los clústeres funcionen correctamente y tengan un buen rendimiento.
Usa las ventanas y las exclusiones de mantenimiento para elegir cuándo se realiza el mantenimiento de algunos clústeres y cuándo no. 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 tus restricciones de recursos.
Tanto en los cambios iniciados manualmente como en los que se inician automáticamente en los nodos, GKE realiza los cambios con las siguientes características generales:
- Los cambios suelen respetar las políticas de mantenimiento: cuando GKE hace 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 has enviado hasta que haya disponibilidad de mantenimiento. Si GKE está esperando a que haya disponibilidad para realizar el mantenimiento y el cambio es urgente, puedes aplicar los cambios manualmente para que la nueva configuración se aplique inmediatamente.
- En el caso de otros cambios manuales, como las actualizaciones manuales, GKE no tiene en cuenta las políticas de mantenimiento. En el caso de estos cambios manuales, asegúrate de que tus cargas de trabajo estén preparadas para sufrir 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 manualmente a los nodos (incluidas las actualizaciones de nodos que no sean de versión), GKE elige una estrategia de actualización de nodos: actualizaciones de aumento o actualizaciones azul-verde. El piloto automático siempre usa las actualizaciones de subida de tensión. Los cambios en los grupos de nodos de clúster estándar suelen usar actualizaciones de aumento, excepto cuando has configurado actualizaciones azul-verde y haces determinados tipos de cambios.
- Los cambios requieren recursos suficientes: cuando GKE aplica un cambio mediante una estrategia de actualización de nodos, este cambio requiere una cantidad determinada de recursos en función de 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 el artículo sobre cómo asegurar los recursos para las actualizaciones de nodos.
Para ver 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.
Maximizar la disponibilidad de las cargas de trabajo preparándose para los cambios disruptivos
Para maximizar la disponibilidad de las cargas de trabajo que se ejecutan en un clúster de GKE, te recomendamos que tomes las medidas que se describen en las siguientes secciones:
Elegir la disponibilidad del 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 de zona. Para obtener más información, consulta Acerca de las opciones de configuración de clústeres.
Controlar las actualizaciones con las herramientas de GKE
Puedes usar las siguientes herramientas para controlar cuándo y cómo actualiza GKE tu clúster, lo que te permite implementar las prácticas recomendadas:
- Canales de lanzamiento: elige un canal de lanzamiento para obtener versiones del clúster con el equilibrio que prefieras entre disponibilidad de funciones y estabilidad.
- Ventanas de mantenimiento: especifica un periodo recurrente en el que se pueden llevar a cabo determinados tipos de mantenimiento de clústeres de GKE, como las actualizaciones.
- Exclusiones de mantenimiento: impide que se realice el mantenimiento del clúster durante un periodo 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.
- Secuencia de lanzamiento: prueba 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 manualmente y realiza acciones como cancelar, reanudar, revertir y completar actualizaciones automáticas o manuales en curso.
Gestionar y monitorizar un clúster
Para gestionar las posibles interrupciones en tus clústeres, realiza las siguientes tareas de forma continua:
- Monitoriza tu clúster con la suite de observabilidad de GKE.
- Consulta las notas de la versión de GKE para ver los anuncios.
- Consulta las notificaciones del clúster, como cuándo empiezan o terminan las actualizaciones, cuándo hay nuevas versiones disponibles, los boletines de seguridad y las fechas de finalización del soporte.
- Consulta el estado de las actualizaciones de los clústeres para saber en qué punto se encuentran.
- Consulta la programación de lanzamientos de GKE para obtener una estimación optimista de cuándo estarán disponibles las versiones secundarias para las actualizaciones y cuándo finalizará el periodo de asistencia.
- Usa las directrices prescriptivas que identifican posibles oportunidades de optimización y explican cómo optimizar el uso de tu clúster, incluidas las directrices sobre obsolescencia de funciones y APIs.
Preparar las cargas de trabajo
Gestiona 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 asegurar la redundancia y evitar un único punto de fallo.
- Especifica un presupuesto de interrupciones para tu aplicación con un presupuesto de interrupciones de pods.
- Define un periodo de gracia de finalización de la duración adecuada para que tu carga de trabajo se cierre correctamente.
- Si tu carga de trabajo usa GPUs o TPUs, sigue las instrucciones para gestionar las interrupciones de nodos de GKE en GPUs y TPUs.
- En el caso de las aplicaciones con estado, que a menudo necesitan tiempo para detener correctamente las operaciones de E/S y desmontar el almacenamiento, sigue los pasos que se indican en el artículo Asegurarse de que las cargas de trabajo con estado estén preparadas para las interrupciones.
Para obtener información general sobre estos temas, consulta la sección Gestionar interrupciones de la entrada de blog Prácticas recomendadas de GKE: operaciones del segundo día para la continuidad del negocio.
Tipos de cambios en un clúster de GKE
En las siguientes tablas se muestran los tipos más habituales de cambios importantes en un clúster, así como las características de estos cambios, como la frecuencia y el nivel de interrupción.
Tipos de actualizaciones
Consulte la siguiente tabla para saber cómo pueden afectar las actualizaciones a un entorno de clúster.
| Cambiar | Iniciada automáticamente o 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 del periodo de 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, que pueden ser semanales, en función del canal de lanzamiento. Actualizaciones menores aproximadamente cada cuatro meses. En los clústeres de canal ampliado, solo se pueden hacer actualizaciones secundarias cuando la versión secundaria se acerca al final del periodo de asistencia. |
Plano de control |
En los clústeres estándar regionales y de Autopilot, el plano de control sigue estando disponible. En el caso de los clústeres estándar zonales, se trata de 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 nodo | Automático o manual |
Las actualizaciones automáticas respetan las políticas de mantenimiento hasta el final del periodo de 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. |
Normalmente, es el mismo que el de las actualizaciones del plano de control. Si tu clúster no está registrado en un canal de lanzamiento y inhabilitas las actualizaciones automáticas de los nodos, serás el responsable de actualizar manualmente los grupos de nodos del clúster. |
Todos los nodos de los clústeres de Autopilot o uno o varios grupos de nodos de clústeres estándar. |
Los nodos deben cerrarse para poder recrearse y los pods deben sustituirse. GKE usa actualizaciones de picos para Autopilot o la estrategia de actualización de nodos configurada (picos o azul-verde) para los clústeres estándar. |
Cambios manuales que recrean los nodos mediante una estrategia de actualización de nodos y respetando las políticas de mantenimiento
Consulta la siguiente tabla para saber cómo pueden afectar estos cambios manuales a un entorno de clúster. Esta lista incluye, entre otros cambios, cambios manuales que respetan las políticas de mantenimiento de GKE.
| Cambiar | Iniciada automáticamente o manualmente | Respeta las políticas de mantenimiento | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
| Inhabilitar el puerto de solo lectura de kubelet | Iniciada manualmente | No respeta las políticas de mantenimiento y aplica los cambios inmediatamente. | 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 estándar. |
Los nodos deben cerrarse para poder volver a crearse. Los pods deben sustituirse. GKE usa inmediatamente las actualizaciones de aumento para recrear los nodos, independientemente de las políticas de mantenimiento activas. |
| Rotar las credenciales del clúster | Automático si las credenciales del clúster caducan en un plazo de 30 días. También se puede iniciar manualmente. | Respeta las políticas de mantenimiento. Sin embargo, GKE puede 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 en el primer paso, que es iniciar la rotación. Además, si activas manualmente operaciones específicas después del primer paso, esas operaciones no respetarán las políticas de mantenimiento. | Una vez por cada cambio manual de este tipo o en función del tiempo de vida de las credenciales del clúster para la iniciación automática. Puedes invocar manualmente operaciones para pasos específicos del proceso de rotación. | En algunos pasos, el plano de control. En el resto de los pasos, todos los nodos de los clústeres de Autopilot y todos los nodos de cada grupo de nodos de los clústeres estándar. |
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:
|
| Rotar la dirección IP del plano de control | Iniciada manualmente | Sin embargo, sí respeta las políticas de mantenimiento. Si activas manualmente operaciones específicas después del primer paso, esas operaciones no respetarán las políticas de mantenimiento. | Una vez por cada cambio manual de este tipo. Puedes invocar manualmente operaciones para pasos específicos del proceso de rotación. | En algunos pasos, el plano de control. En el resto de los pasos, todos los nodos de los clústeres de Autopilot y todos los nodos de cada grupo de nodos de los clústeres estándar. |
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:
|
| Configurar nodos protegidos | Iniciada manualmente |
Al volver a crear el plano de control, no se respetan las políticas de mantenimiento y los cambios se aplican inmediatamente. Al volver a crear los nodos, se respetan las políticas de mantenimiento. |
Una vez por cada cambio de este tipo |
Se actualiza el plano de control. Una vez que se haya actualizado el plano de control, se deben volver a crear todos los nodos de cada grupo de nodos del clúster estándar. |
Cuando se recrea 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:
|
| Configurar políticas de red | Iniciada manualmente | Cumple 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 estándar. |
Los nodos deben cerrarse para poder recrearse y los pods deben sustituirse. GKE usa las actualizaciones de picos para recrear los nodos. |
| Configurar la visibilidad intranodo | Iniciada manualmente | Cumple 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 estándar. |
Los nodos deben cerrarse para poder recrearse y los pods deben sustituirse. GKE usa las actualizaciones de picos para recrear los nodos. |
| Configurar NodeLocal DNSCache | Iniciada manualmente | Cumple las políticas de mantenimiento | Una vez por cada cambio de este tipo | Todos los nodos del grupo de nodos del clúster estándar que se estén actualizando deben actualizarse. |
Los nodos deben cerrarse para poder recrearse y los pods deben sustituirse. GKE usa las actualizaciones de picos para recrear los nodos. |
| Habilitar la transmisión de imágenes | Iniciada manualmente |
Cuando se actualiza a nivel de 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 de grupo de nodos, todos los nodos del grupo de nodos del clúster estándar. Si se activa a nivel de clúster, los nodos de los grupos de nodos de clúster estándar en los que no hayas habilitado o inhabilitado individualmente el ajuste para el grupo de nodos. |
GKE usa las actualizaciones de aumento para recrear los nodos de un grupo de nodos. |
Mantenimiento automático que no respeta las políticas de mantenimiento
Consulta la siguiente tabla para saber cómo puede afectar al entorno de un clúster el mantenimiento automático que no respeta las políticas de mantenimiento.
| Cambiar | Iniciada automáticamente o manualmente | Respeta las políticas de mantenimiento | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
| Reparar o cambiar el 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 afecta a los clústeres regionales Standard ni a los de Autopilot. El cambio de tamaño del plano de control es poco frecuente, pero aumenta con los eventos de escalado del clúster. Además, no tiene ningún impacto en los clústeres de Autopilot ni en los clústeres estándar regionales. |
Plano de control |
En los clústeres estándar regionales y de Autopilot, el plano de control sigue estando disponible. En el caso de los clústeres estándar zonales, se trata de 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 la frecuencia aproximada en Eventos de mantenimiento. | Un nodo |
En la mayoría de los tipos de nodos, el efecto es mínimo. Algunos nodos, incluidos los que tienen GPUs o TPUs, pueden sufrir más interrupciones. Para obtener más información, consulta la sección Otro Trusted Cloud by S3NS 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 | El nodo se reinicia, por lo que se interrumpen los pods que se estén ejecutando en él. |
| Recuperar máquinas virtuales de acceso puntual y máquinas virtuales 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 de 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 de acceso puntual 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 afectan a los clústeres ni a 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 en todos los tipos de clústeres y sigue disponible durante el mantenimiento. |
Cambios manuales que recrean los nodos mediante una estrategia de actualización de nodos sin respetar las políticas de mantenimiento
Consulta la siguiente tabla para saber cómo pueden afectar estos cambios manuales a un entorno de clúster. Esta lista incluye los cambios que se producen cuando GKE usa actualizaciones de aumento y cuando GKE usa actualizaciones azul-verde que no se incluyen en la otra sección porque no respetan las políticas de mantenimiento.
| Cambiar | Iniciada automáticamente o manualmente | Respeta las políticas de mantenimiento | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
| Cambios en la recogida de registros del plano de control | Iniciada manualmente | No respeta las políticas de mantenimiento y aplica los cambios inmediatamente. | Una vez por cada cambio de este tipo | Se actualiza el plano de control. | Cuando se recrea 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 aplica los cambios inmediatamente. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar | GKE usa inmediatamente las actualizaciones de aumento para recrear el grupo de nodos cuando actualizas las etiquetas de los nodos de un grupo de nodos, independientemente de las políticas de mantenimiento activas. |
| Escalar verticalmente los nodos cambiando los atributos de la máquina de los nodos | Iniciada manualmente | No respeta las políticas de mantenimiento y aplica los cambios inmediatamente. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar | GKE usa inmediatamente las actualizaciones de picos para recrear los nodos de un grupo de nodos, independientemente de las políticas de mantenimiento activas. |
| Cambios en el tipo de imagen | Iniciada manualmente | No respeta las políticas de mantenimiento y aplica los cambios inmediatamente. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos deben cerrarse para poder recrearse y los pods deben sustituirse. GKE usa la estrategia de actualización de nodos configurada (de aumento o azul-verde) en los clústeres estándar. |
| Añadir o sustituir grupos de almacenamiento en un grupo de nodos de clúster Standard | Iniciada manualmente | No respeta las políticas de mantenimiento y aplica los cambios inmediatamente. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos deben cerrarse para poder recrearse y los pods deben sustituirse. GKE usa la estrategia de actualización de nodos configurada (de aumento o azul-verde) en los clústeres estándar. |
| Habilitar la transmisión de imágenes | Iniciada manualmente |
Cuando se actualiza a nivel de 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 de grupo de nodos, todos los nodos del grupo de nodos del clúster estándar. Si se activa a nivel de clúster, los nodos de los grupos de nodos de clúster estándar en los que no hayas habilitado o inhabilitado individualmente el ajuste para el grupo de nodos. |
GKE usa las actualizaciones de aumento para recrear los nodos de un grupo de nodos. |
| Actualizaciones de la configuración del rendimiento de la red | Iniciada manualmente | No respeta las políticas de mantenimiento y aplica los cambios inmediatamente. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos deben cerrarse para poder recrearse y los pods deben sustituirse. GKE usa inmediatamente las actualizaciones de picos para recrear los nodos de un grupo de nodos, independientemente de las políticas de mantenimiento activas. |
| Habilitar gVNIC | Iniciada manualmente | No respeta las políticas de mantenimiento y aplica los cambios inmediatamente. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos deben cerrarse para poder recrearse y los pods deben sustituirse. GKE usa inmediatamente las actualizaciones de picos para recrear los nodos de un grupo de nodos, independientemente de las políticas de mantenimiento activas. |
| Cambios en la configuración del sistema de nodos | Iniciada manualmente | No respeta las políticas de mantenimiento y aplica los cambios inmediatamente. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos deben cerrarse para poder recrearse y los pods deben sustituirse. GKE usa inmediatamente las actualizaciones de picos para recrear los nodos de un grupo de nodos, independientemente de las políticas de mantenimiento activas. |
| Nodos confidenciales | Iniciada manualmente | No respeta las políticas de mantenimiento y aplica los cambios inmediatamente. | Una vez por cada cambio de este tipo | Todos los nodos de un grupo de nodos de un clúster estándar |
Los nodos deben cerrarse para poder recrearse y los pods deben sustituirse. GKE usa inmediatamente las actualizaciones de picos para recrear los nodos de un grupo de nodos, independientemente de las políticas de mantenimiento activas. |
Cambios que no requieren volver a crear los nodos
Consulta la siguiente tabla para saber qué cambios en la configuración de los nodos no requieren que se vuelvan a crear. Estos cambios no son disruptivos, pero sigue siendo posible que se produzcan interrupciones si la configuración de nodos actualizada afecta a tu carga de trabajo.
| Cambiar | Iniciada automáticamente o manualmente | Respeta las políticas de mantenimiento | Frecuencia | Tipo de interrupción | Nivel de interrupción |
|---|---|---|---|---|---|
|
Actualiza los siguientes ajustes:
|
Iniciada manualmente | No respeta las políticas de mantenimiento y aplica los cambios inmediatamente. | Una vez por cada cambio de este tipo | Se actualizan todos los nodos pertinentes. | No es necesario sustituir los pods porque la configuración del nodo se actualiza sin tener que volver a crear los nodos. |
Siguientes pasos
- Información general sobre GKE
- Arquitectura de clústeres de GKE
- Responsabilidad compartida de GKE
- Versiones y asistencia de GKE
- Acuerdo de nivel de servicio de GKE
- Actualizaciones de clústeres de GKE