Vérifications préliminaires

Les vérifications préliminaires sont une mesure préventive qui permet d'identifier les problèmes avant de lancer une opération de cluster majeure, telle que la création ou la mise à niveau de clusters. Lorsque ces vérifications sont exécutées automatiquement avant une opération, aucune modification n'est apportée à vos clusters, sauf si toutes les vérifications préliminaires sont réussies. Vous pouvez également exécuter des vérifications préliminaires à 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.

Dans Google Distributed Cloud, vous pouvez exécuter des vérifications préliminaires dans différentes situations :

  • Google Distributed Cloud exécute des vérifications préliminaires lorsque vous créez ou mettez à niveau des clusters et des ressources de pool de nœuds avec bmctl. En cas d'échec des vérifications, aucune modification n'est effectuée. Vous pouvez également contourner ces vérifications ou les exécuter explicitement.

  • Google Distributed Cloud exécute également des vérifications préliminaires internes lorsqu'un cluster d'administrateur ou hybride crée ou met à jour des ressources Kubernetes sur des clusters d'utilisateur. Les vérifications sont exécutées avant que les modifications ne soient appliquées aux clusters d'utilisateur concernés. En cas d'échec des vérifications, aucune modification n'est effectuée.

Ressources personnalisées PreflightCheck

Lorsqu'une vérification préliminaire est exécutée, Google Distributed Cloud crée une ressource personnalisée PreflightCheck. Les ressources personnalisées PreflightCheck sont persistantes et fournissent un enregistrement des activités et des résultats de la vérification préliminaire.

Pour récupérer des ressources personnalisées PreflightCheck, procédez comme suit :

  1. Obtenez la liste des vérifications préliminaires qui ont été exécutées pour un cluster donné :

    kubectl get preflightchecks --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

    La réponse liste les ressources par espace de noms. Vous pouvez exécuter kubectl get preflightchecks dans tous les espaces de noms pour obtenir une liste complète. Pour chaque ressource, la réponse indique l'âge de la ressource et si les vérifications préliminaires ont réussi ou non. L'exemple de réponse suivant affiche les ressources PreflightCheck pour l'espace de noms cluster-test-admin001.

    NAMESPACE              NAME                                PASS    AGE
cluster-test-admin001   test-admin001                      true    52d
cluster-test-admin001   test-admin001jkm4q                 true    52d
cluster-test-admin001   test-admin001k79t7                 true    6d20h
cluster-test-admin001   upgrade-cluster-20231106-222746    true    6d20h

  2. Récupérez les détails d'une ressource personnalisée PreflightCheck spécifique :

    kubectl describe preflightchecks --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 de commande suivant affiche une ressource PreflightCheck pour une vérification préliminaire réussie qui a été exécutée lors de la création du cluster :

    Name:         create-cluster-20230922-175006
Namespace:    cluster-test-user001
Labels:       <none>
Annotations:  <none>
API Version:  baremetal.cluster.gke.io/v1
Kind:         PreflightCheck
Metadata:
  Creation Timestamp:  2023-09-22T17:50:11Z
  Generation:          1
  Resource Version:    6502800
  UID:                 917daf64-963d-44b4-a1f9-c54972a39191
Spec:
  Check Image Version:  latest
  Config YAML:          ---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-test-user
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: test-user001
  namespace: cluster-test-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.16.0
  gkeConnect:
    projectID: clusters-project
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 192.0.2.53
  ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-test-user001
spec:
  clusterName: test-user001
  nodes:
  - address: 192.0.2.54
  ...
