Los clústeres de Anthos en VMware ahora son Google Distributed Cloud (solo software) para VMware. Para obtener más información, consulta la descripción general del producto.

Esta página se ha traducido con Cloud Translation API.

Actualizar un clúster

En este documento se explica cómo actualizar clústeres en Google Distributed Cloud (solo software) para VMware. En este documento se describen los pasos para actualizar tu estación de trabajo de administrador, los clústeres de usuarios y los clústeres de administradores. En los pasos para actualizar un clúster de usuarios se explica cómo actualizar el plano de control y todos los grupos de nodos. Si quieres actualizar el plano de control y los grupos de nodos del clúster de usuarios por separado, consulta Actualizar grupos de nodos.

Esta página está dirigida a administradores y operadores de TI que gestionan el ciclo de vida de la infraestructura tecnológica subyacente. Para obtener más información sobre los roles habituales y las tareas de ejemplo a las que hacemos referencia en el contenido, consulta Roles y tareas habituales de los usuarios de GKE. Google Cloud

Antes de continuar, te recomendamos que consultes la siguiente documentación:

Descripción general de la actualización
Entre otras cosas, este documento describe la diferencia de versiones admitida y las reglas de versiones para las actualizaciones, que han cambiado en la versión 1.28 y posteriores.
Prácticas recomendadas para actualizar
En este documento se incluyen listas de comprobación y prácticas recomendadas para actualizar clústeres.

Diferencias entre los clústeres avanzados

Cuando se habilitan los clústeres avanzados, hay algunas diferencias con las actualizaciones, sobre todo en la vista previa de los clústeres avanzados de la versión 1.31. Para ver las diferencias de la actualización, busca la palabra advanced en este documento. Para ver una tabla con todas las diferencias, consulta Diferencias al ejecutar clústeres avanzados.

Actualización automática a clústeres avanzados en la versión 1.33

Asegúrate de que la versión de gkectl: la versión de gkectl debe ser la misma que la de destino. Por ejemplo, si actualizas un clúster no avanzado de la versión 1.32 a un clúster avanzado de la versión 1.33.0-gke.799, la versión de gkectl debe ser 1.33.0-gke.799. Este requisito estricto de la versión solo se aplica durante la transición a un clúster avanzado. En todas las actualizaciones posteriores de tu clúster avanzado, se aplicarán las reglas de desviación de versión estándar.
No se permite la diferencia de versiones: al actualizar de un clúster no avanzado a uno avanzado, no puedes actualizar el plano de control y los grupos de nodos por separado. Debes actualizar el plano de control y todos los grupos de nodos a la versión 1.33 al mismo tiempo.

Requisitos

En esta sección se proporciona información sobre los requisitos relacionados con las versiones y los requisitos para usar los clientes de la API de GKE On-Prem (la consola, la CLI de Google Cloud y Terraform) para las actualizaciones. Google Cloud

Reglas de versiones

Las reglas de las actualizaciones dependen de la versión secundaria del clúster.

En las versiones 1.30 y anteriores, la versión secundaria del clúster de usuarios debe ser igual o superior a la versión secundaria del clúster de administrador. La versión del parche no importa. Por ejemplo, si un clúster de usuarios tiene la versión 1.30.1, el clúster de administradores se puede actualizar a una versión de parche superior, como la 1.30.3.
En las versiones 1.31 y posteriores, la versión del clúster de administrador, incluida la versión del parche, debe ser igual o posterior a la versión del clúster de usuario. Por ejemplo, si un clúster de administradores tiene la versión 1.31.1, la versión más alta a la que se puede actualizar el clúster de usuarios es la 1.31.1.

Si quieres actualizar tus clústeres a la versión 1.31, primero debes actualizar todos tus clústeres a la versión 1.30. Una vez que todos los clústeres tengan la versión 1.30, actualiza el clúster de administrador a la versión 1.31. Después, puedes actualizar los clústeres de usuarios a la misma versión de parche 1.31 que el clúster de administrador.

Reglas de versión de `gkectl`

La versión de gkectl que puedes usar para la actualización depende de la versión del clúster de destino (es decir, la versión del clúster al que vas a actualizar). Normalmente, se usa la misma versión de gkectl que la versión de destino del clúster. Durante la actualización, se aplican las siguientes reglas:

La versión gkectl no puede ser una versión secundaria inferior a la versión secundaria del clúster de destino. Por ejemplo, si vas a actualizar un clúster de la versión 1.29 a la 1.30, no puedes usar la versión 1.29, ya que es inferior a la versión del clúster de destino.gkectl Las versiones de parche no importan. Por ejemplo, puedes usar la versión gkectl 1.29.0-gke.1456 para actualizar a una versión de parche superior, como la 1.29.1000-gke.94.
La versión gkectl no puede ser más de dos versiones secundarias superior a la versión actual del clúster. Por ejemplo, si actualizas un clúster de la versión 1.28 a la 1.29, la versión de gkectl puede ser la 1.29 o la 1.30. Sin embargo, no puedes usar la versión 1.31 de gkectl porque es tres versiones secundarias superior a la versión del clúster.
Si actualizas el clúster a un clúster avanzado, la versión de gkectl debe ser la misma que la versión de destino. Por ejemplo, si actualizas un clúster no avanzado de la versión 1.32 a un clúster avanzado de la versión 1.33.0-gke.799, la versión de gkectl debe ser 1.33.0-gke.799.
- Tu clúster se actualizará a clúster avanzado de forma predeterminada en la versión 1.33. Esto significa que, para las actualizaciones de 1.32 a 1.33, la versión de gkectl debe ser la misma que la versión actualizada.
- Este requisito de versión estricto solo se aplica durante la transición a un clúster avanzado. En todas las actualizaciones posteriores de tu clúster avanzado, se aplicarán las reglas de desviación de versión estándar.

Si es necesario, consulta Descargar gkectl para obtener una versión compatible de gkectl.

Revisar las reglas de cortafuegos

En la versión 1.29 y posteriores, las comprobaciones previas del lado del servidor están habilitadas de forma predeterminada. Las comprobaciones previas del lado del servidor requieren reglas de cortafuegos adicionales. En Reglas de cortafuegos para clústeres de administrador, busca "Comprobaciones previas" y asegúrate de que estén configuradas todas las reglas de cortafuegos necesarias.

Con las comprobaciones previas del lado del servidor, cuando actualizas un clúster de usuarios mediante gkectl, las comprobaciones previas se ejecutan en el clúster de administrador en lugar de localmente en la estación de trabajo del administrador. Las comprobaciones previas del lado del servidor también se ejecutan en el clúster de administrador cuando usas la Google Cloud consola, la CLI de Google Cloud o Terraform para actualizar un clúster.

