Les vérifications préliminaires sont une mesure préventive permettant d'identifier les problèmes avant de démarrer une opération de cluster importante, telle que la création ou la mise à niveau de clusters. Lorsque ces vérifications s'exécutent automatiquement avant une opération, aucune modification n'est apportée à vos clusters, sauf si elles réussissent toutes les vérifications préliminaires. Vous pouvez également exécuter des vérifications préliminaires à 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.
Dans GDCV pour Bare Metal, vous pouvez exécuter des vérifications préliminaires dans différentes situations:
GDCV pour Bare Metal 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. Si les vérifications échouent, aucune modification n'est apportée. Vous pouvez également ignorer ces vérifications ou les exécuter explicitement.La GDCV pour Bare Metal exécute également des vérifications préliminaires internes lorsqu'un administrateur ou un cluster 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. Si les vérifications échouent, aucune modification n'est apportée.
PreflightCheck ressources personnalisées
Lorsqu'une vérification préliminaire est exécutée, le GDCV pour Bare Metal 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 des vérifications préliminaires.
Pour récupérer PreflightCheck ressources personnalisées:
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_NAMESPACERemplacez les éléments suivants :
ADMIN_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateurCLUSTER_NAMESPACE: espace de noms du cluster
La réponse répertorie les ressources par espace de noms. Vous pouvez exécuter
kubectl get preflightcheckssur tous les espaces de noms pour obtenir une liste complète. Pour chaque ressource, la réponse indique l'âge de la ressource et indique si les vérifications préliminaires ont réussi ou non. L'exemple de réponse suivant affiche les ressourcesPreflightCheckpour l'espace de nomscluster-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 6d20hRécupérez les détails d'une ressource personnalisée
PreflightCheckspécifique:kubectl describe preflightchecks --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 de commande suivant affiche une ressource
PreflightCheckpour une vérification préliminaire réussie qui s'est 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
PreflightCheckprécédente, la sectionStatuscontient les informations suivantes:- La section
Checksrépertorie 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é effectuées :192.0.2.53et192.0.2.54: vérifications des nœuds (configuration du système d'exploitation, ressources et paramètres logiciels) pour les machines avec les adresses IP192.0.2.53et192.0.2.54.192.0.2.53-gpcet192.0.2.54-gcp: vérifications de la connectivité Google Cloud (accès à Container Registry et aux API Google) pour les machines disposant des adresses IP192.0.2.53et192.0.2.54.Gcp: vérifications de connectivité Google Cloud pour le cluster.Node - Network: vérifications réseau (connectivité, opérationetcd, accès VIP et liaison de port) pour le cluster.Pod - Cidr: recherche des adresses IP qui se chevauchent pour le cluster.
- La section
Cluster Specmontre la configuration du cluster. - Le champ
Passaffichetrue, ce qui indique que les vérifications préliminaires ont été effectuées collectivement.
Journaux des vérifications préliminaires
Lorsque des vérifications préliminaires sont exécutées à la suite d'une commande bmctl (bmctl check
preflight, par exemple), la GDCV pour Bare Metal 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 selon le modèle de dénomination suivant :
preflight-TIMESTAMP.Ce répertoire de vérifications préliminaires est créé dans le répertoire
logdu cluster, dans l'espace de travailbmctl. Par défaut, le chemin d'accès au répertoirelogestbmctl-workspace/CLUSTER_NAME/log.Les journaux préliminaires contiennent les fichiers suivants:
Fichiers journaux des vérifications des nœuds et des machines, un pour chaque nœud de cluster. Ces fichiers journaux sont nommés en utilisant l'adresse IP du nœud. Par exemple, un nom de fichier peut être
192.0.2.53.Fichiers journaux des contrôles d'accès Google Cloud, un pour chaque nœud de cluster. Ces fichiers journaux sont nommés en utilisant l'adresse IP du nœud. Par exemple, un nom de fichier peut être
192.0.2.53-gcp.Fichier journal des contrôles d'accès au cluster Google Cloud, nommé
gcp.Fichier journal des vérifications de mise en réseau des nœuds, nommé
node-network.
Si une vérification préliminaire échoue, ces fichiers journaux peuvent vous aider à identifier et à résoudre le problème.
Vérifications préliminaires pour la création du cluster
Lorsque vous créez des clusters, la GDCV pour Bare Metal 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 l'installation vérifient les points suivants:
Vérifications des machines sur les nœuds:
Les machines de cluster utilisent un système d'exploitation (OS) compatible.
La version de l'OS est compatible.
L'OS utilise une version de noyau compatible.
Sous Ubuntu, le pare-feu non complexe (UFW) est désactivé.
Pour Ubuntu, le gestionnaire de packages
aptest utilisable et les packages requis sont disponibles.Pour Red Hat Enterprise Linux, le gestionnaire de packages
dnfest utilisable et les packages requis sont disponibles.Podman n'est pas installé pour Red Hat Enterprise Linux.
Les machines de nœud disposent de la configuration minimale requise en termes 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 de l'heure est configurée sur les machines de nœud.
kubeletest actif et s'exécute sur les machines de nœuds.containerdest actif et s'exécute sur les machines de nœuds.La route par défaut pour l'acheminement 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 des pods ne chevauchent pas les adresses IP des machines de nœuds.
Si le cluster est configuré pour utiliser un miroir de registre, celui-ci est accessible.
Google Cloud vérifie chaque nœud et le cluster:
Container Registry,
gcr.io, la joignabilité 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 (selon 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
etcdest provisionnée et les exigences concernant les ports sont remplies.
Une fois toutes les vérifications effectuées, la GDCV pour Bare Metal crée le cluster. Pour en savoir plus sur les conditions requises pour créer des clusters, consultez la section Présentation des conditions préalables à l'installation.
Exécuter des vérifications préliminaires à la demande pour la création du cluster
Vous pouvez également exécuter 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 importantes, telles que la création d'un cluster, prennent beaucoup de temps. Identifier et résoudre les problèmes séparément avant de démarrer une opération de cluster importante peut faciliter la planification.
Clusters autogérés
La commande suivante valide le fichier de configuration de cluster spécifié, mais ne tente pas de créer le cluster lui-même:
bmctl check config --cluster CLUSTER_NAMERemplacez
CLUSTER_NAMEpar 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 pour la création du cluster:
bmctl check preflight --cluster CLUSTER_NAMERemplacez
CLUSTER_NAMEpar 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_KUBECONFIGRemplacez 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 associé.
La commande suivante vérifie si les machines et le réseau sont prêts pour la création du cluster:
bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG
bmctl accepte l'utilisation de --kubeconfig comme alias pour l'option --admin-kubeconfig.
Vérifications préliminaires pour les mises à niveau du cluster
Lorsque vous mettez à niveau des clusters, GDCV pour Bare Metal exécute automatiquement des vérifications préliminaires avant d'apporter des modifications.
Quels sont les éléments vérifiés ?
Les vérifications préliminaires des mises à niveau du cluster vérifient les points suivants:
Vérifications des machines sur les nœuds:
Les machines de cluster utilisent un système d'exploitation (OS) compatible.
La version de l'OS est compatible.
L'OS utilise une version de noyau compatible.
Sous Ubuntu, le pare-feu non complexe (UFW) est désactivé.
Les machines de nœud disposent de la configuration minimale requise en termes de processeur.
Les machines de nœud disposent de plus de 20% des ressources de processeur disponibles.
Les machines de nœud répondent aux exigences minimales de mémoire.
Les machines de nœud répondent aux exigences minimales de stockage sur disque.
La synchronisation de l'heure est configurée sur les machines de nœud.
La route par défaut pour l'acheminement 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, celui-ci est accessible.
* Aucun nœud du plan de contrôle ni nœud d'équilibreur de charge n'est en mode maintenance.
Google Cloud vérifie chaque nœud et le cluster:
Container Registry,
gcr.io, la joignabilité 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:
kubeletest actif et s'exécute sur les machines de nœuds.containerdest actif et s'exécute sur les machines de nœuds.L'état du point de terminaison d'état CNI (Container Network Interface) est opérationnel.
Les CIDR des pods ne chevauchent pas les adresses IP des machines de nœuds.
Vérifications de la mise en réseau des nœuds (selon 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
etcdest provisionnée et les exigences concernant les ports sont remplies.
Une fois toutes les vérifications effectuées, la GDCV pour Bare Metal met à niveau le cluster. Pour en savoir plus sur la mise à niveau des clusters, consultez les pages Bonnes pratiques concernant la GDCV pour les mises à niveau des clusters Bare Metal et Cycle de vie et étapes des mises à niveau des clusters.
Exécuter des vérifications préliminaires à la demande pour les mises à niveau du 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 lancer la mise à niveau:
Mettez à jour la version du cluster (
anthosBareMetalVersion) dans le fichier de configuration du cluster.Utilisez la commande suivante pour vérifier si les clusters sont prêts pour une mise à niveau et exécutez une vérification préliminaire:
bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIGRemplacez 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 à l'aide de cette commande pour tester la mise à niveau d'un cluster, une ressource personnalisée
PreflightCheckest créée dans le cluster d'administrateur.
Vérifications préliminaires internes sur les clusters existants
La GDCV pour Bare Metal effectue automatiquement des vérifications préliminaires internes lorsque vous appliquez des ressources Kubernetes à un cluster existant. Si des vérifications échouent, la GDCV pour Bare Metal ne modifie aucun des nœuds associés, sauf si vous ignorez 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 dans laquelle le champ bypassPreflightCheck est 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.28.400-gke.77
...
Exécuter les dernières vérifications préliminaires et vérifications d'état
Lorsque vous utilisez bmctl pour exécuter des vérifications préliminaires ou des vérifications d'état, vous pouvez ajouter l'option --check-image-version latest à la commande afin d'effectuer les vérifications à partir de la dernière version du correctif GDCV pour Bare Metal. Cela peut vous aider à identifier les problèmes connus sans avoir à créer ou mettre à niveau votre cluster au préalable.
Pour utiliser la dernière liste de vérifications afin de déterminer si vos machines et votre réseau sont prêts pour la création du cluster, procédez comme suit:
bmctl check preflight --cluster CLUSTER_NAME --check-image-version latestRemplacez
CLUSTER_NAMEpar le nom du cluster que vous vérifiez.
Vous pouvez également effectuer les dernières vérifications de l'état d'un cluster actif pour déterminer s'il est opérationnel.
Pour effectuer les vérifications d'état les plus récentes sur un cluster actif, procédez comme suit:
bmctl check cluster --cluster CLUSTER_NAME --check-image-version latestRemplacez
CLUSTER_NAMEpar le nom du cluster que vous vérifiez.
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 automatisées. Pour contourner les vérifications préliminaires automatisées, utilisez l'option --force facultative lorsque vous exécutez bmctl create cluster ou bmctl upgrade cluster.