Vérifications d'état

Les vérifications d'état sont un moyen de tester et de surveiller le fonctionnement de vos clusters existants. Les vérifications de l'état s'exécutent régulièrement, de manière autonome. Vous pouvez également utiliser bmctl pour exécuter des vérifications d'état à la demande. Ce document décrit chaque vérification, les circonstances dans lesquelles elle s'exécute automatiquement, comment et quand l'exécuter manuellement, et comment interpréter les résultats.

Quels sont les éléments vérifiés ?

Il existe deux catégories de GDCV pour les vérifications d'état Bare Metal:

Vérifications des machines sur les nœuds
Vérifications à l'échelle du cluster

Les sections suivantes décrivent les éléments vérifiés pour chaque catégorie. Ces vérifications sont utilisées pour les vérifications d'état périodiques et à la demande.

Vérifications des machines sur les nœuds

Cette section décrit ce qui est évalué par les vérifications de l'état des machines de nœud. Ces vérifications confirment que les machines de nœuds sont correctement configurées, et qu'elles disposent de ressources et d'une connectivité suffisantes pour la création, les mises à niveau et le fonctionnement du cluster.

Ces vérifications correspondent aux ressources personnalisées HealthCheck Bare Metal nommées bm-system-NODE_IP_ADDRESS-machine (par exemple, bm-system-192.0.2.54-machine) qui s'exécutent dans le cluster d'administrateur de l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'état;état, consultez la section Ressources personnalisées HealthCheck.

Les vérifications courantes sur les machines sont les suivantes:

