De forma predeterminada, las actualizaciones automáticas están habilitadas en los clústeres de Google Kubernetes Engine (GKE) y en los grupos de nodos Estándar de GKE.
En esta página se explica cómo solicitar manualmente un cambio de versión del plano de control o de los nodos de un clúster de GKE. Puedes actualizar la versión manualmente de la siguiente manera:
- Autopilot: actualiza la versión del plano de control.
- Estándar: actualiza la versión del plano de control y la versión del grupo de nodos.
Para actualizar un clúster, GKE actualiza la versión en la que se ejecutan el plano de control y los nodos. Los clústeres se actualizan a una versión secundaria más reciente (por ejemplo, de 1.24 a 1.25) o a una versión de parche más reciente (por ejemplo, de 1.24.2-gke.100 a 1.24.5-gke.200). Para obtener más información, consulta Versiones y asistencia de GKE.
Puedes consultar más información sobre cómo funcionan las actualizaciones automáticas y manuales de clústeres. También puedes controlar cuándo se pueden y cuándo no se pueden realizar las actualizaciones automáticas configurando ventanas de mantenimiento y exclusiones.
Las nuevas versiones de GKE se anuncian periódicamente y puedes recibir avisos sobre las nuevas versiones disponibles para cada clúster específico con las notificaciones de clúster. Para encontrar objetivos de actualización automática específicos de los clústeres, consulta información sobre las actualizaciones de un clúster.
Para obtener información sobre las versiones disponibles, consulta Control de versiones. Para obtener más información sobre los clústeres, consulta Arquitectura de clústeres. Para obtener información sobre cómo actualizar clústeres, consulta Prácticas recomendadas para actualizar clústeres.
Antes de empezar
Antes de empezar, asegúrate de que has realizado las siguientes tareas:
- Habilita la API de Google Kubernetes Engine. Habilitar la API de Google Kubernetes Engine
- Si quieres usar Google Cloud CLI para esta tarea, instálala y, a continuación, inicialízala. Si ya has instalado la gcloud CLI, obtén la versión más reciente ejecutando
gcloud components update.
- Asegúrate de que tienes un clúster Autopilot o Standard. Para crear un clúster, consulta Crear un clúster de Autopilot.
Guardar datos en discos persistentes
Antes de actualizar un grupo de nodos, debes asegurarte de que los datos que quieras conservar estén almacenados en un pod mediante volúmenes persistentes que usen discos persistentes. Los discos persistentes se desmontan, en lugar de borrarse, durante las actualizaciones, y sus datos se "transfieren" entre los pods.
Las siguientes restricciones pertenecen a los discos persistentes:
- Los nodos en los que se ejecutan los pods deben ser máquinas virtuales de Compute Engine
- Esas VMs deben estar en el mismo proyecto y zona de Compute Engine que el disco persistente.
Para saber cómo añadir un disco persistente a una instancia de nodo, consulta el artículo Añadir o cambiar el tamaño de discos persistentes de zona de la documentación de Compute Engine.
Información sobre la actualización
El plano de control y los nodos de un clúster se actualizan por separado.
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.
Limitaciones
Los clústeres alfa no se pueden actualizar.
Versiones compatibles
En las notas de la versión se anuncia cuándo estarán disponibles las nuevas versiones y cuándo dejarán de estarlo las versiones anteriores. En cualquier momento, puedes consultar todas las versiones de clústeres y nodos compatibles con este comando:
gcloud container get-server-config \
--location=CONTROL_PLANE_LOCATION
Sustituye CONTROL_PLANE_LOCATION por la ubicación (región o zona) del plano de control, como us-central1 o us-central1-a.
Si tu clúster está registrado en un canal de lanzamiento, puedes actualizarlo a una versión de parche de otro canal de lanzamiento que tenga la misma versión secundaria que tu plano de control. Por ejemplo, puedes actualizar tu clúster de la versión 1.21.12-gke.1700 del canal Regular a la 1.21.13-gke.900 del canal Rápido. Para obtener más información, consulta Ejecutar versiones de parche de un canal más reciente. Todos los clústeres de Autopilot están registrados en un canal de lanzamiento.
Limitaciones de la versión inferior
En determinados casos, puedes cambiar la versión de tu clúster a una anterior.
Para mitigar el problema de una actualización del plano de control de un clúster que no se ha completado correctamente, puedes cambiar a una versión anterior del parche del plano de control si la versión es una versión anterior del parche dentro de la misma versión secundaria. Por ejemplo, si el plano de control de tu clúster ejecuta GKE 1.25.3-gke.400, puedes cambiar a la versión 1.25.2-gke.100, si esta versión sigue disponible.
No puedes cambiar a una versión inferior del plano de control de un clúster de Kubernetes. Por ejemplo, si tu plano de control ejecuta la versión 1.25 de GKE, no puedes cambiar a la versión 1.24. Si intentas hacerlo, aparecerá el siguiente mensaje de error:
ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.24.3-gke.100": specified version is not
newer than the current version.
No puedes cambiar a una versión secundaria anterior del plano de control de un clúster, por lo que te recomendamos que pruebes y califiques las actualizaciones de versiones secundarias con clústeres en un entorno de pruebas cuando haya disponible una nueva versión secundaria, pero antes de que se convierta en la predeterminada. Esto es especialmente recomendable si tu clúster puede verse afectado por cambios significativos en la próxima versión secundaria, como la eliminación de APIs o funciones obsoletas.
Para mitigar el problema de una actualización de un grupo de nodos que no se ha completado correctamente, puedes cambiar a una versión anterior del parche o a una versión secundaria anterior. Asegúrate de no cambiar la versión de los nodos a una que sea más de dos versiones secundarias anterior a la versión del plano de control del clúster.
Actualizar el clúster
Google actualiza los clústeres y los nodos automáticamente. Para tener más control sobre las actualizaciones automáticas que reciben tu clúster y sus nodos, puedes registrarlos en un canal de lanzamiento. Todos los clústeres de Autopilot se registran automáticamente en un canal de lanzamiento.
Para obtener más información sobre cómo gestionar la versión de GKE de tu clúster, consulta Actualizaciones.
Puedes iniciar una actualización manual en cualquier momento después de que esté disponible una nueva versión.
Actualizar manualmente el plano de control
Cuando inicias una actualización de clúster, no puedes modificar la configuración del clúster durante varios minutos, hasta que se pueda acceder de nuevo al plano de control. Si necesitas evitar el tiempo de inactividad durante las actualizaciones del plano de control, te recomendamos que utilices un clúster de Autopilot o un clúster estándar regional. Esta operación no afecta a la disponibilidad de los nodos de trabajo en los que se ejecutan tus cargas de trabajo, ya que siguen estando disponibles durante las actualizaciones del plano de control.
Puedes actualizar manualmente tu plano de control de Autopilot o Estándar mediante la Google Cloud consola o la CLI de Google Cloud.
gcloud
Para ver las versiones disponibles del plano de control de tu clúster, ejecuta el siguiente comando:
gcloud container get-server-config \
--location=CONTROL_PLANE_LOCATION
Para actualizar a la versión predeterminada del clúster, ejecuta el siguiente comando:
gcloud container clusters upgrade CLUSTER_NAME \
--master \
--location=CONTROL_PLANE_LOCATION
Para actualizar a una versión específica que no sea la predeterminada, especifica la marca --cluster-version como en el siguiente comando:
gcloud container clusters upgrade CLUSTER_NAME \
--master \
--location=CONTROL_PLANE_LOCATION \
--cluster-version=VERSION
Sustituye VERSION por la versión a la que quieras actualizar tu clúster. Puedes usar una versión específica, como 1.18.17-gke.100, o un alias de versión, como latest. Para obtener más información, consulta Especificar la versión del clúster.
Consola
Para actualizar manualmente el plano de control de tu clúster, sigue estos pasos:
Ve a la página Google Kubernetes Engine en la consola de Google Cloud .
Haz clic en el nombre del clúster.
En Información básica del clúster, haz clic en edit Actualización disponible junto a Versión.
Selecciona la versión que quieras y haz clic en Guardar cambios.
Después de actualizar un plano de control estándar, puedes actualizar sus nodos. De forma predeterminada, los nodos estándar creados con la consola tienen habilitada la actualización automática, por lo que se realiza automáticamente. Google Cloud Autopilot siempre actualiza los nodos automáticamente.
Revertir a una versión anterior de clústeres
- Define una exclusión de mantenimiento antes de cambiar a una versión anterior para evitar que GKE actualice automáticamente el plano de control después de que lo hayas cambiado a una versión anterior.
Cambia a una versión anterior del parche del plano de control del clúster:
gcloud container clusters upgrade CLUSTER_NAME \ --master \ --location=CONTROL_PLANE_LOCATION \ --cluster-version=VERSION
Inhabilitar las actualizaciones automáticas de clústeres
La seguridad de la infraestructura es una prioridad para GKE, por lo que los planos de control se actualizan periódicamente y no se pueden inhabilitar. Sin embargo, puedes aplicar ventanas de mantenimiento y exclusiones para suspender temporalmente las actualizaciones de los planos de control y los nodos.
Aunque no se recomienda, puedes inhabilitar la actualización automática de nodos.
Consultar el historial de actualizaciones recientes del plano de control
Para ver un resumen del historial de actualizaciones automáticas recientes de un clúster, obtén información sobre las actualizaciones de un clúster.
También puedes enumerar las operaciones recientes para ver cuándo se actualizó el plano de control:
gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME" \
--location=CONTROL_PLANE_LOCATION
Actualizar grupos de nodos
De forma predeterminada, los nodos de un clúster tienen habilitada la actualización automática. Las actualizaciones automáticas de nodos aseguran que la versión del plano de control y de los nodos de tu clúster estén sincronizadas y cumplan la política de diferencia de versiones de Kubernetes, que garantiza que los planos de control sean compatibles con los nodos que tengan hasta dos versiones secundarias anteriores a la del plano de control. Por ejemplo, los planos de control de Kubernetes 1.29 son compatibles con los nodos de Kubernetes 1.27.
No inhabilite las actualizaciones automáticas de nodos para que su clúster se beneficie de las actualizaciones que se indican en el párrafo anterior.
Con las actualizaciones de grupos de nodos de GKE, puedes elegir entre dos estrategias de actualización configurables: actualizaciones de aumento y actualizaciones azul-verde.
Elige una estrategia y usa los parámetros para ajustarla de forma que se adapte mejor a las necesidades de tu entorno de clúster.
Cómo funcionan las actualizaciones de nodos
Mientras se actualiza un nodo, GKE deja de programar nuevos pods en él e intenta programar sus pods en ejecución en otros nodos. Es similar a otros eventos que vuelven a crear el nodo, como habilitar o inhabilitar una función en el pool de nodos.
Durante las actualizaciones de nodos automáticas o manuales, se respetan los presupuestos de interrupción de pods (PDBs) y el periodo de gracia de finalización de pods durante un máximo de 1 hora. Si los pods que se ejecutan en el nodo no se pueden programar en nodos nuevos después de una hora, GKE inicia la actualización de todos modos. Este comportamiento se aplica incluso si configuras tus PDBs para que siempre tengan todas tus réplicas disponibles asignando al campo maxUnavailable el valor 0 o 0%, o bien asignando al campo minAvailable el valor 100% o el número de réplicas. En todos estos casos, GKE elimina los pods al cabo de una hora para que se pueda eliminar el nodo.
Si una carga de trabajo requiere más flexibilidad con la finalización correcta, utiliza las actualizaciones azul-verde, que proporcionan ajustes para añadir tiempo de rodaje y ampliar las comprobaciones de PDB más allá de la hora predeterminada.
Para obtener más información sobre lo que ocurre durante la finalización de un nodo en general, consulta el tema sobre pods.
La actualización solo se completa cuando se han vuelto a crear todos los nodos y el clúster está en el estado deseado. Cuando un nodo recién actualizado se registra en el plano de control, GKE lo marca como programable.
Las nuevas instancias de nodo ejecutan la versión de Kubernetes deseada, así como:
Para que se considere que la actualización de un grupo de nodos se ha completado, todos los nodos del grupo deben volver a crearse. Si se ha iniciado una actualización, pero no se ha completado y el grupo de nodos está parcialmente actualizado, es posible que la versión del grupo de nodos no refleje la versión de todos los nodos. Para obtener más información, consulta Algunas versiones de nodos no coinciden con la versión del grupo de nodos después de una actualización incompleta del grupo de nodos. Para determinar si se ha completado la actualización del grupo de nodos, consulta el estado de la actualización del grupo de nodos. Si la operación de actualización supera el periodo de conservación, comprueba que la versión de cada nodo coincida con la del grupo de nodos.
Actualizar manualmente un grupo de nodos
Puedes actualizar manualmente la versión de un grupo de nodos para que coincida con la versión del plano de control o con una versión anterior que siga estando disponible y sea compatible con el plano de control. Puedes actualizar manualmente varios grupos de nodos en paralelo, mientras que GKE solo actualiza automáticamente un grupo de nodos a la vez.
Cuando actualizas manualmente un grupo de nodos, GKE elimina las etiquetas que hayas añadido a nodos concretos mediante kubectl.
Para evitarlo, aplica etiquetas a los grupos de nodos.
Antes de actualizar manualmente tu grupo de nodos, ten en cuenta las siguientes condiciones:
- Si actualizas un grupo de nodos, es posible que se interrumpan las cargas de trabajo que se estén ejecutando en ese grupo. Para evitarlo, puedes crear un nuevo grupo de nodos con la versión que quieras y migrar la carga de trabajo. Una vez completada la migración, puedes eliminar el grupo de nodos antiguo.
- Si actualizas un grupo de nodos con un Ingress en estado de error,
el grupo de instancias no se sincroniza. Para solucionar este problema, primero comprueba el estado con el comando
kubectl get ing. Si el grupo de instancias no está sincronizado, puedes solucionar el problema volviendo a aplicar el manifiesto que se usó para crear el recurso de entrada.
Puedes actualizar manualmente tus grupos de nodos a una versión compatible con el plano de control mediante la Google Cloud consola o la CLI de Google Cloud.
gcloud
En los comandos de esta sección se usan las siguientes variables:
CLUSTER_NAME: el nombre del clúster del grupo de nodos que se va a actualizar.NODE_POOL_NAME: el nombre del grupo de nodos que se va a actualizar.CONTROL_PLANE_LOCATION: la ubicación (región o zona) del plano de control, comous-central1ous-central1-a.VERSION: la versión de Kubernetes a la que se actualizan los nodos. Por ejemplo,--cluster-version=1.7.2ocluster-version=latest.
Actualiza un grupo de nodos:
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--location=CONTROL_PLANE_LOCATION
Para especificar una versión diferente de GKE en los nodos, usa la marca opcional --cluster-version:
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--location=CONTROL_PLANE_LOCATION \
--cluster-version VERSION
Para obtener más información sobre cómo especificar versiones, consulta Control de versiones.
Para obtener más información, consulta la documentación de gcloud container clusters upgrade.
Consola
Para actualizar un grupo de nodos mediante la Google Cloud consola, sigue estos pasos:
Ve a la página Google Kubernetes Engine en la consola de Google Cloud .
Haz clic en el nombre del clúster.
En la página Detalles del clúster, haga clic en la pestaña Nodos.
En la sección Grupos de nodos, haz clic en el nombre del grupo de nodos que quieras actualizar.
Haz clic en edit Editar.
Haz clic en Cambiar en Versión de Node.
Selecciona la versión que quieras en la lista desplegable Versión de Node y, a continuación, haz clic en Cambiar.
La versión del nodo puede tardar varios minutos en cambiar.
Revertir a una versión anterior de grupos de nodos
Puedes cambiar a una versión anterior de un grupo de nodos, por ejemplo, para mitigar una actualización fallida. Consulta las limitaciones antes de cambiar a una versión anterior de un grupo de nodos.
Usa la estrategia de actualización de nodos azul-verde si necesitas optimizar la mitigación de riesgos en las actualizaciones de grupos de nodos que afecten a tus cargas de trabajo. Con esta estrategia, puedes restaurar una actualización en curso a los nodos originales si no se completa correctamente.
- Define una exclusión de mantenimiento para el clúster para evitar que GKE actualice automáticamente el grupo de nodos después de cambiar a una versión anterior.
- Para cambiar a una versión anterior de un grupo de nodos, especifica una versión anterior siguiendo las instrucciones para actualizar manualmente un grupo de nodos.
Cambiar los parámetros de las actualizaciones con compensación
Para obtener más información sobre cómo cambiar los parámetros de sobreaprovisionamiento para actualizaciones, consulte Configurar el sobreaprovisionamiento para actualizaciones.
Comprobar el estado de la actualización del grupo de nodos
Puedes consultar el estado de una actualización con gcloud container operations.
Consulta una lista de todas las operaciones en curso y completadas del clúster de los últimos 12 días si hay menos de 5000 operaciones, o las últimas 5000 operaciones:
gcloud container operations list \
--location=CONTROL_PLANE_LOCATION
A cada operación se le asigna un tipo y un ID de operación, así como también las horas de inicio y finalización, el clúster de destino y el estado. La lista se parecerá a la del siguiente ejemplo:
NAME TYPE ZONE TARGET STATUS_MESSAGE STATUS START_TIME END_TIME
operation-1505407677851-8039e369 CREATE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT16:47:57.851933021Z 20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4 UPGRADE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT18:40:05.136739989Z 20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989 DELETE_CLUSTER us-west1-a my-cluster DONE 20xx-xx-xxT18:41:53.918825764Z 20xx-xx-xxT18:43:48.639506814Z
Para obtener más información sobre una operación específica, indica su ID tal como se muestra en el siguiente comando:
gcloud container operations describe OPERATION_ID \
--location=CONTROL_PLANE_LOCATION
Por ejemplo:
gcloud container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a
Si la actualización se ha cancelado o ha fallado y se ha completado parcialmente, puedes reanudarla o restaurar la versión anterior.
Comprobando la configuración de actualización del grupo de nodos
Puedes ver los detalles de la estrategia de actualización de nodos que se está usando en tus grupos de nodos
con el comando gcloud container node-pools
describe. En el caso de las actualizaciones azul-verde, el comando también devuelve la fase actual de la actualización.
Ejecuta el siguiente comando:
gcloud container node-pools describe NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION
Haz los cambios siguientes:
NODE_POOL_NAME: el nombre del grupo de nodos que se va a describir.CLUSTER_NAME: el nombre del clúster del grupo de nodos cuya información se va a mostrar.CONTROL_PLANE_LOCATION: la ubicación (región o zona) del plano de control, comous-central1ous-central1-a.
Este comando mostrará los ajustes de actualización actuales. En el siguiente ejemplo se muestra el resultado si utiliza la estrategia de actualización azul-verde.
upgradeSettings:
blueGreenSettings:
nodePoolSoakDuration: 1800s
standardRolloutPolicy:
batchNodeCount: 1
batchSoakDuration: 10s
strategy: BLUE_GREEN
Si utilizas la estrategia de actualización azul-verde, el resultado también incluye detalles sobre los ajustes de la actualización azul-verde y su fase intermedia actual. En el siguiente ejemplo se muestra cómo podría ser:
updateInfo:
blueGreenInfo:
blueInstanceGroupUrls:
- https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{BLUE_INSTANCE_GROUP_NAME}
bluePoolDeletionStartTime: {BLUE_POOL_DELETION_TIME}
greenInstanceGroupUrls:
- https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{GREEN_INSTANCE_GROUP_NAME}
greenPoolVersion: {GREEN_POOL_VERSION}
phase: DRAINING_BLUE_POOL
Cancelar la actualización de un grupo de nodos
La actualización se puede cancelar en cualquier momento. Para obtener más información sobre lo que ocurre cuando cancelas un sobreaprovisionamiento para actualizaciones, consulta Cancelar un sobreaprovisionamiento para actualizaciones. Para obtener más información sobre lo que ocurre cuando cancelas una actualización azul-verde, consulta Cancelar una actualización azul-verde.
Obtén el ID de operación de la actualización:
gcloud container operations list \ --location=CONTROL_PLANE_LOCATIONPara cancelar la actualización, sigue estos pasos:
gcloud container operations cancel OPERATION_ID \ --location=CONTROL_PLANE_LOCATION
Consulta la documentación de gcloud container operations cancel.
Reanudar la actualización de un grupo de nodos
Puedes reanudar una actualización iniciándola manualmente de nuevo y especificando la versión de destino de la actualización original.
Por ejemplo, si una actualización ha fallado o has pausado una actualización en curso, puedes reanudarla volviendo a iniciar la misma actualización en el grupo de nodos y especificando la versión de destino de la operación de actualización inicial.
Para obtener más información sobre lo que ocurre cuando reanudas una actualización con sobreaprovisionamiento, consulta Reanudar una actualización con sobreaprovisionamiento y Actualización azul-verde.
Para reanudar una actualización, usa el siguiente comando:
gcloud container clusters upgrade CLUSTER_NAME \
--node-pool=NODE_POOL_NAME \
--location=CONTROL_PLANE_LOCATION \
--cluster-version VERSION
Haz los cambios siguientes:
NODE_POOL_NAME: el nombre del grupo de nodos para el que quieres reanudar la actualización.CLUSTER_NAME: el nombre del clúster del grupo de nodos para el que quieres reanudar la actualización.CONTROL_PLANE_LOCATION: la ubicación (región o zona) del plano de control, comous-central1ous-central1-a.VERSION: la versión de destino de la actualización del grupo de nodos cancelada.
Para obtener más información, consulta la documentación de gcloud container clusters upgrade.
Deshacer la actualización de un grupo de nodos
Puedes restaurar un grupo de nodos para volver a la versión anterior de los nodos actualizados, es decir, al estado en el que se encontraban antes de que empezara la actualización del grupo.
Usa el comando rollback si se ha cancelado una actualización en curso, si la actualización ha fallado o si está incompleta porque se ha agotado el tiempo de espera de una ventana de mantenimiento. Si quieres especificar la versión, sigue las instrucciones para cambiar a una versión anterior del grupo de nodos.
Para obtener más información sobre lo que ocurre cuando reviertes una actualización de un grupo de nodos, consulta Revertir una actualización con sobreaprovisionamiento o Revertir una actualización azul-verde.
Para deshacer una actualización, ejecuta el siguiente comando:
gcloud container node-pools rollback NODE_POOL_NAME \
--cluster CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION
Haz los cambios siguientes:
NODE_POOL_NAME: nombre del grupo de nodos cuya actualización se va a revertir.CLUSTER_NAME: el nombre del clúster del grupo de nodos para el que se va a revertir la actualización.CONTROL_PLANE_LOCATION: la ubicación (región o zona) del plano de control, comous-central1ous-central1-a.
Consulta la documentación de gcloud container node-pools rollback.
Completar una actualización de un grupo de nodos
Si utilizas la estrategia de actualización azul-verde, puedes completar una actualización de un grupo de nodos durante la fase de prueba y saltarte el resto del tiempo de prueba.
Para saber cómo funciona la finalización de una actualización de un grupo de nodos, consulta Finalizar una actualización de un grupo de nodos.
Para completar una actualización con la estrategia de actualización azul-verde, ejecuta el siguiente comando:
gcloud container node-pools complete-upgrade NODE_POOL_NAME \
--cluster CLUSTER_NAME \
--location=CONTROL_PLANE_LOCATION
Haz los cambios siguientes:
NODE_POOL_NAME: el nombre del grupo de nodos para el que quieres completar la actualización.CLUSTER_NAME: el nombre del clúster del grupo de nodos para el que quieras completar la actualización.CONTROL_PLANE_LOCATION: la ubicación (región o zona) del plano de control, comous-central1ous-central1-a.
Consulta la documentación de gcloud container node-pools complete-upgrade.
Problemas conocidos
Si tienes PodDisruptionBudget objetos configurados que no pueden permitir más interrupciones, es posible que las actualizaciones de nodos no se puedan actualizar a la versión del plano de control después de varios intentos. Para evitar este error, te recomendamos que aumentes el valor de Deployment o HorizontalPodAutoscaler para que el nodo pueda vaciarse sin dejar de respetar la configuración de PodDisruptionBudget.
Para ver todos los objetos PodDisruptionBudget que no permiten interrupciones, haz lo siguiente:
kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'
Aunque es posible que se produzca este problema durante las actualizaciones automáticas, el proceso de actualización automática obliga a los nodos a actualizarse. Sin embargo, la actualización tarda una hora más por cada nodo del espacio de nombres istio-system que incumpla el PodDisruptionBudget.
Solución de problemas
Para obtener información sobre cómo solucionar problemas, consulta Solucionar problemas de actualizaciones de clústeres.
Siguientes pasos
- Consulta información sobre la arquitectura de clústeres.
- Consulta información sobre los canales de lanzamiento.