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

Verificaciones de estado

Las verificaciones de estado son una forma de probar y supervisar el funcionamiento de los clústeres existentes. Las verificaciones de estado se ejecutan solas de forma periódica. También puedes usar bmctl para ejecutar verificaciones de estado a pedido. En este documento, se describe cada verificación, las circunstancias en las que se ejecuta automáticamente, cómo y cuándo ejecutarla de forma manual, y cómo interpretar los resultados.

¿Qué elementos están marcados?

Existen dos categorías de verificaciones de estado de Google Distributed Cloud:

Verificaciones de la máquina de nodo
Verificaciones de todo el clúster

En las siguientes secciones, se describe lo que se marca para cada categoría. Estas verificaciones se usan para verificaciones de estado periódicas y a pedido.

Verificaciones de la máquina de nodo

En esta sección, se describe lo que evalúan las verificaciones de estado para las máquinas de nodo. Estas verificaciones confirman que las máquinas de nodo están configuradas correctamente y que tienen los recursos y la conectividad suficientes para crear y actualizar clústeres, y su operación.

Estas verificaciones corresponden a los recursos personalizados HealthCheck de Bare Metal llamados bm-system-NODE_IP_ADDRESS-machine (por ejemplo, bm-system-192.0.2.54-machine) que se ejecutan en el clúster de administrador en el espacio de nombres del clúster. Para obtener más información sobre los recursos de verificación de estado, consulta Recursos personalizados de HealthCheck.

Las verificaciones comunes de las máquinas consisten en lo siguiente:

Las máquinas de clústeres usan un sistema operativo (SO) compatible.
La versión del SO es compatible.
El SO usa una versión de kernel compatible.
El kernel tiene habilitada la opción del compilador Just In Time (JIT) de BPF (CONFIG_BPF_JIT=y).
En Ubuntu, el firewall no complicado (UFW) está inhabilitado.
Las máquinas de nodo cumplen con los requisitos mínimos de CPU.
Las máquinas de nodo tienen más del 20% de los recursos de CPU disponibles.
Las máquinas de nodo cumplen con los requisitos mínimos de memoria.
Las máquinas de nodo cumplen con los requisitos mínimos de almacenamiento en disco.
La sincronización de tiempo se configura en las máquinas de nodo.
La ruta predeterminada para enrutar paquetes a la puerta de enlace predeterminada está presente en los nodos.
El sistema de nombres de dominio (DNS) funciona (esta verificación se omite si el clúster está configurado para ejecutarse detrás de un proxy).
Si el clúster está configurado para usar una duplicación de registro, se puede acceder a esta.

Las verificaciones de la máquina de Google Cloud constan de lo siguiente:

Se puede acceder a Container Registry, gcr.io (se omite esta verificación si el clúster está configurado para usar una duplicación de registro).
Las APIs de Google son accesibles.

Las verificaciones de estado de las máquinas constan de lo siguiente:

kubelet está activo y se está ejecutando en máquinas de nodo.
containerd está activo y se está ejecutando en máquinas de nodo.
El estado del extremo de estado de la interfaz de red del contenedor (CNI) está en buen estado.
Los CIDR del Pod no se superponen con las direcciones IP de la máquina del nodo.

Para obtener más información sobre los requisitos de la máquina del nodo, consulta Requisitos previos de la máquina del nodo del clúster.

Verificaciones de todo el clúster

En esta sección, se describe lo que evalúan las verificaciones de estado de un clúster.

Verificaciones de red

Las siguientes verificaciones de red de nodos del clúster del cliente se ejecutan automáticamente como parte de las verificaciones de estado periódicas. Las verificaciones de red no se pueden ejecutar a pedido. Estas verificaciones corresponden a los recursos personalizados HealthCheck de Bare Metal llamados bm-system-network que se ejecutan en el clúster de administrador en el espacio de nombres del clúster. Para obtener más información sobre los recursos de verificación de estado, consulta Recursos personalizados de HealthCheck.

Si el clúster usa balanceo de cargas en paquetes, los nodos del grupo de nodos del balanceo de cargas deben tener conectividad con el protocolo de resolución de direcciones (ARP) de capa 2. Se requiere el ARP para el descubrimiento de VIP.
Los nodos del plano de control tienen los puertos 8443 y 8444 abiertos para que los use GKE Identity Service.
Los nodos del plano de control tienen los puertos 2382 y 2383 abiertos para que los use la instancia etcd-events.

Si quieres obtener información sobre los protocolos y el uso de puertos para tus clústeres de Google Distributed Cloud, consulta Requisitos de red.

Las verificaciones de red para una verificación preliminar difieren de las verificaciones de estado de la red. Para obtener una lista de las verificaciones de red para una verificación preliminar, consulta Verificaciones previas para la creación de clústeres o Verificaciones previas para actualizaciones de clústeres.

Kubernetes

Las verificaciones de Kubernetes, que se ejecutan de forma automática como parte de las verificaciones previas y las verificaciones de estado periódicas, también se pueden ejecutar a pedido. Estas verificaciones de estado no muestran un error si falta alguno de los componentes del plano de control de la lista. La verificación solo muestra errores si los componentes existen y tienen errores en el momento de la ejecución del comando.

Estas verificaciones corresponden a los recursos personalizados HealthCheck de Bare Metal llamados recursos bm-system-kubernetes que se ejecutan en el clúster de administrador en el espacio de nombres del clúster. Para obtener más información sobre los recursos de verificación de estado, consulta Recursos personalizados de HealthCheck.

El servidor de la API está funcionando.
El operador anetd está configurado de forma correcta.
Se pueden operar todos los nodos del plano de control.
Los siguientes componentes del plano de control funcionan de forma correcta:
- anthos-cluster-operator
- controller-manager
- cluster-api-provider
- ais
- capi-kubeadm-bootstrap-system
- cert-manager
- kube-dns

Complementos

Las verificaciones de complementos se ejecutan automáticamente como parte de las comprobaciones preliminares y las verificaciones de estado periódicas, y se pueden ejecutar a pedido. Esta verificación de estado no muestra un error si falta alguno de los complementos de la lista. La verificación solo muestra errores si los complementos existen y tienen errores en el momento de la ejecución del comando.

Estas verificaciones corresponden a los recursos personalizados HealthCheck de Bare Metal llamados bm-system-add-ons* que se ejecutan en el clúster de administrador en el espacio de nombres del clúster. Para obtener más información sobre los recursos de verificación de estado, consulta Recursos personalizados de HealthCheck.

Se pueden operar los componentes de Stackdriver en Cloud Logging y el agente de Connect:
- stackdriver-log-aggregator
- stackdriver-log-forwarder
- stackdriver-metadata-agent
- stackdriver-prometheus-k8
- gke-connect-agent
Los recursos administrados por Google Distributed Cloud no muestran cambios manuales (desvío de configuración):
- No se actualizaron los valores de los campos
- No se agregaron ni quitaron los campos opcionales
- No se borraron los recursos

Si la verificación de estado detecta un desvío de configuración, el valor Status.Pass del recurso personalizado HealthCheck de Bare Metal de bm-system-add-ons se establece en false. El campo Description de la sección Failures contiene detalles sobre los recursos que cambiaron, incluida la siguiente información:

Version: Es la versión de la API del recurso.
Kind: Es el esquema del objeto, como Deployment, para el recurso.
Namespace: Es el espacio de nombres en el que se encuentra el recurso.
Name: el nombre del recurso.
Diff: Es una comparación de formatos de cadena de las diferencias entre el manifiesto del recurso registrado y el manifiesto del recurso modificado.

`HealthCheck` recursos personalizados

Cuando se ejecuta una verificación de estado, Google Distributed Cloud crea un recurso HealthCheck personalizado. Los recursos personalizados de HealthCheck son persistentes y proporcionan un registro estructurado de las actividades y los resultados de la verificación de estado. Hay dos categorías de recursos personalizados de HeathCheck:

Recursos personalizados HealthCheck de Bare Metal (API Version: baremetal.cluster.gke.io/v1): Estos recursos proporcionan detalles sobre las verificaciones de estado periódicas. Estos recursos se encuentran en el clúster de administrador en los espacios de nombres del clúster. Los recursos HealthCheck de Bare Metal son responsables de crear trabajos cron de verificación de estado y trabajos. Estos recursos se actualizan de manera coherente con los resultados más recientes.
Recursos personalizados HealthCheck de Anthos (API Version: anthos.gke.io/v1): Estos recursos se usan para informar sobre las métricas de verificación de estado. Estos recursos se encuentran en el espacio de nombres kube-system de cada clúster. Las actualizaciones de estos recursos son el mejor esfuerzo. Si una actualización genera un problema, como un error de red transitorio, se ignora la falla.

En la siguiente tabla, se enumeran los tipos de recursos que se crean para cada categoría de HealthCheck:

Verificaciones de estado de Bare Metal Verificaciones de estado de GKE Enterprise Gravedad

Verificaciones de estado de Bare Metal	Verificaciones de estado de GKE Enterprise	Gravedad
Tipo: máquina Nombre: `bm-system-NODE_IP_ADDRESS-machine`	Tipo: máquina Nombre: `bm-system-NODE_IP_ADDRESS-machine`	Esencial
Tipo: red Nombre: `bm-system-network`	Tipo: red Nombre: `bm-system-network`	Esencial
Tipo: Kubernetes Nombre: `bm-system-kubernetes`	Tipo: Kubernetes Nombre: `bm-system-kubernetes`	Esencial
Tipo: complementos Nombre: `bm-system-add-ons`	Tipo: complementos Nombre: `bm-system-add-ons-add-ons` Nombre: `bm-system-add-ons-configdrift`	Opcional

Tipo: máquina

Nombre: bm-system-NODE_IP_ADDRESS-machine

Tipo: máquina

Nombre: bm-system-NODE_IP_ADDRESS-machine

Esencial

Tipo: red

Nombre: bm-system-network

Tipo: red

Nombre: bm-system-network

Esencial

Tipo: Kubernetes

Nombre: bm-system-kubernetes

Tipo: Kubernetes

Nombre: bm-system-kubernetes

Esencial

Tipo: complementos

Nombre: bm-system-add-ons

Tipo: complementos

Nombre: bm-system-add-ons-add-ons

Nombre: bm-system-add-ons-configdrift

Opcional

Para recuperar el estado de HealthCheck, haz lo siguiente:

Para leer los resultados de las verificaciones de estado periódicas, puedes obtener los recursos personalizados asociados:

kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig ADMIN_KUBECONFIG --all-namespaces

Reemplaza ADMIN_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de administrador.

En el siguiente ejemplo, se muestran las verificaciones de estado que se ejecutan de forma periódica y si se aprobaron la última vez que se ejecutaron:

NAMESPACE               NAME                               PASS    AGE
cluster-test-admin001   bm-system-192.0.2.52-machine       true    11d
cluster-test-admin001   bm-system-add-ons                  true    11d
cluster-test-admin001   bm-system-kubernetes               true    11d
cluster-test-admin001   bm-system-network                  true    11d
cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
cluster-test-user001    bm-system-add-ons                  true    56d
cluster-test-user001    bm-system-kubernetes               true    56d
cluster-test-user001    bm-system-network                  true    56d

Para leer los detalles de una verificación de estado específica, usa kubectl describe:

kubectl describe healthchecks.baremetal.cluster.gke.io HEALTHCHECK_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

Reemplaza lo siguiente:

HEALTHCHECK_NAME: el nombre de la verificación de estado.
ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
CLUSTER_NAMESPACE: el espacio de nombres del clúster.

Cuando revisas el recurso, la sección Status: contiene los siguientes campos importantes:

Pass: Indica si se aprobó o no el último trabajo de verificación de estado.
Checks: Contiene información sobre el trabajo de verificación de estado más reciente.
Failures: Contiene información sobre el trabajo con errores más reciente.
Periodic: Contiene información como cuándo fue la última vez que se programó e instrumentó un trabajo de verificación de estado.

La siguiente muestra de HealthCheck es para una verificación de máquina correcta:

Name:         bm-system-192.0.2.54-machine
Namespace:    cluster-test-user001
Labels:       baremetal.cluster.gke.io/periodic-health-check=true
              machine=192.0.2.54
              type=machine
Annotations:  <none>
API Version:  baremetal.cluster.gke.io/v1
Kind:         HealthCheck
Metadata:
  Creation Timestamp:  2023-09-22T18:03:27Z
  ...
Spec:
  Anthos Bare Metal Version:  1.16.0
  Cluster Name:               nuc-user001
  Interval In Seconds:        3600
  Node Addresses:
    192.168.1.54
  Type:  machine
Status:
  Check Image Version:  1.16.0-gke.26
  Checks:
    192.168.1.54:
      Job UID:  345b74a6-ce8c-4300-a2ab-30769ea7f855
      Message:  
      Pass:     true
  ...
  Cluster Spec:
    Anthos Bare Metal Version:  1.16.0
    Bypass Preflight Check:     false
    Cluster Network:
      Bundled Ingress:  true
      Pods:
        Cidr Blocks:
          10.0.0.0/16
      Services:
        Cidr Blocks:
          10.96.0.0/20
  ...
  Conditions:
    Last Transition Time:  2023-11-22T17:53:18Z
    Observed Generation:   1
    Reason:                LastPeriodicHealthCheckFinished
    Status:                False
    Type:                  Reconciling
  Node Pool Specs:
    node-pool-1:
      Cluster Name:  nuc-user001
    ...
  Pass:                  true
  Periodic:
    Last Schedule Time:                    2023-11-22T17:53:18Z
    Last Successful Instrumentation Time:  2023-11-22T17:53:18Z
  Start Time:                              2023-09-22T18:03:28Z
Events:
  Type    Reason                  Age                  From                    Message
  ----    ------                  ----                 ----                    -------
  Normal  HealthCheckJobFinished  6m4s (x2 over 6m4s)  healthcheck-controller  health check job bm-system-192.0.2.54-machine-28344593 finished

La siguiente muestra de HealthCheck corresponde a una verificación de máquina con errores:

Name:         bm-system-192.0.2.57-machine
Namespace:    cluster-user-cluster1
...
API Version:  baremetal.cluster.gke.io/v1
Kind:         HealthCheck
...
Status:
  Checks:
    192.0.2.57:
      Job UID:  492af995-3bd5-4441-a950-f4272cb84c83
      Message:  following checks failed, ['check_kubelet_pass']
      Pass:     false
  Failures:
    Category:     AnsibleJobFailed
    Description:  Job: machine-health-check.
    Details:       Target: 1192.0.2.57. View logs with: [kubectl logs -n cluster-user-test bm-system-192.0.2.57-machine-28303170-qgmhn].
    Reason:       following checks failed, ['check_kubelet_pass']
  Pass:                  false
  Periodic:
    Last Schedule Time:                    2023-10-24T23:04:21Z
    Last Successful Instrumentation Time:  2023-10-24T23:31:30Z
  ...

Para obtener una lista de verificaciones de estado para métricas, usa el siguiente comando:

kubectl get healthchecks.anthos.gke.io --kubeconfig CLUSTER_KUBECONFIG --namespace kube-system

Reemplaza CLUSTER_KUBECONFIG por la ruta de acceso del archivo kubeconfig del clúster de destino.

En el siguiente ejemplo, se muestra el formato de la respuesta:

NAMESPACE     NAME                                            COMPONENT   NAMESPACE   STATUS    LAST_COMPLETED
kube-system   bm-system-10.200.0.3-machine                                            Healthy   56m
kube-system   bm-system-add-ons-add-ons                                               Healthy   48m
kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
kube-system   bm-system-kubernetes                                                    Healthy   57m
kube-system   bm-system-kubernetes-1.16.1-non-periodic                                Healthy   25d
kube-system   bm-system-network                                                       Healthy   32m
kube-system   check-kubernetes-20231114-190445-non-periodic                           Healthy   3h6m
kube-system   component-status-controller-manager                                     Healthy   5s
kube-system   component-status-etcd-0                                                 Healthy   5s
kube-system   component-status-etcd-1                                                 Healthy   5s
kube-system   component-status-scheduler                                              Healthy   5s

Trabajos cron de verificación de estado

Para las verificaciones de estado periódicas, cada recurso personalizado HealthCheck de Bare Metal tiene un CronJob correspondiente con el mismo nombre. Este CronJob es responsable de programar la verificación de estado correspondiente para que se ejecute en intervalos establecidos.

Para recuperar información sobre los trabajos cron, sigue estos pasos:

Obtén una lista de trabajos cron que se ejecutaron para un clúster determinado:
```
kubectl get cronjobs --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
```
Reemplaza lo siguiente:
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
- CLUSTER_NAMESPACE: el espacio de nombres del clúster.
En el siguiente ejemplo, se muestra una respuesta típica:
```
NAMESPACE           NAME                           SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
cluster-test-admin   bm-system-10.200.0.3-machine   17 */1 * * *   False     0        11m             25d
cluster-test-admin   bm-system-add-ons              25 */1 * * *   False     0        3m16s           25d
cluster-test-admin   bm-system-kubernetes           16 */1 * * *   False     0        12m             25d
cluster-test-admin   bm-system-network              41 */1 * * *   False     0        47m             25d
```
Los valores en la columna SCHEDULE indican la programación de cada ejecución de trabajo de verificación de estado en la sintaxis de programación. Por ejemplo, el trabajo bm-system-kubernetes se ejecuta 17 minutos después de la hora (17) cada hora (*/1) de todos los días (* * *). Los intervalos de tiempo de las verificaciones de estado periódicas no se pueden editar, pero es útil para solucionar problemas saber cuándo se supone que deben ejecutarse.

Recupera detalles de un recurso personalizado CronJob específico:

kubectl describe cronjob CRONJOB_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

Reemplaza lo siguiente:

ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
CLUSTER_NAMESPACE: el espacio de nombres del clúster.

En el siguiente ejemplo, se muestra un CronJob exitoso:

Name:                          bm-system-network
Namespace:                     cluster-test-admin
Labels:                        AnthosBareMetalVersion=1.16.1
                              baremetal.cluster.gke.io/check-name=bm-system-network
                              baremetal.cluster.gke.io/periodic-health-check=true
                              controller-uid=2247b728-f3f5-49c2-86df-9e5ae9505613
                              type=network
Annotations:                   target: node-network
Schedule:                      41 */1 * * *
Concurrency Policy:            Forbid
Suspend:                       False
Successful Job History Limit:  1
Failed Job History Limit:      1
Starting Deadline Seconds:     <unset>
Selector:                      <unset>
Parallelism:                   <unset>
Completions:                   1
Active Deadline Seconds:       3600s
Pod Template:
  Labels:           baremetal.cluster.gke.io/check-name=bm-system-network
  Annotations:      target: node-network
  Service Account:  ansible-runner
  Containers:
  ansible-runner:
    Image:      gcr.io/anthos-baremetal-release/ansible-runner:1.16.1-gke.5
    Port:       <none>
    Host Port:  <none>
    Command:
      cluster
    Args:
      -execute-command=network-health-check
      -login-user=root
      -controlPlaneLBPort=443
    Environment:  <none>
    Mounts:
      /data/configs from inventory-config-volume (ro)
      /etc/ssh-key from ssh-key-volume (ro)
  Volumes:
  inventory-config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      bm-system-network-inventory-bm-system-ne724a7cc3584de0635099
    Optional:  false
  ssh-key-volume:
    Type:            Secret (a volume populated by a Secret)
    SecretName:      ssh-key
    Optional:        false
Last Schedule Time:  Tue, 14 Nov 2023 18:41:00 +0000
Active Jobs:         <none>
Events:
  Type    Reason            Age   From                Message
  ----    ------            ----  ----                -------
  Normal  SuccessfulCreate  48m   cronjob-controller  Created job bm-system-network-28333121
  Normal  SawCompletedJob   47m   cronjob-controller  Saw completed job: bm-system-network-28333121, status: Complete
  Normal  SuccessfulDelete  47m   cronjob-controller  Deleted job bm-system-network-28333061

Registros de verificaciones de estado

Cuando se ejecutan las verificaciones de estado, estas generan registros. Ya sea que ejecutes verificaciones de estado con bmctl o que se ejecuten de forma automática como parte de verificaciones de estado periódicas, los registros se envían a Cloud Logging. Cuando ejecutas verificaciones de estado a pedido, los archivos de registro se crean en una carpeta con marca de tiempo en el directorio log/ de la carpeta del clúster en la estación de trabajo de administrador. Por ejemplo, si ejecutas el comando bmctl check kubernetes para un clúster llamado test-cluster, encontrarás registros en un directorio como bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923.

Visualiza registros de forma local

Puedes usar kubectl para ver los registros de las verificaciones de estado periódicas:

Obtén Pods y busca el Pod de verificación de estado específico que te interesa:

kubectl get pods --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

Reemplaza lo siguiente:

ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
CLUSTER_NAMESPACE: el espacio de nombres del clúster.

La siguiente respuesta de ejemplo muestra algunos Pods de verificación de estado:

NAME                                                              READY   STATUS      RESTARTS   AGE
bm-system-10.200.0.4-machine-28353626-lzx46                       0/1     Completed   0          12m
bm-system-10.200.0.5-machine-28353611-8vjw2                       0/1     Completed   0          27m
bm-system-add-ons-28353614-gxt8f                                  0/1     Completed   0          24m
bm-system-check-kernel-gce-user001-02fd2ac273bc18f008192e177x2c   0/1     Completed   0          75m
bm-system-cplb-init-10.200.0.4-822aa080-7a2cdd71a351c780bf8chxk   0/1     Completed   0          74m
bm-system-cplb-update-10.200.0.4-822aa082147dbd5220b0326905lbtj   0/1     Completed   0          67m
bm-system-gcp-check-create-cluster-202311025828f3c13d12f65k2xfj   0/1     Completed   0          77m
bm-system-kubernetes-28353604-4tc54                               0/1     Completed   0          34m
bm-system-kubernetes-check-bm-system-kub140f257ddccb73e32c2mjzn   0/1     Completed   0          63m
bm-system-machine-gcp-check-10.200.0.4-6629a970165889accb45mq9z   0/1     Completed   0          77m
...
bm-system-network-28353597-cbwk7                                  0/1     Completed   0          41m
bm-system-network-health-check-gce-user05e0d78097af3003dc8xzlbd   0/1     Completed   0          76m
bm-system-network-preflight-check-create275a0fdda700cb2b44b264c   0/1     Completed   0          77m