Les machines de cluster utilisent un système d'exploitation (OS) compatible.
La version de l'OS est compatible.
L'OS utilise une version de noyau compatible.
L'option de compilateur JIT (Just In Time) du noyau est activée (CONFIG_BPF_JIT=y).
Sous Ubuntu, le pare-feu non complexe (UFW) est désactivé.
Les machines de nœud disposent de la configuration minimale requise en termes de processeur.
Les machines de nœud disposent de plus de 20% des ressources de processeur disponibles.
Les machines de nœud répondent aux exigences minimales de mémoire.
Les machines de nœud répondent aux exigences minimales de stockage sur disque.
La synchronisation de l'heure est configurée sur les machines de nœud.
La route par défaut pour l'acheminement des paquets vers la passerelle par défaut est présente dans les nœuds.
Le système de noms de domaine (DNS) fonctionne (cette vérification est ignorée si le cluster est configuré pour s'exécuter derrière un proxy).
Si le cluster est configuré pour utiliser un miroir de registre, celui-ci est accessible.

Les vérifications Google Cloud de la machine incluent les éléments suivants:

Container Registry, gcr.io, est accessible (cette vérification est ignorée si le cluster est configuré pour utiliser un miroir de registre).
Les API Google sont accessibles.

Les vérifications de l'état des machines se composent des éléments suivants:

kubelet est actif et s'exécute sur les machines de nœuds.
containerd est actif et s'exécute sur les machines de nœuds.
L'état du point de terminaison d'état CNI (Container Network Interface) est opérationnel.
Les CIDR des pods ne chevauchent pas les adresses IP des machines de nœuds.

Pour en savoir plus sur les exigences concernant les machines de nœud, consultez la section Prérequis pour les machines de nœud de cluster.

Vérifications à l'échelle du cluster

Cette section décrit ce qui est évalué par les vérifications d'état pour un cluster.

Vérifications du réseau

Les vérifications réseau des nœuds du cluster côté client suivantes s'exécutent automatiquement dans le cadre des vérifications d'état périodiques. Les vérifications du réseau ne peuvent pas être effectuées à la demande. Ces vérifications correspondent aux ressources personnalisées HealthCheck Bare Metal nommées bm-system-network qui s'exécutent dans le cluster d'administrateur de l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'état;état, consultez la section Ressources personnalisées HealthCheck.

Si le cluster utilise l'équilibrage de charge groupé, les nœuds du pool de nœuds d'équilibrage de charge doivent disposer d'une connectivité ARP (Address Address Resolution Protocol) de couche 2. L'ARP est requis pour la découverte d'adresses IP virtuelles.
Les ports 2382 et 2383 des nœuds du plan de contrôle sont ouverts pour que l'instance etcd-events puisse les utiliser.

Pour en savoir plus sur les protocoles et l'utilisation des ports pour vos clusters GKE sur Bare Metal, consultez la page Configuration requise pour le réseau.

Les vérifications réseau effectuées pour une vérification préliminaire diffèrent des vérifications d'état du réseau. Pour obtenir la liste des vérifications réseau pour une vérification préliminaire, consultez la section Vérifications préliminaires pour la création du cluster ou Vérifications préliminaires des mises à niveau du cluster.

Kubernetes

Les vérifications Kubernetes, qui s'exécutent automatiquement dans le cadre des vérifications d'état préliminaires et périodiques, peuvent également être exécutées à la demande. Ces vérifications d'état ne renvoient pas d'erreur si l'un des composants du plan de contrôle répertoriés est manquant. Le test ne renvoie des erreurs que si les composants existent et présentent des erreurs au moment de l'exécution de la commande.

Ces vérifications correspondent aux ressources personnalisées HealthCheck Bare Metal nommées bm-system-kubernetesressources exécutées dans le cluster d'administrateur de l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'état;état, consultez la section Ressources personnalisées HealthCheck.

le serveur d'API fonctionne.
L'opérateur anetd est correctement configuré.
Tous les nœuds du plan de contrôle sont utilisables.
Les composants du plan de contrôle suivants fonctionnent correctement:
- anthos-cluster-operator
- controller-manager
- cluster-api-provider
- ais
- capi-kubeadm-bootstrap-system
- cert-manager
- kube-dns

Modules complémentaires

Les vérifications des modules complémentaires s'exécutent automatiquement dans le cadre des vérifications préliminaires et des vérifications de l'état périodiques. Elles peuvent être exécutées à la demande. Cette vérification de l'état ne renvoie pas d'erreur si l'un des modules complémentaires répertoriés est manquant. La vérification ne renvoie des erreurs que si les modules complémentaires existent et présentent des erreurs au moment de l'exécution de la commande.

Ces vérifications correspondent aux ressources personnalisées HealthCheck Bare Metal nommées bm-system-add-ons*ressources exécutées dans le cluster d'administrateur de l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'état;état, consultez la section Ressources personnalisées HealthCheck.

Les composants Stackdriver de Cloud Logging et Connect Agent sont opérationnels:
- stackdriver-log-aggregator
- stackdriver-log-forwarder
- stackdriver-metadata-agent
- stackdriver-prometheus-k8
- gke-connect-agent
La GDCV pour les ressources gérées par Bare Metal ne comporte aucune modification manuelle (dérive de configuration):
- Les valeurs des champs n'ont pas été mises à jour
- Les champs facultatifs n'ont pas été ajoutés ni supprimés
- Les ressources n'ont pas été supprimées

Si la vérification de l'état détecte une dérive de configuration, la valeur Status.Pass de la ressource personnalisée bm-system-add-ons Bare MetalHealthCheck est définie sur false. Le champ Description de la section Failures contient des informations sur toutes les ressources qui ont été modifiées, y compris les informations suivantes:

Version: version de l'API pour la ressource.
Kind: schéma d'objet, tel que Deployment, pour la ressource.
Namespace: espace de noms dans lequel se trouve la ressource.
Name : nom de la ressource.
Diff: comparaison du format de chaîne des différences entre le fichier manifeste de la ressource enregistrée et celui de la ressource modifiée.

`HealthCheck` ressources personnalisées

Lorsqu'une vérification de l'état'état s'exécute, la GDCV pour Bare Metal crée une ressource personnalisée HealthCheck. Les ressources personnalisées HealthCheck sont persistantes et fournissent un enregistrement structuré des activités et des résultats de la vérification de l'état;état. Il existe deux catégories de ressources personnalisées HeathCheck:

Ressources personnalisées HealthCheck Bare Metal (API Version: baremetal.cluster.gke.io/v1): ces ressources fournissent des détails sur les vérifications d'état périodiques. Ces ressources se trouvent sur le cluster d'administrateur dans les espaces de noms du cluster. Les ressources HealthCheck Bare Metal sont responsables de la création de tâches et de tâches Cron de vérification de l'état'état. Ces ressources sont régulièrement mises à jour avec les résultats les plus récents.
Ressources personnalisées HealthCheck Anthos (API Version: anthos.gke.io/v1) : ces ressources permettent de générer des rapports sur les métriques de vérification de l'état#39;état. Ces ressources se trouvent dans l'espace de noms kube-system de chaque cluster. Les mises à jour de ces ressources font de votre mieux les démarches possibles. Si une mise à jour échoue à cause d'un problème, par exemple une erreur réseau temporaire, cet échec est ignoré.

Le tableau suivant répertorie les types de ressources créés pour l'une des catégories HealthCheck:

Vérifications de l'état de votre solution Bare Metal Vérifications de l'état de GKE Enterprise Gravité

Vérifications de l'état de votre solution Bare Metal	Vérifications de l'état de GKE Enterprise	Gravité
Type: machine Nom : `bm-system-NODE_IP_ADDRESS-machine`	Type: machine Nom : `bm-system-NODE_IP_ADDRESS-machine`	Critique
Type: réseau Nom : `bm-system-network`	Type: réseau Nom : `bm-system-network`	Critique
Type: kubernetes Nom : `bm-system-kubernetes`	Type: kubernetes Nom : `bm-system-kubernetes`	Critique
Type: modules complémentaires Nom : `bm-system-add-ons`	Type: modules complémentaires Nom : `bm-system-add-ons-add-ons` Nom : `bm-system-add-ons-configdrift`	Facultatif

Type: machine

Nom : bm-system-NODE_IP_ADDRESS-machine

Type: machine

Nom : bm-system-NODE_IP_ADDRESS-machine

Critique

Type: réseau

Nom : bm-system-network

Type: réseau

Nom : bm-system-network

Critique

Type: kubernetes

Nom : bm-system-kubernetes

Type: kubernetes

Nom : bm-system-kubernetes

Critique

Type: modules complémentaires

Nom : bm-system-add-ons

Type: modules complémentaires

Nom : bm-system-add-ons-add-ons

Nom : bm-system-add-ons-configdrift

Facultatif

Pour récupérer l'état HealthCheck:

Pour lire les résultats des vérifications d'état périodiques, vous pouvez obtenir les ressources personnalisées associées:

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

Remplacez ADMIN_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

L'exemple suivant montre les vérifications d'état qui s'exécutent régulièrement et indique si elles ont réussi lors de leur dernière exécution:

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

Pour lire les détails d'une vérification de l'état spécifique, utilisez kubectl describe:

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

Remplacez les éléments suivants :

HEALTHCHECK_NAME : nom de la vérification d'état.
ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
CLUSTER_NAMESPACE : espace de noms du cluster

Lorsque vous examinez la ressource, la section Status: contient les champs importants suivants:

Pass: indique si la dernière tâche de vérification de l'état'état a réussi ou non.
Checks: contient des informations sur la tâche de vérification de l'état#39;état la plus récente.
Failures: contient des informations sur le job ayant échoué le plus récent.
Periodic: contient des informations telles que la date de la dernière planification et de l'instrumentation d'une tâche de vérification de l'état.

L'exemple HealthCheck suivant correspond à une vérification réussie de la machine:

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

L'exemple HealthCheck suivant concerne une vérification ayant échoué sur une machine:

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
  ...

Pour obtenir la liste des vérifications d'état associées aux métriques, exécutez la commande suivante:

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

Remplacez CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig du cluster cible.

L'exemple suivant montre le format de la réponse:

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

Jobs Cron de vérification de l'état

Pour les vérifications d'état périodiques, chaque ressource personnalisée HealthCheck Bare Metal possède un CronJob correspondant portant le même nom. Ce CronJob est chargé de planifier l'exécution de la vérification de l'état correspondante à des intervalles définis.

Pour récupérer des informations sur les tâches Cron, procédez comme suit:

Obtenez la liste des tâches Cron exécutées pour un cluster donné:
```
kubectl get cronjobs --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE
```
Remplacez les éléments suivants :
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
- CLUSTER_NAMESPACE : espace de noms du cluster
L'exemple suivant montre une réponse type:
```
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
```
Les valeurs de la colonne SCHEDULE indiquent la planification de chaque tâche de vérification d'état exécutée dans la syntaxe de planification. Par exemple, la tâche bm-system-kubernetes s'exécute 17 minutes après l'heure (17) toutes les heures (*/1) de chaque jour (* * *). Les intervalles de temps des vérifications d'état périodiques ne sont pas modifiables, mais il est utile pour le dépannage de savoir quand elles sont censées s'exécuter.

Récupérez les détails d'une ressource personnalisée CronJob spécifique:

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

Remplacez les éléments suivants :

ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
CLUSTER_NAMESPACE : espace de noms du cluster

L'exemple suivant montre une opération CronJob réussie:

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

Journaux de vérification d'état

Lorsque des vérifications d'état sont exécutées, elles génèrent des journaux. Que vous exécutiez les vérifications d'état avec bmctl ou automatiquement lors de vérifications d'état périodiques, les journaux sont envoyés à Cloud Logging. Lorsque vous exécutez des vérifications d'état à la demande, les fichiers journaux sont créés dans un dossier horodaté dans le répertoire log/ du dossier de cluster sur votre poste de travail administrateur. Par exemple, si vous exécutez la commande bmctl check kubernetes pour un cluster nommé test-cluster, vous trouverez des journaux dans un répertoire tel que bmctl-workspace/test-cluster/log/check-kubernetes-20231103-165923.

Afficher les journaux localement

Vous pouvez utiliser kubectl pour afficher les journaux des vérifications d'état périodiques:

Obtenez des pods et recherchez celui qui vous intéresse:

kubectl get pods --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

Remplacez les éléments suivants :

ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
CLUSTER_NAMESPACE : espace de noms du cluster

L'exemple de réponse suivant montre des pods de vérification de l'état'état:

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

Récupérez les journaux des pods:

kubectl logs POD_NAME  --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

Remplacez les éléments suivants :

POD_NAME: nom du pod de la vérification de l'état.
ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
CLUSTER_NAMESPACE : espace de noms du cluster

L'exemple suivant montre une partie du journal d'un pod pour une vérification de l'état de la machine des nœuds ayant abouti:

...
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"
    }
}
...

