En esta página, se explica cómo actualizar GKE en VMware. En esta página, se proporcionan los pasos para actualizar la estación de trabajo de administrador, el clúster de usuario y el clúster de administrador. En el caso de los clústeres de usuario, en esta página, se proporcionan los pasos para actualizar el plano de control y los grupos de nodos al mismo tiempo o por separado.
Antes de continuar, te recomendamos revisar la siguiente documentación:
Descripción general de la actualización
Entre otros aspectos, en este documento se describen las reglas del sesgo de versiones y las reglas de versiones compatibles con las actualizaciones, que cambiaron para la versión 1.28 y las versiones posteriores.Prácticas recomendadas de actualización
En este documento, se proporcionan listas de tareas y prácticas recomendadas para actualizar clústeres.
Requisitos de la API y la IAM de Google
Para actualizar un clúster a la versión 1.28 o posterior, debes habilitar kubernetesmetadata.googleapis.com
y otorgar la función de IAM kubernetesmetadata.publisher
a la cuenta de servicio de supervisión de registros. Estos cambios son necesarios para usar Cloud Monitoring.
Habilitar
kubernetesmetadata.googleapis.com
:gcloud services enable --project PROJECT_ID \ kubernetesmetadata.googleapis.com
Reemplaza
PROJECT_ID
por el ID del proyecto host de la flota en el que es miembro el clúster de usuario. Este es el proyecto que especificaste cuando se creó el clúster. Si creaste el clúster congkectl
, este es el ID del proyecto en el campogkeConnect.projectID
del archivo de configuración del clúster.Si tu organización configuró una lista de entidades permitidas que permite que el tráfico de las APIs de Google y otras direcciones pasen por tu servidor proxy, agrega
kubernetesmetadata.googleapis.com
a la lista de entidades permitidas.Otorga el rol
kubernetesmetadata.publisher
a la cuenta de servicio de supervisión de registros:gcloud projects add-iam-policy-binding PROJECT_ID \ --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \ --role "roles/kubernetesmetadata.publisher"
Reemplaza SERVICE_ACCOUNT_EMAIL por la dirección de correo electrónico de tu cuenta de servicio de supervisión de registros.
Requisitos de IAM para actualizar clústeres de usuario
Omite esta sección si planeas usar gkectl
para la actualización del clúster de usuario.
Si quieres usar la consola de Google Cloud, Google Cloud CLI o Terraform para actualizar un clúster de usuario y no eres propietario de un proyecto, se te debe otorgar la función de Identity and Access Management roles/gkeonprem.admin
en el proyecto de Google Cloud en el que se creó el clúster. Para obtener detalles sobre los permisos incluidos en esta función, consulta Funciones de GKE On-Prem en la documentación de IAM.
Si quieres usar la consola para actualizar el clúster, como mínimo, también necesitas lo siguiente:
roles/container.viewer
. Esta función permite a los usuarios ver la página Clústeres de GKE y otros recursos de contenedor en la consola. Para obtener detalles sobre los permisos incluidos en esta función, o sobre cómo otorgar una función con permisos de lectura o escritura, consulta Funciones de Kubernetes Engine en la documentación de IAM.roles/gkehub.viewer
: Esta función permite a los usuarios ver los clústeres en la consola. Para obtener detalles sobre los permisos incluidos en esta función o para otorgar una función con permisos de lectura o escritura, consulta Funciones de GKE Hub en la documentación de IAM.
Realiza cambios en la configuración antes o después de una actualización
Si necesitas realizar cambios en la configuración de los clústeres, realiza la actualización del clúster antes o después de la actualización. El único cambio en la configuración del clúster para una actualización debería ser la versión. Según la versión y el tipo de clúster, otros cambios de configuración se ignoran en silencio o hacen que la actualización falle. Para obtener más información, consulta Quita los cambios no compatibles para desbloquear la actualización.
Actualiza tu estación de trabajo de administrador
Debes actualizar la estación de trabajo de administrador si planeas usar gkectl
para actualizar un clúster de usuario.
Si planeas usar la consola, gcloud CLI o Terraform para actualizar un clúster de usuario, puedes omitir la actualización de la estación de trabajo de administrador por ahora. Sin embargo, deberás actualizar la estación de trabajo de administrador cuando estés listo para actualizar el clúster de administrador, ya que solo gkectl
admite actualizaciones del clúster de administrador.
Ubica los archivos necesarios
Antes de crear la estación de trabajo de administrador, completaste un archivo de configuración de la 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 nombre de la estación de trabajo del administrador.
Localiza el archivo de configuración de la estación de trabajo del administrador y el archivo de información. Los necesitas para realizar los pasos de la actualización. Si estos archivos se encuentran en tu directorio actual y tienen sus nombres predeterminados, no tendrás que especificarlos cuando ejecutes los comandos de actualización. Si estos archivos están en otro directorio o si cambiaste los nombres de archivo, debes especificarlos mediante las marcas --config
y --info-file
.
Si falta tu archivo de información de salida, puedes volver a crearlo. Consulta Cómo volver a crear un archivo de información si falta.
Para actualizar la estación de trabajo de administrador, haz lo siguiente:
Descargar
gkeadm
:gkeadm upgrade gkeadm --target-version TARGET_VERSION
Reemplaza TARGET_VERSION por la versión de destino de tu actualización. Debes especificar un número de versión completo con el formato
X.Y.Z-gke.N.
. Para obtener una lista de las versiones de GKE en VMware, consulta Historial de versiones.Actualiza la estación de trabajo de administrador:
gkeadm upgrade admin-workstation --config AW_CONFIG_FILE \ --info-file INFO_FILE
Reemplaza lo siguiente:
AW_CONFIG_FILE
es la ruta del archivo de configuración de la estación de trabajo del administrador. Puedes omitir esta marca si el archivo se encuentra en el directorio actual y tiene el nombreadmin-ws-config.yaml
.INFO_FILE
es la ruta del archivo de información. Puedes omitir esta marca si el archivo se encuentra en tu directorio actual. El nombre predeterminado de este archivo es el mismo que el nombre de la estación de trabajo del administrador.
El comando anterior realiza las siguientes tareas:
Crea una copia de seguridad de todos los archivos en el directorio principal de la estación de trabajo del administrador actual. Estas son algunas de las funciones:
- El archivo de configuración del clúster de administrador. El nombre predeterminado es
admin-cluster.yaml
. - El archivo de configuración del clúster de usuario. El nombre predeterminado es
user-cluster.yaml
. - Los archivos kubeconfig para el clúster de administrador y los clústeres de usuarios.
- El certificado raíz del servidor de vCenter. Ten en cuenta que este archivo debe tener permisos de lectura y escritura de propietario.
- El archivo de claves JSON para tu cuenta de servicio de acceso a componentes. Ten en cuenta que este archivo debe tener permisos de lectura y escritura de propietario.
- Los archivos de claves JSON para tus cuentas de servicio connect-register y logging-monitoring.
- El archivo de configuración del clúster de administrador. El nombre predeterminado es
Crea una nueva estación de trabajo de administrador y copia todos los archivos con copia de seguridad en la nueva estación de trabajo de administrador.
Borra la estación de trabajo de administrador anterior.
Verifica las versiones disponibles para las actualizaciones de los clústeres
Ejecuta el siguiente comando para ver qué versiones están disponibles para la actualización:
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG
El resultado muestra la versión actual y las versiones disponibles para actualizar.
Si planeas usar la consola, gcloud CLI o Terraform para la actualización, pueden transcurrir entre 7 y 10 días después de un lanzamiento hasta que la versión esté disponible en la API de GKE On-Prem en todas las regiones de Google Cloud.
En la consola, solo se enumeran las versiones disponibles para la actualización del clúster de usuario. Los pasos para actualizar un clúster de usuario con
gcloud CLI o Terraform incluyen un paso con el objetivo de ejecutar
gcloud container vmware clusters query-version-config
y obtener las versiones disponibles para la actualización.
Actualiza un clúster de usuario
Puedes usar gkectl
, la consola, gcloud CLI o Terraform para actualizar un clúster de usuario. Si deseas obtener información para decidir qué herramienta usar, consulta Elige una herramienta para actualizar los clústeres de usuario.
gkectl
Prepárate para actualizar un clúster de usuario
Sigue estos pasos en la estación de trabajo 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 campoosImage
del grupo de nodos. Para obtener instrucciones detalladas, consulta Actualiza el clúster de usuario con grupos de nodos de Windows.En el archivo de configuración del clúster de usuario, establece
gkeOnPremVersion
en la versión de destino de la actualización.Solo grupos de nodos de Ubuntu y COS: Especifica los grupos de nodos que quieres actualizar. La actualización de grupos de nodos por separado desde el plano de control es compatible con los grupos de nodos de Ubuntu y COS, pero no con los de Windows.
En el archivo de configuración del clúster de usuario, indica qué grupos de nodos deseas actualizar de la siguiente manera:
En cada grupo de nodos que desees actualizar, quita el campo
nodePools.nodePool[i].gkeOnPremVersion
o configúralo como la string vacía.Para cada grupo de nodos que no quieras actualizar, establece
nodePools.nodePool[i].gkeOnPremVersion
en la versión actual.
Por ejemplo, supongamos que el clúster de usuario se encuentra en la versión 1.15.5-gke.41 y tiene dos grupos de nodos:
pool-1
ypool-2
. También supongamos que deseas actualizar el plano de control ypool-1
a la versión 1.16.3-gke.45, pero deseas quepool-2
permanezca en la versión 1.15.5-gke.41. En la siguiente parte de un archivo de configuración de clúster de usuario, se muestra cómo especificar este ejemplo:gkeOnPremVersion: 1.16.3-gke.45 nodePools: - name: pool-1 gkeOnPremVersion: "" cpus: 4 memoryMB: 8192 replicas: 3 osImageType: ubuntu_containerd - name: pool-2 gkeOnPremVersion: 1.15.5-gke.41 cpus: 4 memoryMB: 8192 replicas: 5 osImageType: ubuntu_containerd
Ejecución gkectl upgrade cluster
Hay dos variaciones del comando gkectl upgrade cluster
:
Asíncrona: (recomendado)
Con la variación asíncrona, el comando inicia la actualización y, luego, finaliza. No necesitas mirar el resultado del comando durante toda la actualización. En su lugar, puedes verificar de forma periódica el progreso de la actualización ejecutandogkectl list clusters
ygkectl describe clusters
. Para usar la variación asíncrona, incluye la marca--async
en el comando.Síncrona:
Con la variación síncrona, el comandogkectl upgrade cluster
envía mensajes de estado a la estación de trabajo de administrador a medida que avanza la actualización.
Actualización asíncrona
En la estación de trabajo de administrador, inicia una actualización asíncrona:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG \ --async
Se completa el comando anterior y puedes seguir usando la estación de trabajo de administrador mientras la actualización está en curso.
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 aún se está actualizando, el valor deSTATE
esUPGRADING
. Por ejemplo:NAMESPACE NAME READY STATE AGE VERSION my-uc-gkeonprem-mgmt my-uc False UPGRADING 9h 1.28.0-gke.1
Los valores posibles para
STATE
sonPROVISIONING
,UPGRADING
,DELETING
,UPDATING
,RUNNING
,RECONCILING
,ERROR
yUNKNOWN
.Para obtener más detalles 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 para el 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 crítica de actualización, incluidos los siguientes:
- ControlPlaneUpgrade
- MasterNodeUpgrade
- AddonsUpgrade
- NodePoolsUpgrade
Resultado de 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 se completa la actualización,
gkectl list clusters
muestra unSTATUS
deRUNNING
:NAMESPACE NAME READY STATE AGE VERSION my-uc-gkeonprem-mgmt my-uc True RUNNING 9h 1.28.0-gke.1
Además, cuando se complete la actualización,
gkectl describe clusters
mostrará un campoLastGKEOnPremVersion
enStatus
. Por ejemplo:Status: Cluster State: RUNNING LastGKEOnOremVersion: 1.28.0-gke.1
Soluciona problemas de actualización asíncrona
Para una actualización asíncrona, la duración del tiempo de espera se basa en la cantidad de nodos en el 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
, con un evento que indica que se agotó el tiempo de espera de la operación de actualización. Ten en cuenta que el estado ERROR
significa que la actualización está tardando más de lo esperado, pero que no
se cerró. El controlador continúa con la conciliación y vuelve a intentar la operación.
Por lo general, un tiempo de espera es el resultado de un interbloqueo causado por un PodDisruptionBudget (PDB). En ese caso, los Pods no se pueden expulsar de los nodos antiguos y no se pueden vaciar los nodos antiguos. 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
. Luego, puedes ajustar el PDB para permitir que se desvíe el nodo. Luego, la actualización puede 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 una actualización se bloquea o falla, puedes ejecutar gkectl diagnose
para verificar si hay problemas comunes de los clústeres. En función del resultado, puedes decidir si realizar una corrección manual o comunicarte con el equipo de asistencia al cliente de Anthos para obtener más ayuda.
Actualización síncrona
El comando gkectl upgrade
ejecuta comprobaciones preliminares. Si fallan las comprobaciones preliminares, el comando se bloquea. Debes corregir las fallas o usar la marca --skip-preflight-check-blocking
. Solo debes omitir las comprobaciones preliminares si estás seguro de que no hay fallas críticas.
Continúa con estos pasos en la estación de trabajo de administrador:
Actualiza el clúster:
gkectl upgrade cluster \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG_FILE
Si actualizas a la versión 1.14.0 o una posterior, se genera un archivo kubeconfig nuevo para el clúster de usuario que reemplaza cualquier archivo existente. Para ver los detalles del clúster en el archivo, ejecuta el siguiente comando:
kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG
Actualiza grupos de nodos adicionales
Si solo actualizaste el plano de control del clúster de usuario o actualizaste el plano de control y algunos grupos de nodos, pero no todos, sigue estos pasos para actualizar los grupos de nodos:
Edita el archivo de configuración del clúster de usuario. Por cada grupo de nodos que quieras actualizar, quita el campo
nodePools.nodePool[i].gkeOnPremVersion
o configúralo como la string vacía, como se muestra en el siguiente ejemplo:gkeOnPremVersion: 1.16.3-gke.45 nodePools: - name: pool-1 gkeOnPremVersion: "" cpus: 4 memoryMB: 8192 replicas: 3 osImageType: ubuntu_containerd - name: pool-2 gkeOnPremVersion: "" cpus: 4 memoryMB: 8192 replicas: 5 osImageType: ubuntu_containerd
Ejecuta
gkectl update cluster
para aplicar el cambio:gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config USER_CLUSTER_CONFIG
Reemplaza lo siguiente:
ADMIN_CLUSTER_KUBECONFIG
: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.USER_CLUSTER_CONFIG
es la ruta de acceso del archivo de configuración del clúster de usuario.
Si encuentras un problema después de actualizar un grupo de nodos, puedes revertir a la versión anterior. Para obtener más información, consulta Revierte un grupo de nodos después de una actualización.
Reanuda una actualización
Si se interrumpe la actualización de un clúster de usuario, puedes reanudarla mediante la ejecución del 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
Console
La actualización del clúster de usuario requiere algunos cambios en el clúster de administrador. 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 y, luego, implementa un paquete de componentes en el clúster de administrador. La versión de los componentes coincide con la versión que especificas para la actualización. Estos componentes permiten que el clúster de administrador administre los clústeres de usuario en esa versión.
Para actualizar un clúster de usuario, haz lo siguiente:
En la consola, ve a la página de descripción general de los clústeres de Google Kubernetes Engine.
Selecciona el proyecto de Google Cloud y, luego, elige el clúster que deseas actualizar.
En el panel Detalles, haz clic en Más detalles.
En la sección Conceptos básicos del clúster, haz clic en
Actualizar.En la lista Choose target version, selecciona la versión a la que deseas actualizar. La lista seleccionada solo contiene las versiones de parches más recientes.
Haz clic en Actualizar.
Antes de actualizar el clúster, se ejecutan las comprobaciones preliminares para validar su estado y el de los nodos. Si se aprueban las comprobaciones preliminares, el clúster de usuario se actualiza. La actualización tardará aproximadamente 30 minutos en completarse.
Para ver el estado de la actualización, haz clic en Mostrar detalles en la pestaña Detalles del clúster.
gcloud CLI
La actualización del clúster de usuario requiere algunos cambios en el clúster de administrador. El comando gcloud container vmware clusters upgrade
hace lo siguiente de forma automática:
Inscribe el clúster de administrador en la API de GKE On-Prem si aún no está inscrito.
Descarga y, luego, implementa un paquete de componentes en el clúster de administrador. La versión de los componentes coincide con la versión que especificas para la actualización. Estos componentes permiten que el clúster de administrador administre los clústeres de usuario en esa versión.
Para actualizar un clúster de usuario, haz lo siguiente:
Actualiza los componentes de la CLI de Google Cloud:
gcloud components update
Solo grupos de nodos de Ubuntu y COS: Si deseas actualizar solo el plano de control del clúster de usuario y dejar todos los grupos de nodos en la versión actual, cambia la política de actualización en el clúster:
gcloud container vmware clusters update USER_CLUSTER_NAME \ --project=PROJECT_ID \ --location=REGION \ --upgrade-policy control-plane-only=True
Reemplaza lo siguiente:
USER_CLUSTER_NAME
: Es el nombre del clúster de usuario que se actualizará.PROJECT_ID
: Es el ID del proyecto host de la flota en el que es miembro el clúster de usuario. Este es el proyecto que especificaste cuando se creó el clúster. Si creaste el clúster congkectl
, este es el ID del proyecto en el campogkeConnect.projectID
del archivo de configuración del clúster.REGION
: Es la región de Google Cloud en la que se ejecuta y almacena los metadatos de la API de GKE On-Prem. Si creaste el clúster con un cliente de la API de GKE On-Prem, esta es la región que seleccionaste cuando creaste el clúster. Si creaste el clúster congkectl
, esta es la región que especificaste cuando inscribiste el clúster en la API de GKE On-Prem.
Obtén una lista de las versiones disponibles para 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 que aparece después de la lista de versiones. No importa si la versión a la que actualizas 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 especificaste en el comandoupgrade
.Actualiza el clúster. Si ejecutaste el comando
update
para cambiar la política de actualización acontrol-plane-only=True
, solo se actualizará el plano de control del clúster. De lo contrario, el plano de control del clúster y todos los grupos de nodos se actualizan.gcloud container vmware clusters upgrade USER_CLUSTER_NAME \ --project=PROJECT_ID \ --location=REGION \ --version=VERSION
Reemplaza VERSION por la versión de GKE en VMware a la que deseas actualizar. Especifica una versión del resultado del comando anterior. Te recomendamos que actualices a la versión más reciente del parche.
El resultado del comando es similar al 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 string
operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179
es la OPERATION_ID de la operación de larga duración. Para averiguar 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
Actualiza grupos de nodos
Si elegiste actualizar solo el plano de control del clúster de usuario, sigue estos pasos para actualizar los grupos de nodos después de que se actualice el plano de control del clúster de usuario:
Obtén una lista de los grupos de nodos en el clúster de usuario:
gcloud container vmware node-pools list --cluster=USER_CLUSTER_NAME \ --project=PROJECT_ID \ --location=REGION
En cada grupo de nodos que quieras actualizar, ejecuta el siguiente comando:
gcloud container vmware node-pools update NODE_POOL_NAME \ --cluster=USER_CLUSTER_NAME \ --project=PROJECT_ID \ --location=REGION \ --version=VERSION
Terraform
Actualiza los componentes de la CLI de Google Cloud:
gcloud components update
Si aún no lo hiciste, inscribe el clúster de administrador en la API de GKE On-Prem. Después de inscribir el clúster en la API de GKE On-Prem, no es necesario que vuelvas a realizar este paso.
Obtén una lista de las versiones disponibles para actualizar:
gcloud container vmware clusters query-version-config \ --cluster=USER_CLUSTER_NAME \ --project=PROJECT_ID \ --location=REGION
Reemplaza lo siguiente:
USER_CLUSTER_NAME
: Es el nombre del clúster de usuario.PROJECT_ID
: El ID del proyecto de la flota en el que es miembro ese clúster de usuario. Este es el proyecto que especificaste cuando se creó el clúster. Si creaste el clúster congkectl
, este es el ID del proyecto en el campogkeConnect.projectID
del archivo de configuración del clúster.REGION
: Es la región de Google Cloud en la que se ejecuta y almacena los metadatos de la API de GKE On-Prem. En el archivomain.tf
que usaste para crear el clúster de usuario, la región se encuentra en el campolocation
del recurso del 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 versión nueva de los componentes y, luego, impleméntalo en el clúster de administrador:
gcloud vmware admin-clusters update ADMIN_CLUSTER_NAME \ --project=PROJECT_ID \ --location=REGION \ --required-platform-version=VERSION
Con este comando, se descarga la versión de los componentes que especificas en
--required-platform-version
en el clúster de administrador y, luego, se implementan los componentes. Estos componentes permiten que el clúster de administrador administre los clústeres de usuario en esa versión.En el archivo
main.tf
que usaste para crear el clúster de usuario, cambiaon_prem_version
en el recurso del clúster a la versión nueva.Solo grupos de nodos de Ubuntu y COS: Si deseas actualizar solo el plano de control del clúster de usuario y dejar todos los grupos de nodos en la versión actual, agrega lo siguiente al recurso del clúster:
upgrade_policy { control_plane_only = true }
Inicializa y crea terraform plan:
terraform init
Terraform instala las bibliotecas necesarias, como el proveedor de Google Cloud.
Revisa la configuración y realiza cambios si es necesario:
terraform plan
Aplica el plan de Terraform para crear el clúster de usuario:
terraform apply
Actualiza grupos de nodos
Si elegiste actualizar solo el plano de control del clúster de usuario, sigue estos pasos para actualizar grupos de nodos adicionales después de que se actualice el plano de control del clúster de usuario:
En
main.tf
del recurso de cada grupo de nodos que desees actualizar, agrega lo siguiente:on_prem_version = "VERSION"
Por ejemplo:
resource "google_gkeonprem_vmware_node_pool" "nodepool-basic" { name = "my-nodepool" location = "us-west1" vmware_cluster = google_gkeonprem_vmware_cluster.default-basic.name config { replicas = 3 image_type = "ubuntu_containerd" enable_load_balancer = true } on_prem_version = "1.16.0-gke.0" }
Inicializa y crea terraform plan:
terraform init
Revisa la configuración y realiza cambios si es necesario:
terraform plan
Aplica el plan de Terraform para crear el clúster de usuario:
terraform apply
Actualiza el clúster de administrador
Antes de comenzar:
Determina si tus certificados están actualizados y renuévalos si es necesario.
Si actualizas a la versión 1.13 o a una posterior, primero debes registrar el clúster de administrador completando la sección
gkeConnect
en el archivo de configuración del clúster de administrador. Ejecuta el comando update cluster con los cambios en el archivo de configuración.
Sigue los pasos que se indican en esta sección en la nueva estación de trabajo del administrador. Asegúrate de que gkectl
y los clústeres estén en la versión adecuado para una actualización y de haber descargado el paquete adecuado.
Asegúrate de que el campo
bundlepath
del archivo de configuración del clúster de administrador coincida con la ruta de acceso del paquete al que deseas actualizar.Si realizas algún otro cambio en los campos del archivo de configuración del clúster de administrador, estos cambios se ignoran durante la actualización. Para que se apliquen esos cambios, primero debes actualizar el clúster y, luego, ejecutar un comando update cluster con los cambios en el archivo de configuración para realizar otros cambios en el clúster.
Ejecuta el siguiente comando:
gkectl upgrade admin \ --kubeconfig ADMIN_CLUSTER_KUBECONFIG \ --config ADMIN_CLUSTER_CONFIG_FILE \ FLAGS
Reemplaza lo siguiente:
ADMIN_CLUSTER_KUBECONFIG
es el archivo kubeconfig del clúster de administrador.ADMIN_CLUSTER_CONFIG_FILE
: Es el archivo de configuración del clúster de administrador de GKE on VMware en la estación de trabajo de administrador nueva.FLAGS
: un conjunto opcional de marcas. Por ejemplo, puedes incluir la marca--skip-validation-infra
para omitir la comprobación de la infraestructura de vSphere.
Si actualizas a la versión 1.14.0 o a una posterior, se genera un archivo kubeconfig nuevo para el clúster de administrador que reemplaza cualquier archivo existente. Para ver los detalles del clúster en el archivo, ejecuta el siguiente comando:
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
Si descargaste un paquete completo y ejecutaste con éxito los comandos gkectl prepare
y gkectl upgrade admin
, ahora deberías borrar el paquete completo para ahorrar espacio en el disco en la estación de trabajo de administrador. Usa este comando:
rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz
Reanuda la actualización de un clúster de administrador
Si la actualización de un clúster de administrador se interrumpe o falla, la actualización se puede reanudar si el punto de control del clúster de administrador contiene el estado necesario para restablecer el estado antes de la interrupción.
Advertencia: No repares la instancia principal de administrador con gkectl repair admin-master
después de un intento de actualización con errores. Esto hará que el clúster de administrador entre en un mal estado.
Lleve a cabo los pasos siguientes:
Verifica si el plano de control del administrador está en buen estado antes de comenzar el intento de actualización inicial. Consulta Diagnostica problemas de clústeres. Como se explica en ese tema, ejecuta el comando
gkectl diagnose cluster
para el clúster de administrador.Si el plano de control del administrador está en mal estado antes del intento de actualización inicial, repara el plano de control del administrador con el comando
gkectl repair admin-master
.Cuando vuelvas a ejecutar el comando de actualización después de que una actualización se interrumpa o falle, usa el mismo paquete y versión de destino como lo hiciste en el intento de actualización anterior.
Cuando vuelves a ejecutar el comando de actualización, la actualización reanudada vuelve a crear el estado del clúster de administrador desde el punto de control y vuelve a ejecutar la actualización completa. A partir de la versión 1.12.0, si el plano de control de administrador está en mal estado, el proceso de actualización se actualizará directamente a la versión de destino sin intentar restablecer 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 que falló o salió si el punto de control del clúster de administrador está disponible. Si el punto de control no está disponible, la actualización recurrirá al plano de control del administrador y, por lo tanto, este debe estar en buen estado para continuar con la actualización. Después de una actualización exitosa, el punto de control se vuelve a generar.
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 reanudar la actualización, borra el clúster de tipo:
docker stop gkectl-control-plane && docker rm gkectl-control-plane
Después de borrar el clúster de categoría, vuelve a ejecutar el comando de actualización.
Revierte una estación de trabajo de administrador después de una actualización
Puedes revertir la estación de trabajo de administrador a la versión que se usó antes de la actualización.
Durante la actualización, gkeadm
registra la versión antes de que se actualice en el archivo de información de salida. Durante la reversión, gkeadm
usa la versión que se muestra para descargar el archivo anterior.
Para revertir la estación de trabajo de administrador a la versión anterior, sigue estos pasos:
gkeadm rollback admin-workstation --config=AW_CONFIG_FILE
Puedes omitir --config=AW_CONFIG_FILE
si el archivo de configuración de la estación de trabajo de administrador es admin-ws-config.yaml
predeterminado. De lo contrario, reemplaza AW_CONFIG_FILE por la ruta de acceso al 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 reversió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 nueva con la versión de reversión de
gkeadm
. - Borra la estación de trabajo de administrador original.
Instala el paquete con una versión diferente para la actualización
Si actualizas la estación de trabajo, se instalará un paquete con la versión correspondiente para actualizar los clústeres. Si deseas una versión diferente, sigue estos pasos a fin de instalar un paquete para TARGET_VERSION, que es la versión a la que deseas actualizar.
Para comprobar las versiones actuales de los clústeres y de
gkectl
, ejecuta este comando. Usa la marca--details/-d
para obtener información más detallada.gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
En el resultado, se proporciona información sobre las versiones de tu clúster.
Según los resultados que obtengas, busca los siguientes problemas y corrígelos según sea necesario.
Si la versión actual del clúster de administrador es más de una versión secundaria inferior a TARGET_VERSION, actualiza todos los clústeres para que sean una versión secundaria anterior a TARGET_VERSION.
Si la versión
gkectl
es anterior a la 1.11 y deseas actualizar a la versión 1.12.x, tendrás que realizar varias actualizaciones. Actualiza una versión secundaria a la vez hasta llegar a la versión 1.11.x y, luego, continúa con las instrucciones de este tema.Si la versión de
gkectl
es anterior a TARGET_VERSION, actualiza la estación de trabajo de administrador a TARGET_VERSION.
Una vez que hayas determinado que tus versiones de
gkectl
y los clústeres son adecuadas para una actualización, descarga el paquete.Verifica si el paquete comprimido ya existe en la estación de trabajo de administrador.
stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz
Si el paquete no está en la estación de trabajo de administrador, descárgalo.
gsutil 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
Reemplaza ADMIN_CLUSTER_KUBECONFIG por la ruta de acceso de tu archivo kubeconfig. Puedes omitir esta marca si el archivo se encuentra en el directorio actual y tiene el nombre
kubeconfig
.Enumera las versiones de clúster disponibles y asegúrate de que la versión de destino esté incluida en las versiones de clúster de usuario disponibles.
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
Ahora puedes crear un clúster de usuario en la versión de destino o actualizar un clúster de usuario a la versión de destino.
Soluciona problemas del proceso de actualización
Si tienes problemas cuando sigues el proceso de actualización recomendado, sigue estas recomendaciones para resolverlos. Estas sugerencias suponen que has comenzado con una configuración de la versión 1.11.x y que estás realizando el proceso de actualización recomendado.
Consulta también: Soluciona problemas de creación y actualización de clústeres
Soluciona un problema de actualización del clúster de usuario
Supongamos que encuentras un problema con la versión de actualización cuando actualizas un clúster de usuario. Determinas a partir de Atención al cliente de Google que el problema se solucionará en una próxima versión de parche. Puedes continuar de la siguiente manera:
- Continúa usando la versión actual para la producción.
- Prueba la versión del parche en un clúster que no sea de producción cuando se lance
- Actualiza todos los clústeres de usuario de producción a la versión de actualización de parche cuando estés seguro.
- Actualiza el clúster de administrador a la versión de actualización de parches.
Soluciona problemas de actualización de un clúster de administrador
Si surge algún problema cuando actualizas el clúster de administrador, debes comunicarte con la Atención al cliente de Google para resolverlo.
Mientras tanto, con el nuevo flujo de actualización, todavía puedes beneficiarse de las nuevas funciones del clúster de usuario sin que se bloquee la actualización del clúster de administrador, lo que te permite reducir la frecuencia de actualización del clúster de administrador, si así lo desea. El proceso de actualización puede proceder de la siguiente manera:
- Actualiza los clústeres de usuario de producción a la versión 1.12.x.
- Mantén la versión anterior del clúster de administrador y continúa recibiendo parches de seguridad.
- Prueba la actualización de los clústeres de administrador de 1.11.x a 1.12.x en un entorno de prueba y, luego, informar los problemas si los hay
- Si tu problema se resuelve con una versión de parche 1.12.x, puedes elegir actualizar el clúster de administrador de producción a esta versión de parche si lo deseas.
Problemas conocidos de versiones recientes
Los siguientes problemas conocidos podrían afectar las actualizaciones si estás actualizando desde la versión 1.7 o 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
, la actualización podría fallar si el disco de datos está casi lleno, ya que el sistema intenta crear una copia de seguridad de la estación de trabajo de administrador actual de forma local mientras se actualiza a una nueva estación de trabajo de administrador. 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 realizar una copia de seguridad local de la estación de trabajo de administrador actual.
Interrupción de las cargas de trabajo con PodDisruptionBudgets
Por el momento, la actualización de los clústeres puede causar interrupciones o tiempo de inactividad para las cargas de trabajo que usan PodDisruptionBudgets (PDB).
El proceso de actualización de los nodos falla
Si tienes objetos PodDisruptionBudget
configurados que no pueden permitir interrupciones adicionales, es posible que las actualizaciones de los nodos no se actualicen a la versión del plano de control después de varios intentos. Para evitar esta falla, te recomendamos que escales verticalmente la Deployment
o la HorizontalPodAutoscaler
a fin de permitir que el nodo se desvíe y aún respete la configuración de PodDisruptionBudget
.
Para ver todos los objetos PodDisruptionBudget
que no permiten ninguna interrupción, 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, GKE on VMware crea de forma automática reglas de antiafinidad de Distributed Resource Scheduler (DRS) de VMware para los nodos del clúster de usuario, de modo que se distribuyan en al menos tres hosts físicos del centro de datos. A partir de la versión 1.1.0-gke.6, esta función se habilita de forma automática para clústeres nuevos y existentes.
Antes de realizar la actualización, asegúrate de que el entorno de vSphere cumpla con las siguientes condiciones:
DRS de VMware debe estar habilitado. Para el DRS de VMware, se requiere la edición de licencia de vSphere Enterprise Plus. Para aprender a habilitar el DRS, consulta Habilita el DRS de VMware en un clúster.
El nombre de usuario de vSphere que se proporciona en el archivo de configuración de credenciales tiene el permiso
Host.Inventory.EditCluster
.Debe haber al menos tres hosts físicos disponibles.
Si el entorno de vSphere no cumple con las condiciones anteriores, aún puedes realizar la actualización. Pero para actualizar un clúster de usuario de 1.3.x a 1.4.x, debes inhabilitar los grupos antiafinidad. Para obtener más información, consulta este problema conocido en las notas de la versión de GKE en VMware.
Información sobre el tiempo de inactividad durante las actualizaciones
Recurso | Descripción |
---|---|
Clúster de administrador | Cuando un clúster de administrador está inactivo, los planos de control y las cargas de trabajo en los clústeres de usuario continúan ejecutándose, a menos que se vean afectados por una falla que causó el tiempo de inactividad. |
Plano de control del clúster de usuario | Por lo general, no es probable que se produzcan tiempos de inactividad perceptibles en los planos de control del clúster de usuario. Sin embargo, las conexiones de larga duración al servidor de la API de Kubernetes podrían fallar y tendrían que restablecerse. En esos casos, el emisor 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 tiempo de inactividad durante una actualización. |
Nodos del clúster de usuario | Si una actualización requiere un cambio en los nodos del clúster de usuario, GKE en VMware vuelve a crear los nodos de forma progresiva y reprograma los Pods que se ejecutan en estos nodos. Puedes evitar el impacto en tus cargas de trabajo; para ello, configura PodDisruptionBudgets y reglas de antiafinidad adecuados. |
Vuelve a crear un archivo de información si falta
Si falta el archivo de información de salida para tu estación de trabajo de administrador, debes volver a crear este archivo para poder continuar con la actualización. Este archivo se creó cuando creaste la estación de trabajo inicialmente y, si desde entonces realizaste una actualización, se actualizó 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 archivo de información de salida de ejemplo:
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 que correspondan. Guarda el archivo con un nombre de archivo que sea igual al nombre de 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
.
¿Qué sigue?
Documentación de referencia de gcloud CLI
Documentación de referencia de Terraform