Recupera registros de Pods:

kubectl logs POD_NAME  --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

Reemplaza lo siguiente:

POD_NAME: Es el nombre del pod de verificación de estado.
ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
CLUSTER_NAMESPACE: el espacio de nombres del clúster.

En el siguiente ejemplo, se muestra parte de un registro de pod para una verificación de estado correcta de una máquina de nodo:

...
TASK [Summarize health check] **************************************************
Wednesday 29 November 2023  00:26:22 +0000 (0:00:00.419)       0:00:19.780 ****
ok: [10.200.0.4] => {
    "results": {
        "check_cgroup_pass": "passed",
        "check_cni_pass": "passed",
        "check_containerd_pass": "passed",
        "check_cpu_pass": "passed",
        "check_default_route": "passed",
        "check_disks_pass": "passed",
        "check_dns_pass": "passed",
        "check_docker_pass": "passed",
        "check_gcr_pass": "passed",
        "check_googleapis_pass": "passed",
        "check_kernel_version_pass": "passed",
        "check_kubelet_pass": "passed",
        "check_memory_pass": "passed",
        "check_pod_cidr_intersect_pass": "passed",
        "check_registry_mirror_reachability_pass": "passed",
        "check_time_sync_pass": "passed",
        "check_ubuntu_1804_kernel_version": "passed",
        "check_ufw_pass": "passed",
        "check_vcpu_pass": "passed"
    }
}
...

En el siguiente ejemplo, se muestra parte de un registro de pod de verificación de estado de la máquina de nodo con errores. La muestra muestra que la verificación de kubelet (check_kubelet_pass) falló, lo que indica que kubelet no se está ejecutando en este nodo.

...
TASK [Reach a final verdict] ***************************************************
Thursday 02 November 2023  17:30:19 +0000 (0:00:00.172)       0:00:17.218 *****
fatal: [10.200.0.17]: FAILED! => {"changed": false, "msg": "following checks failed, ['check_kubelet_pass']"}
...

Ver registros en Cloud Logging

Los registros de verificaciones de estado se transmiten a Cloud Logging y se pueden ver en el Explorador de registros. Las verificaciones de estado periódicas se clasifican como Pods en los registros de la consola.

En la consola de Google Cloud, ve a la página Explorador de registros en el menú de Logging.

Ir al Explorador de registros

En el campo Consulta, ingresa la siguiente consulta básica:

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system.*-machine.*"

En la ventana Resultados de la consulta, se muestran los registros de las verificaciones de estado de la máquina de nodos.

A continuación, se incluye una lista de consultas para verificaciones de estado periódicas:

Máquina de nodo

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system.*-machine.*"

Red

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system-network.*"

Kubernetes

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system-kubernetes.*"

Complementos

resource.type="k8s_container"
resource.labels.pod_name=~"bm-system-add-ons.*"

Verificaciones de estado periódicas

De forma predeterminada, las verificaciones de estado periódicas se ejecutan cada hora y comprueban los siguientes componentes del clúster:

Machine
Red
Kubernetes
Complementos

Para verificar el estado del clúster, observa los recursos personalizados HealthCheck (healthchecks.baremetal.cluster.gke.io) de Bare Metal en el clúster de administrador. Las verificaciones de red, Kubernetes y complementos son verificaciones a nivel del clúster, por lo que hay un solo recurso para cada verificación. Se ejecuta una verificación de máquina para cada nodo en el clúster de destino, por lo que hay un recurso para cada nodo.

Si quieres enumerar los recursos HealthCheck de Bare Metal para un clúster determinado, ejecuta el siguiente comando:

kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE

Reemplaza lo siguiente:

ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
CLUSTER_NAMESPACE: Es el espacio de nombres del clúster de destino de la verificación de estado.

La siguiente respuesta de ejemplo muestra el formato:

NAMESPACE               NAME                               PASS    AGE
cluster-test-user001    bm-system-192.0.2.53-machine       true    56d
cluster-test-user001    bm-system-192.0.2.54-machine       true    56d
cluster-test-user001    bm-system-add-ons                  true    56d
cluster-test-user001    bm-system-kubernetes               true    56d
cluster-test-user001    bm-system-network                  true    56d

El campo Pass de healthchecks.baremetal.cluster.gke.io indica si la última verificación de estado se aprobó (true) o falló (false).

Para obtener más información sobre cómo verificar el estado de las verificaciones de estado periódicas, consulta Recursos personalizados de HealthCheck y Registros de verificaciones de estado.

Inhabilita las verificaciones de estado periódicas

