Versión 1.8. Ya no se admite esta versión. Para obtener más información, consulta la política de asistencia de la versión. Para obtener información sobre cómo actualizar a la versión 1.9, consulta Actualiza Anthos en equipos físicos en la documentación de la versión 1.9.

Versiones compatibles disponibles: 1.14 | 1.13 | 1.12

Soluciona problemas: diagnostica y restablece clústeres

Puedes diagnosticar o verificar los clústeres para depurar problemas y capturar una instantánea del estado del clúster. Además, si realizaste la instalación de forma parcial, pero el clúster muestra errores o no funciona de forma correcta, puedes intentar restablecer el clúster.

Diagnostica clústeres con `bmctl check cluster`

Puedes capturar el estado de los clústeres creados con el comando bmctl check cluster. Las marcas del comando te permiten elegir el alcance de diagnóstico del comando para que puedas obtener información enfocada.

La información de diagnóstico puede ayudarte a descubrir problemas y depurar tus implementaciones de manera más eficaz. El comando captura todos los archivos de configuración de clúster y nodo relevantes para el alcance definido y, luego, empaqueta la información en un solo archivo tar.

bmctl check cluster --snapshot --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Reemplaza lo siguiente:

CLUSTER_NAME: Es el nombre del clúster de destino.
ADMIN_KUBECONFIG_PATH: Es la ruta al archivo kubeconfig del clúster de administrador

Este comando genera un archivo tar que incluye información de depuración relevante de todos los componentes y las máquinas del sistema en el clúster que especificaste.

Puedes cambiar el alcance de la información de diagnóstico recopilada con las siguientes marcas de comando:

La marca --snapshot-scenario all aumenta el alcance de la instantánea de diagnóstico para incluir todos los Pods en el clúster especificado:

bmctl check cluster --snapshot --snapshot-scenario all --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

La marca --snapshot-dry-run funciona junto con la marca --snapshot-config string. Usa la marca --snapshot-dry-run a fin de generar un archivo de configuración que puedas modificar para definir un alcance de diagnóstico personalizado. Tu alcance puede incluir Pods, espacios de nombres o comandos de nodo específicos.

Después de modificar el archivo de salida creado con la marca --snapshot-dry-run, puedes usarlo como entrada para diagnosticar tu alcance específico con la marca --snapshot-config string, que se describe a continuación. Si omites esta marca, se aplica una configuración predeterminada.

bmctl check cluster --snapshot --snapshot-dry-run --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

La marca --snapshot-config le indica al comando bmctl que use las opciones de alcance especificadas en un archivo de configuración de instantáneas. Por lo general, debes crear el archivo de configuración de instantáneas con la marca --snapshot-dry-run.

bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Diagnostica clústeres cuando no se puede acceder al clúster de administrador

Cuando el clúster de administrador esté inactivo o no se pueda acceder, usa un archivo de configuración de instantáneas para tomar una instantánea del clúster. Un archivo de configuración de instantáneas tiene el formato YAML. En el archivo de configuración, se incluyen los siguientes campos a fin de especificar cómo se captura la información para tu clúster:

numOfParallelThreads: La rutina de instantánea suele ejecutar varios comandos. Contar con varios subprocesos paralelos ayuda a que la rutina se ejecute más rápido. Te recomendamos establecer numOfParallelThreads en 10 como se muestra en el siguiente ejemplo. Si las instantáneas tardan demasiado, aumenta este valor.
excludeWords: La instantánea contiene una gran cantidad de datos para los nodos del clúster. Usa excludeWords para reducir los riesgos de seguridad cuando compartas la instantánea. Por ejemplo, excluye password para que no se puedan identificar las strings de contraseña correspondientes.
nodeCommands: En esta sección, se especifica la siguiente información:
- nodes: Una lista de direcciones IP para los nodos del clúster del que deseas recopilar información. Para crear una instantánea cuando no se puede acceder al clúster de administrador, especifica al menos una dirección IP de nodo.
- commands: Una lista de comandos (y argumentos) que se ejecutarán en cada nodo. El resultado de cada comando se incluye en la instantánea.
nodeFiles: En esta sección, se especifica la siguiente información:
- nodes: Una lista de direcciones IP para los nodos del clúster del que deseas recopilar archivos. Para crear una instantánea cuando no se puede acceder al clúster de administrador, especifica al menos una dirección IP de nodo.
- files: Una lista de los archivos que se recuperarán de cada nodo. Cuando se encuentran los archivos especificados en un nodo, se incluyen en la instantánea.
nodeSSHKey: La ruta de acceso al archivo de clave SSH para los nodos. Este campo es obligatorio para crear una instantánea cuando no se puede acceder al clúster de administrador.

Usa el siguiente comando para crear una instantánea mediante un archivo de configuración de instantáneas:

bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG

Reemplaza SNAPSHOT_CONFIG por la ruta de acceso al archivo de configuración de instantánea.

En el siguiente archivo de configuración de instantáneas de muestra, se muestran los comandos y archivos estándar que se usan para crear una instantánea. Puedes agregar más comandos y archivos cuando se necesite información adicional de diagnóstico.

