Vérifications de l'état du cluster

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 de manière autonome et périodique. Vous pouvez également utiliser gkectl diagnose cluster pour exécuter des vérifications de l'état à la demande. Ce document décrit chaque vérification, les circonstances dans lesquelles elle s'exécute automatiquement, comment et quand l'exécuter manuellement, et comment interpréter les résultats.

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

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 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 pour les nœuds. Ces vérifications confirment que les machines de nœud sont correctement configurées 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 dans l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'état;état, consultez HealthCheck ressources personnalisées.

Les vérifications courantes de machine sont les suivantes :

  • Les machines du cluster utilisent un système d'exploitation 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 des nœuds répondent aux exigences minimales en termes de processeur.

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

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

  • Les machines des nœuds répondent aux exigences minimales en termes d'espace disque.

  • La synchronisation horaire est configurée sur les machines de nœud.

  • Une 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 s'exécute sur les nœuds.

  • containerd est actif et s'exécute sur les nœuds.

  • L'état du point de terminaison d'état de l'interface réseau du conteneur (CNI) est "OK".

  • Les CIDR des pods ne chevauchent pas les adresses IP des machines des nœuds.

Pour en savoir plus sur les exigences concernant les nœuds, consultez Exigences concernant le processeur, la RAM et l'espace de stockage.

Vérifications à l'échelle du cluster

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

Vérifications 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 de l'état du cluster. Ces vérifications permettent de s'assurer 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 HealthCheck ressources personnalisées.

Les vérifications de cluster par défaut auditent les types de ressources et les conditions 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 de nœud suivantes)

    • État "Prêt" du nœud
    • Pression sur le disque kubelet
    • Pression sur la mémoire kubelet
    • Pression sur l'ID de processus (PID) kubelet
    • Fréquence de redémarrage de 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 des événements de désinscription des appareils 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 ressources mémoire et de processeur sont définies pour les pods sur les nœuds cibles.
    • La demande de ressources moyenne par nœud est inférieure à 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 des nœuds de cluster côté client suivantes s'exécutent automatiquement dans le cadre des vérifications d'état périodiques. Les vérifications du réseau ne peuvent pas être 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'administrateur dans l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'état;état, consultez 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. Le protocole ARP est requis pour la découverte de l'adresse IP virtuelle.

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

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

Pour en savoir plus sur les protocoles et l'utilisation des ports pour vos clusters, consultez Règles de proxy et de pare-feu.

Kubernetes

Les vérifications Kubernetes, qui s'exécutent automatiquement dans le cadre des vérifications préliminaires et d'état périodiques, peuvent également être exécutées à la demande. Ces vérifications de l'é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 HealthCheck ressources personnalisées.

  • 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 de l'é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 HealthCheck ressources personnalisées.

  • 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 (dérive de configuration) :

    • Les valeurs des champs n'ont pas été mises à jour

    • Aucun champ facultatif n'a été ajouté ni supprimé

    • 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 bm-system-add-ons Bare Metal 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, 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 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 la vérification de l'état;état. Il existe deux catégories de ressources personnalisées HeathCheck :

  • Ressources personnalisées HealthCheck Bare Metal (API Version: baremetal.cluster.gke.io/v1) : ces ressources fournissent des détails sur les vérifications d'état périodiques. Ces ressources se trouvent sur le cluster d'administrateur dans les espaces de noms du cluster. Les ressources Bare Metal HealthCheck sont responsables de la création de jobs et de jobs Cron de vérification de l'état. Ces ressources sont régulièrement mises à jour avec les derniers résultats.

  • Ressources personnalisées HealthCheck Anthos (API Version: anthos.gke.io/v1) : ces ressources sont utilisées pour générer des métriques de vérification de l'état. Ces ressources se trouvent dans l'espace de noms kube-system de chaque cluster. La mise à jour de ces ressources est effectuée du mieux 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 :

Contrôles de l'état Bare Metal Anthos HealthChecks Gravité

Type : par défaut

Nom : bm-system-default-daemonset

Nom : bm-system-default-deployment

Nom : bm-system-default-node

Nom : bm-system-default-pod

Nom : bm-system-default-poddisruptionbudget

Nom : bm-system-default-resource

Nom : bm-system-default-service

Nom : bm-system-default-statefulset

Type : par défaut

Nom : bm-system-default-daemonset

Nom : bm-system-default-deployment

Nom : bm-system-default-node

Nom : bm-system-default-pod

Nom : bm-system-default-poddisruptionbudget

Nom : bm-system-default-resource

Nom : bm-system-default-service