L'exemple suivant montre une partie du journal d'un pod de vérification de l'état de la machine de nœud ayant échoué. L'exemple montre que la vérification kubelet (check_kubelet_pass) a échoué, ce qui indique que kubelet n'est pas en cours d'exécution sur ce nœud.

...
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']"}
...

Afficher les journaux dans Cloud Logging

Les journaux de vérification de l'état sont transmis à Cloud Logging et peuvent être consultés dans l'explorateur de journaux. Les vérifications d'état périodiques sont classées comme des pods dans les journaux de la console.

Dans la console Google Cloud, accédez à la page Explorateur de journaux du menu Journalisation.

Accéder à l'explorateur de journaux

Dans le champ Requête, saisissez la requête suivante :

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

La fenêtre Résultats de la requête affiche les journaux des vérifications de l'état des machines des nœuds.

Voici la liste des requêtes effectuées pour des vérifications d'état périodiques:

Machine à nœuds

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

Réseau

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

Kubernetes

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

Modules complémentaires

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

Vérifications d'état périodiques

Par défaut, les vérifications d'état périodiques s'exécutent toutes les heures et vérifient les composants de cluster suivants:

Machine
Réseau
Kubernetes
Add-ons

Vous pouvez vérifier l'état du cluster en consultant les ressources personnalisées HealthCheck (healthchecks.baremetal.cluster.gke.io) Bare Metal sur le cluster d'administrateur. Les vérifications du réseau, de Kubernetes et des modules complémentaires sont des vérifications au niveau du cluster. Il existe donc une seule ressource pour chaque vérification. Une vérification des machines est exécutée pour chaque nœud du cluster cible, de sorte qu'il existe une ressource pour chaque nœud.

