Solucionar problemas de creación o actualización de clústeres

En esta página se explica cómo investigar problemas relacionados con la creación y la actualización de clústeres en Google Distributed Cloud (solo software) para VMware.

Problemas de instalación

Las siguientes secciones pueden ayudarte a solucionar problemas con la instalación de Google Distributed Cloud.

Usar el clúster de arranque para depurar problemas

Durante la instalación, Google Distributed Cloud crea un clúster de arranque temporal. Una vez que la instalación se haya realizado correctamente, Google Distributed Cloud eliminará el clúster de arranque, por lo que solo quedarán el clúster de administrador y el clúster de usuario. Por lo general, no debería tener ningún motivo 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 depurar el problema.

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

Examinar los registros del clúster de arranque

  1. Busca los nombres de los pods que se ejecutan en el espacio de nombres kube-system:

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

  2. Para ver los registros de un pod, haz lo siguiente:

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

    Sustituye POD_NAME por el nombre del pod que quieras ver.

  3. Para obtener los registros del clúster de arranque directamente, ejecuta el siguiente comando durante la creación, la actualización y la mejora del clúster:

    docker exec -it gkectl-control-plane bash

    Este comando abre una terminal dentro del contenedor gkectl-control-plane que se ejecuta en el clúster de arranque.

  4. 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 vista general del clúster de arranque

Si intentas crear o actualizar un clúster de administrador y esa operación falla, Google Distributed Cloud hará una instantánea externa del clúster de arranque. Esta instantánea del clúster de arranque es similar a la que se obtiene al ejecutar el comando gkectl diagnose snapshot en el clúster de administrador, pero el proceso se activa automáticamente. 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 Cloud Customer Care si es necesario.

La instantánea externa incluye registros de pods del onprem-admin-cluster-controller que puedes consultar para depurar problemas de creación o actualización de clústeres. Los registros se almacenan en un archivo independiente. 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 inicie el plano de control del administrador

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

  1. Busca el nombre del pod de los controladores de la API Cluster:

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

  2. Ver los registros de vsphere-controller-manager. Empieza especificando el pod, pero no el contenedor:

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

    El resultado indica que debes especificar un contenedor y te proporciona los nombres de los contenedores del pod. Por ejemplo:

    ... a container name must be specified ...,
choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]

  3. Elige un contenedor y consulta sus registros:

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

Se ha asignado un número suficiente de direcciones IP, pero la máquina no se puede registrar en el clúster

Este problema puede producirse si hay un conflicto de direcciones IP. Por ejemplo, una dirección IP que has especificado para una máquina se está usando en un balanceador de carga.

Para solucionar este problema, actualice el archivo de bloque de IP del clúster para que las direcciones de las máquinas no entren en conflicto con las direcciones especificadas en el archivo de configuración del clúster o en el archivo de bloque de IP de Seesaw.

El clúster de Kind no se elimina

Cuando creas un clúster de administrador, se crea un clúster kind (también llamado clúster de arranque) como parte del proceso. Cuando se complete la operación del clúster de administrador, el clúster kind se eliminará automáticamente.

Si ves el mensaje de error Failed to delete the kind cluster, puedes seguir estos pasos en tu estación de trabajo de administrador para eliminar manualmente el clúster kind:

  1. Obtenga el ID de contenedor kind:

    docker inspect --format="{{.Id}}" gkectl-control-plane

  2. Obtén el containerd-shim ID de proceso:

    sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'

  3. Finaliza el proceso:

    sudo kill -9 PROCESS_ID

Problemas de actualización de clústeres

En las siguientes secciones se ofrecen consejos sobre cómo resolver los problemas que pueden surgir durante una actualización de clúster.

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

Si actualizas un clúster de usuario y, después, detectas un problema con los nodos del clúster, puedes restaurar la versión anterior de los grupos de nodos seleccionados.

