Versión 1.1. Esta versión ya no es compatible como se describe en la política de compatibilidad de versiones de Anthos. Para obtener los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a clústeres de Anthos alojados en VMware (GKE On-Prem), actualiza a una versión compatible. Puedes encontrar la versión más reciente aquí.

Versiones disponibles

Actualiza GKE On-Prem

En este tema, se explica cómo actualizar GKE On-Prem.

Para actualizar GKE On-Prem, debes actualizar tu estación de trabajo de administrador. Luego, actualiza tus clústeres.

Antes de comenzar

Asegúrate de seguir estas instrucciones desde tu estación de trabajo o laptop local. No sigas estas instrucciones desde la estación de trabajo de administrador existente.
Verifica la versión actual de los clústeres.
Revisa las notas de la versión.
Revisa las versiones

Además, lee las siguientes consideraciones:

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

Actualización secuencial

GKE On-Prem admite la actualización secuencial. Para actualizar un clúster a una versión nueva, este ya debe estar en la versión anterior más reciente.

No puedes actualizar tus clústeres de forma directa a la versión más reciente desde una versión con más de una versión anterior. Si tu clúster tiene más de una versión anterior, debes actualizarlo de forma secuencial.

Ejemplo

Supongamos que las siguientes versiones están disponibles. Además, supongamos que tu estación de trabajo de administrador y tus clústeres ejecutan la versión más antigua:

1.0.1 (versión más antigua)
1.0.2
1.1 (versión más reciente)

En este caso, 1.1 es la versión más reciente. Para actualizar de 1.0.1 a 1.1, sigue estos pasos:

Actualiza la estación de trabajo de administrador de 1.0.1 a 1.0.2.
Actualiza los clústeres de 1.0.1 a 1.0.2.
Actualiza la estación de trabajo de administrador de 1.0.2 a 1.1.
Actualiza los clústeres de 1.0.2 a 1.1.

Crea una copia de seguridad de tu archivo de configuración de GKE On-Prem y de tus archivos de kubeconfig

Cuando actualizas la estación de trabajo de administrador, Terraform borra la VM de la estación de trabajo de administrador y la reemplaza por una actualizada. Antes de actualizar tu estación de trabajo de administrador, debes crear una copia de seguridad del archivo de configuración de GKE On-Prem y de los archivos kubeconfig de tus clústeres. Luego, copia los archivos en tu estación de trabajo de administrador actualizada.

Actualizar la estación de trabajo de administrador

Cuando actualizas tu estación de trabajo de administrador, incluye las siguientes entidades en la misma versión que el archivo Open Virtualization Appliance (OVA) de la estación de trabajo de administrador:

gkectl
paquete completo

Después de actualizar la estación de trabajo de administrador, debes actualizar los clústeres.

Descarga el archivo OVA

En Descargas, descarga el archivo OVA de la estación de trabajo de administrador para la versión a la que actualizas.

Para descargar el archivo OVA más reciente, ejecuta el siguiente comando:

gsutil cp gs://gke-on-prem-release/admin-appliance/1.1.2-gke.0/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.{ova,ova.sig} ~/

Importa el archivo OVA a vSphere y márcalo como una plantilla de VM

En las siguientes secciones, harás lo siguiente:

Crear algunas variables que declaren elementos de vCenter Server y del entorno de vSphere
Importar el OVA de la estación de trabajo de administrador a vSphere y marcarlo como una plantilla de VM

Crea variables para `govc`

Antes de importar el OVA de la estación de trabajo de administrador a vSphere, debes proporcionar a govc algunas variables que declaren los elementos de vCenter Server y el entorno de vSphere:

export GOVC_URL=https://[VCENTER_SERVER_ADDRESS]/sdk
export GOVC_USERNAME=[VCENTER_SERVER_USERNAME]
export GOVC_PASSWORD=[VCENTER_SERVER_PASSWORD]
export GOVC_DATASTORE=[VSPHERE_DATASTORE]
export GOVC_DATACENTER=[VSPHERE_DATACENTER]
export GOVC_INSECURE=true

