Vérifications d'état

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

Qu'est-ce qui est vérifié ?

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

• Vérifications de la machine de nœud

• Vérifications à l'échelle du cluster

Les sections suivantes décrivent ce qui est vérifié pour chaque catégorie. Ces vérifications sont utilisées à la fois pour les vérifications d'état périodiques et à la demande.

Vérifications de la machine de nœud

Cette section décrit ce qui est évalué par les vérifications d'état des machines de nœuds. Ces vérifications confirment que les machines de nœuds sont correctement configurées et qu'elles disposent de suffisamment de ressources et de connectivité pour créer, mettre à niveau et exploiter un 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) exécutées dans le cluster d'administrateurs dans l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'état;état, consultez les ressources personnalisées HealthCheck.

Les vérifications courantes de machine sont les suivantes :

• Les machines du cluster utilisent un système d'exploitation (OS) compatible.

• La version de l'OS est compatible.

• Le système d'exploitation utilise une version de noyau compatible.

• L'option de compilateur opportun BPF (Just In Time) est activée pour le noyau (CONFIG_BPF_JIT=y).

• Pour Ubuntu, le pare-feu UFW (Uncomplicated Firewall) est désactivé.

• Les machines de nœuds répondent aux exigences minimales en termes de processeurs.

• Les machines de nœud disposent de plus de 20% de ressources de processeur disponibles.

• Les machines de nœuds répondent aux exigences minimales de mémoire.

• Les machines de nœuds répondent aux exigences minimales de stockage sur disque.

• La synchronisation horaire 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) est fonctionnel (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, le miroir de registre est accessible.

Les vérifications de machine Google Cloud sont les suivantes:

• Artifact 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 de la machine sont les suivantes:

• kubelet est actif et en cours d'exécution sur les machines de nœud.

• containerd est actif et en cours d'exécution sur les machines de nœud.

• L'état du point de terminaison d'intégrité de la CNI (Container Network Interface) est "OK".

• Les CIDR des pods ne se chevauchent pas avec les adresses IP des machines de nœud.

Vérifications à l'échelle du cluster

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

Vérifications par défaut

Les vérifications de cluster par défaut, qui s'exécutent automatiquement dans le cadre des vérifications d'état périodiques, peuvent également être exécutées à la demande dans le cadre des vérifications d'état du cluster. Ces vérifications garantissent que les ressources du cluster Kubernetes sont correctement configurées et fonctionnent correctement.

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

Les vérifications du cluster par défaut auditent les types et conditions de ressources suivants:

• DaemonSet

  • Les configurations sont valides
  • Les DaemonSets sont opérationnels

• Déploiement

  • Les configurations sont valides
  • Les déploiements sont opérationnels

• Nœud (toutes les conditions suivantes concernent les nœuds)

  • État de préparation du nœud
  • Pression sur le disque du kubelet
  • Pression de la mémoire du kubelet
  • Pression de l'ID de processus (PID) kubelet
  • Fréquence de redémarrage du kubelet
  • kubelet est opérationnel
  • Disponibilité du réseau
  • Fonction containerd
  • Fréquence de redémarrage de containerd
  • Fonction Docker Overlay2
  • Fréquence de redémarrage de Docker
  • Fréquence d'événement de désenregistrement d'appareil réseau
  • Interblocages du noyau
  • KubeProxy est opérationnel
  • Système de fichiers en lecture seule

• Pod

  • Les configurations sont valides
  • Les pods sont opérationnels
  • Les conteneurs sont opérationnels

• PodDisruptionBudget (PDB)

  • Les configurations sont valides
  • Fonction d'exécution PDB
  • Les PDB correspondent aux pods
  • Pods non gérés par plusieurs PDB

• Demandes de ressources

  • Les demandes de processeur et de mémoire des pods sur les nœuds cibles sont définies
  • La demande de ressources moyenne par nœud est dans la limite suivie

• Service

  • Les configurations sont valides
  • Les services sont opérationnels

• StatefulSet

  • Les configurations sont valides
  • StatefulSet

Vérifications au niveau du réseau

Les vérifications réseau du nœud de cluster côté client suivantes s'exécutent automatiquement dans le cadre des vérifications d'état périodiques. Les vérifications réseau ne peuvent pas être exécuté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'administrateurs 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.

• 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 Resolution Protocol) de couche 2. L'ARP est nécessaire pour la découverte des VIP.

