Soluciona problemas relacionados con la creación o actualización de clústeres

En esta página, se muestra cómo investigar problemas con la creación y actualización de clústeres en GKE on VMware.

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Problemas de instalación

Las siguientes secciones pueden ayudarte a solucionar problemas con la instalación de GKE en VMware.

Usa el clúster de arranque para depurar problemas

Durante la instalación, GKE on VMware crea un clúster de arranque temporal. Después de una instalación exitosa, GKE en VMware borra el clúster de arranque, lo que te deja el clúster de administrador y el de usuario. Por lo general, no deberías tener motivos para interactuar con el clúster de arranque. Sin embargo, si tienes problemas durante la instalación, puedes usar los registros del clúster de arranque para ayudarte a depurarlos.

Si pasas --cleanup-external-cluster=false a gkectl create cluster, el clúster de arranque no se borra y puedes usar el clúster de arranque para depurar problemas de instalación.

Examina los registros del clúster de arranque

Busca los nombres de Pods que se ejecutan en el espacio de nombres kube-system:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

Visualiza los registros de un Pod:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME

Reemplaza POD_NAME por el nombre del Pod que deseas ver.

Para obtener los registros del clúster de arranque directamente, ejecuta el siguiente comando durante la creación del clúster y la actualización:
```
docker exec -it gkectl-control-plane bash
```
Con este comando, se abre una terminal dentro del contenedor gkectl-control-plane que se ejecuta en el clúster de arranque.

Para inspeccionar los registros kubelet y containerd, usa los siguientes comandos y busca errores o advertencias en el resultado:

systemctl status -l kubelet
journalctl --utc -u kubelet
systemctl status -l containerd
journalctl --utc -u containerd

Examina la instantánea del clúster de arranque

Si intentas crear o actualizar un clúster de administrador y esa operación falla, GKE en VMware toma una instantánea externa del clúster de arranque. Esta instantánea del clúster de arranque es similar a la instantánea que se toma cuando se ejecuta el comando gkectl diagnose snapshot en el clúster de administrador, pero el proceso se activa de forma automática. La instantánea del clúster de arranque contiene información de depuración importante para el proceso de creación y actualización del clúster de administrador. Puedes proporcionar esta instantánea a Atención al cliente de Cloud si es necesario.

La instantánea externa incluye registros de Pods de onprem-admin-cluster-controller que puedes ver para depurar la creación de clústeres o los problemas de actualización. Los registros se almacenan en un archivo separado, por ejemplo:

kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_ \
    --container_onprem-admin-cluster-controller_ \
    --kubeconfig_.home.ubuntu..kube.kind-config-gkectl_\
    --namespace_kube-system

La VM no se inicia después de que se inicia el plano de control del administrador

Si una VM no se inicia después de que se inicia el plano de control de administrador, puedes investigar el problema si inspeccionas los registros del Pod de los controladores de la API de clúster en el clúster de administrador:

Busca el nombre del Pod de controladores de la API de clúster:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    get pods | grep clusterapi-controllers

Ver registros de vsphere-controller-manager. Primero, especifica el Pod, pero no el contenedor:
```
kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME
```
El resultado te indica que debes especificar un contenedor y que proporciona los nombres de los contenedores en el Pod. Por ejemplo:
```
... a container name must be specified ...,
choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]
```

Elige un contenedor y consulta sus registros:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME --container CONTAINER_NAME

Hay una cantidad suficiente de direcciones IP asignadas, pero la máquina no se registra con el clúster

Este problema puede ocurrir si hay un conflicto de direcciones IP. Por ejemplo, se usa una dirección IP que especificaste para una máquina en un balanceador de cargas.

A fin de resolver este problema, actualiza el archivo de bloqueo de IP del clúster para que las direcciones de la máquina no entren en conflicto con las direcciones especificadas en el archivo de configuración del clúster o en el archivo de bloqueo de IP de Seesaw.

Problemas de actualización del clúster

En las siguientes secciones, se proporcionan sugerencias para resolver problemas que podrían surgir durante una actualización de un clúster.

Revierte un grupo de nodos después de una actualización

Si actualizas un clúster de usuario y, luego, descubres un problema con los nodos del clúster, puedes revertir los grupos de nodos seleccionados a la versión anterior.

La reversión de grupos de nodos seleccionados es compatible con los grupos de nodos de Ubuntu y COS, pero no con los de Windows.