Puedes elegir usar el grupo de recursos predeterminado de vSphere o crear el tuyo:

# If you want to use a resource pool you've configured yourself, export this variable:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources/[VSPHERE_RESOURCE_POOL]

# If you want to use vSphere's default resource pool, export this variable instead:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources

Donde:

[VCENTER_SERVER_ADDRESS] es la dirección IP o el nombre de host de vCenter Server.
[VCENTER_SERVER_USERNAME] es el nombre de usuario de una cuenta que contiene la función de administrador o privilegios equivalentes en vCenter Server.
[VCENTER_SERVER_PASSWORD] es la contraseña de la cuenta de vCenter Server.
[VSPHERE_DATASTORE] es el nombre del almacén de datos que configuraste en el entorno de vSphere.
[VSPHERE_DATACENTER] es el nombre del centro de datos que configuraste en el entorno de vSphere.
[VSPHERE_CLUSTER] es el nombre del clúster que configuraste en el entorno de vSphere.
[VSPHERE_RESOURCE_POOL] es el nombre del grupo de recursos que configuraste en el entorno de vSphere.

Importa el OVA a vSphere: Interruptor estándar

Si usas un interruptor estándar vSphere, importa el archivo OVA a vSphere mediante este comando:

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true
}
EOF

Importa el archivo OVA a vSphere: Interruptor distribuido

Si usas un interruptor distribuido vSphere, importa el OVA a vSphere mediante este comando, en el que [YOUR_DISTRIBUTED_PORT_GROUP_NAME] es el nombre del grupo de puertos distribuido:

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true,
  "NetworkMapping": [
      {
          "Name": "VM Network",
          "Network": "[YOUR_DISTRIBUTED_PORT_GROUP_NAME]"
      }
  ]
}
EOF

Configura la variable de plantilla de Terraform para la VM de la nueva estación de trabajo de administrador

En el archivo TFVARS de la estación de trabajo de administrador, configura vm_template a la versión a la que actualizas. El valor de vm_template se ve de la siguiente manera, en la que [VERSION] es la versión del archivo OVA:

gke-on-prem-admin-appliance-vsphere-[VERSION]

Usa Terraform para actualizar la estación de trabajo de administrador

Para actualizar la estación de trabajo de administrador, ejecuta el siguiente comando. Este comando borra la VM de la estación de trabajo de administrador actual y la reemplaza por una VM actualizada:

terraform init && terraform apply -auto-approve -input=false