Cuando actualizas un clúster de administrador, Google Distributed Cloud despliega un clúster Kubernetes in Docker (kind) para alojar temporalmente los controladores de Kubernetes necesarios para actualizar el clúster de administrador. Este clúster transitorio se denomina clúster de arranque. Las comprobaciones previas del lado del servidor se ejecutan en el clúster de arranque cuando actualizas un clúster de administrador.

Habilitar Dataplane V2

A partir de la versión 1.31, es obligatorio habilitar Dataplane V2 en todos los clústeres de usuarios. Antes de actualizar un clúster de usuarios a la versión 1.31, sigue estos pasos. Si tienes alguna duda sobre la eliminación temporal de la especificación NetworkPolicy, ponte en contacto con el equipo de Asistencia de Google.

Asigna el valor enableDataplaneV2 a true en el archivo de configuración del clúster de usuarios.

Si tu clúster usa un NetworkPolicy, quita temporalmente su especificación del clúster de la siguiente manera:

Comprueba si hay algún NetworkPolicy no perteneciente al sistema aplicado a tu clúster:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system

Si la salida del paso anterior no estaba vacía, guarda cada especificación NetworkPolicy en un archivo para que puedas volver a aplicar la especificación después de actualizar el clúster.
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
```
Haz los cambios siguientes:
- NETWORK_POLICY_NAME: el nombre del NetworkPolicy que vas a guardar.
- NETWORK_POLICY_NAMESPACE: el espacio de nombres de NetworkPolicy.

Elimina el NetworkPolicy con el siguiente comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

Continúa con la actualización.
Una vez completada la actualización, si has eliminado alguna especificación de NetworkPolicy que no sea del sistema, vuelve a aplicarla con este comando:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Requisitos de las APIs de Google y de IAM

Para actualizar un clúster a la versión 1.28 o posterior, debes habilitar kubernetesmetadata.googleapis.com y conceder el rol de gestión de identidades y accesos kubernetesmetadata.publisher a la cuenta de servicio de registro y monitorización. Estos cambios son necesarios para usar Cloud Monitoring.

Habilitar kubernetesmetadata.googleapis.com:
```
gcloud services enable --project PROJECT_ID  \
    kubernetesmetadata.googleapis.com
```
Sustituye PROJECT_ID por el ID del proyecto host de la flota del que forma parte el clúster de usuario. Este es el proyecto que especificaste cuando se creó el clúster. Si has creado el clúster con gkectl, este es el ID de proyecto del campo gkeConnect.projectID del archivo de configuración del clúster.
Si tu organización ha configurado una lista de permitidos que permite que el tráfico de las APIs de Google y otras direcciones pase por tu servidor proxy, añade kubernetesmetadata.googleapis.com a la lista de permitidos.
Asigna el rol kubernetesmetadata.publisher a la cuenta de servicio de registro y monitorización:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
    --role "roles/kubernetesmetadata.publisher"
```
Sustituye SERVICE_ACCOUNT_EMAIL por la dirección de correo de tu cuenta de servicio de registro y monitorización.

Funciones antiguas bloqueadas en las actualizaciones

Las siguientes funciones antiguas se bloquean durante la actualización del clúster a la versión 1.32:

Dataplane V1 (Calico)
Configuración integrada del balanceador de carga F5 Big IP
Clúster de administrador sin alta disponibilidad
Clúster de usuarios de Kubeception
Balanceador de carga de Seesaw

Debes migrar tus clústeres a las funciones recomendadas antes de actualizar a la versión 1.32.

Requisitos de IAM para actualizar clústeres de usuarios

Si tienes previsto usar gkectl para actualizar el clúster de usuarios, puedes saltarte esta sección.

Si quieres usar la consola de Google Cloud, la CLI de Google Cloud o Terraform para actualizar un clúster de usuario y no eres el propietario del proyecto, debes tener asignado el rol de gestión de identidades y accesos roles/gkeonprem.admin en el proyecto Google Cloud en el que se creó el clúster. Google Cloud Para obtener información sobre los permisos incluidos en este rol, consulta Roles de GKE On-prem en la documentación de gestión de identidades y accesos.

Para usar la consola y actualizar el clúster, como mínimo, también necesitas lo siguiente:

roles/container.viewer. Este rol permite a los usuarios ver la página Clústeres de GKE y otros recursos de contenedores en la consola. Para obtener más información sobre los permisos incluidos en este rol o para conceder un rol con permisos de lectura y escritura, consulta los roles de Kubernetes Engine en la documentación de gestión de identidades y accesos.
roles/gkehub.viewer. Este rol permite a los usuarios ver clústeres en la consola. Para obtener información sobre los permisos incluidos en este rol o para conceder un rol con permisos de lectura y escritura, consulta Roles de GKE Hub en la documentación de IAM.

Limitaciones de los clústeres avanzados

Ten en cuenta las siguientes limitaciones si tienes habilitados los clústeres avanzados:

Debes usar gkectl para actualizar los clústeres. No se admiten los clientes de la API GKE On-Prem (la consola, la CLI de gcloud y Terraform).
Solo se admiten las actualizaciones síncronas.

Hacer cambios en la configuración antes o después de una actualización

Si necesitas hacer cambios en la configuración de tus clústeres, realiza la actualización del clúster antes o después de la actualización. El único cambio que se debe hacer en la configuración del clúster para una actualización es la versión. En función de la versión y el tipo de clúster, otros cambios de configuración se ignoran de forma silenciosa o provocan que la actualización falle. Para obtener más información, consulta Eliminar cambios no admitidos para desbloquear la actualización.

Consultar las versiones disponibles para actualizar un clúster

Ejecuta el siguiente comando para ver qué versiones están disponibles para la actualización:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Sustituye ADMIN_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster de administrador.

El resultado muestra la versión actual y las versiones a las que se puede actualizar.

Si tienes previsto usar la consola, la CLI de gcloud o Terraform para la actualización, la versión tardará entre 7 y 14 días en estar disponible en la API de GKE On-Prem en todas las Google Cloud regiones. La consola solo muestra las versiones disponibles para la actualización del clúster de usuario. Los pasos para actualizar un clúster de usuario con la CLI de gcloud o Terraform incluyen un paso para ejecutar gcloud container vmware clusters query-version-config y obtener las versiones disponibles para la actualización.

Actualizar la estación de trabajo de administrador

