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

En esta página se explica cómo resolver problemas relacionados con la instalación o la actualización de clústeres de Google Distributed Cloud.

Problemas de instalación

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

Mensajes de error transitorios

El proceso de instalación de Google Distributed Cloud es un bucle de conciliación continuo. Por lo tanto, es posible que veas mensajes de error transitorios en el registro durante la instalación.

Si la instalación se completa correctamente, puedes ignorar estos errores. A continuación se muestra una lista de mensajes de registro de errores transitorios habituales:

  Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
  https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Internal error occurred: failed calling webhook "vcluster.kb.io": Post
  https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Failed to register cluster with GKE Hub; gcloud output: error running command
  'gcloud container fleet memberships register CLUSTER_NAME  --verbosity=error --quiet':
  error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
  Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF

  Get
  https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
  cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"

  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""

Si tu Google Cloud clave de cuenta de servicio ha caducado, verás los siguientes mensajes de error de bmctl:

Error validating cluster config: 3 errors occurred:
        * GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}

Debes generar una nueva clave de cuenta de servicio.

Usar el clúster de arranque para depurar problemas

Cuando Google Distributed Cloud crea clústeres autogestionados (de administrador, híbridos o independientes), despliega un clúster Kubernetes in Docker (kind) para alojar temporalmente los controladores de Kubernetes necesarios para crear clústeres. Este clúster transitorio se denomina clúster de arranque. Los clústeres de usuarios los crean y actualizan el administrador o el clúster híbrido que los gestiona sin usar un clúster de arranque.

Si ya existe un clúster de tipo en tu implementación cuando intentas instalarlo, Google Distributed Cloud elimina el clúster de tipo. La eliminación solo se produce después de que la instalación o la actualización se hayan completado correctamente. Para conservar el clúster de tipo Kind aunque se haya creado correctamente, usa la marca --keep-bootstrap-cluster de bmctl.

Google Distributed Cloud crea un archivo de configuración para el clúster de arranque en WORKSPACE_DIR/.kindkubeconfig. Solo puedes conectarte al clúster de arranque durante la creación y la actualización del clúster.

El clúster de arranque necesita acceder a un repositorio de Docker para extraer imágenes. El registro predeterminado es Artifact Registry, a menos que uses un registro privado. Durante la creación del clúster,bmctl crea los siguientes archivos:

  • bmctl-workspace/config.json: contiene las Google Cloud credenciales de la cuenta de servicio para acceder al registro. Las credenciales se obtienen del campo gcrKeyPath del archivo de configuración del clúster.

  • bmctl-workspace/config.toml: contiene la configuración de containerd en el clúster de kind.

Examinar los registros del clúster de arranque

Para depurar el clúster de arranque, puedes seguir estos pasos:

  • Conéctate al clúster de arranque durante la creación y la actualización del clúster.
  • Obtén los registros del clúster de arranque.

Puedes encontrar los registros en la máquina que usas para ejecutar bmctl en las siguientes carpetas:

  • bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
  • bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

Sustituye CLUSTER_NAME y TIMESTAMP por el nombre de tu clúster y la hora del sistema correspondiente.

Para obtener los registros del clúster de arranque directamente, puedes ejecutar el siguiente comando durante la creación y la actualización del clúster:

docker exec -it bmctl-control-plane bash

El comando abre un terminal dentro del contenedor del plano de control de bmctl que se ejecuta en el clúster de arranque.

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

journalctl -u kubelet
journalctl -u containerd

Habilitar el registro de depuración de containerd

Si los registros estándar de containerd no proporcionan suficiente información para solucionar problemas, puedes aumentar el nivel de registro. Aumentar el nivel de registro suele ser necesario para diagnosticar problemas complejos, como problemas con un mirror del registro o errores ImagePullBackOff.

Para aumentar el nivel de registro, haz lo siguiente:

  1. Habilita el registro de depuración:

    1. Abre el archivo de configuración de containerd (/etc/containerd/config.toml) con el editor de texto que prefieras.

    2. En el archivo, busque la sección [debug] y cambie el valor de level de "" a "debug".

    3. Guarda el archivo y cierra el editor de texto.

    4. Verifica que hayas actualizado el archivo de configuración correctamente:

      cat /etc/containerd/config.toml | grep debug

      La salida debería ser la siguiente:

      [debug]
  level = "debug"
    shim_debug = false

    5. Para aplicar el cambio en el nivel de registro, reinicia containerd:

      sudo systemctl restart containerd

  2. Para generar nuevas entradas de registro, intenta extraer una imagen que no exista o que no utilicen ningún nodo ni clúster. Por ejemplo:

    # This command fails because the image doesn't exist