La versión de un grupo de nodos puede ser igual o inferior a la versión del plano de control del clúster de usuario. Por ejemplo, si el plano de control está en la versión 1.14, los grupos de nodos pueden estar en la versión 1.14 o 1.13.

Ver las versiones de grupos de nodos disponibles

Supongamos que hace poco actualizaste el plano de control y los nodos del clúster de usuario de la versión 1.13.1-gke.35 a la 1.14.0 y descubres un problema con los nodos trabajadores actualizados. Por lo tanto, decides revertir uno o más grupos de nodos a la versión que estabas ejecutando antes: 1.13.1-gke.35. Antes de comenzar la reversión, debes verificar que la versión anterior esté disponible para ella.

Para ver las versiones disponibles, ejecuta el siguiente comando:

gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

El resultado muestra la versión actual y la anterior de cada grupo de nodos. Por ejemplo:

user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Revierte la versión del grupo de nodos

Puedes revertir la versión de un grupo de nodos de a un grupo de nodos a la vez o varios grupos de nodos en un solo paso.

Para revertir la versión de un grupo de nodos, completa los siguientes pasos:

En el archivo de configuración del clúster de usuario, en uno o más grupos de nodos, establece el valor de gkeOnPremVersion como la versión anterior. En el siguiente ejemplo, se muestra cómo revertir a la versión 1.13.1-gke.35:
```
nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: 1.13.1-gke.35
  ...
```

Actualiza el clúster para revertir los grupos de nodos:

gkectl update cluster --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Verifica si la reversión se realizó de forma correcta:

gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

En el siguiente resultado, se muestra que pool-1 se revirtió a la versión 1.13.1-gke.35.

user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.13.1-gke.35
  - previous version: 1.14.0-gke.x
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Cómo actualizar a una versión de parche nueva

Puedes actualizar todos los grupos de nodos y el plano de control a una versión del parche nueva. Esto podría ser útil si revirtiste a una versión anterior y deseas actualizar a una versión que incluya una solución.

Para actualizar a una nueva versión, completa los siguientes pasos:

Realiza los siguientes cambios en el archivo de configuración del clúster de usuario:
1. Establece el valor de gkeOnPremVersion en una versión del parche nueva. En este ejemplo, se usa 1.14.1-gke.x.
2. Para cada grupo de nodos, quita el campo gkeOnPremVersion o configúralo como la string vacía. Cuando no se especifica ninguna versión para un grupo de nodos, la versión del grupo de nodos se establece de forma predeterminada en la versión especificada para el clúster.
  
  Estos cambios son similares al siguiente ejemplo:
```
gkeOnPremVersion: 1.14.1-gke.x

nodePools:
-   name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: ""
-   name: pool-2
  cpus: 8
  memoryMB: 8192
  replicas: 2
  gkeOnPremVersion: ""
```
Ejecuta gkectl prepare y gkectl upgrade cluster como se describe en Actualiza GKE en VMware.

Verifica la versión nueva del clúster y observa las versiones que están disponibles para la reversión:

gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