• Les nœuds du plan de contrôle ont les ports 8443 et 8444 ouverts pour être utilisés par GKE Identity Service.

• Les nœuds du plan de contrôle ont les ports 2382 et 2383 ouverts pour être utilisés par l'instance etcd-events.

Kubernetes

Les vérifications Kubernetes, qui s'exécutent automatiquement dans le cadre des requêtes préliminaires et des vérifications d'état périodiques, peuvent également être exécutées à la demande. Ces vérifications d'état ne renvoient aucune erreur si l'un des composants du plan de contrôle listés est manquant. La vérification 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 ressources bm-system-kubernetes exécutées dans le cluster d'administrateurs dans l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'état;état, consultez les 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 opérationnels.

• 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 requêtes préliminaires et des vérifications d'état périodiques. Elles peuvent être exécutées à la demande. Cette vérification de l'état d'état ne renvoie aucune erreur si l'un des modules complémentaires listé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 ressources bm-system-add-ons* exécutées dans le cluster d'administrateur au sein de l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'état;état, consultez les ressources personnalisées HealthCheck.

• Les composants Stackdriver de Cloud Logging 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 n'affichent aucune modification manuelle (écart 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 HealthCheck Bare Metal bm-system-add-ons 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 pour la ressource.
• Kind: schéma de l'objet, par exemple 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 la ressource enregistré et le fichier manifeste de la ressource modifiée.

Ressources personnalisées HealthCheck

Lorsqu'une vérification de l'état'état s'exécute, 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 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 dans le cluster d'administrateur dans des espaces de noms de cluster. Les ressources HealthCheck Bare Metal sont chargées de créer des jobs et des jobs cron de vérification de l'é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 sont effectuées dans la mesure du possible. Si une mise à jour échoue en raison d'un problème, tel qu'une erreur réseau temporaire, l'échec est ignoré.

Le tableau suivant liste les types de ressources créés pour chaque catégorie HealthCheck:

Pour récupérer l'état HealthCheck, procédez comme suit :

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

2. 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 la plus récente.
   • Failures: contient des informations sur la tâche ayant échoué la plus récente.
   • Periodic: contient des informations telles que la date et l'heure de la dernière planification et instrumentation d'une tâche de vérification de l'état.

   L'exemple HealthCheck suivant est destiné à une vérification de machine réussie:

   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 de machine ayant échoué:

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

3. Pour obtenir la liste des vérifications d'état des 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 du fichier kubeconfig de votre cluster d'utilisateur.

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

   NAMESPACE     NAME                                            COMPONENT   NAMESPACE   STATUS    LAST_COMPLETED
   kube-system   bm-system-add-ons-add-ons                                               Healthy   48m
   kube-system   bm-system-add-ons-configdrift                                           Healthy   48m
   kube-system   bm-system-default-daemonset                                             Healthy   52m
   kube-system   bm-system-default-deployment                                            Healthy   52m
   kube-system   bm-system-default-node                                                  Healthy   52m
   kube-system   bm-system-default-pod                                                   Healthy   52m
   kube-system   bm-system-default-poddisruptionbudget                                   Healthy   52m
   kube-system   bm-system-default-resource                                              Healthy   52m
   kube-system   bm-system-default-service                                               Healthy   52m
   kube-system   bm-system-default-statefulset                                           Healthy   57m
   kube-system   bm-system-kubernetes                                                    Healthy   57m
   kube-system   bm-system-network                                                       Healthy   32m
   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
   

Tâches Cron de vérification de l'état

Pour les vérifications de l'état périodiques, chaque ressource personnalisée HealthCheck bare metal possède une CronJob correspondante du même nom. Cet élément CronJob est chargé de planifier l'exécution de la vérification de l'état correspondante à des intervalles définis. CronJob inclut également un conteneur ansible-runner qui exécute la vérification de l'état en établissant une connexion SSH (Secure Shell) aux nœuds.