La forma de actualizar tu estación de trabajo de administrador depende de cómo la hayas creado: gkeadm o gestionada por el usuario.

gkeadm

Buscar archivos necesarios

Antes de crear tu estación de trabajo de administrador, rellenaste un archivo de configuración de estación de trabajo de administrador que generó gkeadm create config. El nombre predeterminado de este archivo es admin-ws-config.yaml.

Además, tu estación de trabajo tiene un archivo de información. El nombre predeterminado de este archivo es el mismo que el de tu estación de trabajo de administrador.

Busca el archivo de configuración de tu estación de trabajo de administrador y tu archivo de información. Necesitas que sigan los pasos para completar la actualización. Si estos archivos están en tu directorio actual y tienen los nombres predeterminados, no tendrás que especificarlos al ejecutar los comandos de actualización. Si estos archivos están en otro directorio o has cambiado sus nombres, especifícalos con las marcas --config y --info-file.

Si falta el archivo de información de salida, puedes volver a crearlo. Consulta Volver a crear un archivo de información si falta.

Actualizar

Para actualizar la estación de trabajo de administrador, sigue estos pasos:

Comprueba el campo adminWorkstation.diskGB del archivo de configuración de la estación de trabajo de administrador y asegúrate de que el tamaño especificado sea de al menos 100. Por ejemplo:
```
adminWorkstation:
  diskGB: 100
```
Al actualizar a la versión 1.28 o a una posterior, se necesitan 100 GB y la actualización del clúster falla si la estación de trabajo del administrador no tiene suficiente espacio en disco.
En tu servidor de salto, descarga gkeadm:
```
gkeadm upgrade gkeadm --target-version TARGET_VERSION
```
Sustituye TARGET_VERSION por la versión a la que vas a actualizar. Debes especificar un número de versión completo con el formato X.Y.Z-gke.N.. Para ver una lista de las versiones de Google Distributed Cloud, consulta Control de versiones.
Actualiza tu estación de trabajo de administrador:
```
gkeadm upgrade admin-workstation --config AW_CONFIG_FILE \
    --info-file INFO_FILE
```
Haz los cambios siguientes:
- AW_CONFIG_FILE: la ruta del archivo de configuración de tu estación de trabajo de administrador. Puedes omitir esta marca si el archivo está en tu directorio actual y se llama admin-ws-config.yaml.
- INFO_FILE: la ruta del archivo de información. Puedes omitir esta marca si el archivo está en tu directorio actual. El nombre predeterminado de este archivo es el mismo que el de tu estación de trabajo de administrador.

Gestionada por el usuario

En tu estación de trabajo de administrador, ve al directorio en el que quieras instalar una nueva versión de gkectl.

Descarga gkectl:
```
gcloud storage cp gs://gke-on-prem-release/gkectl/TARGET_VERSION/gkectl ./
chmod +x gkectl
```
Sustituye TARGET_VERSION por la versión a la que vas a actualizar. Debes especificar un número de versión completo con el formato X.Y.Z-gke.N.. Para ver una lista de las versiones de Google Distributed Cloud, consulta Control de versiones.
Descarga el paquete de Google Distributed Cloud. Asegúrate de que la versión coincida con la que usaste para descargar gkectl:
```
gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz ./
```

Actualizar el clúster de administrador

Los pasos para actualizar el clúster de administrador varían ligeramente en función de la versión secundaria a la que vayas a actualizar (la versión de destino):

1.31 y versiones posteriores

Si la versión de destino es la 1.31 o una posterior, antes de actualizar los clústeres de usuarios a la siguiente versión secundaria, debes actualizar el clúster de administrador. En la versión 1.31 y posteriores, la versión del clúster de administrador, incluida la versión del parche, debe ser igual o posterior a la versión del clúster de usuario. Por ejemplo, si un clúster de administradores tiene la versión 1.31.1, la versión más alta a la que se puede actualizar el clúster de usuarios es la 1.31.1.

Ejecuta el siguiente comando en tu estación de trabajo de administrador para importar imágenes de SO a vSphere:

gkectl prepare \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Sustituye ADMIN_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster de administrador.

1.30 y versiones anteriores

Si la versión de destino es la 1.30 o una anterior, debes actualizar todos los clústeres de usuarios antes de actualizar el clúster de administrador. La versión secundaria del clúster de administrador debe ser igual o inferior a la versión secundaria del clúster de usuario. La versión del parche no importa. Por ejemplo, si un clúster de usuarios tiene la versión 1.30.1, el clúster de administradores se puede actualizar a una versión de parche superior, como la 1.30.3.

Antes de empezar:

Si vas a actualizar a la versión 1.13 o posterior, primero debes registrar el clúster de administrador rellenando la sección gkeConnect del archivo de configuración del clúster de administrador. Ejecuta el comando gkectl update cluster con los cambios del archivo de configuración.
Asegúrate de que tu gkectl y tus clústeres tengan la versión adecuada para la actualización y de que hayas descargado el paquete correspondiente. La diferencia de versión entre los clústeres de administrador y de usuario depende de la versión de Google Distributed Cloud. Para asegurarte de que puedes actualizar tu clúster de administrador, consulta Diferencia entre las versiones de los clústeres de administrador y de usuario.
Asegúrate de que el campo bundlepath del archivo de configuración del clúster de administrador coincida con la ruta del paquete al que quieras actualizar.

Si haces otros cambios en los campos del archivo de configuración del clúster de administración, se ignorarán durante la actualización. Para que esos cambios surtan efecto, primero debes actualizar el clúster y, a continuación, ejecutar un comando update cluster con los cambios del archivo de configuración para hacer otros cambios en el clúster.

Realizar la actualización

Sigue los pasos de esta sección en tu estación de trabajo de administrador. Hay dos variantes del comando gkectl upgrade admin:

Asíncrona:
Con la variante asíncrona, el comando inicia la actualización y, a continuación, se completa. No es necesario que veas el resultado del comando durante toda la duración de la actualización. En su lugar, puedes comprobar periódicamente el progreso de la actualización ejecutando gkectl list admin y gkectl describe admin. Para usar la variante asíncrona, incluye la marca --async en el comando.

Requisitos para la actualización asíncrona:
- Solo se admite en clústeres de administrador de alta disponibilidad con la versión 1.29 o posterior.
- Todos los clústeres de usuarios deben tener habilitado Controlplane V2.
- Versión 1.31: no compatible con clústeres avanzados.
- Versión 1.32 y posteriores: disponible en clústeres avanzados.
Síncrono:
Con la variante síncrona, el comando gkectl upgrade admin muestra mensajes de estado en la estación de trabajo de administrador a medida que avanza la actualización.

Actualización asíncrona

En tu estación de trabajo de administrador, inicia una actualización asíncrona:
```
gkectl upgrade admin \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config ADMIN_CLUSTER_CONFIG_FILE \
  --async
```
Haz los cambios siguientes:
- ADMIN_CLUSTER_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador.
- ADMIN_CLUSTER_CONFIG_FILE: la ruta al archivo de configuración del clúster de administrador.
El comando anterior se completa y puedes seguir usando tu estación de trabajo de administrador mientras se lleva a cabo la actualización.
Para ver el estado de la actualización, sigue estos pasos:
```
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
El resultado muestra un valor para el clúster STATE. Si el clúster sigue actualizándose, el valor de STATE es UPGRADING. Por ejemplo:
```
NAME              STATE         AGE    VERSION
gke-admin-test    UPGRADING     9h     1.33.0-gke.799
```
Los valores posibles de STATE son RUNNING, UPGRADING, RECONCILING, ERROR y UNKNOWN.

Para obtener más información sobre el progreso de la actualización y los eventos del clúster, sigue estos pasos:

gkectl describe admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

El resultado muestra el recurso personalizado OnPremAdminCluster del clúster de administrador especificado, que incluye el estado, las condiciones y los eventos del clúster.

Registramos eventos para el inicio y el final de cada fase de actualización crítica.

Ejemplo:

Events:
Type    Reason                             Age   From                             Message
----       ------                                  ----     ----                                -------
Normal  ControlPlaneUpgradeStarted         40m   onprem-admin-cluster-controller  Creating or updating admin cluster API Controller
Normal  ControlPlaneMachineUpgradeStarted  40m   onprem-admin-cluster-controller  Creating or updating control plane machine
Normal  StatusChanged                      40m   onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: UPGRADING
- New Ready condition: False, CreateOrUpdateControlPlaneMachine, Creating or updating control plane machine
Normal   StatusChanged      2m                onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: RUNNING
- New Ready condition: True, ClusterRunning, Cluster is running

Cuando la actualización se haya completado, gkectl list admin mostrará un STATUS de RUNNING:
```
NAME              STATE         AGE    VERSION
gke-admin-test    RUNNING       9h     1.33.0-gke.799
```
Además, cuando se complete la actualización, gkectl describe admin mostrará un campo Last GKE On Prem Version en Status. Por ejemplo:
```
Status:
  Cluster State:  RUNNING
  Last GKE On Prem Version:  1.33.0-gke.1
```

Solucionar problemas de actualización asíncrona

En el caso de las actualizaciones asíncronas, la duración del tiempo de espera se basa en el número de nodos del clúster. Si la actualización tarda más que la duración del tiempo de espera, el estado del clúster cambia de UPGRADING a ERROR y se muestra un evento que indica que la operación de actualización ha superado el tiempo de espera. Ten en cuenta que el estado ERROR significa que la actualización está tardando más de lo esperado, pero no se ha cancelado. El controlador continúa la conciliación y sigue intentando realizar la operación. Si una actualización se bloquea o falla, puedes ejecutar gkectl diagnose para comprobar si hay problemas habituales en el clúster. En función del resultado, puedes decidir si quieres realizar una corrección manual o ponerte en contacto con el equipo de Asistencia deGoogle Cloud para obtener más ayuda.

Actualización síncrona

Ejecuta el siguiente comando:
```
gkectl upgrade admin \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config ADMIN_CLUSTER_CONFIG_FILE
```
Haz los cambios siguientes:
- ADMIN_CLUSTER_KUBECONFIG: la ruta al archivo kubeconfig del clúster de administrador.
- ADMIN_CLUSTER_CONFIG_FILE: la ruta al archivo de configuración del clúster de administrador.
El comando gkectl upgrade realiza comprobaciones preparatorias. Si las comprobaciones previas fallan, el comando se bloquea. Debes corregir los errores o usar la marca --skip-preflight-check-blocking con el comando para desbloquearlo.
Si vas a actualizar a la versión 1.14.0 o posterior, se generará un nuevo archivo kubeconfig para el clúster de administrador que sobrescribirá cualquier archivo que ya exista. Para ver los detalles del clúster en el archivo, ejecuta el siguiente comando:
```
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```

Actualizar un clúster de usuarios

Puedes usar gkectl, la consola, gcloud CLI o Terraform para actualizar un clúster de usuario. Para obtener información sobre qué herramienta usar, consulta Elegir una herramienta para actualizar clústeres de usuarios.

gkectl

Preparar la actualización de un clúster de usuarios

Sigue estos pasos en tu estación de trabajo de administrador:

Solo tienes que dar este paso si la TARGET_VERSION es 1.30 o una versión anterior, o si vas a actualizar el clúster de usuarios a una versión distinta de la del clúster de administrador. Ejecuta gkectl prepare para importar imágenes de SO a vSphere:
```
gkectl prepare \
  --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Si tu clúster tiene un grupo de nodos de Windows, ejecuta gkectl prepare windows y actualiza el campo osImage del grupo de nodos. Para obtener instrucciones detalladas, consulta Actualizar un clúster de usuario con grupos de nodos de Windows.
En el archivo de configuración del clúster de usuarios, asigna el valor de la versión de destino de la actualización a gkeOnPremVersion.

Realizar comprobaciones preparatorias

Cuando actualices a la versión 1.29 o a una posterior, puedes ejecutar las comprobaciones previas antes de actualizar un clúster de usuarios:

gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG \
    --dry-run

Sustituye USER_CLUSTER_CONFIG por la ruta al archivo de configuración del clúster de usuarios.

Con la marca --dry-run, gkectl upgrade cluster ejecuta las comprobaciones previas, pero no inicia el proceso de actualización. Aunque las versiones anteriores de Google Distributed Cloud ejecutan comprobaciones previas, no se pueden ejecutar por separado de la actualización. Si añades la marca --dry-run, puedes encontrar y solucionar los problemas que detecten las comprobaciones previas en tu clúster de usuarios antes de la actualización.

Ejecutar `gkectl upgrade cluster`

Hay dos variantes del comando gkectl upgrade cluster:

Asíncrona: (opción recomendada)
Con la variante asíncrona, el comando inicia la actualización y, a continuación, la completa. No es necesario que veas el resultado del comando durante toda la duración de la actualización. En su lugar, puedes comprobar periódicamente el progreso de la actualización ejecutando gkectl list clusters y gkectl describe clusters. Para usar la variante asíncrona, incluye la marca --async en el comando.
- Versión 1.31: no disponible en clústeres avanzados.
- Versión 1.32 y posteriores: disponible en clústeres avanzados.
Síncrono:
Con la variante síncrona, el comando gkectl upgrade cluster muestra mensajes de estado en la estación de trabajo de administrador a medida que avanza la actualización.

Actualización asíncrona

Sáltate este paso si vas a actualizar a una versión posterior a la 1.16.

Si usas credenciales preparadas y un registro privado para el clúster de usuario, asegúrate de que la credencial del registro privado esté preparada antes de actualizar el clúster de usuario. Para obtener información sobre cómo preparar la credencial de registro privada, consulta el artículo Configurar credenciales preparadas para clústeres de usuarios.
En tu estación de trabajo de administrador, inicia una actualización asíncrona:
```
gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --async
```
El comando anterior se completa y puedes seguir usando tu estación de trabajo de administrador mientras se lleva a cabo la actualización.
Para ver el estado de la actualización, sigue estos pasos:
```
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
El resultado muestra un valor para el clúster STATE. Si el clúster sigue actualizándose, el valor de STATE es UPGRADING. Por ejemplo:
```
NAMESPACE             NAME    READY   STATE       AGE   VERSION
my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.33.0-gke.1
```
Los valores posibles de STATE son PROVISIONING, UPGRADING, DELETING, UPDATING, RUNNING, RECONCILING, ERROR y UNKNOWN.

Para obtener más información sobre el progreso de la actualización y los eventos del clúster, sigue estos pasos:

gkectl describe clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster USER_CLUSTER_NAME -v 5

El resultado muestra el recurso personalizado OnPremUserCluster del clúster de usuario especificado, que incluye el estado, las condiciones y los eventos del clúster.

Registramos eventos para el inicio y el final de cada fase de actualización crítica, incluidos los siguientes:

ControlPlaneUpgrade
MasterNodeUpgrade
AddonsUpgrade
NodePoolsUpgrade

Ejemplo:

Events:
Type    Reason                      Age    From                            Message
----     ------                     ----   ----                            -------
Normal  NodePoolsUpgradeStarted     22m    onprem-user-cluster-controller  Creating or updating node pools: pool-2: Creating or updating node pool
Normal  AddonsUpgradeStarted        22m    onprem-user-cluster-controller  Creating or updating addon workloads
Normal  ControlPlaneUpgradeStarted  25m    onprem-user-cluster-controller  Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready
Normal  ControlPlaneUpgradeFinished 23m    onprem-user-cluster-controller  Control plane is running

Cuando la actualización se haya completado, gkectl list clusters mostrará un STATUS de RUNNING:
```
NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.33.0-gke.1
```
Además, cuando se complete la actualización, gkectl describe clusters mostrará un campo Last GKE On Prem Version en Status. Por ejemplo:
```
Status:
Cluster State:  RUNNING
Last GKE On Prem Version:  1.33.0-gke.1
```

Solucionar problemas de actualización asíncrona

En el caso de las actualizaciones asíncronas, la duración del tiempo de espera se basa en el número de nodos del clúster. Si la actualización tarda más que el tiempo de espera, el estado del clúster cambia de UPGRADING a ERROR y se genera un evento que indica que la operación de actualización ha superado el tiempo de espera. Ten en cuenta que el estado ERROR significa que la actualización está tardando más de lo esperado, pero no se ha terminado. El controlador continúa la conciliación y sigue intentando realizar la operación.

Normalmente, el tiempo de espera se debe a un bloqueo provocado por un PodDisruptionBudget (PDB). En ese caso, los pods no se pueden desalojar de los nodos antiguos y estos no se pueden vaciar. Si la expulsión del pod tarda más de 10 minutos, escribimos un evento en el objeto OnPremUserCluster. Para capturar el evento, ejecuta gkectl describe clusters. Después, puedes ajustar el PDB para permitir que el nodo se vacíe. Después, la actualización podrá continuar y, finalmente, completarse.

Ejemplo de evento:

Warning  PodEvictionTooLong  96s (x2 over 4m7s)  onprem-user-cluster-controller
Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.

Además, cuando se bloquea o se produce un error en una actualización, puedes ejecutar gkectl diagnose para comprobar si hay problemas habituales en el clúster. En función del resultado, puede decidir si quiere realizar una corrección manual o ponerse en contacto con el equipo de Asistencia de Anthos para obtener más ayuda.

Actualización síncrona

El comando gkectl upgrade realiza comprobaciones preparatorias. Si las comprobaciones previas fallan, el comando se bloquea. Debes corregir los errores o usar la marca --skip-preflight-check-blocking. Solo debes omitir las comprobaciones previas si tienes la certeza de que no hay fallos críticos.

Sigue estos pasos en tu estación de trabajo de administrador:

Sáltate este paso si vas a actualizar a una versión posterior a la 1.16.

Si usas credenciales preparadas y un registro privado para el clúster de usuario, asegúrate de que la credencial del registro privado esté preparada antes de actualizar el clúster de usuario. Para obtener información sobre cómo preparar la credencial de registro privada, consulta el artículo Configurar credenciales preparadas para clústeres de usuarios.

Actualiza el clúster:

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG

Si vas a actualizar a la versión 1.14.0 o a una posterior, se generará un nuevo archivo kubeconfig para el clúster de usuarios que sobrescribirá cualquier archivo que ya exista. Para ver los detalles del clúster en el archivo, ejecuta el siguiente comando:
```
kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG
```

Reanudar una actualización

Si se interrumpe la actualización de un clúster de usuarios, puedes reanudarla ejecutando el mismo comando de actualización con la marca --skip-validation-all:

gkectl upgrade cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG_FILE \
    --skip-validation-all

Consola

Para actualizar un clúster de usuarios, es necesario hacer algunos cambios en el clúster de administradores. La consola hace lo siguiente automáticamente:

Inscribe el clúster de administrador en la API de GKE On-Prem si aún no está inscrito.
Descarga e implementa un paquete de componentes en el clúster de administrador. La versión de los componentes coincide con la que especifiques para la actualización. Estos componentes permiten que el clúster de administrador gestione los clústeres de usuario de esa versión.

Para actualizar un clúster de usuarios, sigue estos pasos:

En la consola, ve a la página Descripción general de los clústeres de Google Kubernetes Engine.

Ir a clústeres de GKE
Selecciona el Google Cloud proyecto y, a continuación, el clúster que quieras actualizar.
En el panel Detalles, haga clic en Más detalles.
En la sección Información básica de los clústeres, haz clic en Actualizar.
En la lista Elegir versión de destino, selecciona la versión a la que quieras actualizar. La lista seleccionada solo contiene las versiones de parche más recientes.
Haz clic en Actualizar.

Antes de actualizar el clúster, se ejecutan comprobaciones previas para validar el estado del clúster y el estado de los nodos. Si las comprobaciones previas se superan, el clúster de usuarios se actualiza. La actualización tarda unos 30 minutos en completarse.

Para ver el estado de la actualización, haga clic en Mostrar detalles en la pestaña Detalles del clúster.

CLI de gcloud

Para actualizar un clúster de usuarios, es necesario hacer algunos cambios en el clúster de administradores. El comando gcloud container vmware clusters upgrade hace lo siguiente automáticamente:

Inscribe el clúster de administrador en la API de GKE On-Prem si aún no está inscrito.
Descarga e implementa un paquete de componentes en el clúster de administrador. La versión de los componentes coincide con la que especifiques para la actualización. Estos componentes permiten que el clúster de administrador gestione los clústeres de usuario de esa versión.

Para actualizar un clúster de usuarios, sigue estos pasos:

Actualiza los componentes de Google Cloud CLI:
```
gcloud components update
```

Obtén una lista de las versiones a las que puedes actualizar:

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

El resultado del comando es similar al siguiente:

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

Puedes ignorar el mensaje después de la lista de versiones. No importa si la versión a la que vas a actualizar está instalada en el clúster de administrador. El comando upgrade descarga e implementa un paquete de los componentes que coinciden con la versión que especifiques en el comando upgrade.

Actualiza el clúster.
```
gcloud container vmware clusters upgrade USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION
```
Sustituye VERSION por la versión de Google Distributed Cloud a la que quieras actualizar. Especifica una versión de la salida del comando anterior. Te recomendamos que actualices a la versión de parche más reciente.

La salida del comando es similar a la siguiente:
```
Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
```
En el resultado de ejemplo, la cadena operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 es el OPERATION_ID de la operación de larga duración. Para consultar el estado de la operación, ejecuta el siguiente comando en otra ventana de terminal:
```
gcloud container vmware operations describe OPERATION_ID \
  --project=PROJECT_ID \
  --location=REGION