crictl pull us-west1-docker.pkg.dev/gdc-project/samples/non-existent-image:latest

    De esta forma, se obliga a containerd a realizar una acción y generar registros detallados.

  3. Espera a que se extraiga la imagen o se produzca un error y, a continuación, recoge los registros de containerd en un archivo llamado containerd_log.txt:

    journalctl -u containerd --no-pager --since TIME_PERIOD > containerd_log.txt

    Sustituye TIME_PERIOD por un valor que especifique la hora de inicio de los registros. Incluye entre comillas dobles cualquier valor que contenga espacios. Por ejemplo, "2 hours ago".

  4. Cuando hayas terminado de solucionar el problema, vuelve a cambiar el nivel de registro al valor predeterminado. Si dejas habilitado el registro de depuración, se pueden inundar los registros del sistema, lo que puede afectar al rendimiento y exponer información sensible.

    1. Abre el archivo /etc/containerd/config.toml y cambia el valor de level a "", el nivel de registro predeterminado.

    2. Verifica que has actualizado la configuración correctamente:

      cat /etc/containerd/config.toml | grep level

      La salida debería ser la siguiente:

      level = ""

    3. Para aplicar el cambio, reinicia containerd:

      sudo systemctl restart containerd

      El sistema vuelve a su configuración de registro estándar.

Problemas de actualización de clústeres

Cuando actualizas clústeres de Google Distributed Cloud, puedes monitorizar el progreso y comprobar el estado de tus clústeres y nodos.

Las siguientes directrices pueden ayudarte a determinar si la actualización continúa con normalidad o si hay algún problema.

Monitorizar el progreso de la actualización

Usa el comando kubectl describe cluster para ver el estado de un clúster durante el proceso de actualización:

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Sustituye los siguientes valores:

  • CLUSTER_NAME: el nombre de tu clúster.
  • CLUSTER_NAMESPACE: el espacio de nombres de tu clúster.
  • ADMIN_KUBECONFIG: el archivo kubeconfig de administrador.
    • De forma predeterminada, los clústeres de administrador, híbridos y independientes usan una actualización in situ. Si usas la marca --use-bootstrap=true con el comando bmctl upgrade, la operación de actualización usa un clúster de arranque. Para monitorizar el progreso de la actualización cuando se usa un clúster de arranque, especifica la ruta al archivo kubeconfig del clúster de arranque, .kindkubeconfig. Este archivo se encuentra en el directorio del espacio de trabajo.

Consulta la sección Status del resultado, que muestra una agregación del estado de actualización del clúster. Si el clúster informa de un error, utiliza las secciones siguientes para determinar dónde se produce el problema.

Comprobar si los nodos están listos

Usa el comando kubectl get nodes para ver el estado de los nodos de un clúster durante el proceso de actualización:

kubectl get nodes --kubeconfig KUBECONFIG

Para comprobar si un nodo ha completado correctamente el proceso de actualización, consulta las columnas VERSION y AGE de la respuesta del comando. VERSION es la versión de Kubernetes del clúster. Para ver la versión de Kubernetes de una versión concreta de Google Distributed Cloud, consulta Control de versiones.

Si el nodo muestra NOT READY, intenta conectar el nodo y comprueba el estado de kubelet:

systemctl status kubelet

También puedes consultar los registros de kubelet:

journalctl -u kubelet

Revisa la salida del estado y los registros de kubelet para ver los mensajes que indican por qué el nodo tiene un problema.

Comprobar qué nodo se está actualizando

Para comprobar qué nodo del clúster se está actualizando, usa el comando kubectl get baremetalmachines:

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Sustituye los siguientes valores:

  • CLUSTER_NAMESPACE: el espacio de nombres de tu clúster.
  • ADMIN_KUBECONFIG: el archivo kubeconfig de administrador.
    • Si se usa un clúster de arranque para una actualización de administrador, híbrida o independiente, especifica el archivo kubeconfig del clúster de arranque (bmctl-workspace/.kindkubeconfig).

En el siguiente ejemplo de salida se muestra que el nodo que se está actualizando tiene un ABM VERSION diferente al DESIRED ABM VERSION:

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

Comprobar qué nodos están en proceso de drenaje

Durante el proceso de actualización, los nodos se vacían de pods y la programación se inhabilita hasta que el nodo se actualice correctamente. Para ver qué nodos están drenando, usa el comando kubectl get nodes:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

Sustituye USER_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig del clúster de usuario.

La columna STATUS se filtra con grep para mostrar solo los nodos que informan SchedulingDisabled. Este estado indica que los nodos se están drenando.

También puedes comprobar el estado del nodo desde el clúster de administrador:

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Sustituye los siguientes valores:

  • CLUSTER_NAMESPACE: el espacio de nombres de tu clúster.
  • ADMIN_KUBECONFIG: el archivo kubeconfig de administrador.
    • Si se usa un clúster de arranque para una actualización de administrador, híbrida o independiente, especifica el archivo kubeconfig del clúster de arranque (bmctl-workspace/.kindkubeconfig).

El nodo que se está drenando muestra el estado en la columna MAINTENANCE.

Comprobar por qué un nodo lleva mucho tiempo en estado de drenaje

Usa uno de los métodos de la sección anterior para identificar el nodo que se está vaciando con el comando kubectl get nodes. Usa el comando kubectl get pods y filtra por este nombre de nodo para ver más detalles:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

Sustituye NODE_NAME por el nombre del nodo que se está drenando. El resultado devuelve una lista de pods que están bloqueados o tardan en vaciarse. La actualización continúa, incluso con los pods atascados, cuando el proceso de drenaje de un nodo tarda más de 20 minutos.

A partir de la versión 1.29, el proceso de drenaje de nodos usa la API de desalojo, que respeta los PodDisruptionBudgets (PDBs).

Los siguientes ajustes de PDB pueden provocar problemas de drenaje de nodos:

  • Pods gestionados por varias PDBs

  • Configuraciones estáticas de PDB, como las siguientes:

    • maxUnavailable == 0
    • minUnavailable >= réplicas totales

    Es difícil determinar el número total de réplicas a partir del recurso PDB, ya que se define en un recurso de nivel superior, como Deployment, ReplicaSet o StatefulSet. Los PDBs se corresponden con los pods en función del selector de su configuración. Una buena forma de diagnosticar si una configuración de PDB estática está causando un problema es comprobar si pdb.Status.ExpectPods <= pdb.Status.DesiredHealthy y ver si una de las configuraciones estáticas mencionadas permite que esto ocurra.

Las infracciones del tiempo de ejecución, como el valor DisruptionsAllowed calculado de un recurso de PDB que sea 0, también pueden bloquear el drenaje de nodos. Si tienes PodDisruptionBudgetobjetos configurados que no pueden permitir interrupciones adicionales, es posible que las actualizaciones de los nodos no se puedan actualizar a la versión del plano de control después de varios intentos. Para evitar este error, te recomendamos que aumentes la escala de Deployment o HorizontalPodAutoscaler para que el nodo pueda drenarse sin dejar de respetar la configuración de PodDisruptionBudget.

Para ver todos los objetos PodDisruptionBudget que no permiten interrupciones, usa el siguiente comando:

kubectl get poddisruptionbudget --all-namespaces \
    -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Comprobar por qué los pods no están en buen estado

Las actualizaciones pueden fallar si un pod contiene direcciones IP del plano de control upgrade-first-node o upgrade-node. Este comportamiento suele deberse a que los pods estáticos no están en buen estado.

  1. Comprueba los pods estáticos con el comando crictl ps -a y busca los pods de Kubernetes o etcd que fallen. Si tienes algún pod que no se ha podido ejecutar, revisa los registros de los pods para ver por qué fallan.

    Estas son algunas de las posibles causas del bucle de fallos:

    • Los permisos o el propietario de los archivos montados en pods estáticos no son correctos.
    • La conectividad a la dirección IP virtual no funciona.
    • Problemas con etcd.

  2. Si el comando crictl ps no funciona o no devuelve nada, comprueba el estado de kubelet y de containerd. Usa los comandos systemctl status SERVICE y journalctl -u SERVICE para consultar los registros.

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:

  • Requisitos para abrir un caso de asistencia.
  • Herramientas para ayudarte a solucionar problemas, como la configuración de tu entorno, los registros y las métricas.
  • Componentes admitidos.