La reversión de grupos de nodos seleccionados se admite en grupos de nodos de Ubuntu y COS, pero no en grupos de nodos de Windows.

La versión de un grupo de nodos puede ser la misma o una versión secundaria anterior a la versión del plano de control del clúster de usuarios. Por ejemplo, si el plano de control tiene la versión 1.14, los grupos de nodos pueden tener la versión 1.14 o la 1.13.

Ver las versiones de grupos de nodos disponibles

Supongamos que has actualizado recientemente los nodos de trabajo y el plano de control de tu 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 de trabajo actualizados. Por lo tanto, decides revertir uno o varios grupos de nodos a la versión que estabas usando anteriormente: 1.13.1-gke.35. Antes de iniciar la reversión, debes verificar que la versión anterior esté disponible.

Para ver las versiones disponibles, ejecuta el siguiente comando:

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

En el resultado se 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

Restaurar la versión de un grupo de nodos

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

Para revertir la versión de un grupo de nodos, sigue estos pasos:

  1. En el archivo de configuración del clúster de usuarios, en uno o varios grupos de nodos, asigna a gkeOnPremVersion el valor de la versión anterior. En el siguiente ejemplo se muestra cómo restaurar la versión 1.13.1-gke.35:

    nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: 1.13.1-gke.35
  ...

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

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

  3. Verifica que la reversión se haya realizado correctamente:

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

    En el siguiente resultado se muestra que se ha revertido pool-1 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

Actualizar a una nueva versión de parche

Puedes actualizar todos los grupos de nodos y el plano de control a una nueva versión de parche. Esto puede ser útil si has vuelto a una versión anterior y quieres actualizar a una versión que incluya una corrección.

Para actualizar a una nueva versión, sigue estos pasos:

  1. Haz los siguientes cambios en el archivo de configuración del clúster de usuarios:

    1. Define el valor de gkeOnPremVersion en una nueva versión del parche. En este ejemplo se usa 1.14.1-gke.x.

    2. En cada grupo de nodos, quite el campo gkeOnPremVersion o asígnele la cadena vacía. Si no se especifica ninguna versión para un grupo de nodos, se usará de forma predeterminada 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: ""

  2. Ejecuta gkectl prepare y gkectl upgrade cluster tal como se describe en Actualizar Google Distributed Cloud.

  3. Verifica la nueva versión del clúster y consulta las versiones disponibles para revertir:

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

    El resultado debería ser 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 comprobaciones del estado se ejecutan automáticamente cuando falla la actualización del clúster

Si intentas actualizar un clúster de administrador o de usuario y esa operación falla, Google Distributed Cloud ejecuta automáticamente el comando gkectl diagnose cluster en el clúster.

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

El proceso de actualización se bloquea

En segundo plano, Google Distributed Cloud usa el comando de Kubernetes drain durante una actualización. Este procedimiento drain se puede bloquear mediante una implementación con una sola réplica que tenga un PodDisruptionBudget (PDB) creado con minAvailable: 1.

A partir de la versión 1.13 de Google Distributed Cloud, puedes consultar los errores a través de los eventos de pods de Kubernetes.

  1. Busca los nombres de las máquinas:

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

  2. Comprueba si hay errores con el comando kubectl describe machine:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

    El resultado debería ser 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.

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

    El resultado debería ser 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 solucionar este problema, guarde el PDB y quítelo del clúster antes de intentar realizar la actualización. Después, puedes volver a añadir el archivo PDB cuando se haya completado la actualización.

Eliminar los cambios no admitidos para desbloquear la actualización

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

Al actualizar los clústeres de usuarios a la versión 1.28 o posteriores, validamos todos los cambios realizados en el archivo de configuración y devolvemos un error si se han hecho cambios no admitidos, en lugar de ignorarlos. Esta función solo está disponible para los clústeres de usuarios. Al actualizar clústeres de administrador, los cambios en la mayoría de los campos se ignoran de forma silenciosa y no se aplican después de la actualización.