Nom : bm-system-default-statefulset

 Critique

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, 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 dernière tâche ayant échoué.
    • 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 concerne 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 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 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 ressource CronJob correspondante portant le même nom. Ce CronJob est responsable de la planification de 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#39;état en établissant une connexion Secure Shell (SSH) aux nœuds.

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

  1. Obtenez la liste des jobs Cron qui ont été exécutés 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 exécution du job de vérification de l'état dans la syntaxe de planification. Par exemple, le job 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 de l'é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

Lorsque les vérifications d'état sont exécutées, elles génèrent des journaux. Que vous exécutiez des vérifications de l'état avec gkectl diagnose cluster ou qu'elles s'exécutent automatiquement dans le cadre de vérifications de l'état périodiques, les journaux sont envoyés à Cloud Logging. Lorsque vous exécutez des vérifications d'état à la demande, des fichiers journaux sont créés dans /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log.

Afficher les journaux en local

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

  1. Obtenez les 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 d'un journal de pod de vérification de l'état de 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 des 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 :

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 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. Il existe donc une ressource pour chaque nœud.

  • Pour lister les ressources HealthCheck Bare Metal pour 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 ressources personnalisées HealthCheck et les journaux de vérification d'état.

Vérifications d'état à la demande

Pour exécuter des vérifications d'état à la demande, utilisez la commande gkectl diagnose cluster. Lorsque vous utilisez gkectl diagnose cluster pour exécuter des vérifications d'état, les règles suivantes s'appliquent :

  • Lorsque vous vérifiez un cluster d'utilisateur avec une commande gkectl diagnose cluster, 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é du dossier de journaux du cluster sur votre poste de travail administrateur (par défaut, /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log).

  • Les journaux de vérification de l'état sont également envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez Journaux des vérifications d'état.

Détection des écarts de configuration

Lorsque la vérification de l'état des modules complémentaires s'exécute, elle vérifie, 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 entités externes y ont apporté des modifications. Ces vérifications peuvent vous avertir des modifications involontaires qui pourraient nuire à l'état du cluster. Elles fournissent également des informations de dépannage utiles.

Quels fichiers manifestes sont 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 administré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 la dérive de configuration. Les fichiers manifestes concernent tous les types de ressources, y compris, mais sans s'y limiter, les suivants :

  • ClusterRoles
  • ClusterRoleBindings
  • CustomResourceDefinitions
  • DaemonSets
  • Déploiements
  • HorizontalPodAutoscalers
  • Émetteurs
  • MetricsServers
  • MutatingWebhookConfigurations
  • Espaces de noms
  • Réseaux
  • NetworkLoggings
  • PodDisruptionBudgets
  • Fournisseurs
  • Rôles
  • RoleBindings
  • Services
  • StorageClasses
  • ValidatingWebhookConfigurations

Manifestes non vérifiés

Par conception, nous excluons certains fichiers manifeste de l'examen. Pour des raisons de confidentialité et de sécurité, nous ignorons certains types de ressources spécifiques, comme les certificats, les secrets et les comptes de service. La vérification des modules complémentaires ignore également certaines ressources et certains 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.

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 nécessitent parfois des modifications pour répondre à des exigences 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'utilisateur (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 ressource 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 sous la forme d'un objet JSON dans le tableau de chaînes :

    L'objet JSON d'une ressource et de ses champs présente 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 pour la ressource.

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

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

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

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

    Chacun des champs de l'objet JSON est facultatif. Différentes permutations sont donc 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 à la section command du déploiement ais sur votre cluster d'administrateur, le code JSON peut ressembler à ce qui suit :

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

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

    Ce 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 dérive de configuration.

    Si vous souhaitez exclure tous les déploiements, la valeur ignore-resources peut ressembler à ce qui 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 résolvez des problèmes ou que vous effectuez des tests avec vos clusters, et que vous ne souhaitez pas déclencher d'erreurs de dérive de configuration, cette flexibilité permettant d'exclure de la détection de dérive à la fois des ressources et des champs de ressources très ciblés, ou des catégories de ressources plus larges, peut être utile.

Étapes suivantes

Pour en savoir plus, consultez les ressources suivantes :

Si vous avez besoin d'une aide supplémentaire, contactez Cloud Customer Care.

Vous pouvez également consulter Obtenir de l'aide pour en savoir plus sur les ressources d'assistance, y compris les suivantes :

  • Conditions requises pour ouvrir une demande d'assistance.
  • Des outils pour vous aider à résoudre les problèmes, tels que les journaux et les métriques.
  • Composants, versions et fonctionnalités compatibles de Google Distributed Cloud pour VMware (logiciel uniquement).