Pour répertorier les ressources Bare Metal HealthCheck d'un cluster donné, exécutez la commande suivante:

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

Remplacez les éléments suivants :

ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
CLUSTER_NAMESPACE: espace de noms du cluster cible de la vérification de l'état.

L'exemple de réponse suivant indique le format:

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

Le champ Pass pour healthchecks.baremetal.cluster.gke.io indique si la dernière vérification de l'état a réussi (true) ou échoué (false).

Pour en savoir plus sur la vérification de l'état des vérifications d'état périodiques, consultez les sections Ressources personnalisées HealthCheck et Journaux de vérification d'état.

Désactiver les vérifications d'état périodiques

Les vérifications d'état périodiques sont activées par défaut sur tous les clusters. Vous pouvez désactiver les vérifications d'état périodiques pour un cluster en définissant le champ periodicHealthCheck.enable sur false dans la ressource de cluster.

Pour désactiver les vérifications d'état périodiques:

Modifiez le fichier de configuration du cluster, puis ajoutez le champ periodicHealthCheck.enable à la spécification du cluster et définissez sa valeur sur 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
  ...

Mettez à jour le cluster en exécutant la commande bmctl update:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster que vous souhaitez mettre à jour.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
Pour vérifier que les vérifications d'état périodiques ont été désactivées, exécutez la commande suivante afin de confirmer que les ressources healthchecks.baremetal.cluster.gke.io correspondantes ont été supprimées:
```
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Remplacez les éléments suivants :
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
- CLUSTER_NAMESPACE: espace de noms du cluster cible de la vérification de l'état.

Réactiver les vérifications d'état périodiques

Les vérifications d'état périodiques sont activées par défaut sur tous les clusters. Si vous avez désactivé les vérifications d'état périodiques, vous pouvez les réactiver en définissant le champ periodicHealthCheck.enable sur true dans la ressource de cluster.

Pour réactiver les vérifications d'état périodiques:

Modifiez le fichier de configuration du cluster, puis ajoutez le champ periodicHealthCheck.enable à la spécification du cluster et définissez sa valeur sur 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
  ...

Mettez à jour le cluster en exécutant la commande bmctl update:
```
bmctl update cluster -c CLUSTER_NAME --kubeconfig=ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster que vous souhaitez mettre à jour.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
Pour vérifier que les vérifications d'état périodiques sont activées, exécutez la commande suivante afin de vérifier que les ressources healthchecks.baremetal.cluster.gke.io correspondantes sont présentes:
```
kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \
    --namespace=CLUSTER_NAMESPACE
```
Remplacez les éléments suivants :
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
- CLUSTER_NAMESPACE: espace de noms du cluster cible de la vérification de l'état.
L'affichage des ressources peut prendre quelques minutes.

Vérifications d'état à la demande

Les sections suivantes décrivent les vérifications d'état que vous pouvez exécuter à la demande avec bmctl check. Lorsque vous utilisez bmctl check pour exécuter des vérifications d'état, les règles suivantes s'appliquent:

Lorsque vous vérifiez un cluster d'utilisateur à l'aide d'une commande bmctl check, spécifiez le chemin d'accès du fichier kubeconfig pour le cluster d'administrateur avec l'option --kubeconfig.
Les journaux sont générés dans un répertoire horodaté du dossier des journaux du cluster sur votre poste de travail administrateur (par défaut, bmctl-workspace/CLUSTER_NAME/log).
Les journaux de vérification de l'état sont également envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez la section Journaux de vérification d'état.

Pour en savoir plus sur les options des commandes bmctl, consultez la documentation de référence sur la commande bmctl.

Modules complémentaires

Vérifiez que les modules complémentaires Kubernetes spécifiés pour le cluster spécifié sont opérationnels.

Pour vérifier les modules complémentaires d'un cluster:
```
bmctl check add-ons --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME: nom du cluster que vous vérifiez.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

Pour obtenir la liste des éléments cochés, consultez la section Modules complémentaires dans la section "Éléments vérifiés" de ce document.

Cette vérification génère des fichiers journaux dans un répertoire check-addons-TIMESTAMP du dossier des journaux du cluster sur votre poste de travail administrateur. Les journaux sont aussi envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez la section Journaux de vérification d'état.

Cluster

Vérifiez tous les nœuds du cluster, la mise en réseau des nœuds, Kubernetes et les modules complémentaires du cluster spécifié. Par défaut, vous indiquez le nom du cluster et bmctl recherche le fichier de configuration du cluster à l'emplacement bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml.

Pour vérifier l'état d'un cluster, procédez comme suit:
```
bmctl check cluster --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME: nom du cluster que vous vérifiez.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

Pour obtenir la liste des éléments cochés, consultez les sections suivantes de la section "Éléments vérifiés" de ce document:

Vérifications au niveau des machines sur les nœuds
Vérifications du réseau
Kubernetes
Add-ons

Cette vérification génère des fichiers journaux dans un répertoire check-cluster-TIMESTAMP du dossier des journaux du cluster sur votre poste de travail administrateur. Les journaux sont aussi envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez la section Journaux de vérification d'état.

Configuration

Vérifiez le fichier de configuration du cluster. Cette vérification suppose que vous ayez généré le fichier de configuration et que vous l'ayez modifié pour spécifier les détails de configuration de votre cluster. L'objectif de cette commande est de déterminer si un paramètre de configuration est incorrect, manquant ou comporte des erreurs de syntaxe. Par défaut, vous indiquez le nom du cluster et bmctl recherche le fichier de configuration du cluster à l'adresse bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml.

Pour vérifier un fichier de configuration de cluster:
```
bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME: nom du cluster que vous vérifiez.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

Cette commande vérifie la syntaxe YAML du fichier de configuration du cluster, l'accès à Google Cloud et les autorisations du compte de service spécifié dans le fichier de configuration du cluster.

Cette vérification génère des fichiers journaux dans un répertoire check-config-TIMESTAMP du dossier des journaux du cluster sur votre poste de travail administrateur. Les journaux sont aussi envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez la section Journaux de vérification d'état.

GCP

Vérifiez que toutes les machines de nœud de cluster peuvent accéder à Container Registry (gcr.io) et au point de terminaison des API Google (googleapis.com).

Pour vérifier l'accès du cluster aux ressources Google Cloud requises, procédez comme suit:
```
bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME: nom du cluster que vous vérifiez.
- ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

