Los clústeres de Anthos en Bare Metal ahora son Google Distributed Cloud (solo software) para Bare Metal. Para obtener más información, consulta la descripción general del producto.

Se usó la API de Cloud Translation para traducir esta página.

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

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

Problemas de instalación

Las siguientes secciones pueden ayudarte a solucionar problemas relacionados 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. Como resultado, es posible que veas mensajes de error transitorios en el registro durante la instalación.

Siempre que la instalación se complete con éxito, estos errores pueden ignorarse sin problemas. La siguiente es una lista de mensajes de registro de errores transitorios típicos:

  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 venció la clave de tu cuenta de servicio de Google Cloud , 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."}

Deberás generar una clave de cuenta de servicio nueva.

Usa el clúster de arranque para depurar problemas

Cuando Google Distributed Cloud crea clústeres autoadministrados (de administrador, híbridos o independientes), implementa un clúster de Kubernetes en Docker (tipo) para alojar de forma temporal los controladores de Kubernetes necesarios para crear clústeres. Este clúster transitorio se denomina clúster de arranque. Los clústeres de usuario se crean y actualizan a través de su clúster de administrador o híbrido sin usar un clúster de arranque.

Si ya existe un clúster de tipo en tu implementación cuando intentas realizar una instalación, Google Distributed Cloud borra el clúster de tipo existente. La eliminación solo ocurre después de que la instalación o actualización se realiza de forma correcta. Para conservar el clúster de tipo existente incluso después de éxito, 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 actualización del clúster.

El clúster de arranque necesita acceder a un repositorio de Docker para extraer imágenes. El registro se establece de forma predeterminada en 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 credenciales de la cuenta de servicio de Google Cloud para el acceso al registro. Las credenciales se obtienen del campo gcrKeyPath en el archivo de configuración del clúster.
bmctl-workspace/config.toml: Contiene la configuración en containerd en el clúster de tipo.

Examina los registros del clúster de arranque

Para depurar el clúster de arranque, puedes realizar los siguientes pasos:

Conectarse al clúster de arranque durante la creación y 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/

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

Para obtener los registros directamente del clúster de arranque, 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 una 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

Habilita 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 cuando se diagnostican problemas complejos, como problemas con un duplicado del registro o errores de ImagePullBackOff.

Para aumentar el nivel de registro, haz lo siguiente:

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, busca la sección [debug] y cambia el valor de level de "" a "debug".
3. Guarda el archivo y sal del editor de texto.
4. Verifica que hayas actualizado el archivo de configuración correctamente:
```
cat /etc/containerd/config.toml | grep debug
```
  El resultado debería ser el siguiente:
```
[debug]
  level = "debug"
    shim_debug = false
```
5. Para aplicar el cambio en el nivel de registro, reinicia containerd:
```
sudo systemctl restart containerd
```
Para generar nuevas entradas de registro, intenta extraer una imagen que no exista o que no usen nodos ni clústeres. 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
```
Esto obliga a containerd a realizar una acción y generar registros detallados.
Espera a que se extraiga la imagen o a que falle la extracción y, luego, recopila los registros de containerd en un archivo llamado containerd_log.txt:
```
journalctl -u containerd --no-pager --since TIME_PERIOD > containerd_log.txt
```
Reemplaza TIME_PERIOD por un valor que especifique la hora de inicio de los registros. Encierra entre comillas dobles cualquier valor que contenga espacios. Por ejemplo, "2 hours ago"
Cuando termines de solucionar el problema, revierte 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 el rendimiento y exponer información sensible.
1. Abre el archivo /etc/containerd/config.toml y vuelve a cambiar el valor de level a "", el nivel de registro predeterminado.
2. Verifica que hayas actualizado la configuración correctamente:
```
cat /etc/containerd/config.toml | grep level
```
  El resultado debería ser el siguiente:
```
level = ""
```
3. Para aplicar el cambio, reinicia containerd:
```
sudo systemctl restart containerd
```
  El sistema ahora volvió a su configuración de registro estándar.

Problemas de actualización del clúster

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

Si tienes problemas durante una actualización, intenta determinar en qué etapa se produce la falla. Para obtener más información sobre lo que sucede con un clúster durante el proceso de actualización, consulta Ciclo de vida y etapas de las actualizaciones de clústeres.
Para obtener más información sobre el impacto de un problema durante las actualizaciones de clústeres, consulta Comprende el impacto de las fallas en Google Distributed Cloud.

La siguiente guía puede ayudarte a determinar si la actualización continúa con normalidad o si hay un problema.

Supervisa 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

Reemplaza los siguientes valores:

CLUSTER_NAME: Es el nombre de tu clúster.
CLUSTER_NAMESPACE: Es el espacio de nombres de tu clúster.
ADMIN_KUBECONFIG: Es el archivo kubeconfig de administrador.
- De forma predeterminada, los clústeres independientes, híbridos y de administrador 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 supervisar el progreso de la actualización cuando se usa un clúster de arranque, especifica la ruta de acceso 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 un error, usa las siguientes secciones para solucionar el problema.

Verifica si los nodos están listos

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

kubectl get nodes --kubeconfig KUBECONFIG

Para verificar si un nodo completó correctamente el proceso de actualización, consulta las columnas VERSION y AGE en 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 determinada de Google Distributed Cloud, consulta Control de versiones.

Si el nodo muestra NOT READY, intenta conectarlo y verifica el estado de kubelet:

systemctl status kubelet

También puedes revisar los registros de kubelet:

journalctl -u kubelet

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

Verifica qué nodo se está actualizando

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

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

Reemplaza los siguientes valores:

CLUSTER_NAMESPACE: Es el espacio de nombres de tu clúster.
ADMIN_KUBECONFIG: Es 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 resultado, se muestra que el nodo que se actualiza tiene un ABM VERSION diferente del 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

Verifica qué nodos están en proceso de vaciado

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

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

Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso 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 se están vaciando los nodos.

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

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Reemplaza los siguientes valores:

CLUSTER_NAMESPACE: Es el espacio de nombres de tu clúster.
ADMIN_KUBECONFIG: Es 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á vaciando muestra el estado en la columna MAINTENANCE.

Verifica por qué un nodo está en estado de vaciado durante mucho tiempo

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 el nombre de este nodo para ver detalles adicionales:

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

Reemplaza NODE_NAME por el nombre del nodo que se está vaciando. El resultado muestra una lista de los Pods que están atascados o tardan en vaciarse. La actualización continúa, incluso con Pods atascados, cuando el proceso de vaciado en un nodo tarda más de 20 minutos.

A partir de la versión 1.29, el proceso de vaciado de nodos usa la API de Eviction, que respeta los PodDisruptionBudgets (PDB).

Los siguientes parámetros de configuración del PDB pueden causar problemas de desvío de nodos:

Pods administrados por varios PDB
Configuraciones estáticas del PDB, como las siguientes:
- maxUnavailable == 0
- minUnavailable >= réplicas totales
El recuento total de réplicas es difícil de determinar a partir del recurso PDB, ya que se define en un recurso de nivel superior, como Deployment, ReplicaSet o StatefulSet. Los PDB coinciden con los Pods solo según el selector en su configuración. Un buen enfoque para diagnosticar si una configuración de PDB estática está causando un problema es verificar si pdb.Status.ExpectPods <= pdb.Status.DesiredHealthy primero y ver si una de las configuraciones estáticas mencionadas permite que esto suceda.

Los incumplimientos durante el tiempo de ejecución, como el valor DisruptionsAllowed calculado para un recurso de PDB que es 0, también pueden bloquear el desvío de nodos. Si tienes objetos PodDisruptionBudget configurados que no pueden permitir interrupciones adicionales, es posible que las actualizaciones de los nodos no se actualicen a la versión del plano de control después de varios intentos. Para evitar esta falla, te recomendamos que escales verticalmente la Deployment o la HorizontalPodAutoscaler para permitir que el nodo se desvíe y aún respete la configuración de PodDisruptionBudget.

Para ver todos los objetos PodDisruptionBudget que no permiten ninguna interrupción, usa el siguiente comando:

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

Verifica 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. Por lo general, este comportamiento se debe a que los Pods estáticos no están en buen estado.

Verifica los Pods estáticos con el comando crictl ps -a y busca cualquier Pod de Kubernetes o etcd que falle. Si tienes Pods con errores, revisa sus registros para ver por qué fallan.

Estas son algunas posibilidades de comportamiento de bucle de fallas:
- Los permisos o el propietario de los archivos que se activan en Pods estáticos no son correctos.
- La conectividad a la dirección IP virtual no funciona.
- Problemas con etcd.
Si el comando crictl ps no funciona o no devuelve nada, verifica el estado de kubelet y de containerd. Usa los comandos systemctl status SERVICE y journalctl -u SERVICE para consultar los registros.

¿Qué sigue?

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud. También puedes consultar Cómo 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 compatibles

Soluciona problemas de creación o actualización de clústeres Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Problemas de instalación

Mensajes de error transitorios

Usa el clúster de arranque para depurar problemas

Examina los registros del clúster de arranque

Habilita el registro de depuración de containerd

Problemas de actualización del clúster

Supervisa el progreso de la actualización

Verifica si los nodos están listos

Verifica qué nodo se está actualizando

Verifica qué nodos están en proceso de vaciado

Verifica por qué un nodo está en estado de vaciado durante mucho tiempo

Verifica por qué los Pods no están en buen estado

¿Qué sigue?

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