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

Versiones de destino

A partir de los clústeres de Anthos alojados en VMware, versión 1.3.2, puedes actualizar de forma directa a cualquier versión que esté en la misma versión secundaria o en la próxima versión secundaria. Por ejemplo, puedes actualizar de la versión 1.3.2 a la 1.3.5 o de la versión 1.5.2 a la 1.6.1.

Si tu versión actual es anterior a 1.3.2, debes realizar actualizaciones secuenciales para alcanzar la versión 1.3.2 primero. Por ejemplo, para actualizar de 1.3.0 a 1.3.2, primero debes actualizar de 1.3.0 a 1.3.1 y, luego, de 1.3.1 a 1.3.2.

Si actualizas de la versión 1.3.2 o posterior a una versión que no forma parte de la próxima versión secundaria, debes actualizar mediante una versión de cada actualización secundaria entre la versión actual y la deseada. Por ejemplo, si actualizas de la versión 1.3.2 a la versión 1.6.1, no es posible actualizar de forma directa. Primero debes actualizar de la versión 1.3.2 a la versión 1.4.x, en la que x representa cualquier actualización de parche en esa versión secundaria. Luego, puedes actualizar a la versión 1.5.x y, finalmente, a la versión 1.6.1.

Descripción general del proceso de actualización

  1. Descarga la herramienta gkeadm. La versión de gkeadm debe ser la misma que la versión de destino de tu actualización.

  2. Usa gkeadm para actualizar la estación de trabajo del administrador.

  3. Desde la estación de trabajo del administrador, actualiza el clúster de administrador.

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

Actualiza la política

Después de actualizar el clúster de administrador, haz lo siguiente:

  • Todos los clústeres de usuarios nuevos que crees deben tener la misma versión que el clúster de administrador.

  • Si actualizas un clúster de usuario existente, debes actualizarlo a la misma versión que el clúster de administrador.

  • Antes de volver a actualizar el clúster de administrador, debes actualizar todos los clústeres de usuarios a la misma versión que el clúster de administrador actual.

Localiza tus archivos de información y configuración

Cuando creaste la estación de trabajo del administrador actual, completaste un archivo de configuración de la estación de trabajo del administrador que generó gkeadm create config. El nombre predeterminado para este archivo es admin-ws-config.yaml.

Cuando creaste la estación de trabajo del administrador actual, gkeadm creó un archivo de información para ti. El nombre predeterminado de este archivo es el mismo que el nombre de la estación de trabajo del administrador actual.

Localiza el archivo de configuración de la estación de trabajo del administrador y el archivo de información. Los necesitarás para realizar los pasos de esta guía. Si estos archivos se encuentran en tu directorio actual y tienen los nombres predeterminados, no tendrás que especificarlos cuando ejecutes gkeadm upgrade admin-workstation. Si estos archivos están en otro directorio o si cambiaste los nombres de archivo, debes especificarlos mediante las marcas --config y --info-file.

Actualiza la estación de trabajo del administrador

Para actualizar la estación de trabajo de administrador, primero descarga una versión nueva de la herramienta de gkeadm y, luego, úsala para actualizar la configuración de la estación de trabajo de administrador. La versión de gkeadm debe coincidir con la versión de destino de la actualización.

Descarga gkeadm

Para descargar la versión adecuada de gkeadm, sigue las instrucciones de la página Descargas.

Actualiza la estación de trabajo del administrador

gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]