numOfParallelThreads: 10
excludeWords:
- password
nodeCommands:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - ip neigh
  - iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1 || true
  - docker info || true
  - docker ps -a || true
  - crictl ps -a || true
  - docker ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo docker logs || true
  - docker ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo docker logs || true
  - crictl ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo crictl logs || true
  - crictl ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo crictl logs || true
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - conntrack --count
  - dmesg
  - systemctl status -l docker || true
  - journalctl --utc -u docker
  - journalctl --utc -u docker-monitor.service
  - systemctl status -l kubelet
  - journalctl --utc -u kubelet
  - journalctl --utc -u kubelet-monitor.service
  - journalctl --utc --boot --dmesg
  - journalctl --utc -u node-problem-detector
  - systemctl status -l containerd || true
  - journalctl --utc -u containerd
  - systemctl status -l docker.haproxy || true
  - journalctl --utc -u docker.haproxy
  - systemctl status -l docker.keepalived || true
  - journalctl --utc -u docker.keepalived
  - systemctl status -l container.haproxy || true
  - journalctl --utc -u container.haproxy
  - systemctl status -l container.keepalived || true
  - journalctl --utc -u container.keepalived
nodeFiles:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/netfilter/nf_conntrack_max
  - /proc/sys/net/ipv4/conf/all/rp_filter
  - /lib/systemd/system/kubelet.service
  - /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
  - /lib/systemd/system/docker.service || true
  - /etc/systemd/system/containerd.service || true
  - /etc/docker/daemon.json || true
  - /etc/containerd/config.toml || true
  - /etc/systemd/system/container.keepalived.service || true
  - /etc/systemd/system/container.haproxy.service || true
  - /etc/systemd/system/docker.keepalived.service || true
  - /etc/systemd/system/docker.haproxy.service || true
nodeSSHKey: ~/.ssh/id_rsa # path to your ssh key file to each nodes

Crea una instantánea para la instalación o actualización detenida del clúster de administrador

Cuando instalas clústeres independientes de administrador, híbridos e independientes, si bmctl está atascado en el siguiente resultado

Espera a que el clúster kubeconfig esté listo
Espera a que el clúster esté listo
Espera a que los grupos de nodos estén listos

o cuando se actualizan los clústeres de administrador, híbridos o independientes

Espera a que se complete la actualización

Puedes ejecutar el siguiente comando para tomar una instantánea mediante el clúster de arranque.

bmctl check cluster --snapshot --kubeconfig <var>WORKSPACE_DIR</var>/.kindkubeconfig --cluster <var>CLUSTER_NAME</var>

Restablece clústeres con `bmctl reset cluster`

Cuando un clúster no se instala de forma correcta, puedes intentar restablecer los nodos a un estado limpio si lo restableces. Luego, puedes volver a instalar el clúster después de realizar cambios en la configuración.

Restablece clústeres autoadministrados

Para restablecer un clúster que se administre por sí mismo, como un clúster de administrador, ejecuta el siguiente comando:

bmctl reset --cluster CLUSTER_NAME

Reemplaza CLUSTER_NAME por el nombre del clúster que deseas restablecer.

Restablece clústeres de usuario

Para restablecer un clúster, ejecuta el siguiente comando:

bmctl reset --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Reemplaza CLUSTER_NAME por el nombre del clúster de usuario que deseas restablecer, y reemplaza ADMIN_KUBECONFIG_PATH por la ruta de acceso al archivo kubeconfig del clúster de administrador asociado. bmctl admite el uso de --kubeconfig como un alias para la marca --admin-kubeconfig.

Restablece los detalles del clúster

Sin importar el tipo de clúster, el comando de restablecimiento se aplica a todo el clúster. No hay opción para apuntar un subconjunto de nodos en un clúster.

El resultado del comando bmctl cluster reset es similar al siguiente ejemplo:

bmctl reset --cluster cluster1
Creating bootstrap cluster... OK
Deleting GKE Hub member admin in project my-gcp-project...
Successfully deleted GKE Hub member admin in project my-gcp-project
Loading images... OK
Starting reset jobs...
Resetting: 1    Completed: 0    Failed: 0
...
Resetting: 0    Completed: 1    Failed: 0
Flushing logs... OK

Durante la operación de restablecimiento, bmctl primero intenta borrar el registro de la membresía de GKE Hub y, luego, limpia los nodos afectados. Durante el restablecimiento, también se borran los datos y las activaciones de almacenamiento de anthos-system StorageClass.

Para todos los nodos, bmctl ejecuta kubeadm reset, quita las interfaces de túnel que se usan para las redes del clúster y borra los siguientes directorios:

/etc/kubernetes
/etc/cni/net.d
/root/.kube
/var/lib/kubelet

En los nodos del balanceador de cargas, bmctl también realiza las siguientes acciones:

Inhabilita los servicios keepalived y haproxy
Borra los archivos de configuración de keepalived y haproxy

La herramienta de restablecimiento espera que el archivo de configuración del clúster esté en la siguiente ubicación del directorio de trabajo actual:

bmctl-workspace/cluster name/cluster name.yaml