Status:
  Checks:
    192.0.2.53:
      Job UID:  d0b5dc1f-9d39-4cc8-b3d2-0841212f7f8c
      Message:  
      Pass:     true
    192.0.2.53-gcp:
      Job UID:  b4d96ce5-0d4e-4e3c-97db-6317e0c15fc8
      Message:  
      Pass:     true
    192.0.2.54:
      Job UID:  b67cf195-3951-46ad-b91c-0d79025cfc0a
      Message:  
      Pass:     true
    192.0.2.54-gcp:
      Job UID:  aed509e2-4bf7-44c4-bfa0-8147ef8ea74e
      Message:  
      Pass:     true
    Gcp:
      Job UID:  ac479ac4-e1c4-4681-9f2b-5773069bf6ae
      Message:  
      Pass:     true
    Node - Network:
      Job UID:  8a57c4ee-ad17-4560-8809-b117c871ad5d
      Message:  
      Pass:     true
    Pod - Cidr:
      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
  ...
  Completion Time:                 2023-09-22T17:51:22Z
  Conditions:
    Last Transition Time:  2023-10-02T23:59:06Z
    Observed Generation:   1
    Reason:                Reconciling
    Status:                True
    Type:                  Reconciling
  Node Pool Specs:
    node-pool-1:
      Cluster Name:  test-user001
      Nodes:
        Address:         192.0.2.54
    ...
  Pass:                  true
  Start Time:            2023-09-22T17:50:32Z
