Cette page a été traduite par l'API Cloud Translation.

Vérifications d'état

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

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

Il existe deux catégories de vérifications de l'état Google Distributed Cloud:

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

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

Vérifications des machines de nœuds

Cette section décrit les éléments évalués par les vérifications de l'état des machines de nœud. Ces vérifications confirment que les machines de nœud sont configurées correctement et qu'elles disposent de ressources et d'une connectivité suffisantes pour la création, la mise à 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 situé dans 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 de la machine comprennent les éléments suivants:

Les machines du 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) BPF est activée (CONFIG_BPF_JIT=y) sur le noyau.
Pour Ubuntu, UFW (Uncomplicated Firewall) est désactivé.
Les machines de nœud répondent à la configuration minimale requise pour le 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 le routage 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 des machines comprennent 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 incluent les éléments suivants:

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

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 les éléments évalués par les vérifications d'état d'un cluster.

Vérifications du réseau

Les vérifications suivantes du réseau de nœuds de cluster côté client s'exécutent automatiquement dans le cadre de 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 situé dans l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'é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 (Layer 2 Address Resolution Protocol). L'ARP est requis pour la découverte d'adresses IP virtuelles.
Les nœuds du plan de contrôle ont les ports 8443 et 8444 ouverts à l'utilisation par GKE Identity Service.
Les nœuds du plan de contrôle ont les ports 2382 et 2383 ouverts pour que l'instance etcd-events puisse les utiliser.

Pour en savoir plus sur les protocoles et l'utilisation des ports de vos clusters Google Distributed Cloud, consultez la page Configuration réseau requise.

Les vérifications réseau pour une vérification préliminaire diffèrent des vérifications d'état du réseau. Pour obtenir la liste des vérifications du réseau pour une vérification préliminaire, consultez la section Vérifications préliminaires pour la création de clusters ou Vérifications préliminaires pour les 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 de l'état ne renvoient pas d'erreur si l'un des composants du plan de contrôle listé est manquant. Elle 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 situé dans 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 exploitables.
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 de modules complémentaires s'exécutent automatiquement dans le cadre des vérifications préliminaires et des vérifications d'é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. Elle 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 situé dans 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 Cloud Logging Stackdriver et l'agent Connect sont opérationnels:
- stackdriver-log-aggregator
- stackdriver-log-forwarder
- stackdriver-metadata-agent
- stackdriver-prometheus-k8
- gke-connect-agent
Les ressources gérées par Google Distributed Cloud ne présentent 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 Metal HealthCheck est définie sur false. Le champ Description de la section Failures contient des détails sur toutes les ressources modifiées, y compris les informations suivantes:

Version: version de l'API de 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 au format de chaîne des différences entre le fichier manifeste de ressource enregistré et le fichier manifeste de la ressource modifiée.

`HealthCheck` ressources personnalisées

Lorsqu'une vérification de l'état est exécutée, Google Distributed Cloud 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 informations 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 chargées de créer des 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. La mise à jour de ces ressources s'effectue dans la mesure du possible. Si une mise à jour n'aboutit pas, par exemple une erreur réseau temporaire, l'échec est ignoré.

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

Vérifications d'état Bare Metal Vérifications d'état GKE Enterprise Gravité

Vérifications d'état Bare Metal	Vérifications d'état 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 exécutées 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#39;état a réussi ou non.
Checks: contient des informations sur la tâche de vérification de l'état'état la plus récente.
Failures: contient des informations sur le job en échec 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 montre que la vérification de la machine a réussi:

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 illustre l'échec de la vérification de la 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 pour les métriques, utilisez 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 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 du même nom. Ce CronJob permet 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:

Obtenez la liste des tâches Cron qui ont été 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 programmation. 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 ils sont censés 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

Lors de l'exécution des vérifications d'état, des journaux sont générés. Que vous exécutiez des vérifications d'état avec bmctl ou automatiquement dans le cadre 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/ de votre 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 les 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 le pod de vérification de l'état d'état spécifique 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 présente 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 du pod:

kubectl logs POD_NAME  --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

Remplacez les éléments suivants :

POD_NAME: nom du pod de vérification de l'état'é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 d'un journal de pod pour une vérification de l'état de la machine de nœud réussie:

...
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 d'un journal de pod de vérification de l'état de la machine de nœud ayant échoué. Cet 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 diffusés vers Cloud Logging et peuvent être consultés dans l'explorateur de journaux. Les vérifications d'état périodiques sont classées en tant que 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 d'état de la machine de nœud.

Voici une liste de requêtes associées à 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 de la machine est exécutée pour chaque nœud du cluster cible. Chaque nœud dispose donc d'une ressource.

Pour répertorier les ressources HealthCheck Bare Metal 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 a échoué (false).

Pour en savoir plus sur la vérification de l'état des vérifications d'état périodiques, consultez les pages Ressources personnalisées HealthCheck et Journaux de vérification de l'é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 "Cluster".

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

Modifiez le fichier de configuration du cluster, 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 vérifier que les ressources healthchecks.baremetal.cluster.gke.io correspondantes ont bien é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, procédez comme suit:

Modifiez le fichier de configuration du cluster, 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 au fichier kubeconfig du cluster d'administrateur avec l'option --kubeconfig.
Les journaux sont générés dans un répertoire horodaté du dossier du journal 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 de l'é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, procédez comme suit:
```
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 "Fonctionnalités vérifiées" de ce document.

Cette vérification génère des fichiers journaux dans un répertoire check-addons-TIMESTAMP du dossier du journal 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 de l'état.

Cluster

Vérifiez tous les nœuds, la mise en réseau des nœuds, Kubernetes et les modules complémentaires du cluster spécifié. Vous fournissez le nom du cluster, et bmctl recherche par défaut le fichier de configuration du cluster dans bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml.

Pour vérifier l'état d'un cluster:
```
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 vérifiés, consultez les sections suivantes de la section "Éléments vérifiés" de ce document:

Vérifications au niveau des 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 du journal 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 de l'état.

Config

Vérifiez le fichier de configuration du cluster. Cette vérification suppose que vous avez généré le fichier de configuration et que vous l'avez modifié pour spécifier les détails de configuration du cluster. L'objectif de cette commande est de déterminer si un paramètre de configuration est incorrect, manquant ou s'il comporte des erreurs de syntaxe. Vous fournissez le nom du cluster, et bmctl recherche par défaut le fichier de configuration du cluster dans 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 du journal 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 de l'état.

GCP

Vérifiez que toutes les machines de nœud du 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:
```
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 du journal 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 de l'état.

Kubernetes

Vérifiez l'état des opérateurs Kubernetes critiques s'exécutant 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 présentent des erreurs au moment de l'exécution de la commande.

Pour vérifier l'état des composants Kubernetes de votre cluster:
```
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 vérifiés, consultez la section Kubernetes de la section "Éléments vérifiés" de ce document.

Cette vérification génère des fichiers journaux dans un répertoire check-kubernetes-TIMESTAMP du dossier du journal 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 de l'é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 ressources et d'une connectivité suffisantes pour les mises à niveau et le fonctionnement du cluster.

Pour vérifier l'état des machines de nœud de votre cluster:
```
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 une virgule pour les machines de nœud.
- ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.

Pour obtenir la liste des éléments vérifiés, consultez la section Vérifications de la machine 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 journal 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 de l'état.

Requête préliminaire

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

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

La vérification préliminaire de l'environnement d'exécution des VM sur Google Distributed Cloud valide un ensemble de conditions préalables pour les machines de nœud avant d'utiliser l'environnement d'exécution des VM sur Google Distributed Cloud et les VM. Si la vérification préliminaire de l'environnement d'exécution de VM sur Google Distributed Cloud échoue, la création de 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 section Vérification préliminaire de l'environnement d'exécution des VM sur Google Distributed Cloud.

Vérifications d'état

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

Vérifications des machines de 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

Config

GCP

Kubernetes

Nœuds

Requête préliminaire

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

Étapes suivantes

`HealthCheck` ressources personnalisées