Cette vérification génère des fichiers journaux dans un répertoire check-gcp-TIMESTAMP du dossier des journaux du cluster sur votre poste de travail administrateur. Les journaux sont aussi envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez la section Journaux de vérification d'état.

Kubernetes

Vérifier l'état des opérateurs Kubernetes critiques exécutés dans le plan de contrôle. Cette vérification permet de vérifier que les opérateurs critiques fonctionnent correctement et que leurs pods ne plantent pas. Cette vérification de l'état ne renvoie pas d'erreur si l'un des composants du plan de contrôle est manquant: elle ne renvoie des erreurs que si les composants existent et comportent des erreurs au moment de l'exécution de la commande.

Pour vérifier l'état des composants Kubernetes dans votre cluster, procédez comme suit:
```
bmctl check kubernetes --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME: nom du cluster contenant les nœuds que vous vérifiez.
- ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.

Pour obtenir la liste des éléments cochés, consultez la section Kubernetes dans la section Éléments cochés de ce document.

Cette vérification génère des fichiers journaux dans un répertoire check-kubernetes-TIMESTAMP du dossier de journaux du cluster sur votre poste de travail administrateur. Les journaux sont aussi envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez la section Journaux de vérification d'état.

Nœuds

Vérifiez les machines des nœuds du cluster pour vous assurer qu'elles sont correctement configurées, et qu'elles disposent de suffisamment de ressources et d'une connectivité suffisante pour les mises à niveau et le fonctionnement du cluster.

Pour vérifier l'état des machines de votre cluster, procédez comme suit:
```
bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIG
```
Remplacez les éléments suivants :
- CLUSTER_NAME: nom du cluster contenant les nœuds que vous vérifiez.
- NODE_IP_ADDRESSES: liste d'adresses IP séparées par des virgules pour les machines de nœuds.
- ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.

Pour obtenir la liste des éléments cochés, consultez la section Vérifications des machines de nœud dans la section Éléments vérifiés de ce document.

Cette vérification génère des fichiers journaux pour chaque machine de nœud de cluster dans un répertoire check-nodes-TIMESTAMP du dossier de journaux du cluster sur votre poste de travail administrateur. Les journaux sont également envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez la section Journaux de vérification d'état.

Requête préliminaire

Pour en savoir plus sur l'utilisation de bmctl pour exécuter des vérifications préliminaires, consultez Exécuter des vérifications préliminaires à la demande pour la création d'un cluster et Exécuter des vérifications préliminaires à la demande pour les mises à niveau de cluster.

Vérification préliminaire de l'environnement d'exécution de VM

La vérification préliminaire de l'environnement d'exécution de VM sur Google Distributed Cloud valide un ensemble de conditions préalables pour la machine à nœuds avant d'utiliser l'environnement d'exécution de VM sur Google Distributed Cloud et sur des VM. Si la vérification préliminaire de l'environnement d'exécution de VM sur Google Distributed Cloud échoue, la création de la VM est bloquée. Lorsque spec.enabled est défini sur true dans la ressource personnalisée VMRuntime, la vérification préliminaire de l'environnement d'exécution de VM sur Google Distributed Cloud s'exécute automatiquement.

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

Pour en savoir plus, consultez la page Vérification préliminaire de l'environnement d'exécution de VM sur Google Distributed Cloud.

Vérifications d'état

Quels sont les éléments vérifiés ?

Vérifications des machines sur les nœuds

Vérifications à l'échelle du cluster

Vérifications du réseau

Kubernetes

Modules complémentaires

HealthCheck ressources personnalisées

Jobs Cron de vérification de l'état

Journaux de vérification d'état

Afficher les journaux localement

Afficher les journaux dans Cloud Logging

Vérifications d'état périodiques

Désactiver les vérifications d'état périodiques

Réactiver les vérifications d'état périodiques

Vérifications d'état à la demande

Modules complémentaires

Cluster

Configuration

GCP

Kubernetes

Nœuds

Requête préliminaire

Vérification préliminaire de l'environnement d'exécution de VM

Étapes suivantes

`HealthCheck` ressources personnalisées