Las verificaciones de estado periódicas están habilitadas de forma predeterminada en todos los clústeres. Puedes inhabilitar las verificaciones de estado periódicas de un clúster si configuras el campo periodicHealthCheck.enable como false en el recurso Clúster.

Para inhabilitar las verificaciones de estado periódicas, haz lo siguiente:

Edita el archivo de configuración del clúster, agrega el campo periodicHealthCheck.enable a la especificación del clúster y establece su valor como false:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
spec:
  type: user
  profile: default
  ...
  periodicHealthCheck:
    enable: false
  ...

Actualiza el clúster mediante la ejecución del comando bmctl update:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster que deseas actualizar.
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
Para verificar que se hayan inhabilitado las verificaciones de estado periódicas, ejecuta el siguiente comando a fin de confirmar que se hayan borrado los recursos healthchecks.baremetal.cluster.gke.io correspondientes:
```
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Reemplaza lo siguiente:
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
- CLUSTER_NAMESPACE: Es el espacio de nombres del clúster de destino de la verificación de estado.

Vuelve a habilitar verificaciones de estado periódicas

Las verificaciones de estado periódicas están habilitadas de forma predeterminada en todos los clústeres. Si inhabilitaste las verificaciones de estado periódicas, puedes volver a habilitarlas mediante la configuración del campo periodicHealthCheck.enable como true en el recurso del clúster.

Para volver a habilitar las verificaciones de estado periódicas, haz lo siguiente:

Edita el archivo de configuración del clúster, agrega el campo periodicHealthCheck.enable a la especificación del clúster y establece su valor como true:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user-basic
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user-basic
  namespace: cluster-user-basic
spec:
  type: user
  profile: default
  ...
  periodicHealthCheck:
    enable: true
  ...

Actualiza el clúster mediante la ejecución del comando bmctl update:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster que deseas actualizar.
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
Para verificar que las verificaciones de estado periódicas estén habilitadas, ejecuta el siguiente comando para confirmar que los recursos healthchecks.baremetal.cluster.gke.io correspondientes estén presentes:
```
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Reemplaza lo siguiente:
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador
- CLUSTER_NAMESPACE: Es el espacio de nombres del clúster de destino de la verificación de estado.
Es posible que los recursos tarden un par de minutos en aparecer.

Verificaciones de estado a pedido

En las siguientes secciones, se describen las verificaciones de estado que puedes ejecutar a pedido con bmctl check. Cuando usas bmctl check para ejecutar verificaciones de estado, se aplican las siguientes reglas:

Cuando verifiques un clúster de usuario con un comando bmctl check, especifica la ruta de acceso del archivo kubeconfig para el clúster de administrador con la marca --kubeconfig.
Los registros se generan en un directorio con marca de tiempo en la carpeta de registros del clúster en la estación de trabajo de administrador (de forma predeterminada, bmctl-workspace/CLUSTER_NAME/log).
Los registros de verificaciones de estado también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de verificación de estado.

Si deseas obtener más información sobre las opciones para los comandos bmctl, consulta la referencia de los comandos bmctl.

Complementos

Comprueba que funcionen los complementos de Kubernetes especificados para el clúster especificado.

Para verificar los complementos de un clúster, sigue estos pasos:
```
bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster que estás verificando.
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

Para obtener una lista de lo que está marcado, consulta Complementos en la sección Contenido marcado de este documento.

Con esta verificación, se generan archivos de registro en un directorio check-addons-TIMESTAMP en la carpeta de registro del clúster en la estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de verificación de estado.

Clúster

Verifica todos los nodos del clúster, las redes de nodos, Kubernetes y los complementos del clúster especificado. Proporcionas el nombre del clúster y bmctl busca el archivo de configuración del clúster en bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml de forma predeterminada.

Para verificar el estado de un clúster, sigue estos pasos:
```
bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster que estás verificando.
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

Para obtener una lista de lo que está verificado, consulta las siguientes secciones de la sección Lo que se verificó de este documento:

Verificaciones a nivel de la máquina de nodos
Verificaciones de la red
Kubernetes
Complementos

Con esta verificación, se generan archivos de registro en un directorio check-cluster-TIMESTAMP en la carpeta de registro del clúster en la estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de verificación de estado.

Configuración

Verifica el archivo de configuración del clúster. Esta verificación espera que hayas generado el archivo de configuración y lo hayas editado para especificar los detalles de configuración del clúster. El propósito de este comando es determinar si algún parámetro de configuración es incorrecto, falta o tiene errores de sintaxis. Debes proporcionar el nombre del clúster y bmctl busca el archivo de configuración del clúster en bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml, de forma predeterminada.