Pour récupérer des informations sur les tâches Cron:

1. 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 typique:

   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 de l'é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 pour les vérifications d'état périodiques ne sont pas modifiables, mais il est utile de savoir quand elles sont censées s'exécuter pour résoudre les problèmes.

2. 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 de l'état

Afficher les journaux localement

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

1. Obtenez des pods et recherchez le pod de vérification de l'état de l'état 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 affiche des pods de vérification de l'é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
   

2. 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.
   • 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 d'état de 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 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 d'é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 comme pods dans les journaux de la console.

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

   Accéder à l'explorateur de journaux

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

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

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

Voici une liste de requêtes pour les vérifications d'état périodiques:

• Par défaut

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

• Machine de 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:

• Par défaut
• Machine
• Réseau
• Kubernetes
• Add-ons

Vous pouvez vérifier l'état du cluster en examinant 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 effectuées au niveau du cluster. Il n'y a donc qu'une seule ressource pour chaque vérification. Une vérification de machine est exécutée pour chaque nœud du cluster cible. Il existe donc une ressource pour chaque nœud.

• Pour lister 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 d'état.

  L'exemple de réponse suivant montre 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 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 d'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:

1. Modifiez le fichier de configuration du cluster et ajoutez le champ periodicHealthCheck.enable à la spécification de 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
     ...
   

2. Mettez à jour le cluster en exécutant la commande suivante:

   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

3. Pour vérifier que les vérifications de l'état périodiques ont été désactivées, exécutez la commande suivante pour 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 d'é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:

1. Modifiez le fichier de configuration du cluster et ajoutez le champ periodicHealthCheck.enable à la spécification de 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
     ...
   

2. Mettez à jour le cluster en exécutant la commande suivante:

   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

3. Pour vérifier que les vérifications de l'état périodiques sont activées, exécutez la commande suivante pour 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 d'état.

   L'affichage des ressources peut prendre quelques minutes.

Vérifications d'état à la demande

• Lorsque vous vérifiez un cluster d'utilisateur avec une commande bmctl check, spécifiez le chemin d'accès au fichier kubeconfig du cluster d'administrateur avec l'indicateur --kubeconfig.

• Les journaux sont générés dans un répertoire horodaté dans le dossier de journaux du cluster sur votre poste de travail administrateur (bmctl-workspace/CLUSTER_NAME/log par défaut).

• 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 autres 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 vérifié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 dans le 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 de l'é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é. Vous indiquez le nom du cluster, et bmctl recherche le fichier de configuration du cluster dans bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml, par défaut.

• 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 de la machine de nœud
• Contrôles par défaut
• Vérifications au niveau du réseau
• Kubernetes
• Add-ons

Cette vérification génère des fichiers journaux dans un répertoire check-cluster-TIMESTAMP dans le 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 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. Le but de cette commande est de déterminer si un paramètre de configuration est incorrect, manquant ou comporte des erreurs de syntaxe. Vous fournissez le nom du cluster, et bmctl recherche le fichier de configuration du cluster dans bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml par défaut.

• Pour vérifier un fichier de configuration de cluster, procédez comme suit :

  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èsGoogle 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 dans le 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 de l'état.

Connectivité avec Google Cloud

Vérifiez que toutes les machines de nœud de cluster peuvent accéder à Artifact 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 dans le 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 de l'état.

Kubernetes

Vérifiez l'état des opérateurs Kubernetes critiques exécutés dans le plan de contrôle. Cette vérification vérifie que les opérateurs critiques fonctionnent correctement et que leurs pods ne plantent pas. Cette vérification d'état ne renvoie aucune 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 Kubernetes 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-kubernetes-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 de l'état.

Nœuds

Vérifiez les machines de nœud 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 des virgules 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 de journaux du cluster sur votre poste de travail d'administration. 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 plus d'informations sur l'utilisation de bmctl pour exécuter des requêtes préliminaires, consultez les pages suivantes : Exécuter des requêtes préliminaires à la demande pour la création de clusters et Exécuter des requêtes préliminaires à la demande pour les mises à niveau de clusters.

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

La vérification préliminaire de l'environnement d'exécution des VM sur GDC valide un ensemble de conditions préalables à l'utilisation de la machine de nœud avant d'utiliser l'environnement d'exécution des VM sur GDC et les VM. Si la vérification préliminaire de l'environnement d'exécution des VM sur GDC é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 la VM sur GDC 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 GDC.

Exécuter les dernières vérifications de l'état

Les vérifications d'état (et les vérifications préliminaires) sont mises à jour à mesure que des problèmes connus sont identifiés. Pour demander à bmctl d'exécuter les vérifications à partir de la dernière image de correctif de votre version mineure installée, utilisez l'option --check-image-version latest :

bmctl check cluster --cluster CLUSTER_NAME --check-image-version latest

Remplacez CLUSTER_NAME par le nom du cluster que vous vérifiez.

Cela peut vous aider à détecter les problèmes connus récemment identifiés sans avoir à mettre à niveau votre cluster.

Vous pouvez également effectuer les dernières vérifications préliminaires avant d'installer ou de mettre à niveau un cluster. Pour en savoir plus, consultez la section Exécuter les dernières vérifications préliminaires.

Détection des dérives de configuration

Lorsque la vérification de l'état des modules complémentaires s'exécute, elle recherche, entre autres, les modifications inattendues apportées aux ressources gérées par Google Distributed Cloud. Plus précisément, la vérification évalue les fichiers manifestes de ces ressources pour déterminer si des modifications ont été apportées par des entités externes. Ces vérifications peuvent vous aider à vous prémunir contre les modifications involontaires qui pourraient nuire à l'état du cluster. Elles fournissent également des informations de dépannage précieuses.

Les fichiers manifestes vérifiés

À quelques exceptions près, la vérification de l'état des modules complémentaires examine toutes les ressources gérées par Google Distributed Cloud pour vos clusters. Il s'agit de ressources installées et gérées par le logiciel Google Distributed Cloud. Il existe des centaines de ces ressources, et la plupart de leurs fichiers manifestes sont vérifiés pour détecter les écarts de configuration. Les fichiers manifestes sont destinés à tous types de ressources, y compris, mais sans s'y limiter, les éléments suivants:

Fichiers manifestes non vérifiés

Par conception, nous excluons certains fichiers manifestes de l'examen. Pour des raisons de confidentialité et de sécurité, nous ignorons certains types de ressources, tels que les certificats, les secrets et les comptes de service. La vérification des modules complémentaires ignore également certaines ressources et champs de ressources, car nous nous attendons à ce qu'ils soient modifiés et nous ne voulons pas que ces modifications déclenchent des erreurs de dérive de configuration. Par exemple, la vérification ignore les champs replicas dans les déploiements, car l'autoscaler peut modifier cette valeur.

Comment exclure des fichiers manifestes supplémentaires ou des parties de fichiers manifestes de l'examen

En général, nous vous recommandons de ne pas modifier les ressources gérées par Google Distributed Cloud ni d'ignorer les modifications qui leur sont apportées. Cependant, nous savons que les ressources doivent parfois être modifiées pour répondre à des besoins spécifiques ou résoudre des problèmes. C'est pourquoi nous fournissons un fichier ConfigMap ignore-config-drift pour chaque cluster de votre parc. Vous utilisez ces ConfigMaps pour spécifier les ressources et les champs de ressources spécifiques à exclure de l'évaluation.

Google Distributed Cloud crée un fichier ConfigMap ignore-config-drift pour chaque cluster. Ces ConfigMaps se trouvent dans le cluster de gestion (administrateur ou hybride) sous l'espace de noms du cluster correspondant. Par exemple, si vous disposez d'un cluster d'administrateur (admin-one) qui gère deux clusters d'utilisateurs (user-one et user-two), vous pouvez trouver le ConfigMap ignore-config-drift pour le cluster user-one dans le cluster admin-one dans l'espace de noms cluster-user-one.

Pour exclure une ressource ou des champs de ressources de l'examen:

1. Ajoutez un champ data.ignore-resources au ConfigMap ignore-config-drift.

   Ce champ accepte un tableau de chaînes JSON, chaque chaîne spécifiant une ressource et, éventuellement, des champs spécifiques de la ressource.

2. Spécifiez la ressource et, éventuellement, les champs spécifiques à ignorer en tant qu'objet JSON dans le tableau de chaînes:

   L'objet JSON d'une ressource et de ses champs a la structure suivante:

   {
     "Version": "RESOURCE_VERSION",
     "Kind": "RESOURCE_KIND",
     "Namespace": "RESOURCE_NAMESPACE",
     "Name": "RESOURCE_NAME",
     "Fields": [
       "FIELD_1_NAME",
       "FIELD_2_NAME",
       ...
       "FIELD_N_NAME"
     ]
   }
   

   Remplacez les éléments suivants :

   • RESOURCE_VERSION: (facultatif) valeur apiVersion de la ressource.

   • RESOURCE_KIND: (facultatif) valeur kind de la ressource.

   • RESOURCE_NAMESPACE: (facultatif) valeur metadata.namespace de la ressource.

   • RESOURCE_NAME: (facultatif) valeur metadata.name de la ressource.

   • FIELD_NAME (facultatif) : spécifiez un tableau de champs de ressources à ignorer. Si vous ne spécifiez aucun champ, la vérification des modules complémentaires ignore toutes les modifications apportées à la ressource.

   Chacun des champs de l'objet JSON est facultatif. Par conséquent, diverses permutations sont autorisées. Vous pouvez exclure des catégories entières de ressources, ou être très précis et exclure des champs spécifiques d'une ressource spécifique.

   Par exemple, si vous souhaitez que la vérification des modules complémentaires ignore les modifications apportées uniquement à la section command du déploiement ais sur votre cluster d'administration, le fichier JSON peut se présenter comme suit:

   {
     "Version": "apps/v1",
     "Kind": "Deployment",
     "Namespace": "anthos-identity-service",
     "Name": "ais",
     "Fields": [
       "command"
     ]
   }
   

   Vous devez ajouter cet objet JSON à ignore-resources dans le ConfigMap config-drift-ignore en tant que valeur de chaîne dans un tableau, comme illustré dans l'exemple suivant:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     creationTimestamp: "2024-09-24T00:39:45Z"
     name: config-drift-ignore
     namespace: cluster-example-admin
     ownerReferences:
     - apiVersion: baremetal.cluster.gke.io/v1
       kind: Cluster
       name: example-admin
     ...
   data:
     ignore-resources: '[{"Version":"apps/v1","Kind":"Deployment","Namespace":"anthos-identity-service","Name":"ais","Fields":["command"]}]'
     ...
   

   Cet exemple de paramètre ConfigMap vous permet d'ajouter, de supprimer ou de modifier des champs command dans le déploiement ais sans déclencher d'erreurs de dérive de configuration. Toutefois, les modifications apportées aux champs en dehors de la section command du déploiement sont toujours détectées par la vérification des modules complémentaires et signalées comme écart de configuration.

   Si vous souhaitez exclure tous les déploiements, la valeur ignore-resources peut se présenter comme suit:

   ...
   data:
     ignore-resources: '[{"Kind":"Deployment"}]'
   ...
   

   Étant donné que ignore-resources accepte un tableau de chaînes JSON, vous pouvez spécifier plusieurs modèles d'exclusion. Si vous essayez de résoudre des problèmes ou d'expérimenter vos clusters, et que vous ne souhaitez pas déclencher d'erreurs de dérive de configuration, cette flexibilité vous permet d'exclure à la fois des ressources très ciblées et des champs de ressources ou des catégories de ressources plus larges de la détection de dérive.

Étapes suivantes

• Détecteur de problème de nœud

• Vérifier la connectivité du cluster avec nettest

• Créer des instantanés pour diagnostiquer les problèmes de cluster