Actualiza GKE On-Prem

En esta página, se explica cómo actualizar GKE On-Prem.

Versiones de destino

A partir de la versión 1.3.2 de GKE On-Prem, puedes actualizar de forma directa 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 la versión 1.3.2 a la 1.4.0. Cuando 1.4.1 esté disponible, podrás actualizar directamente de 1.3.2 a 1.4.1.

En la siguiente tabla, se muestra las posibles actualizaciones directas:

Versión actual1.4.01.4.11.4.2
1.3.2
1.4.0
1.4.1

Si tu versión actual es anterior a la 1.3.2, debes realizar actualizaciones secuenciales. Por ejemplo, si deseas actualizar de 1.2.0 a 1.2.2, primero debes actualizar de 1.2.0 a 1.2.1 y, luego, de 1.2.1 a 1.2.2.

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 tu estación de trabajo de administrador, actualiza tus clústeres de usuario.

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

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

Para descargar gkeadm, haz lo siguiente:

gsutil cp gs://gke-on-prem-release-public/gkeadm/[VERSION]/linux/gkeadm ./
chmod +x gkeadm

En el ejemplo anterior, [VERSION] es la versión de destino de la actualización. Por ejemplo, 1.5.0-gke.27.

Para actualizar la estación de trabajo del administrador, haz lo siguiente:

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 GKE On-Prem. 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 incluida en la lista de anunciantes permitidos. 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.

Quita la estación de trabajo del administrador anterior de known_hosts

Si la estación de trabajo del administrador tiene una dirección IP estática, debes quitar la estación de trabajo del administrador anterior del archivo known_hosts después de actualizar la estación de trabajo del administrador.

Para quitar la estación de trabajo del administrador anterior de known_hosts, haz lo siguiente:

ssh-keygen -R [ADMIN_WS_IP]

donde [ADMIN_WS_IP] es la dirección IP de tu estación de trabajo de administrador.

Configura la ruta del paquete en tu archivo de configuración de GKE On-Prem

En la nueva estación de trabajo del administrador, abre el archivo de configuración de GKE On-Prem. Configura el valor de bundlepath como la ruta del archivo de paquete en la nueva estación de trabajo del administrador:

bundlepath: "/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz"

En el ejemplo anterior, [VERSION] es la versión de destino de la actualización.

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 [CONFIG_FILE] [FLAGS]

Donde:

  • [CONFIG_FILE] es el archivo de configuración de GKE On-Prem en tu nueva estación de trabajo de administración.

  • [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

Durante una actualización, GKE On-Prem crea un nodo temporal en el clúster de administrador y en cada clúster de usuario asociado. Asegúrate de que el servidor DHCP pueda proporcionar suficientes direcciones IP para estos nodos temporales. Si deseas obtener más información, consulta Direcciones IP necesarias para clústeres de administrador y de usuario.

IP estáticas

Durante una actualización, GKE On-Prem crea un nodo temporal en el clúster de administrador y en cada clúster de usuario asociado. Para el clúster de administrador y cada uno de los clústeres de usuario, verifica que hayas reservado suficientes direcciones IP. Para cada clúster, debes haber reservado 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.

Importante: A partir de 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 de las más en el clúster de usuarios. Si este no es el caso, puedes abrir el archivo host del clúster del 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 tantas direcciones IP estáticas adicionales al bloque correspondiente como sea necesario y, luego, ejecuta el clúster de actualización de gkectl.

Inhabilita las funciones de vSphere nuevas (opcional)

Una versión nueva de GKE On-Prem puede incluir funciones nuevas o compatibilidad con funciones específicas de VMware vSphere. A veces, la actualización a una versión de GKE On-Prem habilita de forma automática esas funciones. Aprenderás sobre las funciones nuevas en las notas de la versión de GKE On-Prem. A veces, las funciones nuevas se muestran en el archivo de configuración de GKE on-prem.

Si necesitas inhabilitar una función nueva que se habilita automáticamente en una versiónde GKE on-prem nueva y que controla el archivo de configuración, realiza los siguientes pasos antes de actualizar tu clúster:

  1. Desde tu estación de trabajo de administrador actualizada, crea un archivo de configuración nuevo con un nombre diferente al de tu 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 tu 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 [CONFIG_FILE] \
[FLAGS]

En el ejemplo anterior, se ilustra lo siguiente:

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

  • [CONFIG_FILE] es el archivo de configuración de GKE On-Prem en tu nueva estación de trabajo de administración.

  • [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 [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME] \
[FLAGS]

Donde:

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

  • [CLUSTER_NAME] es el nombre del clúster de usuario que estás actualizando.

  • [CONFIG_FILE] es el archivo de configuración de GKE On-Prem en tu nueva estación de trabajo de administración.

  • [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 o acceder a los clústeres de GKE On-Prem registrados y los 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 GKE On-Prem, 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 la estación de trabajo del administrador, ejecuta el comando gkectl upgrade cluster, en el que [ADMIN_CLUSTER_KUBECONFIG] es el archivo kubeconfig del clúster de administrador, [CLUSTER_NAME] es el nombre del clúster de usuarios que estás actualizando y [CONFIG_FILE] es el archivo de configuración de GKE On-Prem en la nueva estación de trabajo del administrador.

Reanuda una actualización

Si la actualización de un clúster de usuario se interrumpe después de que el clúster de administrador se actualiza de forma correcta, puedes reanudar la actualización del clúster de usuario si ejecutas el mismo comando de actualización con el marcador --skip-validation-all:

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [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.

Problemas comunes

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

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 GKE On-Prem 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 GKE On-Prem.

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 GKE On-Prem.

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 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 falta de coincidencia puede hacer que las actualizaciones fallen.

Para obtener instrucciones, consulta las notas de la versión de GKE On-Prem.

Actualización a la versión 1.1.0-gke.6 desde la versión 1.0.2-gke.3: problema 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) configurados 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. Para 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 la malla de servicios de Anthos instalada o OSS Istio instalada en tu clúster, según la configuración de PodDisruptionBudget para los componentes de Istio, es posible que los nodos del usuario no actualicen su versión 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 del Pod 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 Anthos Service Mesh 1.4.x o OSS Istio 1.4.x:

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, GKE On-Prem crea de forma automática reglas de antiafinidad de Distributed Resource Scheduler (DRS) de VMware para los nodos del clúster de usuario, de modo que se distribuyen en al menos tres hosts físicos de tu 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 DRS, consulta Habilita DRS de VMware en un clúster.
  • La cuenta de usuario de vSphere proporcionada en el campo vcenter tiene el permiso Host.Inventory.EditCluster.
  • Hay al menos tres hosts físicos disponibles.

Si el entorno de vSphere no cumple con las condiciones anteriores, aún puedes realizar la actualización. Pero para actualizar un clúster de usuario de 1.3.x a 1.4.x, debes inhabilitar los grupos antiafinidad. Para obtener más información, consulta este problema conocido en las notas de la versión de GKE On-Prem.

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, 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 mediante la configuración de los PodDisruptionBudgets y las reglas antiafinidad adecuadas.

Soluciona problemas

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

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