Para verificar un archivo de configuración de clúster, sigue estos pasos:
```
bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster que estás verificando.
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

Este comando verifica la sintaxis YAML del archivo de configuración del clúster, el acceso a Google Cloud y los permisos de la cuenta de servicio especificada en el archivo de configuración del clúster.

Con esta verificación, se generan archivos de registro en un directorio check-config-TIMESTAMP en la carpeta de registro del clúster en la estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de verificación de estado.

GCP

Comprueba que todas las máquinas de nodos del clúster puedan acceder a Container Registry (gcr.io) y al extremo de las API de Google (googleapis.com).

Para verificar el acceso del clúster a los recursos de Google Cloud requeridos, sigue estos pasos:
```
bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster que estás verificando.
- ADMIN_KUBECONFIG: la ruta del archivo kubeconfig del clúster de administrador

Con esta verificación, se generan archivos de registro en un directorio check-gcp-TIMESTAMP en la carpeta de registro del clúster en la estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de verificación de estado.

Kubernetes

Verifica el estado de los operadores críticos de Kubernetes que se ejecutan en el plano de control. Esta verificación verifica que los operadores críticos estén funcionando correctamente y que sus Pods no fallen. Esta verificación de estado no muestra un error si falta alguno de los componentes del plano de control: solo muestra errores si los componentes existen y tienen errores en el momento de la ejecución del comando.

Sigue estos pasos para verificar el estado de los componentes de Kubernetes en tu clúster:
```
bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster que contiene los nodos que estás verificando.
- ADMIN_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.

Para obtener una lista de lo que está marcado, consulta Kubernetes en la sección Qué se ha marcado de este documento.

Con esta verificación, se generan archivos de registro en un directorio check-kubernetes-TIMESTAMP en la carpeta de registro del clúster en la estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de verificación de estado.

Nodos

Verifica las máquinas de los nodos del clúster para confirmar que estén configuradas de forma correcta y que tengan los recursos y la conectividad suficientes para las actualizaciones y el funcionamiento del clúster.

Para verificar el estado de las máquinas de nodo en el clúster, sigue estos pasos:
```
bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIG
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster que contiene los nodos que estás verificando.
- NODE_IP_ADDRESSES: Una lista separada por comas de direcciones IP para máquinas de nodos.
- ADMIN_KUBECONFIG: Es la ruta de acceso del archivo kubeconfig del clúster de administrador.

Para obtener una lista de lo que está verificado, consulta Verificaciones de la máquina de nodos en la sección Lo que se verificó de este documento.

Con esta verificación, se generan archivos de registro para cada máquina de nodo del clúster en un directorio check-nodes-TIMESTAMP en la carpeta de registro del clúster en la estación de trabajo de administrador. Los registros también se envían a Cloud Logging. Para obtener más información sobre los registros, consulta Registros de verificación de estado.

Preliminar

Si quieres obtener información sobre el uso de bmctl para ejecutar comprobaciones preliminares, consulta Ejecuta comprobaciones preliminares a pedido para la creación de clústeres y Ejecuta comprobaciones preliminares a pedido para actualizaciones del clúster.

Verificación previa del entorno de ejecución de la VM

La verificación previa del entorno de ejecución de VM en Google Distributed Cloud valida un conjunto de requisitos previos de la máquina del nodo antes de usar el entorno de ejecución de VM en Google Distributed Cloud y de las VMs. Si falla la verificación previa del entorno de ejecución de VM en Google Distributed Cloud, se bloquea la creación de la VM. Cuando spec.enabled se configura como true en el recurso personalizado VMRuntime, la verificación previa del entorno de ejecución de VM en Google Distributed Cloud se ejecuta de forma automática.

apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
  name: vmruntime
spec:
  enabled: true
...

Para obtener más información, consulta Tiempo de ejecución de VM en la verificación previa de Google Distributed Cloud.

Verificaciones de estado

¿Qué elementos están marcados?

Verificaciones de la máquina de nodo

Verificaciones de todo el clúster

Verificaciones de red

Kubernetes

Complementos

HealthCheck recursos personalizados

Trabajos cron de verificación de estado

Registros de verificaciones de estado

Visualiza registros de forma local

Ver registros en Cloud Logging

Verificaciones de estado periódicas

Inhabilita las verificaciones de estado periódicas

Vuelve a habilitar verificaciones de estado periódicas

Verificaciones de estado a pedido

Complementos

Clúster

Configuración

GCP

Kubernetes

Nodos

Preliminar

Verificación previa del entorno de ejecución de la VM

¿Qué sigue?

`HealthCheck` recursos personalizados