El resultado es similar al siguiente:

 user cluster version: 1.14.1-gke.y

 node pools:
 - pool-1:
   - version: 1.14.1-gke.y
   - previous version: 1.13.1-gke.35
 - pool-2:
   - version: 1.14.1-gke.y
   - previous version: 1.13.1-gke.35

 available node pool versions:
 - 1.13.1-gke.35
 - 1.14.0-gke.x
 - 1.14.1-gke.y
 ```

Las verificaciones de estado se ejecutan de forma automática cuando falla la actualización del clúster

Si intentas actualizar un clúster de administrador o de usuario y esa operación falla, GKE en VMware ejecuta de forma automática el comando gkectl diagnose cluster en el clúster.

Para omitir el diagnóstico automático, pasa la marca --skip-diagnose-cluster a gkectl upgrade.

El proceso de actualización se atasca

En segundo plano, GKE on VMware usa el comando drain de Kubernetes durante una actualización. Un Deployment puede bloquear este procedimiento drain con una sola réplica que tenga un PodDisruptionBudget (PDB) creado con minAvailable: 1.

Desde la versión 1.13 de GKE on VMware, puedes verificar las fallas a través de los eventos de Pod de Kubernetes.

Busca los nombres de las máquinas:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

Verifica si hay errores con el comando kubectl describe machine:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

El resultado es similar al siguiente:

Events:
  Type     Reason              Age    From                Message
  ----     ------              ----   ----                -------
  Warning  PodEvictionTooLong  3m49s  machine-controller  Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.

Opcional: Para obtener un análisis más detallado del estado de los objetos de máquina, ejecuta gkectl diagnose cluster.

El resultado es similar al siguiente:

...
Checking machineset...SUCCESS
Checking machine objects...FAILURE
    Reason: 1 machine objects error(s).
    Unhealthy Resources:
    Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB.
...
Checking all poddisruptionbudgets...FAILURE
    Reason: 1 pod disruption budget error(s).
    Unhealthy Resources:
    PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3).
...
Some validation results were FAILURE or UNKNOWN. Check report above.

Para resolver este problema, guarda el PDB y quítalo del clúster antes de intentar la actualización. Luego, puedes volver a agregar el PDB después de que se complete la actualización.

Quita los cambios no admitidos para desbloquear la actualización

Cuando actualizas clústeres a la versión 1.16 o a versiones anteriores, los cambios en la mayoría de los campos se ignoran en silencio durante la actualización, lo que significa que estos cambios no se aplican durante ni después de la actualización.

Cuando actualizas los clústeres de usuario a la versión 1.28 o a versiones posteriores, validamos todos los cambios realizados en el archivo de configuración y mostramos un error para los cambios no compatibles, en lugar de solo ignorarlos. Esta función solo está disponible para clústeres de usuario. Cuando actualizas clústeres de administrador, los cambios en la mayoría de los campos se ignoran en silencio y no surtirán efecto después de la actualización.

Por ejemplo, si intentas inhabilitar la reparación automática de nodos cuando actualizas un clúster de usuario a la versión 1.28, la actualización falla y muestra el siguiente mensaje de error:

failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
   v1alpha1.OnPremUserClusterSpec{
    ... // 20 identical fields
    UsageMetering:         nil,
    CloudAuditLogging:     &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
-   AutoRepair:            &v1alpha1.AutoRepairConfig{Enabled: true},
+   AutoRepair:            &v1alpha1.AutoRepairConfig{},
    CARotation:            &{Generated: &{CAVersion: 1}},
    KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
    ... // 8 identical fields
  }

Si necesitas omitir este error, existen las siguientes soluciones alternativas:

Revierte el cambio que intentaste modificar y, luego, vuelve a ejecutar la actualización. Por ejemplo, en el caso anterior, revertirías los cambios realizados a la configuración de AutoRepair y, luego, volverías a ejecutar gkectl upgrade.
Como alternativa, puedes generar archivos de configuración que coincidan con el estado actual del clúster si ejecutas gkectl get-config, actualiza los campos gkeOnPremVersion del clúster y los grupos de nodos en el archivo de configuración y, luego, vuelve a ejecutar gkectl upgrade.

Depura los problemas de BIG-IP de F5 con el archivo kubeconfig interno

Después de una instalación, GKE en VMware genera un archivo kubeconfig llamado internal-cluster-kubeconfig-debug en el directorio principal de la estación de trabajo de administrador. Este archivo kubeconfig es idéntico a tu archivo kubeconfig del clúster de administrador, excepto que apunta directamente al nodo del plano de control del clúster de administrador, en el que se ejecuta el servidor de API de Kubernetes. Puedes usar el archivo internal-cluster-kubeconfig-debug para depurar los problemas de BIG-IP de F5.

Depura problemas con vSphere

Puedes usar govc para investigar problemas con vSphere. Por ejemplo, puedes confirmar los permisos y el acceso de tus cuentas de usuario de vCenter y puedes recopilar registros de vSphere.

Vuelve a crear el archivo kubeconfig del clúster de usuario faltante

Es posible que desees volver a crear un archivo kubeconfig de clúster de usuario en las siguientes situaciones:

Si intentas crear un clúster de usuario y la operación de creación falla, y deseas tener el archivo kubeconfig del clúster de usuario.
Si falta el archivo kubeconfig del clúster de usuario, por ejemplo, después de borrarlo.

Ejecuta el siguiente comando para volver a crear el archivo kubeconfig del clúster de usuario:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n admin \
  -o jsonpath='{.data.admin\.conf}' | base64 -d  > USER_CLUSTER_KUBECONFIG

Reemplaza lo siguiente:

USER_CLUSTER_KUBECONFIG: Es el nombre del archivo kubeconfig nuevo para el clúster de usuario.
ADMIN_CLUSTER_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.