Por ejemplo, si intentas inhabilitar la reparación automática de nodos al actualizar un clúster de usuario a la versión 1.28, la actualización fallará y se mostrará 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
    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 evitar este error, puedes probar las siguientes soluciones alternativas:

  • Deshaz el cambio que has intentado hacer y vuelve a ejecutar la actualización. Por ejemplo, en el caso anterior, deshacerías los cambios realizados en la configuración de AutoRepair y, a continuación, volverías a ejecutar gkectl upgrade.
  • También puedes generar archivos de configuración que coincidan con el estado actual del clúster ejecutando gkectl get-config, actualizar los campos gkeOnPremVersion del clúster y los grupos de nodos en el archivo de configuración y, a continuación, volver a ejecutar gkectl upgrade.

Problema: No se encuentra la imagen del SO después de gkectl prepare

Después de ejecutar el comando gkectl prepare y, a continuación, intentar actualizar un clúster de usuario con gkectl upgrade cluster, puede que aparezca un error similar al siguiente:

[FAILURE] User OS images exist: OS images [gke-on-prem-ubuntu-VERSION] don't exist, please run `gkectl prepare` to upload OS images.

Este error puede producirse cuando el clúster de administrador y el clúster de usuario están configurados para usar carpetas de vSphere diferentes. De forma predeterminada, el comando gkectl prepare sube la imagen del SO a la carpeta del clúster de administrador. Para subir la imagen a la carpeta del clúster de usuarios, usa la marca --user-cluster-config, tal como se muestra en el siguiente comando:

  gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-VERSION-full.tgz \
    --user-cluster-config USER_CLUSTER_CONFIG

Depurar problemas de F5 BIG-IP con el archivo kubeconfig interno

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

Depurar problemas con vSphere

Puedes usar govc para investigar problemas con vSphere. Por ejemplo, puede confirmar los permisos y el acceso de sus cuentas de usuario de vCenter, así como recoger los registros de vSphere.

Volver a crear el archivo kubeconfig del clúster de usuarios que falta

Puede que quieras volver a crear un archivo kubeconfig de clúster de usuarios en las siguientes situaciones:

  • Si intentas crear un clúster de usuarios, la operación falla y quieres tener su archivo kubeconfig.
  • Si falta el archivo kubeconfig del clúster de usuarios, por ejemplo, si se ha eliminado.

Para generar un archivo kubeconfig para tu clúster de usuario, sigue estos pasos:

  1. Define las variables de entorno:

    Empieza definiendo las siguientes variables de entorno con los valores adecuados:

    USER_CONTROLPLANEVIP=USER_CONTROLPLANEVIP
USER_CLUSTER_NAME=USER_CLUSTER_NAME
ADMIN_CLUSTER_KUBECONFIG=PATH_TO_ADMIN_KUBECONFIG
KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets -n $USER_CLUSTER_NAME | grep ^admin | cut -d' ' -f1 | head -n 1)

    Haz los cambios siguientes:

    • ADMIN_CLUSTER_KUBECONFIG: la ruta del archivo kubeconfig de tu clúster de administrador.
    • USER_CONTROLPLANEVIP: el controlPlaneVIP del clúster de usuarios. Se puede obtener del archivo de manifiesto del clúster de usuarios.

  2. Genera el archivo kubeconfig:

    Ejecuta el siguiente comando para crear el nuevo archivo kubeconfig:

    kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets $KUBECONFIG_SECRET_NAME \
 -n $USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}'  | base64 -d | \
 sed -r "s/ kube-apiserver.*local\./${USER_CONTROLPLANEVIP}/" \
 > USER_CLUSTER_KUBECONFIG

    Reemplazar :

    • USER_CLUSTER_KUBECONFIG: el nombre del nuevo archivo kubeconfig de tu clúster de usuarios.

Siguientes pasos

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud.

También puedes consultar la sección Obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes: