Soluciona problemas de instalación o actualización del clúster

En esta página, se proporciona información para la solución de problemas si tienes problemas cuando instalas o actualizas los clústeres de Anthos en Bare Metal.

Problemas relacionados con el clúster de arranque

Cuando los clústeres de Anthos en el equipo físico crean o actualizan clústeres, implementa un clúster de Kubernetes en Docker (tipo) para alojar de forma temporal los controladores de Kubernetes necesarios a fin de crear o actualizar clústeres. Este clúster transitorio se denomina clúster de arranque.

Si ya existe un clúster de tipo en tu implementación cuando intentas realizar una instalación, los clústeres de Anthos en el equipo físico borran 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 similares existente incluso después de realizarlo con éxito, usa la marca --keep-bootstrap-cluster de bmctl.

Los clústeres de Anthos en equipos físicos crean 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 Container 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.

Depura el 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 kubelet y containerd, usa los siguientes comandos y busca errores o advertencias en el resultado:

journalctl -u kubelet
journalctl -u containerd

Problemas con la actualización del clúster

Cuando actualizas los clústeres de Anthos en Bare Metal, puedes supervisar el progreso y verificar el estado de tus clústeres y nodos. 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: El espacio de nombres de tu clúster.
  • ADMIN_KUBECONFIG: Es el archivo kubeconfig del administrador.
    • De forma predeterminada, un clúster de arranque se usa para las actualizaciones de clústeres independientes, de administrador y híbridas. Para supervisar 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 de 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 de un clúster durante el proceso de actualización:

kubectl get nodes --kubeconfig KUBECONFIG

Para verificar si un nodo completó de forma correcta el proceso de actualización, consulta las columnas VERSION y AGE en la respuesta del comando. VERSION es la versión de Kubernetes para el clúster. Para ver la versión de Kubernetes de unos clústeres de Anthos determinado en versión de Bare Metal, consulta la tabla en la Política de asistencia de la versión.

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

systemctl status kubelet

También puedes revisar los registros de kubelet:

journalctl -u kubelet

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

Comprueba qué nodo se está actualizando en este momento

Para verificar qué nodo del clúster se encuentra en proceso de actualización, usa el comando kubectl get baremetalmachines:

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

Reemplaza los siguientes valores:

  • CLUSTER_NAMESPACE: El espacio de nombres de tu clúster.
  • ADMIN_KUBECONFIG: Es el archivo kubeconfig del 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 siguiente resultado de ejemplo muestra que el nodo que se está actualizando en ese momento 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

Verifica los nodos que se están desviando en este momento

Durante el proceso de actualización, los nodos se desvían de los pods y la programación se inhabilita hasta que el nodo se actualice de forma correcta. Para ver qué nodos se desvían de los Pods en la actualidad, 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 los nodos se están desviando.

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: El espacio de nombres de tu clúster.
  • ADMIN_KUBECONFIG: Es el archivo kubeconfig del 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 desvía muestra el estado en la columna MAINTENANCE.

Comprueba por qué un nodo se ha estado en estado de desvío durante mucho tiempo

Usa uno de los métodos de la sección anterior para identificar el nodo que se desvía con el comando kubectl get nodes. Usa el comando kubectl get pods y filtra en este nombre de 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 desvía. El resultado muestra una lista de pods que están atascados o que se desvían lentamente. La actualización continúa, incluso con los pods atascados, cuando el proceso de desvío en un nodo tarda más de 20 minutos.