Actualiza clústeres

En esta página, se explica cómo actualizar los clústeres de administrador y de usuario de una versión de parche de GKE On-Prem a la siguiente versión de parche superior. Para obtener más información sobre las versiones disponibles, consulta Versiones.

También consulta lo siguiente:

• Descargas
• Notas de la versión
• Actualiza la estación de trabajo de administrador

Descripción general

GKE On-Prem admite la actualización secuencial. Por ejemplo, supongamos que estas son las únicas versiones que existen:

• 1.0.10
• 1.0.X, en el que X viene después de .10
• 1.0.Y, en el que Y viene después de X

En este caso, 1.0.Y es la versión más reciente. Para actualizar un clúster de la versión 1.0.10 a 1.0.Y, debes seguir estos pasos:

1. Actualiza el clúster de 1.0.10 a 1.0.X.
2. Luego, actualiza el clúster de 1.0.X a 1.0.Y.

Antes de comenzar

1. Para establecer una conexión SSH a tu estación de trabajo de administrador, haz lo siguiente:

   ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
   

2. Autoriza a gcloud para que acceda a Google Cloud:

   gcloud auth login

3. Activa la cuenta de servicio de acceso:

   gcloud auth activate-service-account --project [PROJECT_ID] \
   --key-file [ACCESS_KEY_FILE]
   

   Donde:

   • [PROJECT_ID] es el ID del proyecto.
   • [ACCESS_KEY_FILE] es la ruta de acceso al archivo de claves JSON para tu cuenta de servicio de acceso, como /home/ubuntu/access.json.

Actualiza a la versión 1.0.2

En la versión 1.0.2-gke.3, se agregaron los siguientes campos de OIDC (usercluster.oidc). Estos campos permiten acceder a un clúster desde la consola de Google Cloud:

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

Si no quieres acceder a un clúster desde la consola de Google Cloud, pero deseas usar OIDC, puedes pasar valores de marcador de posición para estos campos:

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

Determina la situación de actualización de tus clústeres

Antes de actualizar tu clúster, decide cuál de estas situaciones es relevante para la versión a la que quieres actualizar:

Situación	Acción necesaria	Notas
La versión no tiene actualizaciones de seguridad.	Descarga la versión más reciente de gkectl. Descarga el paquete más reciente. Sigue las instrucciones de esta página.
La versión tiene actualizaciones de seguridad.	Descarga el OVA de la estación de trabajo de administrador más reciente. Actualiza tu estación de trabajo de administrador. Sigue las instrucciones de esta página.	Solo debes actualizar tu estación de trabajo de administrador si la versión nueva tiene actualizaciones de seguridad. Cuando se actualiza la estación de trabajo de administrador, se incluye la versión más reciente de gkectl y el paquete.

Determina la versión de la plataforma

A fin de actualizar los clústeres, debes determinar la versión de la plataforma para ellos:

Desde la documentación

Consulta Versiones.

Desde el paquete

Ejecuta el siguiente comando para extraer el paquete a un directorio temporal:

tar -xvzf /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz -C [TEMP_DIR]

Revisa los archivos YAML extraídos para tener una idea general del contenido del paquete.

En particular, abre gke-onprem-vsphere-[VERSION]-images.yaml. Observa el campo osimages. Puedes ver la versión de la plataforma de GKE en el nombre del archivo de imagen del SO. Por ejemplo, en la siguiente imagen de SO, puedes ver que la versión de la plataforma de GKE es 1.12.7-gke.19.

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

Modifica el archivo de configuración

En tu VM de la estación de trabajo de administrador, edita el archivo de configuración. Configura los valores de gkeplatformversion y bundlepath. Por ejemplo:

gkeplatformversion: 1.12.7-gke.19
bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-1.0.10.tgz

Cómo ejecutar gkectl prepare

Ejecuta el siguiente comando:

gkectl prepare --config [CONFIG_FILE]

El comando gkectl prepare realiza las siguientes tareas:

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

