Versión 1.7. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, que ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos alojados en VMware (GKE On-Prem). Consulta las notas de la versión para obtener más detalles. Esta es la versión más reciente.

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.

A partir de la versión 1.7, puedes usar cualquier versión del parche dentro del rango de dos versiones secundarias y hacer que tus clústeres de administrador y usuario usen las siguientes versiones:

  • El clúster de administrador usa la versión 1.6.x y los clústeres de usuario usan la versión 1.6.x o 1.7.
  • De manera alternativa, tanto el clúster de administrador como los clústeres de usuario usan la versión 1.7.

Descripción general del proceso de actualización actual

A partir de la versión 1.7, se cambió el proceso de actualización predeterminado. Primero, actualiza la estación de trabajo de administrador y, luego, los clústeres de usuario y, por último, el clúster del administrador. En la versión 1.7, no es necesario que actualices el clúster de administrador de inmediato después de actualizar los clústeres de usuario si deseas mantener el clúster de administrador en su versión actual.

  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. Actualiza tu estación de trabajo de administrador.
  3. Desde la estación de trabajo de administrador, actualiza los clústeres de usuarios.
  4. Desde la estación de trabajo del administrador, actualiza el clúster de administrador.

Proceso de actualización para la versión 1.6.x y anteriores

Para la versión 1.6.x y las anteriores, el proceso de actualización es el siguiente. Aún puedes seguir este orden de proceso en la versión 1.7 con las marcas de parámetros, pero este proceso es obsoleto y no funcionará en algunas versiones futuras. También puedes seguir este proceso de actualización si tu configuración actual es 1.5.x o inferior, y si deseas llevar tu configuración a la versión 1.6.x, de modo que puedas continuar con una actualización de 1.7.

  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.

Supongamos que tu estación de trabajo de administrador, el clúster de administrador y los clústeres de usuario usan actualmente la versión 1.6.2 y deseas actualizar el clúster de administrador y los clústeres de usuario a 1.7. Si sigues una ruta de actualización como la siguiente, con el uso de un clúster de versión canary para realizar pruebas antes de continuar, deberás minimizar el riesgo de interrupción.

A continuación, se presenta una descripción general de alto nivel de un proceso recomendado de actualización. Antes de comenzar, crea un clúster de usuario canary que use 1.6.2, si aún no lo hiciste.

  1. Prueba la versión 1.7 en un clúster de versión canary.
    • Actualiza la estación de trabajo de administrador a la versión 1.7.
    • Ejecuta el comando gkectl prepare, como se describe más adelante, para configurar la actualización.
      • Actualiza el clúster de usuario en versión canary a 1.7.
  2. Actualiza todos los clústeres de usuario de producción a la versión 1.7 cuando estés seguro de que quieres actualizar a 1.7.
  3. Actualiza el clúster de administrador a la versión 1.7.

Localiza los archivos de información y configuración para preparar la actualización

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

Además, gkeadm creó un archivo de información por ti. El nombre predeterminado de este archivo es el mismo que el nombre de la estación de trabajo de 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 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.

Actualiza la estación de trabajo del administrador

Asegúrate de que gkectl y los clústeres estén en el nivel de versión adecuado para una actualización y de haber descargado el paquete adecuado.

Actualiza la configuración de la estación de trabajo de 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.

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. Puedes separar las IP adicionales según sea necesario, como se describe para cada Una de las IP estáticas y DHCP.

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.

En la versión 1.7, para agregar direcciones IP al clúster de administrador, haz lo siguiente:

Primero, edita el archivo de bloque de IP, como se muestra en este ejemplo.

blocks:
- netmask: "255.255.252.0"
  ips:
  - ip: 172.16.20.10
    hostname: admin-host1
  - ip: 172.16.20.11
    hostname: admin-host2
  # Newly-added IPs.
  - ip: 172.16.20.12
    hostname: admin-host3

Luego, ejecuta este comando para actualizar la configuración.

gkectl update admin --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [ADMIN_CONFIG_FILE]
  • En el ejemplo anterior, [ADMIN_CLUSTER_KUBECONFIG] es la ruta de acceso de tu archivo kubeconfig.

  • [ADMIN_CONFIG_FILE] es la ruta de acceso de tu archivo de configuración de administrador. Puedes omitir esta marca si el archivo se encuentra en el directorio actual y tiene el nombre admin-config.yaml.

