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 régulièrement de manière autonome. Vous pouvez également utiliser bmctl pour exécuter des vérifications de l'état à la demande. Ce document décrit chaque vérification, dans quelles circonstances elle s'exécute automatiquement, comment et quand l'exécuter manuellement, et comment interpréter les résultats.
Éléments vérifiés
Il existe deux catégories de vérifications d'état Google Distributed Cloud :
Vérifications de la machine de nœuds
Vérifications à l'échelle du cluster
Les sections suivantes décrivent les éléments vérifiés pour chaque catégorie. Ces vérifications sont utilisées à la fois pour les vérifications périodiques et à la demande.
Vérifications de la machine de nœuds
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œud sont correctement configurées et qu'elles disposent de suffisamment de ressources et de connectivité 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 au sein de l'espace de noms du cluster. Pour en savoir plus sur les ressources de vérification de l'état, consultez les ressources personnalisées HealthCheck.
Les vérifications courantes de machine sont les suivantes :
Les machines de cluster utilisent un système d'exploitation (OS) compatible.
La version du système d'exploitation est compatible.
Le système d'exploitation utilise une version de noyau compatible.
L'option de compilateur JIT (Just In Time) BPF est activée dans 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.
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 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) 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 pour les machines se composent des éléments suivants :
Container Registry,
gcr.ioest 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 se composent des éléments suivants :
kubeletest actif et s'exécute sur les machines de nœud.containerdest actif et en cours d'exécution 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 relatives aux machines de nœuds, consultez la section Prérequis pour les machines du nœud de cluster.
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 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 de vérifications périodiques de l'état. 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 au sein de 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 (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 ports 2382 et 2383 sont ouverts aux nœuds du plan de contrôle par l'instance
etcd-events.
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 requête préliminaire diffèrent des vérifications d'état du réseau. Pour obtenir la liste des vérifications réseau pour une requête préliminaire, consultez la section Requêtes préliminaires pour la création de cluster ou Requêtes préliminaires pour les mises à niveau des clusters.
Kubernetes
Les vérifications Kubernetes, qui s'exécutent automatiquement dans le cadre des vérifications d'état préliminaires et périodiques, peuvent également être exécutées à la demande. Ces vérifications d'état ne renvoient pas d'erreur si l'un des composants du plan de contrôle répertoriés est manquant. 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, consultez les ressources personnalisées HealthCheck.
Le serveur d'API fonctionne.
L'opérateur
anetdest 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-operatorcontroller-managercluster-api-provideraiscapi-kubeadm-bootstrap-systemcert-managerkube-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 d'état ne renvoie pas d'erreur si l'un des modules complémentaires répertoriés est manquant. La vérification ne renvoie des erreurs que si les modules complémentaires existent et présentent des erreurs au moment de l'exécution de la commande.
Ces vérifications correspondent aux ressources personnalisées HealthCheck Bare Metal nommées 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, consultez les ressources personnalisées HealthCheck.
Les composants Stackdriver de Cloud Logging et l'agent Connect sont opérationnels :
stackdriver-log-aggregatorstackdriver-log-forwarderstackdriver-metadata-agentstackdriver-prometheus-k8gke-connect-agent
Les ressources gérées par Google Distributed Cloud n'affichent aucune modification manuelle (déviation de configuration) :
Les valeurs de 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 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, par exempleDeployment, 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 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 des vérifications de l'état. Il existe deux catégories de ressources personnalisées HeathCheck :
Ressources personnalisées
HealthCheckBare 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 ressourcesHealthCheckBare Metal sont chargées de créer des tâches Cron et des tâches 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
HealthCheckAnthos (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. Ces ressources se trouvent dans l'espace de nomskube-systemde 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 :
| Vérifications de l'état Bare Metal | Vérifications de l'état de GKE Enterprise | Gravité |
|---|---|---|
|
Type : machine
Nom : |
Type : machine
Nom : |
Critique |
|
Type : réseau
Nom : |
Type: réseau
Nom : |
Critique |
|
Type : kubernetes
Nom : |
Type: kubernetes
Nom : |
Critique |
|
Type : modules complémentaires
Nom : |
Type : modules complémentaires
Nom :
Nom : |
Facultatif |
Pour récupérer l'état HealthCheck, procédez comme suit :
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-namespacesRemplacez
ADMIN_KUBECONFIGpar 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 56dPour lire les détails d'une vérification d'état spécifique, utilisez
kubectl describe:kubectl describe healthchecks.baremetal.cluster.gke.io HEALTHCHECK_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACERemplacez 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'administrateurCLUSTER_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 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écemment.Periodic: contient des informations telles que la date et l'heure de la dernière planification et instrumentation d'un job de vérification de l'état.
L'exemple
HealthChecksuivant 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 finishedL'exemple
HealthChecksuivant 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 ...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-systemRemplacez
CLUSTER_KUBECONFIGpar 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-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
Tâches 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 objet CronJob correspondant portant le même nom. Ce CronJob est chargé de planifier l'exécution de la vérification d'é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 :
Obtenez la liste des tâches cron exécutées pour un cluster donné :
kubectl get cronjobs --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACERemplacez les éléments suivants :
ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateurCLUSTER_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 25dLes valeurs de la colonne
SCHEDULEindiquent la planification de chaque tâche de vérification de l'état exécutée dans la syntaxe de planification. Par exemple, la tâchebm-system-kubernetess'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 de savoir quand elles sont censées s'exécuter pour résoudre les problèmes.Récupérez les détails d'une ressource personnalisée
CronJobspécifique :kubectl describe cronjob CRONJOB_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACERemplacez les éléments suivants :
ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateurCLUSTER_NAMESPACE: espace de noms du cluster
L'exemple suivant montre une opération
CronJobré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 d'état avec bmctl ou qu'elles s'exécutent 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é du répertoire log/ du dossier de votre 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 en local
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 qui vous intéresse :
kubectl get pods --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACERemplacez les éléments suivants :
ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateurCLUSTER_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 77mRécupérez les journaux du pod :
kubectl logs POD_NAME --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACERemplacez les éléments suivants :
POD_NAME: nom du pod de vérification d'état.ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateurCLUSTER_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 d'état de machine de nœud ayant échoué. L'exemple montre que la vérification
kubelet(check_kubelet_pass) a échoué, ce qui indique quekubeletn'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.
Dans la console Google Cloud, accédez à la page Explorateur de journaux du menu Journalisation.
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 pour les vérifications d'état périodiques :
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 de l'é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 effectuées au niveau du cluster. Il n'y a donc qu'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
HealthCheckBare Metal d'un cluster donné, exécutez la commande suivante :kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACERemplacez les éléments suivants :
ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateurCLUSTER_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 56dLe champ
Passpourhealthchecks.baremetal.cluster.gke.ioindique si la dernière vérification d'é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 sections Ressources personnalisées HealthCheck et Journaux de vérification d'état.
Désactiver les vérifications d'état périodiques
Les vérifications d'état périodiques sont activées par défaut sur tous les clusters. Vous pouvez désactiver les vérifications d'état périodiques 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 :
Modifiez le fichier de configuration du cluster et ajoutez le champ
periodicHealthCheck.enableà la spécification de cluster et définissez sa valeur surfalse: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_KUBECONFIGRemplacez 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 périodiques de l'état ont été désactivées, exécutez la commande suivante pour confirmer que les ressources
healthchecks.baremetal.cluster.gke.iocorrespondantes ont été supprimées :kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACERemplacez les éléments suivants :
ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateurCLUSTER_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 :
Modifiez le fichier de configuration du cluster et ajoutez le champ
periodicHealthCheck.enableà la spécification du cluster, puis définissez sa valeur surtrue: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_KUBECONFIGRemplacez 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 de l'état périodiques sont activées, exécutez la commande suivante pour vérifier que les ressources
healthchecks.baremetal.cluster.gke.iocorrespondantes sont présentes :kubectl get healthchecks.baremetal.cluster.gke.io --kubeconfig=ADMIN_KUBECONFIG \ --namespace=CLUSTER_NAMESPACERemplacez les éléments suivants :
ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateurCLUSTER_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
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 des journaux de cluster sur votre poste de travail administrateur (par défaut,
bmctl-workspace/CLUSTER_NAME/log).Les journaux de vérification d'é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 plus d'informations sur les autres options pour les commandes bmctl, consultez la documentation de référence sur les commandes 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_KUBECONFIGRemplacez 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 Modules complémentaires dans la section "Éléments coché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 page Journaux de vérification d'état.
Cluster
Vérifiez tous les nœuds du cluster, la mise en réseau des nœuds, Kubernetes et les modules complémentaires du cluster spécifié. 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_KUBECONFIGRemplacez 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 :
Cette vérification génère des fichiers journaux dans un répertoire check-cluster-TIMESTAMP du dossier de journal de cluster sur votre poste de travail administrateur. Les journaux sont également envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez la page Journaux de vérification d'é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 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 un fichier de configuration de cluster, procédez comme suit :
bmctl check config --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIGRemplacez 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 de journal de cluster sur votre poste de travail administrateur. Les journaux sont également envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez la page Journaux de vérification d'état.
Connectivité à Google Cloud
Vérifiez que toutes les machines de nœud de cluster peuvent accéder à Container Registry (gcr.io) et au point de terminaison des API Google (googleapis.com).
Pour vérifier l'accès du cluster aux ressources Google Cloud requises, procédez comme suit :
bmctl check gcp --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIGRemplacez 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_KUBECONFIGRemplacez 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 dans la section "Éléments à vérifier" de ce document.
Cette vérification génère des fichiers journaux dans un répertoire check-kubernetes-TIMESTAMP du dossier de journal de cluster sur votre poste de travail administrateur. Les journaux sont également envoyés à Cloud Logging. Pour en savoir plus sur les journaux, consultez la page Journaux de vérification d'é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œuds de votre cluster :
bmctl check nodes --cluster CLUSTER_NAME --addresses NODE_IP_ADDRESSES --kubeconfig ADMIN_KUBECONFIGRemplacez 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 de 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 Google Distributed Cloud valide un ensemble de conditions préalables à l'utilisation de l'environnement d'exécution des VM sur Google Distributed Cloud et des VM. Si la vérification préliminaire de l'environnement d'exécution des 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 la VM sur Google Distributed Cloud s'exécute automatiquement.
apiVersion: vm.cluster.gke.io/v1
kind: VMRuntime
metadata:
name: vmruntime
spec:
enabled: true
...
Pour en savoir plus, consultez la page Vérification préliminaire de l'environnement d'exécution de VM sur Google Distributed Cloud.
Exécuter les dernières vérifications d'état
Les vérifications d'état (et 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 mettre à niveau votre cluster au préalable.
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 page Exécuter les dernières vérifications préliminaires.