```

Terraform

Actualiza los componentes de Google Cloud CLI:
```
gcloud components update
```
Si aún no lo has hecho, registra el clúster de administrador en la API de GKE On-Prem. Una vez que el clúster se haya registrado en la API de GKE On-Prem, no tendrás que volver a realizar este paso.

Obtén una lista de las versiones a las que puedes actualizar:

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

Haz los cambios siguientes:

USER_CLUSTER_NAME: nombre del clúster de usuarios.
PROJECT_ID: el ID del proyecto de flota en el que se encuentra el clúster de usuarios. Este es el proyecto que especificaste cuando se creó el clúster. Si has creado el clúster con gkectl, este es el ID de proyecto del campo gkeConnect.projectID del archivo de configuración del clúster.
REGION: la región en la que se ejecuta la API de GKE On-Prem y almacena sus metadatos. Google Cloud En el archivo main.tf que has usado para crear el clúster de usuarios, la región se encuentra en el campo location del recurso de clúster.

El resultado del comando es similar al siguiente:

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

Descarga la nueva versión de los componentes e impleméntala en el clúster de administración:
```
gcloud container vmware admin-clusters update ADMIN_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --required-platform-version=VERSION
```
Este comando descarga la versión de los componentes que especifiques en --required-platform-version al clúster de administrador y, a continuación, implementa los componentes. Estos componentes permiten que el clúster de administrador gestione los clústeres de usuario de esa versión.
En el archivo main.tf que has usado para crear el clúster de usuario, cambia on_prem_version en el recurso de clúster a la nueva versión.
Inicializa y crea el plan de Terraform:
```
terraform init
```
Terraform instala las bibliotecas necesarias, como el Google Cloudproveedor.
Revisa la configuración y haz los cambios necesarios:
```
terraform plan
```
Aplica el plan de Terraform para crear el clúster de usuarios:
```
terraform apply
```

Quitar todo el paquete

Si has descargado un paquete completo y has ejecutado gkectl prepare correctamente, así como actualizado el clúster de administrador y todos los clústeres de usuario, debes eliminar el paquete completo para ahorrar espacio en disco en la estación de trabajo del administrador. Ejecuta el siguiente comando para eliminar todo el paquete:

rm /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION-full.tgz

Reanudar la actualización de un clúster de administrador

Si se interrumpe o falla una actualización de un clúster de administrador, se puede reanudar si el punto de control del clúster de administrador contiene el estado necesario para restaurar el estado anterior a la interrupción.

Advertencia: No repares el administrador principal con gkectl repair admin-master después de un intento de actualización fallido. Esto hará que el clúster de administrador entre en un estado incorrecto.

Sigue estos pasos:

Comprueba si el plano de control de administrador está en buen estado antes de iniciar el primer intento de actualización. Consulta Diagnosticar problemas de clústeres. Como se explica en ese tema, ejecuta el comando gkectl diagnose cluster en el clúster de administrador.
Si el plano de control de administrador no está en buen estado antes del primer intento de actualización, repara el plano de control de administrador con el comando gkectl repair admin-master.
Cuando vuelvas a ejecutar el comando de actualización después de que se haya interrumpido o haya fallado, usa el mismo paquete y la misma versión de destino que en el intento anterior.

Cuando vuelvas a ejecutar el comando de actualización, la actualización reanudada volverá a crear el estado del clúster de administrador a partir del punto de control y volverá a ejecutar toda la actualización. A partir de la versión 1.12.0, si el plano de control de administrador no está en buen estado, el proceso de actualización se actualizará directamente a la versión de destino sin intentar restaurar el clúster de administrador en la versión de origen antes de continuar con la actualización.

La actualización se reanudará desde el punto en el que se haya producido un error o se haya cerrado si el punto de control del clúster de administrador está disponible. Si el punto de control no está disponible, la actualización volverá a depender del plano de control de administrador, por lo que este debe estar en buen estado para poder continuar con la actualización. Una vez que se haya completado la actualización, se volverá a generar el punto de control.

Si gkectl se cierra de forma inesperada durante una actualización del clúster de administrador, el clúster de tipo no se limpia. Antes de volver a ejecutar el comando de actualización para reanudarla, elimina el clúster de Kind:

docker stop gkectl-control-plane && docker rm gkectl-control-plane

Después de eliminar el clúster de Kind, vuelve a ejecutar el comando de actualización.

Restaurar una estación de trabajo de administrador a una versión anterior después de una actualización

Puedes restaurar la versión de la estación de trabajo de administrador que se usaba antes de la actualización.

Durante la actualización, gkeadm registra la versión anterior a la actualización en el archivo de información de salida. Durante la reversión, gkeadm usa la versión indicada para descargar el archivo anterior.

Para restaurar la versión anterior de tu estación de trabajo de administrador, sigue estos pasos:

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

Puedes omitir --config=AW_CONFIG_FILE si el archivo de configuración de tu estación de trabajo de administrador es el predeterminado admin-ws-config.yaml. De lo contrario, sustituye AW_CONFIG_FILE por la ruta del archivo de configuración de la estación de trabajo de administrador.

El comando de reversión realiza estos pasos:

Descarga la versión de restauración de gkeadm.
Crea una copia de seguridad del directorio principal de la estación de trabajo de administrador actual.
Crea una estación de trabajo de administrador con la versión de restauración de gkeadm.
Elimina la estación de trabajo de administrador original.

Instalar un paquete con una versión diferente para actualizarlo

Si actualizas tu estación de trabajo, se instalará un paquete con la versión correspondiente para actualizar tus clústeres. Si quieres usar otra versión, sigue estos pasos para instalar un paquete de TARGET_VERSION, que es la versión a la que quieres actualizar.

Para comprobar las versiones actuales de gkectl y del clúster, ejecuta este comando. Usa la marca --details/-d para obtener información más detallada.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```
El resultado proporciona información sobre las versiones de tu clúster.
En función del resultado que obtengas, busca los siguientes problemas y corrígelos si es necesario.
- Si la versión actual del clúster de administrador es más de una versión secundaria anterior a la TARGET_VERSION, actualiza todos tus clústeres para que tengan una versión secundaria anterior a la TARGET_VERSION.
- Si la versión de gkectl es inferior a 1.11 y quieres actualizar a 1.12.x, tendrás que realizar varias actualizaciones. Actualiza las versiones secundarias de una en una hasta llegar a la 1.11.x y, a continuación, sigue las instrucciones de este tema.
- Si la versión de gkectl es inferior a la de TARGET_VERSION, actualiza la estación de trabajo de administrador a la versión TARGET_VERSION.
Cuando hayas determinado que las versiones de gkectl y del clúster son adecuadas para una actualización, descarga el paquete.