No puedes quitar direcciones IP, solo agregarlas.

En las versiones anteriores a 1.7, puedes agregar una dirección adicional si editas el objeto Cluster directamente.

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.

Importante: A partir de la versión 1.5.0, el mismo procedimiento no funciona para los clústeres de usuarios, y debes usar gkectl update cluster para cada uno de ellos.

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

En el ejemplo anterior, se ilustra lo siguiente:

  • [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, puedes abrir el archivo de bloque de IP del clúster de usuario para editarlo:

  • Si alguna de las direcciones reservadas para un clúster de usuario se incluye en el archivo hostconfig, agrégalas al bloque correspondiente basado en netmask y gateway.

  • Agrega las direcciones IP estáticas adicionales necesarias al bloque correspondiente y, luego, ejecuta gkectl update cluster.

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.

Instala el paquete para la actualización

A fin de que una versión esté disponible para la creación o la actualización del clúster, debes instalar el paquete correspondiente. Sigue estos pasos para instalar un paquete para TARGET_VERSION, que es el número de 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

A continuación, se muestra un resultado de ejemplo:

gkectl version: 1.7.2-gke.2 (git-5b8ef94a3)onprem user cluster controller version: 1.6.2-gke.0
current admin cluster version: 1.6.2-gke.0
current user cluster versions (VERSION: CLUSTER_NAMES):
- 1.6.2-gke.0: user-cluster1
available admin cluster versions:
- 1.6.2-gke.0
available user cluster versions:
- 1.6.2-gke.0
- 1.7.2-gke.2
Info: The admin workstation and gkectl is NOT ready to upgrade to "1.8" yet, because there are "1.6" clusters.
Info: The admin cluster can't be upgraded to "1.7", because there are still "1.6" user clusters.

Según los resultados que obtengas, busca los siguientes problemas y corrígelos según sea necesario.

  • Si la versión gkectl es inferior a 1.7, el nuevo flujo de actualización no está disponible directamente. Sigue el flujo de actualización original para actualizar todos tus clústeres a la versión 1.6 y, luego, actualiza tu estación de trabajo de administrador a la versión 1.7 para comenzar a usar el nuevo flujo de actualización.

  • Si la versión actual del clúster de administrador es más de una versión secundaria anterior a TARGET_VERSION, actualiza todos tus clústeres para que sean una versión secundaria inferior a TARGET_VERSION.

  • Si la versión gkectl es inferior a TARGET_VERSION, sigue las instrucciones para actualizar 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

Donde:

  • En el ejemplo anterior, [ADMIN_CLUSTER_KUBECONFIG] es 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.

Actualiza un clúster de usuario

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

gkectl

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

[FLAGS]

Donde:

  • [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de administrador.

  • [USER_CLUSTER_CONFIG_FILE] es el archivo de configuración del clúster de usuario de los clústeres de Anthos alojados en VMware en la nueva estación de trabajo 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.

Console

Puedes elegir registrar los clústeres de usuario con Cloud Console durante la instalación o después de crearlos. Puedes ver y acceder a tus clústeres registrados de clústeres de Anthos alojados en VMware y tus clústeres de Google Kubernetes Engine desde el menú de GKE de Cloud Console.

Cuando hay una actualización disponible para los clústeres de usuario de clústeres de Anthos alojados en VMware, aparece una notificación en Cloud Console. 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 el menú de GKE en Cloud Console.

    Visitar el menú de GKE

  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. Desde tu estación de trabajo de administrador, ejecuta el comando gkectl upgrade cluster, en el que [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de administrador y [USER_CLUSTER_CONFIG_FILE] es el archivo de configuración del clúster de usuario de clústeres de Anthos alojados en VMware de la nueva estación de trabajo de administrador.

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

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 el nivel de versión adecuado para una actualización y de haber descargado el paquete adecuado.

La versión objetivo de tu actualización no debe ser superior a la versión de gkectl y, como máximo, una versión secundaria inferior a la versión de gkectl. Entonces, si la versión de gkectl es 1.7, la versión de destino de la actualización puede ser de 1.6.x a 1.7. El clúster de administrador solo se puede actualizar a una versión secundaria, cuando todos los clústeres de usuario se actualizaron a esa versión secundaria. Por ejemplo, si intenta actualizar el clúster de administrador a la versión 1.7, cuando todavía existen clústeres de usuario 1.6.2, recibirá un error:

admin cluster can't be upgraded to
"1.7.0-gke.0" yet, because there are still user clusters at "1.6.2-gke.0".

Ejecuta el siguiente comando:

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

En el ejemplo anterior, se ilustra 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 los clústeres de Anthos alojados en VMware en la nueva estación de trabajo 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. Usa la marca --force-upgrade-admin para volver al flujo de actualización anterior, en el que el clúster de administrador se actualiza primero y, luego, los clústeres de usuario.

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

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 Atención al cliente de Google para obtener ayuda.

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.6.2 y que estás realizando el proceso de actualización recomendado.

Soluciona un problema de actualización del clúster de usuario

Supongamos que tienes un problema con 1.7 cuando pruebas el clúster canary o actualizas un clúster de usuario. Google determina que el problema se solucionará en una próxima versión de parche 1.7.x. Puedes continuar de la siguiente manera:

  1. Sigue usando la versión 1.6.2 para la producción.
  2. Prueba la versión de parche 1.7.x en un clúster versión canary cuando se lance. Actualiza todos los clústeres de usuario de producción a la versión 1.7.x cuando estés seguro de que deseas hacerlo.
  3. Actualiza el clúster de administrador a la versión 1.7.x.

Administra una versión de parche 1.6.x cuando pruebas la versión 1.7

Supongamos que estás en proceso de prueba o migración a la versión 1.7, pero aún no estás seguro de hacerlo, y tu clúster de administrador todavía usa 1.6.2. Observas que se lanzó una versión importante de parche 1.6.x. Aún puedes aprovechar esta versión de parche 1.6.x mientras continúas probando la versión 1.7. Sigue este proceso de actualización:

  1. Instala el paquete 1.6.x-gke.0.
  2. Actualiza todos los clústeres de usuario de producción 1.6.2 a 1.6.x.
  3. Actualiza el clúster de administrador a la versión 1.6.x.

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. Por ejemplo, es posible que desees usar el grupo de nodos de Container-Optimized OS lanzado en la versión 1.7. 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.7.
  2. Mantén el clúster de administrador en la versión 1.6 y sigue recibiendo parches de seguridad
  3. Prueba la actualización del clúster de administrador de la versión 1.6 a la 1.7 en un entorno de prueba y, si hay alguno, informa los problemas.
  4. Si tu problema se resuelve mediante una versión de parche 1.7, puedes actualizar el clúster de administrador de producción de 1.6 a esta versión 1.7 de parche si lo deseas.

Problemas conocidos

Los siguientes problemas conocidos afectan a la actualización de los clústeres.

Versión 1.7.0: cambios en las actualizaciones de Anthos Config Management

En las versiones anteriores a 1.7.0, los clústeres de Anthos alojados en VMware incluían las imágenes necesarias para instalar y actualizar Anthos Config Management. A partir de 1.7.0, el software de Anthos Config Management ya no se incluye el paquete de clústeres de Anthos alojados en VMware, y debes agregarlo por separado. Si usabas Anthos Config Management en tu clúster o clústeres, el software no se actualizará hasta que tomes medidas.

Para obtener más información sobre la instalación de Anthos Config Management, consulta Instala Anthos Config Management.

Versión 1.1.0-gke.6, 1.2.0-gke.6: se quitó el campo stackdriver.proxyconfigsecretname

El campo stackdriver.proxyconfigsecretname se quitó en la versión 1.1.0-gke.6. Las comprobaciones previas de los clústeres de Anthos alojados en VMware mostrarán un error si el campo está presente en el archivo de configuración.

Para solucionar este problema, antes de actualizar a 1.2.0-gke.6, borra el campo proxyconfigsecretname del archivo de configuración.

Stackdriver hace referencia a la versión anterior

Antes de la versión 1.2.0-gke.6, un problema conocido evita que Stackdriver actualice la configuración después de las actualizaciones del clúster. Stackdriver todavía hace referencia a una versión anterior, lo que evita que Stackdriver reciba las funciones más recientes de su canalización de telemetría. Este problema puede dificultar que Atención al cliente de Google solucione los problemas de los clústeres.

Después de actualizar los clústeres a 1.2.0-gke.6, ejecuta el siguiente comando en los clústeres de administrador y usuario:

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

En el ejemplo anterior, [KUBECONFIG] es la ruta de acceso al archivo kubeconfig del clúster.

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

Versión 1.2.0-gke.6: Prometheus y Grafana se inhabilitan después de la actualización

En los clústeres de usuario, Prometheus y Grafana se inhabilitan de forma automática durante la actualización. Sin embargo, los datos y las métricas de configuración no se pierden. En los clústeres de administrador, Prometheus y Grafana permanecen habilitados.

Para obtener instrucciones, consulta las notas de la versión de los clústeres de Anthos alojados en VMware.

Versión 1.1.2-gke.0: los nodos de clúster de usuario borrados no se quitan del almacén de datos de vSAN

Para obtener instrucciones, consulta las notas de la versión de los clústeres de Anthos alojados en VMware.

Versión 1.1.1-gke.2: Se puede borrar el disco de datos en la carpeta del almacén de datos de vSAN

Si usas un almacén de datos de vSAN, debes crear una carpeta en la que puedas guardar el VMDK. Un problema conocido requiere que proporciones la ruta de acceso de identificador único universal (UUID) de la carpeta, en lugar de su ruta de acceso de archivo, a vcenter.datadisk. Esta incompatibilidad puede hacer que las actualizaciones fallen.

Para obtener instrucciones, consulta las notas de la versión de los clústeres de Anthos alojados en VMware.

Actualización a la versión 1.1.0-gke.6 desde la versión 1.0.2-gke.3: Error de OIDC

Los clústeres de las versiones 1.0.11, 1.0.1-gke.5 y 1.0.2-gke.3 que tienen OpenID Connect (OIDC) configurado no se pueden actualizar a la versión 1.1.0-gke.6. Este problema se solucionó en la versión 1.1.1-gke.2.

Si configuraste un clúster de versión 1.0.11, 1.0.1-gke.5 o 1.0.2-gke.3 con OIDC durante la instalación, no puedes actualizarlo. En su lugar, debes crear clústeres nuevos.

Actualiza la versión 1.0.11 a la versión 1.0.2-gke.3

La versión 1.0.2-gke.3 presenta los siguientes campos de OIDC (usercluster.oidc). Estos campos permiten acceder a un clúster desde Cloud Console:

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

Si deseas usar OIDC, el campo clientsecret es obligatorio incluso si no deseas acceder a un clúster desde Cloud Console. A fin de usar OIDC, es posible que debas proporcionar un valor de marcador de posición para clientsecret:

oidc:
  clientsecret: "secret"

El proceso de actualización de los nodos falla

Si tienes OSS Istio o Anthos Service Mesh instalado en tu clúster, según la configuración de PodDisruptionBudget para los componentes de Istio, es posible que los nodos del usuario no se actualicen a la versión del plano de control después de varios intentos. A fin de evitar este error, te recomendamos que aumentes la configuración del ajuste de escala automático horizontal de Pods minReplicas de 1 a 2 para los componentes del espacio de nombres istio-system antes de la actualización. Esto garantizará que siempre tengas una instancia del plano de control de ASM en ejecución.

Si tienes Anthos Service Mesh 1.5+ o OSS Istio 1.5+, ejecuta lo siguiente:

kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istiod -p '{"spec":{"minReplicas": 2}}' --type=merge

Si tienes OSS Istio 1.4.x o Anthos Service Mesh 1.4.x, ejecuta lo siguiente:

kubectl patch hpa -n istio-system istio-galley -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-ingressgateway -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-nodeagent -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-pilot -p '{"spec":{"minReplicas": 2}}' --type=merge
kubectl patch hpa -n istio-system istio-sidecar-injector -p '{"spec":{"minReplicas": 2}}' --type=merge

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.

Tiempo de inactividad

Acerca del 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