• Envía imágenes de Docker actualizadas, especificadas en el conjunto nuevo, a tu registro privado de Docker, si configuraste una.

Actualiza tus clústeres

Para actualizar un clúster de usuario, tu clúster de administrador debe tener una versión igual o superior a la de la versión de destino de la actualización del clúster de usuario. Si la versión de tu clúster de administrador es inferior, deberás actualizarlo antes que al clúster de usuario.

Clúster del administrador

Ejecuta el siguiente comando:

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

En el ejemplo anterior, [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster del administrador y [CONFIG_FILE] es el archivo de configuración GKE On-Prem que usas para realizar la actualización.

Clúster de usuario

Ejecuta el siguiente comando:

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME]

En el ejemplo anterior, [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de administrador, [CLUSTER_NAME] es el nombre del clúster de usuario que actualizas y [CONFIG_FILE] es el archivo de configuración GKE On-Prem que usas para realizar la actualización.

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. Nota: Si los nodos del clúster de usuario no pueden acceder al plano de control de usuario durante la actualización, las cargas de trabajo nuevas no estarán programadas en el clúster. Las cargas de trabajo existentes no se verán afectadas.
Nodos del clúster de usuario	Si una actualización requiere un cambio en los nodos del clúster de usuario, GKE On-Prem los vuelve a crear 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.

Problemas conocidos

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

Soluciona problemas

Para obtener más información, consulta Soluciona problemas.

Se crearon nodos nuevos, pero no en buen estado

Síntomas

Los nodos nuevos no se registran en el plano de control del clúster de usuario cuando usan el modo de balanceo de cargas manual.

Causas posibles

Es posible que la validación de Ingress en nodos esté habilitada y que bloquee el proceso de inicio de los nodos.

Solución

Para inhabilitar la validación, ejecuta este comando:

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

Diagnostica problemas de clústeres mediante gkectl

Usa los comandos gkectl diagnose para identificar los problemas de clústeres y compartir la información de un clúster con Google. Consulta Diagnostica problemas de clústeres.

Comportamiento de registro predeterminado

Para gkectl y gkeadm, basta con usar la configuración de registro predeterminada:

• De forma predeterminada, las entradas de registro se guardan de la siguiente manera:

  • Para gkectl, el archivo de registro predeterminado es /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log y el archivo está vinculado con un symlink con el archivo logs/gkectl-$(date).log en el directorio local en el que ejecutas gkectl.
  • Para gkeadm, el archivo de registro predeterminado es logs/gkeadm-$(date).log en el directorio local en el que ejecutas gkeadm.
• Todas las entradas de registro se guardan en el archivo de registro, incluso si no se imprimen en la terminal (cuando --alsologtostderr es false).
• El nivel de verbosidad -v5 (predeterminado) cubre todas las entradas de registro que necesita el equipo de asistencia al cliente.
• El archivo de registro también contiene el comando ejecutado y el mensaje de error.

Recomendamos que envíes el archivo de registro al equipo de asistencia al cliente cuando necesites ayuda.

Especifica una ubicación no predeterminada para el archivo de registro

A fin de especificar una ubicación no predeterminada para el archivo de registro gkectl, usa la marca --log_file. El archivo de registro que especifiques no se vinculará con un symlink con el directorio local.

A fin de especificar una ubicación no predeterminada para el archivo de registro gkeadm, usa la marca --log_file.

Ubica los registros de la API de clúster en el clúster de administrador

Si una VM no se inicia después de que se inicia el plano de control de administrador, puedes intentar depurarla mediante la inspección de los registros de los controladores de la API de clúster en el clúster de administrador:

1. Encuentra el nombre del Pod de controladores de la API de clúster en el espacio de nombres kube-system, en el que [ADMIN_CLUSTER_KUBECONFIG] es la ruta de acceso al archivo kubeconfig del clúster de administrador:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

2. Abre los registros del Pod, en los que [POD_NAME] es el nombre del Pod. De manera opcional, usa grep o una herramienta similar para buscar errores:

   kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager