Actualiza clústeres de Anthos alojados en VMware

En esta página, se explica cómo actualizar clústeres de Anthos alojados en VMware (GKE On-Prem). Si la API de Anthos On-Prem administra tu clúster de usuario y deseas usar la consola de Google Cloud o Google Cloud CLI para actualizar el clúster, con el procedimiento de actualización de vista previa, consulta Actualiza un clúster de usuario mediante clientes de la API de Anthos On-Prem.

Descripción general del proceso de actualización

Puedes actualizar directamente a cualquier versión que se encuentre en la misma versión secundaria o en la próxima versión secundaria. Por ejemplo, puedes actualizar de 1.13.0 a 1.13.1 o de 1.12.1 a 1.13.0.

Si quieres actualizar a una versión que no forma parte de la próxima versión secundaria, debes actualizar a través de una versión de cada actualización secundaria entre tu versión actual y la deseada. Por ejemplo, si actualizas de la versión 1.11.2 a la versión 1.13.0, no podrás hacerlo directamente. Primero debes actualizar de la versión 1.11.2 a la versión 1.12.x y, luego, a la versión 1.13.0.

En este tema, se analiza cómo actualizar de la versión 1.12.x a la 1.13.y.

Revisa las prácticas recomendadas de actualización del clúster antes de comenzar el proceso de actualización.

Este es el flujo de trabajo general para actualizar.

  1. Actualiza la estación de trabajo de administrador a la versión de destino de la actualización.

  2. Desde la estación de trabajo de administrador, actualiza los clústeres de usuarios.

  3. Después de actualizar todos los clústeres de usuario, puedes actualizarlo de la estación de trabajo de administrador. Este paso es opcional, a menos que necesites las funciones disponibles en la actualización.

Actualización asíncrona de clústeres de usuarios

Para una actualización del clúster de usuario, hay dos variaciones del comando gkectl upgrade cluster:

  • Asíncrono (recomendado)
  • Síncrona

Con la variación asíncrona, el comando inicia la actualización y, luego, se completa. No necesitas observar el resultado del comando durante todo el período de la actualización. En su lugar, puedes verificar el progreso de la actualización de forma periódica si ejecutas gkectl list cluster y gkectl describe cluster.

Para usar la variación asíncrona, incluye la marca --async en el comando. Para obtener más información, consulta Actualiza un clúster de usuario.

Rotación de certificados durante la actualización

Durante una actualización, los certificados de hoja se rotan, pero los certificados de CA no se rotan. Debes rotar manualmente tus certificados de CA al menos una vez cada cinco años. Para obtener más información, consulta Cómo rotar autoridades de certificados del clúster de usuario y Rotar certificados de CA del clúster de administrador.

Prepárate para la actualización

Antes de iniciar una actualización, toma una instantánea de tu clúster. La instantánea te ayudará a solucionar problemas si hay un problema durante la actualización.

Antes de crear la estación de trabajo de administrador, completaste 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 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.

Actualiza tu estación de trabajo de administrador

  1. Descargar gkeadm:

    gkeadm upgrade gkeadm --target-version TARGET_VERSION

    Reemplaza TARGET_VERSION por la versión de destino de la actualización.

  2. 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 nombre admin-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.

  • 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 que haya suficientes direcciones IP disponibles

Antes de actualizar los clústeres, asegúrate de haber asignado suficientes direcciones IP. Puedes asignar direcciones IP adicionales según sea necesario. Consulta Administra direcciones IP de nodos para determinar cuántas direcciones IP necesitas.

Actualiza un clúster de usuario

Línea de comandos

Hay dos tipos de actualización del clúster de usuario que puede realizar en la línea de comandos:

  • Asíncrona
  • Síncrona

Actualización asíncrona

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

En el archivo de configuración del clúster de usuario, establece gkeOnPremVersion en la versión de destino de la actualización.

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

El comando anterior se completa y puedes seguir usando el clúster de usuario 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 de STATE es UPGRADING. Por ejemplo:

NAMESPACE             NAME    READY   STATE       AGE   VERSION
my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.13.0-gke.1

Los valores posibles para STATE son PROVISIONING, UPGRADING, DELETING, UPDATING, RUNNING, RECONCILING, ERROR y UNKNOWN.

Para obtener más detalles sobre el progreso de la actualización y los eventos del clúster, haz lo siguiente:

gkectl describe cluster --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 según el inicio y el final de cada fase de actualización crítica, incluidos los siguientes:

  • Actualización del plano de control
  • Actualización de MasterNode
  • Actualización de complementos
  • Actualización de los grupos de nodos

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 cluster muestra un STATUS de RUNNING:

NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.13.0-gke.1

Además, cuando se completa la actualización, gkectl describe cluster muestra un campo LastGKEOnPremVersion en Status. Por ejemplo:

Status:
Cluster State:  RUNNING
LastGKEOnOremVersion:  1.12.0-gke.0

Cómo solucionar 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 demora más que el 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, en este caso, el estado ERROR significa que la actualización tarda más de lo esperado, pero no se finalizó. El control continúa la conciliación y sigue reintentando la operación.

Por lo general, un tiempo de espera es el resultado de un interbloqueo que genera un PodDisruptionBudget (PDB). En ese caso, los Pods no se pueden expulsar de los nodos antiguos, y estos no se pueden desviar. Si la expulsión del Pod tarda más de 10 minutos, se escribe un evento en el objeto OnPremUserCluster. Para capturar el evento, ejecuta gkectl describe cluster. Luego, puedes ajustar el PDB para permitir que el nodo se desvíe. Después de eso, la actualización puede 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 una actualización se bloquea o falla, puedes ejecutar gkectl diagnose para verificar los problemas comunes del clúster. En función del resultado, puedes decidir si deseas 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 verificaciones previas, el comando se bloquea. Debes corregir las fallas o usar la marca --skip-preflight-check-blocking. Solo debes omitir las verificaciones previas si estás seguro de que no hay fallas críticas.

Continúa con estos pasos en la estación de trabajo de administrador:

  1. 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

  2. En el archivo de configuración del clúster de usuario, establece gkeOnPremVersion en la versión de destino de la actualización.

  3. Actualiza el clúster:

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

Consola

Sigue estos pasos si deseas usar la consola para actualizar un clúster de usuario administrado por la API de Anthos On-Prem, pero no deseas usar el procedimiento de actualización de la vista previa a fin de actualizar el clúster de usuario.

  1. En tu estación de trabajo de administrador, ejecuta el siguiente comando:

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

    Reemplaza lo siguiente:

    • ADMIN_CLUSTER_KUBECONFIG es la ruta de acceso al archivo kubeconfig del clúster de administrador.

    Este comando descarga e instala paquetes en el clúster de administrador y, luego, implementa la versión nueva de los componentes que administran el clúster de usuario. Este comando te permite actualizar el clúster de usuario en la consola.

  2. En la consola de Google Cloud, ve a la página Clústeres de Anthos.

    Ir a la página Clústeres de Anthos

  3. Selecciona el proyecto de Google Cloud en el que se encuentra el clúster de usuario.

  4. En la lista de clústeres, haz clic en el que deseas actualizar.

  5. En el panel Detalles, si el Tipo es vm Anthos (VMware), realiza los siguientes pasos para borrar el clúster mediante la consola de Google Cloud:

    1. En el panel Detalles, haz clic en Más detalles.

    2. En la sección Conceptos básicos del clúster, haz clic en Actualizar.

    3. En la lista clústeres de Anthos alojados en VMware, selecciona la versión a la que deseas actualizar.

    4. Haz clic en Actualizar.

    Si el Tipo es externo, esto indica que el clúster se creó con gkectl. En este caso, sigue los pasos en la pestaña Línea de comandos para actualizar el clúster.

Reanuda una actualización

Si se interrumpe una actualización del clúster de usuario, puedes reanudar la actualización del clúster de usuario si ejecutas 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

Actualiza el clúster de administrador

Antes de comenzar:

  • Determine si sus certificados están actualizados y renuévelos si es necesario.

  • Si actualizas a la versión 1.13 o a una versión posterior, primero debes completar la sección gkeConnect del archivo de configuración del clúster de administrador para registrar el clúster de administrador. Ejecuta el comando update con los cambios del 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.

  1. 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 esos cambios se apliquen, primero debes actualizar el clúster y, luego, ejecutar un comando de actualización con los cambios en el archivo de configuración para realizar otros cambios en el clúster.

  2. 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: el archivo de configuración del clúster de administrador de los clústeres de Anthos alojados en VMware en la nueva estación de trabajo de administrador.

    • 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 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 mal estado.

Lleve a cabo los pasos siguientes:

  1. 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.

  2. 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.

  3. 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 recrea el estado del clúster de administrador desde el punto de control y vuelve a ejecutar toda la actualización. A partir de la versión 1.12.0, si el plano de control del 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:

  1. Descarga la versión de reversión de gkeadm.
  2. Crea una copia de seguridad del directorio principal de la estación de trabajo de administrador actual.
  3. Crea una estación de trabajo de administrador nueva con la versión de reversión de gkeadm.
  4. 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.

  1. 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.

  2. 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.

  3. 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/

  4. 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.

  5. 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:

  1. Continúa usando la versión actual para la producción.
  2. Prueba la versión del parche en un clúster que no sea de producción cuando se lance
  3. Actualiza todos los clústeres de usuario de producción a la versión de actualización de parche cuando estés seguro.
  4. 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:

  1. Actualiza los clústeres de usuario de producción a la versión 1.12.x.
  2. Mantén la versión anterior del clúster de administrador y continúa recibiendo parches de seguridad.
  3. 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
  4. 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, los clústeres de Anthos alojados en VMware crean 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 distribuyen 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 los clústeres de Anthos alojados 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, los clústeres de Anthos alojados en VMware recrean los nodos de forma progresiva y reprograman 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.