Donde:

  • [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. Estos incluyen:

    • Tu archivo de configuración de los clústeres de Anthos alojados en VMware El nombre predeterminado para este archivo es config.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, connect-agent y logging-monitoring.

  • Crea una nueva estación de trabajo del administrador y copia todos los archivos con copia de seguridad en esta.

  • Borra la estación de trabajo del administrador anterior.

Actualiza la imagen de SO del nodo y las imágenes de Docker

En la nueva estación de trabajo del administrador, ejecuta el siguiente comando:

gkectl prepare --config [ADMIN_CONFIG] [FLAGS]

Donde:

  • [ADMIN_CONFIG] es la ruta de acceso del archivo de configuración de tu clúster de administrador.

  • [FLAGS] es un conjunto opcional de marcas. Por ejemplo, puedes incluir la marca --skip-validation-infra para omitir la comprobación de la infraestructura de vSphere.

El comando anterior realiza las siguientes tareas:

  • Si es necesario, copia una nueva imagen de SO de nodo en tu entorno de vSphere y marca la imagen del SO como una plantilla.

  • Si configuraste un registro privado de Docker, envía imágenes de Docker actualizadas al registro privado de Docker.

Verifica que haya suficientes direcciones IP disponibles

Sigue los pasos que se indican en esta sección en la nueva estación de trabajo del administrador.

Antes de realizar la actualización, asegúrate de tener suficientes direcciones IP disponibles para los clústeres.

DHCP

Cuando actualizas el clúster de administrador, los clústeres de Anthos alojados en VMware crean un nodo temporal en el clúster de administrador. Cuando actualizas un clúster de usuario, los clústeres de Anthos alojados en VMware crean un nodo temporal en ese clúster.  El objetivo del nodo temporal es garantizar una disponibilidad sin interrupciones. Antes de actualizar un clúster, asegúrate de que el servidor DHCP pueda proporcionar suficientes direcciones IP para el nodo temporal. Si deseas obtener más información, consulta Direcciones IP necesarias para clústeres de administrador y de usuario.

IP estáticas

Cuando actualizas el clúster de administrador, los clústeres de Anthos alojados en VMware crean un nodo temporal en el clúster de administrador. Cuando actualizas un clúster de usuario, los clústeres de Anthos alojados en VMware crean un nodo temporal en ese clúster.  El objetivo del nodo temporal es garantizar una disponibilidad sin interrupciones. Antes de actualizar un clúster, verifica que reservaste suficientes direcciones IP. Para cada clúster, debes reservar al menos una dirección IP más que la cantidad de nodos del clúster. Para obtener más información, consulta Configura direcciones IP estáticas.

Determina la cantidad de nodos en el clúster de administrador:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

En el comando anterior, [ADMIN_CLUSTER_KUBECONFIG] es la ruta del archivo kubeconfig del clúster de administrador.

A continuación, observa las direcciones reservadas para el clúster de administrador:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

En la salida, en el campo reservedAddresses, puedes observar la cantidad de direcciones IP que se reservaron para los nodos del clúster de administrador. Por ejemplo, en la siguiente salida, se muestra que hay cinco direcciones IP reservadas para los nodos del clúster de administrador:

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

Las direcciones IP reservadas deben ser al menos una más que la cantidad de nodos en el clúster de administrador. Si este no es el caso, puedes editar el objeto de clúster para reservar una dirección adicional.

Abre el objeto de clúster para editar:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

En reservedAddresses, agrega un bloque adicional que tenga gateway, hostname, ip y netmask.

Para determinar la cantidad de nodos en un clúster de usuario, haz lo siguiente:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

En el comando anterior, [USER_CLUSTER_KUBECONFIG] es la ruta de acceso del archivo kubeconfig del clúster de usuario.

Si deseas ver las direcciones reservadas para un clúster de usuario, haz lo siguiente:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

Donde:

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

  • [USER_CLUSTER_NAME] es el nombre del clúster de usuario.

La cantidad de direcciones IP reservadas debe ser al menos una más que la cantidad de nodos del clúster de usuarios. Si este no es el caso, realiza los siguientes pasos:

  • Abre el archivo de bloque IP del clúster de usuario para editarlo.

  • Agrega direcciones IP adicionales al bloque y cierra el archivo.

  • Actualiza el clúster de usuario:

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONIFG] \
  --config [USER_CLUSTER_CONFIG]

Inhabilita las funciones de vSphere nuevas (opcional)

Una versión nueva de los clústeres de Anthos alojados en VMware puede incluir funciones nuevas o compatibilidad con funciones específicas de VMware vSphere. A veces, la actualización a una versión de los clústeres de Anthos alojados en VMware habilita esas funciones de forma automática. Puedes obtener información sobre las funciones nuevas en las notas de la versión de los clústeres de Anthos alojados en VMware. A veces, se muestran las funciones nuevas en el archivo de configuración de los clústeres de Anthos alojados en VMware.