Conéctate a tu estación de trabajo de administrador

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]
```
Si usas un proxy, debes configurar Google Cloud CLI para este, de forma que puedas ejecutar los comandos de gcloud y gsutil. Si deseas obtener instrucciones, consulta Configura la CLI de gcloud para usarla detrás de un proxy o firewall.
Accede a Google Cloud con las credenciales de tu cuenta:
```
gcloud auth login
```
Registra gcloud como auxiliar de credenciales de Docker. (Obtén más información sobre este comando):
```
gcloud auth configure-docker
```
Crea una clave privada para tu cuenta de servicio incluida en la lista de anunciantes permitidos.

Copia la dirección de correo electrónico de la cuenta de servicio:
```
gcloud iam service-accounts list
```
Crea la clave privada de la cuenta de servicio, en la que [KEY_FILE] es el nombre que eliges para el archivo. Este comando guarda el archivo en el directorio de trabajo actual:
```
gcloud iam service-accounts keys create key.json \
--project [PROJECT_ID] --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]
```
Donde:
- [PROJECT_ID] es el ID del proyecto.
- [KEY_FILE] es un nombre y una ruta en la que se guarda la clave privada de la cuenta de servicio, como /home/ubuntu/key.json.
- [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] es la dirección de correo electrónico de la cuenta de servicio que se incluye en la lista de anunciantes permitidos.

Activa tu cuenta de servicio incluida en la lista de anunciantes permitidos:

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

Copia la configuración de copia de seguridad y los archivos de kubeconfig

Antes, creaste una copia de seguridad de tu archivo de configuración de GKE On-Prem y de los archivos kubeconfig de tus clústeres. Ahora, debes volver a copiar esos archivos a tu estación de trabajo de administrador actualizada.

Actualiza clústeres

Después de actualizar la estación de trabajo de administrador y conectarte a ella, sigue estos pasos:

Verifica que haya suficientes direcciones IP disponibles

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

DHCP

Si el clúster tiene sus direcciones IP asignadas por un servidor de DHCP, verifica que el servidor de DHCP de la red en la que se crean los nodos tenga suficientes direcciones IP. Debe haber más direcciones IP que nodos en ejecución en el clúster de usuarios.

IP estáticas

Si el clúster tiene direcciones IP estáticas, verifica que hayas asignado suficientes direcciones IP en el clúster:

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

Donde:

[ADMIN_CLUSTER_KUBECONFIG] le indica a kubectl que use el kubeconfig del clúster de administrador, que se usa para ver o cambiar la configuración del clúster de usuario.
-n [USER_CLUSTER_NAME] le indica a kubectl que busque en un espacio de nombres con el mismo nombre del clúster de usuario.
[USER_CLUSTER_NAME] -o yaml le indica a kubectl en qué clúster de usuario se ejecuta el comando. -o yaml muestra la configuración del clúster de usuario.

En el resultado del comando, busca el campo reservedAddresses. Debe haber más direcciones IP en el campo que nodos en ejecución en el clúster de usuario.

Si necesitas agregar más direcciones al campo reservedAddresses, realiza los siguientes pasos:

Abre el archivo de configuración del clúster de usuarios para editarlo:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \
-n [USER_CLUSTER_NAME] --validate=false
```
La configuración del clúster se abre en el editor predeterminado de tu shell.
Agrega tantos bloques de IP estáticos adicionales como sea necesario. Un bloque de IP se compone de los campos gateway, hostname, ip y netmask.

Nota: Siempre es seguro agregar más bloques de IP al campo reservedAddresses, pero no es seguro quitar las direcciones IP que están en uso.

A continuación, se muestra un campo reservedAddresses de ejemplo con sus cuatro bloques de IP estáticos resaltados:

...
networkSpec:
  dns:
  - 172.x.x.x
  ntp: 129.x.x.x
  reservedAddresses:
  - gateway: 100.x.x.x
    hostname: host-1
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-2
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-3
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-4
    ip: 100.x.x.x
    netmask: x
...

Modifica el archivo de configuración

En tu VM de la estación de trabajo de administrador, edita el archivo de configuración. Configura el valor de bundlepath, en el que [VERSION] es la versión de GKE On-Prem en la que actualizas tus clústeres:

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

Información sobre las funciones habilitadas de forma automática

Una versión nueva de GKE On-Prem puede incluir funciones nuevas o compatibilidad con características específicas de VMware vSphere. A veces, la actualización a una versión de GKE On-Prem habilita automáticamente esas funciones. Aprenderás sobre las nuevas funciones 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.

Inhabilita las características nuevas a través del archivo de configuración

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

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]
```
Abre el archivo de configuración nuevo y el campo de la función. Cierra el archivo.
Abre el archivo de configuración actual y agrega el campo de la función nueva en la especificación correspondiente.
Proporciona un valor false o equivalente para el campo.
Guarda el archivo de configuración. Continúa con la actualización de los clústeres.

Siempre debes revisar 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.

Ejecución de `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 tu clúster de 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.

Actualiza el clúster de usuario

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.

gkectl

Desde tu estación de trabajo de administrador, 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.

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 GKE On-Prem registrados y los clústeres de Google Kubernetes Engine desde el menú de GKE de la consola de Google Cloud.

Cuando haya una actualización disponible para los clústeres de usuario de GKE On-Prem, aparecerá una notificación en Google 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:

Visita el menú de GKE en la consola de Google Cloud.