Events:                  <none>

    Dans la ressource personnalisée PreflightCheck précédente, la section Status contient les informations suivantes :

    • La section Checks liste les vérifications préliminaires individuelles qui ont été exécutées et indique si elles ont réussi ou non. Dans cet exemple, les vérifications suivantes ont été exécutées :
      • 192.0.2.53 et 192.0.2.54 : vérifications de nœud (configuration de l'OS, ressources et paramètres logiciels) pour les machines ayant les adresses IP 192.0.2.53 et 192.0.2.54.
      • 192.0.2.53-gpc et 192.0.2.54-gcp : Google Cloud vérifications de la connectivité (accès à Artifact Registry et à l'API Google) pour les machines ayant les adresses IP 192.0.2.53 et 192.0.2.54.
      • Gcp : Google Cloud vérifications de la connectivité pour le cluster.
      • Node - Network: vérifications du réseau (connectivité, opération etcd, accès IPV et liaison de port) pour le cluster.
      • Pod - Cidr : l'adresse IP du pod recherche les adresses qui se chevauchent pour le cluster.
    • La section Cluster Spec affiche la configuration du cluster.
    • Le champ Pass affiche true, ce qui indique que les vérifications préliminaires ont réussi collectivement.

Journaux de vérification préliminaire

Lorsque les vérifications préliminaires sont exécutées à la suite d'une commande bmctl, telle que bmctl check preflight, Google Distributed Cloud crée des fichiers journaux. Voici ce qui est généré et où :

  • Les journaux de vérification préliminaire sont générés dans un répertoire avec le modèle de dénomination suivant : preflight-TIMESTAMP.

  • Ce répertoire de vérification préliminaire est créé dans le répertoire log du cluster dans l'espace de travail bmctl. Par défaut, le log chemin d'accès au répertoire est bmctl-workspace/CLUSTER_NAME/log.

  • Les journaux de requête préliminaires se composent des fichiers suivants :

    • Fichiers journaux pour les vérifications de machine de nœud, un pour chaque nœud de cluster. Ces fichiers journaux sont nommés à l'aide de l'adresse IP du nœud. Par exemple, un nom de fichier peut être 192.0.2.53.

    • Fichiers journaux pour les Google Cloud vérifications d'accès, un pour chaque nœud de cluster. Ces fichiers journaux sont nommés à l'aide de l'adresse IP du nœud. Par exemple, un nom de fichier peut être 192.0.2.53-gcp.

    • Fichier journal pour les vérifications d'accès au cluster Google Cloud , nommé gcp.

    • Fichier journal pour les vérifications de mise en réseau des nœuds, nommé node-network.

En cas d'échec d'une vérification préliminaire, ces fichiers journaux peuvent vous aider à identifier et à résoudre le problème.

Vérifications préliminaires pour la création de clusters

Lorsque vous créez des clusters, Google Distributed Cloud exécute automatiquement des vérifications préliminaires avant toute modification sont apportées.

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

Les vérifications préliminaires pour l'installation vérifient les éléments suivants :

  • Vérifications de la machine de nœud :

    • Les machines de 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.

    • Les machines de nœud sont configurées pour utiliser cgroupsv2. La vérification échoue si
      cgroupsv1 est détecté.

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

    • Pour Ubuntu, le gestionnaire de packages apt est opérationnel et les packages requis sont disponibles.

    • Pour Red Hat Enterprise Linux, le gestionnaire de packages dnf est opérationnel et les packages requis sont disponibles.

    • Pour Red Hat Enterprise Linux, Podman n'est pas installé.

    • Les machines de nœud répondent aux exigences minimales en matière de processeur.

    • Les machines de nœud répondent aux exigences minimales en matière de mémoire.

    • Les machines de nœud répondent aux exigences minimales en matière de stockage sur disque.

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

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

    • 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 correctement. Si le cluster est configuré pour s'exécuter derrière un proxy, cette vérification est ignorée.

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

    • Si le cluster est configuré pour utiliser un miroir de registre, le miroir de registre est accessible.

  • Google Cloud vérifie chaque nœud et le cluster :

    • L'accessibilité d'Artifact Registry, gcr.io, est vérifiée. Si le cluster est configuré pour utiliser un miroir de registre, cette vérification est ignorée.

    • Les API Google sont accessibles.

  • Vérifications de la mise en réseau des nœuds (varient en fonction de la configuration de l'équilibrage de charge) :

    • L'adresse IP virtuelle du serveur d'API Kubernetes est accessible.

    • Les adresses IP virtuelles de l'équilibreur de charge sont accessibles.

    • Les nœuds peuvent communiquer sur les ports requis.

    • L'instance d'événements etcd est provisionnée et les exigences en matière de ports sont respectées.

Une fois toutes les vérifications effectuées, Google Distributed Cloud crée le cluster. Pour en savoir plus sur les exigences liées à la création de clusters, consultez la page Présentation des conditions préalables à l'installation.

Exécuter des vérifications préliminaires à la demande pour la création de clusters

Vous pouvez également effectuer des vérifications préliminaires de manière indépendante avant de créer un cluster. Cela peut être utile, car les opérations de cluster majeures, telles que la création de clusters, prennent du temps. Identifier et résoudre les problèmes séparément avant de lancer une opération de cluster majeure peut vous aider à planifier.

Clusters autogérés

  • La commande suivante valide le fichier de configuration de cluster spécifié, mais n'essaie pas de créer le cluster lui-même : 

    bmctl check config --cluster CLUSTER_NAME

    Remplacez CLUSTER_NAME par le nom du cluster associé au fichier de configuration que vous vérifiez.

  • Cette commande vérifie si les machines et le réseau sont prêts à créer le cluster :

    bmctl check preflight --cluster CLUSTER_NAME

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

Clusters d'utilisateur

  • La commande suivante valide le fichier de configuration de cluster spécifié, mais n'essaie pas de créer le cluster lui-même : 

    bmctl check config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster d'utilisateur que vous vérifiez.
    • ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur

  • La commande suivante vérifie si les machines et le réseau sont prêts à créer le cluster :

    bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG

bmctl permet d'utiliser --kubeconfig comme alias pour l'option --admin-kubeconfig.

Vérifications préliminaires pour les mises à niveau de cluster

Lorsque vous mettez à niveau des clusters, Google Distributed Cloud exécute automatiquement des vérifications préliminaires avant toute modification.

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

Les vérifications préliminaires pour les mises à niveau de cluster vérifient les éléments suivants :

  • Vérifications de la machine de nœud :

    • Les machines de 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.

    • Les machines de nœud sont configurées pour utiliser cgroupsv2. La vérification échoue si cgroupsv1 est détecté.

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

    • Les machines de nœud répondent aux exigences minimales en matière de processeur.

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

    • Les machines de nœud répondent aux exigences minimales en matière de mémoire.

    • Les machines de nœud répondent aux exigences minimales en matière 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 correctement. Si le cluster est configuré pour s'exécuter derrière un proxy, cette vérification est ignorée.

    • Si le cluster est configuré pour utiliser un miroir de registre, le miroir de registre est accessible.

    • Aucun nœud de plan de contrôle ni aucun nœud d'équilibreur de charge ne sont en mode maintenance.

  • Google Cloud vérifie chaque nœud et le cluster :

    • L'accessibilité d'Artifact Registry, gcr.io, est vérifiée. Si le cluster est configuré pour utiliser un miroir de registre, cette vérification est ignorée.

    • Les API Google sont accessibles.

  • Vérifications de la machine :

    • 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'état de fonctionnement de l'interface CNI (Container Network Interface) est "Healthy".

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

    • Les certificats kubeadm n'ont pas expiré.

  • Vérifications de la mise en réseau des nœuds (varient en fonction de la configuration de l'équilibrage de charge) :

    • L'adresse IP virtuelle du serveur d'API Kubernetes est accessible.

    • Les adresses IP virtuelles de l'équilibreur de charge sont accessibles.

    • Les nœuds peuvent communiquer sur les ports requis.

    • L'instance d'événements etcd est provisionnée et les exigences en matière de ports sont respectées.

Une fois toutes les vérifications effectuées, Google Distributed Cloud met à niveau le cluster. Pour en savoir plus sur la mise à niveau des clusters, consultez les pages Bonnes pratiques de mise à niveau des clusters Google Distributed Cloud et Cycle de vie et étapes des mises à niveau de cluster.

Exécuter des vérifications préliminaires à la demande pour les mises à niveau de cluster

La commande bmctl check preflight vous permet d'exécuter une vérification préliminaire avant de mettre à niveau votre cluster. Vous pouvez vérifier si les clusters sont prêts pour une mise à niveau en exécutant la commande de vérification préliminaire suivante avant de commencer la mise à niveau :

  1. Mettez à jour la version du cluster (anthosBareMetalVersion) dans le fichier de configuration du cluster.

  2. Utilisez la commande suivante pour vérifier si les clusters sont prêts pour une mise à niveau et exécuter une vérification préliminaire :

    bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom du cluster à mettre à niveau.
    • ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur.

    Lorsque vous créez la vérification préliminaire avec cette commande pour tester une mise à niveau de cluster, une ressource personnalisée PreflightCheck est créée dans le cluster d'administrateur.

Vérifications préliminaires internes sur les clusters existants

Google Distributed Cloud effectue automatiquement des vérifications préliminaires internes lorsque vous appliquez des ressources Kubernetes à un cluster existant. En cas d'échec d'une vérification, Google Distributed Cloud ne modifie aucun des nœuds associés, sauf si vous contournez explicitement les vérifications.

Contourner les vérifications préliminaires lors de l'application de ressources Kubernetes

Pour ignorer les vérifications préliminaires internes lors de l'application de ressources à des clusters existants, vous devez définir le champ BypassPreflightCheck sur true dans le fichier de configuration du cluster.

Voici une partie d'un fichier de configuration de cluster qui montre le champ bypassPreflightCheck défini sur true :

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  type: user
  bypassPreflightCheck: true
  # Anthos cluster version.
  anthosBareMetalVersion: 1.35.0-gke.525
...

Exécuter les dernières vérifications préliminaires

Les vérifications préliminaires (et les vérifications d'état) 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 preflight --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 à créer ou à mettre à niveau votre cluster.

Vous pouvez également effectuer les dernières vérifications d'état d'un cluster actif pour déterminer s'il fonctionne correctement. Pour en savoir plus, consultez la section Exécuter les dernières vérifications d'état.

Ignorer les résultats des vérifications préliminaires automatiques

Si vous exécutez des vérifications préliminaires à la demande avant de créer ou de mettre à niveau des clusters, vous pouvez contourner les vérifications préliminaires automatiques. Pour contourner les vérifications préliminaires automatiques, utilisez l'option facultative --force lorsque vous exécutez bmctl create cluster ou bmctl upgrade cluster.

Étape suivante