Si necesitas inhabilitar una función nueva que se habilita automáticamente en una nueva versión de los clústeres de Anthos alojados en VMware y que controla el archivo de configuración, realiza los siguientes pasosantes de actualizar el clúster:

  1. Desde la estación de trabajo de administrador actualizada, crea un archivo de configuración nuevo con un nombre diferente al del archivo de configuración actual:

    gkectl create-config --config [CONFIG_NAME]

  2. Abre el nuevo archivo de configuración y toma nota del campo de la función. Cierra el archivo.

  3. Abre el archivo de configuración actual y agrega el campo de la función nueva. Configura el valor del campo como false o equivalente.

  4. Guarda el archivo de configuración.

Revisa las notas de la versión antes de actualizar los clústeres. No puedes cambiar de forma declarativa la configuración de un clúster existente después de actualizarlo.

Actualiza el clúster de administrador

Sigue los pasos que se indican en esta sección en la nueva estación de trabajo del administrador.

Recuerda que la versión de destino de la actualización debe ser la misma que la versión de gkeadm.

Ejecuta el siguiente comando:

gkectl upgrade admin \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [ADMIN_CLUSTER_CONFIG_FILE] \
    [FLAGS]

Donde:

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

  • En el ejemplo anterior, [ADMIN_CLUSTER_CONFIG_FILE] es la ruta de acceso del archivo de configuración de tu clúster de administrador.

  • [FLAGS] es un conjunto opcional de marcas. Por ejemplo, puedes incluir la marca --skip-validation-infra para omitir la comprobación de la infraestructura de vSphere.

Actualizar un clúster de usuario

Sigue los pasos que se indican en esta sección en la nueva estación de trabajo del administrador.

Recuerda que la versión de destino de la actualización debe ser la misma que la versión de gkeadm.

gkectl

gkectl upgrade cluster \
    --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
    --config [USER_CLUSTER_CONFIG_FILE] \
    [FLAGS]

Donde:

  • En el comando anterior, [ADMIN_CLUSTER_KUBECONFIG] es la ruta del archivo kubeconfig del clúster de administrador.

  • [USER_CLUSTER_CONFIG_FILE] es la ruta del archivo de configuración de tu clúster de usuario.

  • [FLAGS] es un conjunto opcional de marcas. Por ejemplo, puedes incluir la marca --skip-validation-infra para omitir la comprobación de la infraestructura de vSphere.

Consola

Puedes elegir registrar los clústeres de usuario con la consola de Google Cloud durante la instalación o después de crearlos. Puedes ver y acceder a los clústeres de Anthos registrados y los clústeres de GKE en la consola de Google Cloud.

Cuando hay una actualización disponible para un clúster de uso, aparece una notificación en la consola de Google Cloud. Si haces clic en esta notificación, se muestra una lista de las versiones disponibles y un comando de gkectl que puedes ejecutar para actualizar el clúster:

  1. Visita la página de Google Kubernetes Engine en la consola de Google Cloud.

    Visitar la página Google Kubernetes Engine

  2. En la columna Notificaciones del clúster de usuario, haz clic en Actualización disponible, si está disponible.

  3. Copia el comando gkectl upgrade cluster.

  4. En tu estación de trabajo de administrador, ejecuta el comando gkectl upgrade cluster, en el que [ADMIN_CLUSTER_KUBECONFIG] es la ruta del archivo kubeconfig del clúster de administrador, [CLUSTER_NAME] es el nombre del clúster de usuario que vuelve a actualizar, y [USER_CLUSTER_CONFIG_FILE] es la ruta de acceso del archivo de configuración del clúster de usuario.

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] \
    --cluster-name [CLUSTER_NAME] \
    --skip-validation-all

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

No debes interrumpir la actualización de un clúster de administrador. Por el momento, las actualizaciones del clúster de administrador no siempre se pueden reanudar. Si por algún motivo se interrumpe la actualización de un clúster de administrador, debes comunicarte con el equipo de asistencia para obtener ayuda.

Crea un clúster de usuario nuevo después de una actualización

Después de actualizar la estación de trabajo del administrador y el clúster de administrador, cualquier clúster de usuario nuevo que crees debe tener la misma versión que la versión de destino de la actualización.

Reglas de DRS de VMware

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. 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.
  • La cuenta de usuario de vSphere proporcionada en el campo vcenter debe tener 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 las notas de la versión de la versión 1.4.0.

Tiempo de inactividad

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.

Problemas conocidos

Consulta Problemas conocidos.

Soluciona problemas

Consulta Soluciona problemas de creación y actualización de clústeres