Visitar el menú de GKE On-Prem
En la columna Notificaciones del clúster de usuario, haz clic en Actualización disponible, si está disponible.
Copia el comando gkectl upgrade cluster.
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, [CLUSTER_NAME] es el nombre del clúster de usuario que actualizas y [CONFIG_FILE] es el archivo de configuración de GKE On-Prem que usas para realizar la actualización.

Reanuda una actualización

Si la actualización de un clúster de usuario se interrumpe, pero el clúster de administrador se actualizó correctamente, puedes reanudar la actualización si vuelves a ejecutar gkectl upgrade cluster con el mismo archivo de configuración de GKE On-Prem y kubeconfig el clúster de administrador.

Acerca de cómo reanudar una actualización de clúster de administrador

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

Problemas conocidos

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

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.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. En este momento, un problema conocido requiere que proporciones la ruta de identificador único universal (UUID) de la carpeta, en lugar de su ruta de archivo, a vcenter.datadisk. Esta falta de coincidencia puede hacer que las actualizaciones fallen.

Una corrección está dirigida a la versión 1.1.2. Antes de realizar la actualización, realiza estos pasos en el nodo del plano de control del administrador como una solución alternativa:

Desde la interfaz de vCenter, obtén el UUID de la carpeta en tu almacén de datos de vSAN.
Enumera los recursos de máquina en tus clústeres. Estas máquinas corresponden a los nodos de los clústeres:
```
kubectl get machines -n all
```
En la máquina del plano de control de administrador (gke-admin-master), abre su configuración para editarla:
```
kubectl edit machine [MACHINE_NAME]
```

Cambia el campo spec.providerSpec.value.machineVariables.data_disk_path. Reemplaza la ruta de acceso al archivo VMDK por el UUID. Por ejemplo:

spec:
providerSpec:
 value:
   apiVersion: vsphereproviderconfig.k8s.io/v1alpha1
   kind: VsphereMachineProviderConfig
   machineVariables:
     data_disk_path: 14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk
     datacenter: datacenter
     datastore: datastore

Guarde el archivo.
Abre el archivo de configuración de GKE On-Prem.
En vcenter.datadisk, reemplaza la carpeta de la ruta del archivo por el UUID de la carpeta. Por ejemplo:
```
vcenter:
 ...
 datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
```
Continúa con la actualización de tus clústeres.

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 la 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 la consola de Google Cloud:

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 la consola de Google Cloud. A fin de usar OIDC, es posible que debas proporcionar un valor de marcador de posición para clientsecret:

oidc:
  clientsecret: "secret"

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 automáticamente reglas de antiafinidad del Programador de recursos distribuidos (DRS) de VMware para los nodos del clúster de usuarios, lo que hace que se distribuyan en al menos tres hosts físicos de tu centro de datos. A partir de la versión 1.1.0-gke.6, esta característica se habilita automáticamente 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.

Inhabilita DRS de VMware antes de actualizar a 1.1.0-gke.6

Si no deseas habilitar esta característica para tus clústeres de usuarios existentes, por ejemplo, si no tienes suficientes hosts que admitan la característica, realiza los siguientes pasos antes de actualizar tus clústeres de usuario:

Abre tu archivo de configuración de GKE On-Prem existente.
En la especificación usercluster, agrega el campo antiaffinitygroups como se describe en la documentación de antiaffinitygroups:
```
usercluster:
      ...
      antiaffinitygroups:
        enabled: false
```
Guarde el archivo.
Usa el archivo de configuración para actualizar. Tus clústeres están actualizados, pero la función no está habilitada.

Situación de actualización alternativa

En este tema, se describe la forma más sencilla de actualizar GKE On-Prem. En la siguiente tabla, se describe una situación de actualización alternativa. En este caso, solo actualizarías gkectl y los clústeres, y no actualizarías la estación de trabajo de administrador:

Situación	Pasos
La versión no tiene actualizaciones de seguridad para la estación de trabajo de administrador.	Descarga `gkectl`. Descarga el paquete. Sigue las instrucciones de esta página.

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:

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
```
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
```