Comprueba si el archivo tar del paquete ya existe en la estación de trabajo del administrador.
```
stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz
```
Si el paquete no está en la estación de trabajo del administrador, descárgalo.
```
gcloud storage cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
```
Instala el paquete.
```
gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Sustituye ADMIN_CLUSTER_KUBECONFIG por la ruta de tu archivo kubeconfig. Puedes omitir esta marca si el archivo se encuentra en el directorio actual y tiene el nombre kubeconfig.

Nota: De forma predeterminada, se descarga el paquete normal, no el completo. El paquete completo contiene todas las imágenes de contenedor y de máquina virtual, mientras que el paquete normal descarga las imágenes de contenedor y de máquina virtual de Google Cloud Platform en la estación de trabajo del administrador durante la instalación. Para usar el paquete completo, la ruta del paquete en el comando de instalación es gke-onprem-vsphere-TARGET_VERSION-full.tgz.
.
Consulta las versiones de clúster disponibles y asegúrate de que la versión de destino se incluye en las versiones de clúster de usuario disponibles.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```

Ahora puede crear un clúster de usuarios con la versión de destino o actualizar un clúster de usuarios a la versión de destino.

Solucionar problemas del proceso de actualización

Si tienes algún problema al seguir el proceso de actualización recomendado, sigue estas recomendaciones para solucionarlo. Estas sugerencias parten de la base de que has empezado con una configuración de la versión 1.11.x y estás siguiendo el proceso de actualización recomendado.

Consulte también Solucionar problemas de creación y actualización de clústeres.

Solucionar un problema de actualización de un clúster de usuarios

Supongamos que detectas un problema con la versión de actualización al actualizar un clúster de usuarios. Determinas con el equipo de Asistencia de Google que el problema se solucionará en una próxima versión del parche. Para hacerlo, sigue estos pasos:

Seguir usando la versión actual en producción.
Prueba la versión del parche en un clúster que no sea de producción cuando se publique.
Actualiza todos los clústeres de usuarios de producción a la versión de lanzamiento de parche cuando estés seguro.
Actualiza el clúster de administrador a la versión de lanzamiento del parche.

Solucionar un problema de actualización de un clúster de administrador

Si tienes algún problema al actualizar el clúster de administrador, debes ponerte en contacto con el equipo de Asistencia de Google para resolverlo.

Mientras tanto, con el nuevo flujo de actualización, puedes seguir disfrutando de las nuevas funciones del clúster de usuarios sin que la actualización del clúster de administrador te lo impida, lo que te permite reducir la frecuencia de actualización del clúster de administrador si quieres. El proceso de actualización puede seguir los siguientes pasos:

Actualiza los clústeres de usuarios de producción a la versión 1.12.x.
Mantener el clúster de administrador en su versión anterior y seguir recibiendo parches de seguridad.
Prueba la actualización del clúster de administrador de la versión 1.11.x a la 1.12.x en un entorno de prueba e informa de los problemas que encuentres.
Si el problema se resuelve con un parche de la versión 1.12.x, puedes actualizar el clúster de administrador de producción a esta versión si quieres.

Problemas conocidos de versiones recientes

Los siguientes problemas conocidos pueden afectar a las actualizaciones si actualizas desde la versión 1.7 o una posterior.

Consulta también Problemas conocidos.

La actualización de la estación de trabajo de administrador puede fallar si el disco de datos está casi lleno

Si actualizas la estación de trabajo de administrador con el comando gkectl upgrade admin-workstation, es posible que la actualización falle si el disco de datos está casi lleno, ya que el sistema intenta crear una copia de seguridad local de la estación de trabajo de administrador actual mientras se actualiza a una nueva. Si no puedes liberar suficiente espacio en el disco de datos, usa el comando gkectl upgrade admin-workstation con la marca adicional --backup-to-local=false para evitar crear una copia de seguridad local de la estación de trabajo del administrador actual.

Interrupciones en cargas de trabajo con PodDisruptionBudgets

Al actualizar los clústeres, se pueden producir interrupciones o periodos de inactividad en las cargas de trabajo que usan PodDisruptionBudgets (PDBs).

Los nodos no completan el proceso de actualización

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}'

Apéndice

Acerca de las reglas de DRS de VMware habilitadas en la versión 1.1.0-gke.6

A partir de la versión 1.1.0-gke.6, Google Distributed Cloud crea automáticamente reglas de antiafinidad de Distributed Resource Scheduler (DRS) de VMware para los nodos de tu clúster de usuario, lo que hace que se distribuyan en al menos tres hosts físicos de tu centro de datos. A partir de la versión 1.1.0-gke.6, esta función se habilita automáticamente en los clústeres nuevos y en los que ya existen.

Antes de actualizar, asegúrate de que tu entorno de vSphere cumpla las siguientes condiciones:

VMware DRS está habilitado. VMware DRS requiere la edición de licencia de vSphere Enterprise Plus. Para saber cómo habilitar DRS, consulta Habilitar VMware DRS en un clúster.
El nombre de usuario de vSphere proporcionado en el archivo de configuración de credenciales tiene el permiso Host.Inventory.EditCluster.
Hay al menos tres hosts físicos disponibles.

Si tu entorno de vSphere no cumple las condiciones anteriores, puedes seguir actualizando, pero para actualizar un clúster de usuarios de la versión 1.3.x a la 1.4.x, debes inhabilitar los grupos de antiafinidad. Para obtener más información, consulta este problema conocido en las notas de la versión de Google Distributed Cloud.

Información sobre el tiempo de inactividad durante las actualizaciones

Recurso	Descripción
Clúster de administradores	Cuando un clúster de administrador está inactivo, los planos de control de los clústeres de usuarios y las cargas de trabajo de los clústeres de usuarios siguen ejecutándose, a menos que se hayan visto afectados por un fallo que haya provocado el tiempo de inactividad.
Plano de control de clústeres de usuarios	Normalmente, no debería haber ningún tiempo de inactividad notable en los planos de control de los clústeres de usuarios. Sin embargo, las conexiones de larga duración con el servidor de la API de Kubernetes pueden interrumpirse y sería necesario volver a establecerlas. En esos casos, el llamante de la API debe volver a intentarlo hasta que se establezca una conexión. En el peor de los casos, puede haber hasta un minuto de inactividad durante una actualización. Nota: Si los nodos del clúster de usuarios no pueden acceder al plano de control de usuarios durante la actualización, no se programarán nuevas cargas de trabajo en el clúster. Las cargas de trabajo que ya tengas no se verán afectadas.
Nodos de clúster de usuarios	Si una actualización requiere un cambio en los nodos del clúster de usuarios, Google Distributed Cloud recrea los nodos de forma gradual y vuelve a programar los pods que se ejecutan en esos nodos. Para evitar que esto afecte a tus cargas de trabajo, configura PodDisruptionBudgets y reglas de antiafinidad adecuadas.

Volver a crear un archivo de información si falta

Si falta el archivo de información de salida de tu estación de trabajo de administrador, debes volver a crearlo para poder continuar con la actualización. Este archivo se creó cuando creaste tu estación de trabajo. Si has hecho una actualización desde entonces, se habrá actualizado con información nueva.

El archivo de información de salida tiene este formato:

Admin workstation version: GKEADM_VERSION
Created using gkeadm version: GKEADM_VERSION
VM name: ADMIN_WS_NAME
IP: ADMIN_WS_IP
SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY
To access your admin workstation:
ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP

A continuación se muestra un ejemplo de archivo de información de salida:

Admin workstation version: v1.10.3-gke.49
Created using gkeadm version: v1.10.3-gke.49
VM name: admin-ws-janedoe
IP: 172.16.91.21
SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation
Upgraded from (rollback version): v1.10.0-gke.194
To access your admin workstation:
ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21

Crea el archivo en un editor y sustituye los parámetros correspondientes. Guarda el archivo con el mismo nombre que la VM en el directorio desde el que se ejecuta gkeadm. Por ejemplo, si el nombre de la VM es admin-ws-janedoe, guarda el archivo como admin-ws-janedoe.

Siguientes pasos

Documentación de referencia de la CLI de gcloud
Documentación de referencia de Terraform
- google_gkeonprem_vmware_cluster
- google_gkeonprem_vmware_node_pool

Actualizar un clúster Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

Diferencias entre los clústeres avanzados

Actualización automática a clústeres avanzados en la versión 1.33

Requisitos

Reglas de versiones

Reglas de versión de gkectl

Revisar las reglas de cortafuegos

Habilitar Dataplane V2

Requisitos de las APIs de Google y de IAM

Funciones antiguas bloqueadas en las actualizaciones

Requisitos de IAM para actualizar clústeres de usuarios

Limitaciones de los clústeres avanzados

Hacer cambios en la configuración antes o después de una actualización

Consultar las versiones disponibles para actualizar un clúster

Actualizar la estación de trabajo de administrador

gkeadm

Buscar archivos necesarios

Actualizar

Gestionada por el usuario

Actualizar el clúster de administrador

1.31 y versiones posteriores

1.30 y versiones anteriores

Antes de empezar:

Realizar la actualización

Actualización asíncrona

Solucionar problemas de actualización asíncrona

Actualización síncrona

Actualizar un clúster de usuarios

gkectl

Preparar la actualización de un clúster de usuarios

Realizar comprobaciones preparatorias

Ejecutar gkectl upgrade cluster

Actualización asíncrona

Solucionar problemas de actualización asíncrona

Actualización síncrona

Reanudar una actualización

Consola

CLI de gcloud

Terraform

Quitar todo el paquete

Reanudar la actualización de un clúster de administrador

Restaurar una estación de trabajo de administrador a una versión anterior después de una actualización

Instalar un paquete con una versión diferente para actualizarlo

Solucionar problemas del proceso de actualización

Solucionar un problema de actualización de un clúster de usuarios

Solucionar un problema de actualización de un clúster de administrador

Problemas conocidos de versiones recientes

La actualización de la estación de trabajo de administrador puede fallar si el disco de datos está casi lleno

Interrupciones en cargas de trabajo con PodDisruptionBudgets

Los nodos no completan el proceso de actualización

Apéndice

Acerca de las reglas de DRS de VMware habilitadas en la versión 1.1.0-gke.6

Información sobre el tiempo de inactividad durante las actualizaciones

Volver a crear un archivo de información si falta

Siguientes pasos

Actualizar un clúster

Reglas de versión de `gkectl`

Ejecutar `gkectl upgrade cluster`