Ce document explique comment diagnostiquer les problèmes au sein de vos clusters à l'aide de gkectl diagnose
.
Présentation
L'outil gkectl
comporte deux commandes permettant de résoudre les problèmes liés aux clusters : gkectl diagnose cluster
et gkectl diagnose snapshot
. Ces commandes fonctionnent aussi bien avec les clusters d'administrateur que d'utilisateur.
gkectl diagnose cluster
Effectue des vérifications de l'état sur votre cluster et signale les erreurs. Exécute des vérifications de l'état sur les composants suivants :
- VCenter
- Identifiant
- DRS
- Groupes anti-affinité
- Réseau
- Version
- de données moyen
- Datastore
- Pool de ressources
- Dossier
- Réseau
- Équilibreur de charge (F5, Seesaw, manuel)
- Cluster d'utilisateur et pool de nœuds
- Objets du cluster
- Disponibilité du serveur Konnectivity du cluster d'utilisateur
- Objets machine et nœuds de cluster correspondants
- Pods dans les espaces de noms kube-system et gke-system
- Plan de contrôle
- Volumes persistants vSphere dans le cluster
- Processeur virtuel de cluster d'utilisateur et d'administrateur et signaux de conflit de mémoire
- Les alarmes ESXi d'utilisateur et de cluster d'administrateur préconfigurées pour l'utilisation du processeur hôte et de la mémoire
- Heure de la journée
- Règle de réseau de nœud pour un cluster avec Dataplane V2 activé
- État général de l'agent de nœud Dataplane V2
gkectl diagnose snapshot
Cette commande compresse l'état, les configurations et les journaux d'un cluster dans un fichier tarball. Si vous exécutez gkectl diagnose snapshot
, cette commande exécute automatiquement gkectl diagnose cluster
dans le cadre du processus, et les fichiers de sortie sont placés dans un nouveau dossier de l'instantané appelé /diagnose-report
.
La configuration par défaut de la commande gkectl diagnose snapshot
capture également les informations suivantes sur votre cluster:
Version de Kubernetes
État des ressources Kubernetes dans les espaces de noms kube-system et gke-system : cluster, machine, nœuds, Services, Endpoints, ConfigMaps, ReplicaSets, CronJobs, Pods et les propriétaires de ces pods, y compris les déploiements, DaemonSets et StatefulSets
État du plan de contrôle
Détails sur chaque configuration de nœud, y compris les adresses IP, les règles iptables, les points d'installation, le système de fichiers, les connexions réseau et les processus en cours d'exécution
Journaux de conteneur provenant du nœud du plan de contrôle du cluster d'administrateur lorsque le serveur d'API Kubernetes n'est pas disponible
Informations sur vSphere, y compris les objets de VM et leurs événements basés sur un pool de ressources ; également les objets de centre de données, de cluster, de réseau et de datastore associés à des VM
Informations sur l'équilibreur de charge F5 BIG-IP (y compris, serveur virtuel, adresse virtuelle, pool, nœud et surveillance)
Journaux de la commande
gkectl diagnose snapshot
Journaux des tâches préliminaires
Journaux de conteneurs dans les espaces de noms en fonction des scénarios
Informations sur l'expiration du certificat Kubernetes du cluster d'administrateur dans le fichier d'instantané
/nodes/<admin_master_node_name>/sudo_kubeadm_certs_check-expiration
Fichier d'index HTML pour tous les fichiers de l'instantané
Éventuellement, le fichier de configuration du cluster d'administrateur utilisé pour installer et mettre à jour le cluster avec l'option
--config
.
Les identifiants, y compris les identifiants vSphere et F5, sont supprimés avant la création du tarball.
Obtenir de l'aide
Pour obtenir de l'aide sur les commandes disponibles:
gkectl diagnose --help
Analyser un cluster d'administrateur
Pour diagnostiquer un cluster d'administrateur:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'administrateur.
Exemple de résultat:
Preparing for the diagnose tool... Diagnosing the cluster......DONE - Validation Category: Admin Cluster Connectivity Checking VMs TOD (availability)...SUCCESS Checking Konnectivity Server (readiness)...SUCCESS - Validation Category: Admin Cluster F5 BIG-IP Checking f5 (credentials, partition)...SUCCESS - Validation Category: Admin Cluster VCenter Checking Credentials...SUCCESS Checking DRS enabled...SUCCESS Checking Hosts for AntiAffinityGroups...SUCCESS Checking Version...SUCCESS Checking Datacenter...SUCCESS Checking Datastore...SUCCESS Checking Resource pool...SUCCESS Checking Folder...SUCCESS Checking Network...SUCCESS - Validation Category: Admin Cluster Checking cluster object...SUCCESS Checking machine deployment...SUCCESS Checking machineset...SUCCESS Checking machine objects...SUCCESS Checking kube-system pods...SUCCESS Checking anthos-identity-service pods...SUCCESS Checking storage...SUCCESS Checking resource...SUCCESS Checking virtual machine resource contention...SUCCESS Checking host resource contention...SUCCESS All validation results were SUCCESS. Cluster is healthy!
En cas de problème avec une adresse IP virtuelle (VIP) dans le cluster cible, utilisez l'indicateur --config
pour fournir le fichier de configuration du cluster d'administrateur. Vous disposez ainsi d'informations de débogage supplémentaires.
gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG
Remplacez CLUSTER_CONFIG par le chemin d'accès au fichier de configuration du cluster d'utilisateur ou d'administrateur.
Exemple de résultat :
Failed to access the api server via LB VIP "...": ... Try to use the admin master IP instead of problematic VIP... Reading config with version "[CONFIG_VERSION]" Finding the admin master VM... Fetching the VMs in the resource pool "[RESOURCE_POOL_NAME]"... Found the "[ADMIN_MASTER_VM_NAME]" is the admin master VM. Diagnosing admin|user cluster "[TARGET_CLUSTER_NAME]"... ...
Analyser un cluster d'utilisateur
Pour obtenir le nom d'un cluster d'utilisateur:
kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG
Remplacez USER_CLUSTER_KUBECONFIG par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.
Pour diagnostiquer un cluster d'utilisateur:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME
Remplacez USER_CLUSTER_NAME par le nom du cluster d'utilisateur.
Exemple de résultat :
Preparing for the diagnose tool... Diagnosing the cluster......DONE Diagnose result is saved successfully in- Validation Category: User Cluster Connectivity Checking Node Network Policy...SUCCESS Checking VMs TOD (availability)...SUCCESS Checking Dataplane-V2...Success - Validation Category: User Cluster F5 BIG-IP Checking f5 (credentials, partition)...SUCCESS - Validation Category: User Cluster VCenter Checking Credentials...SUCCESS Checking DRS enabled...SUCCESS Checking Hosts for AntiAffinityGroups...SUCCESS Checking VSphere CSI Driver...SUCCESS Checking Version...SUCCESS Checking Datacenter...SUCCESS Checking Datastore...SUCCESS Checking Resource pool...SUCCESS Checking Folder...SUCCESS Checking Network...SUCCESS - Validation Category: User Cluster Checking user cluster and node pools...SUCCESS Checking cluster object...SUCCESS Checking machine deployment...SUCCESS Checking machineset...SUCCESS Checking machine objects...SUCCESS Checking control plane pods...SUCCESS Checking kube-system pods...SUCCESS Checking gke-system pods...SUCCESS Checking gke-connect pods...SUCCESS Checeking anthos-identity-service pods...SUCCESS Checking storage...SUCCESS Checking resource...SUCCESS Checking virtual machine resource contention...SUCCESS Checking host resource contention...SUCCESS All validation results were SUCCESS. Cluster is healthy!
Résoudre les problèmes de clusters diagnostiqués
Si vous rencontrez les problèmes suivants lors de l'exécution de gkectl diagnose cluster
, voici quelques solutions.
Problème | Causes possibles : | Solution |
---|---|---|
Le serveur d'API Kubernetes est inaccessible, pour le cluster d'administrateur comme pour les clusters d'utilisateur. | Vérifiez les graphiques de latence mémoire OOB (out-of-box) de la santé de la machine virtuelle, qui doivent idéalement afficher une latence mémoire autour de zéro. Un conflit de mémoire peut également accroître l'utilisation du processeur. Les graphiques de disponibilité du processeur peuvent présenter un pic d'utilisation, en raison des échanges disque. | Augmentez la mémoire physique. Pour connaître les autres options, consultez Suggestions de dépannage de VMware. |
Le processus de création du pool de nœuds expire. | Latence de lecture/écriture élevée VMDK. Vérifiez l'état OOB de la VM pour déterminer la latence de lecture et d'écriture du disque virtuel. Selon VMware, une latence totale supérieure à 20 ms indique un problème. | Consultez la page sur les solutions VMware aux problèmes de performances de disque. |
Capturer l'état du cluster
Si gkectl diagnose cluster
détecte des erreurs, vous devez capturer l'état du cluster et fournir les informations à Google. Pour ce faire, utilisez la commande gkectl diagnose snapshot
.
gkectl diagnose snapshot
possède une option facultative, --config
. En plus de collecter des informations sur le cluster, cette option collecte le fichier de configuration Anthos clusters on VMware utilisé pour créer ou mettre à jour le cluster.
Capturer l'état du cluster d'administrateur
Pour capturer l'état d'un cluster d'administrateur, exécutez la commande suivante, où --config
est facultatif :
gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] --config
Le résultat inclut une liste de fichiers et le nom d'un fichier tarball :
Taking snapshot of admin cluster "[ADMIN_CLUSTER_NAME]"... Using default snapshot configuration... Setting up "[ADMIN_CLUSTER_NAME]" ssh key file...DONE Taking snapshots... commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_kube-system ... nodes/[ADMIN_CLUSTER_NODE]/commands/journalctl_-u_kubelet nodes/[ADMIN_CLUSTER_NODE]/files/var/log/startup.log ... Snapshot succeeded. Output saved in [TARBALL_FILE_NAME].tar.gz.Pour extraire le fichier tarball dans un répertoire, exécutez la commande suivante :
tar -zxf TARBALL_FILE_NAME --directory EXTRACTION_DIRECTORY_NAME
Pour afficher la liste des fichiers générés par l'instantané, exécutez les commandes suivantes :
cd EXTRACTION_DIRECTORY_NAME/EXTRACTED_SNAPSHOT_DIRECTORY ls kubectlCommands ls nodes/NODE_NAME/commands ls nodes/NODE_NAME/files
Pour afficher les détails d'une opération spécifique, ouvrez l'un des fichiers.
Spécifier la clé SSH pour le cluster d'administrateur
Lorsque vous obtenez un instantané du cluster d'administrateur, gkectl
trouve automatiquement la clé SSH privée du cluster d'administrateur. Vous pouvez également spécifier la clé explicitement à l'aide du paramètre --admin-ssh-key-path
.
Suivez les instructions de la section Utiliser SSH pour se connecter à un nœud de cluster afin de télécharger les clés SSH.
Ensuite, dans votre commande gkectl diagnose snapshot
, définissez --admin-ssh-key-path
sur le chemin d'accès du fichier de clé décodée :
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --admin-ssh-key-path=PATH_TO_DECODED_KEY
Capturer l'état du cluster d'utilisateur
Pour capturer l'état d'un cluster d'utilisateur, exécutez la commande suivante :
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME
Le résultat inclut une liste de fichiers et le nom d'un fichier tarball :
Taking snapshot of user cluster "[USER_CLUSTER_NAME]"... Using default snapshot configuration... Setting up "[USER_CLUSTER_NAME]" ssh key file...DONE commands/kubectl_get_pods_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user commands/kubectl_get_deployments_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_...env.default.kubeconfig_--namespace_user ... commands/kubectl_get_pods_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system commands/kubectl_get_deployments_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system commands/kubectl_get_daemonsets_-o_yaml_--kubeconfig_.tmp.user-kubeconfig-851213064_--namespace_kube-system ... nodes/[USER_CLUSTER_NODE]/commands/journalctl_-u_kubelet nodes/[USER_CLUSTER_NODE]/files/var/log/startup.log ... Snapshot succeeded. Output saved in [FILENAME].tar.gz.
Scénarios d'instantanés
La commande gkectl diagnose snapshot
accepte deux scénarios pour le cluster d'utilisateur. Pour spécifier un scénario, utilisez l'indicateur --scenario
. La liste suivante présente les valeurs possibles:
Système(par défaut): collecte un instantané avec les journaux dans les espaces de noms système compatibles.
Tous: collecter un instantané avec les journaux dans tous les espaces de noms, y compris les espaces de noms définis par l'utilisateur
Les exemples suivants illustrent certaines des possibilités.
Pour créer un instantané du cluster d'administrateur, vous n'avez pas besoin de spécifier un scénario:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
Pour créer un instantané d'un cluster d'utilisateur en utilisant le scénario system
:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=system
Pour créer un instantané d'un cluster d'utilisateur en utilisant le scénario all
:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=all
Utiliser --log-since
pour limiter un instantané
Vous pouvez utiliser l'indicateur --log-since
pour limiter la collecte de journaux à une période récente. Par exemple, vous pouvez ne collecter que les journaux des deux derniers jours ou des trois dernières heures. Par défaut, diagnose snapshot
collecte tous les journaux.
Pour limiter la période de collecte de journaux, procédez comme suit :
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=CLUSTER_NAME \ --scenario=system \ --log-since=DURATION
Remplacez DURATION par une valeur temporelle telle que 120m
ou 48h
.
Remarques :
- L'option
--log-since
n'est compatible qu'avec les journauxkubectl
etjournalctl
. - Les options de commande telles que
--log-since
ne sont pas autorisées dans la configuration de l'instantané personnalisée.
Effectuer une simulation pour un instantané
Vous pouvez utiliser l'option --dry-run
pour afficher les actions à effectuer et la configuration de l'instantané.
Pour exécuter une simulation sur votre cluster d'administrateur, saisissez la commande suivante :
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=ADMIN_CLUSTER_NAME \ --dry-run
Pour exécuter une simulation sur un cluster d'utilisateur, saisissez la commande suivante :
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --dry-run
Utiliser une configuration d'instantané
Si aucun des quatre scénarios ne répond pas à vos besoins, vous pouvez créer un instantané personnalisé en transmettant un fichier de configuration d'instantané à l'aide de l'option --snapshot-config
:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --snapshot-config=SNAPSHOT_CONFIG_FILE
Générer une configuration d'instantané
Vous pouvez générer une configuration d'instantané pour un scénario donné en transmettant les options --scenario
et --dry-run
. Par exemple, pour afficher la configuration de l'instantané du scénario par défaut (system
) d'un cluster d'utilisateur, saisissez la commande suivante :
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=system --dry-run
Le résultat ressemble à ce qui suit :
numOfParallelThreads: 10 excludeWords: - password kubectlCommands: - commands: - kubectl get clusters -o wide - kubectl get machines -o wide - kubectl get clusters -o yaml - kubectl get machines -o yaml - kubectl describe clusters - kubectl describe machines namespaces: - default - commands: - kubectl version - kubectl cluster-info - kubectl get nodes -o wide - kubectl get nodes -o yaml - kubectl describe nodes namespaces: [] - commands: - kubectl get pods -o wide - kubectl get deployments -o wide - kubectl get daemonsets -o wide - kubectl get statefulsets -o wide - kubectl get replicasets -o wide - kubectl get services -o wide - kubectl get jobs -o wide - kubectl get cronjobs -o wide - kubectl get endpoints -o wide - kubectl get configmaps -o wide - kubectl get pods -o yaml - kubectl get deployments -o yaml - kubectl get daemonsets -o yaml - kubectl get statefulsets -o yaml - kubectl get replicasets -o yaml - kubectl get services -o yaml - kubectl get jobs -o yaml - kubectl get cronjobs -o yaml - kubectl get endpoints -o yaml - kubectl get configmaps -o yaml - kubectl describe pods - kubectl describe deployments - kubectl describe daemonsets - kubectl describe statefulsets - kubectl describe replicasets - kubectl describe services - kubectl describe jobs - kubectl describe cronjobs - kubectl describe endpoints - kubectl describe configmaps namespaces: - kube-system - gke-system - gke-connect.* prometheusRequests: [] nodeCommands: - nodes: [] commands: - uptime - df --all --inodes - ip addr - sudo iptables-save --counters - mount - ip route list table all - top -bn1 - sudo docker ps -a - ps -edF - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup - sudo conntrack --count nodeFiles: - nodes: [] files: - /proc/sys/fs/file-nr - /proc/sys/net/nf_conntrack_max seesawCommands: [] seesawFiles: [] nodeCollectors: - nodes: [] f5: enabled: true vCenter: enabled: true
numOfParallelThreads
: nombre de threads parallèles utilisés pour prendre des instantanés.excludeWords
: liste des mots à exclure de l'instantané (non sensible à la casse). Les lignes contenant ces mots sont supprimées des résultats de l'instantané. "mot de passe" est toujours exclu, que vous le spécifiiez ou non.kubectlCommands
: liste des commandes kubectl à exécuter. Les résultats sont enregistrés. Les commandes s'exécutent sur les espaces de noms correspondants. Pour les commandeskubectl logs
, tous les pods et conteneurs des espaces de noms correspondants sont automatiquement ajoutés. Les expressions régulières sont compatibles avec la spécification des espaces de noms. Si vous ne spécifiez pas d'espace de noms, l'espace de nomsdefault
est utilisé.nodeCommands
: liste des commandes à exécuter sur les nœuds correspondants. Les résultats sont enregistrés. Lorsqu'aucun nœud n'est spécifié, tous les nœuds du cluster cible sont pris en compte.nodeFiles
: liste des fichiers à collecter à partir des nœuds correspondants. Les fichiers sont enregistrés. Lorsqu'aucun nœud n'est spécifié, tous les nœuds du cluster cible sont pris en compte.seesawCommands
: liste des commandes à exécuter pour collecter des informations sur l'équilibreur de charge Seesaw. Les résultats sont enregistrés si le cluster utilise l'équilibreur de charge Seesaw.seesawFiles
: liste des fichiers à collecter pour l'équilibreur de charge Seesaw.nodeCollectors
: collecteur qui exécute les nœuds Cilium pour collecter des informations eBPF.f5
: option permettant de collecter des informations liées à l'équilibreur de charge F5 BIG-IP.vCenter
: option permettant de collecter des informations liées à vCenter.prometheusRequests
: liste des requêtes Prometheus. Les résultats sont enregistrés.
Importer des instantanés dans un bucket Cloud Storage
Pour faciliter la gestion des enregistrements, l'analyse et le stockage, vous pouvez importer tous les instantanés d'un cluster spécifique dans un bucket Cloud Storage. Cela est particulièrement utile si vous avez besoin de l'aide de Cloud Customer Care.
Avant d'exécuter cette commande, assurez-vous d'avoir rempli les conditions de configuration requises.
Activez
storage.googleapis.com
dans le projet hôte du parc. Bien que vous puissiez utiliser un autre projet, le projet hôte de parc est recommandé.gcloud services enable --project=FLEET_HOST_PROJECT_ID storage.googleapis.com
Accordez le
roles/storage.admin
au compte de service de son projet parent et transmettez le fichier de clé JSON du compte de service à l'aide du paramètre--service-account-key-file
. Vous pouvez utiliser n'importe quel compte de service, mais nous vous recommandons d'utiliser le compte de service Connect Connect. Pour en savoir plus, consultez la page Comptes de service.gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \ --member "serviceAccount:CONNECT_REGISTER_SERVICE_ACCOUNT" \ --role "roles/storage.admin"
Remplacez CONNECT_REGISTER_SERVICE_ACCOUNT par le compte de service Connect Register.
Suivez les instructions pour créer un compte de service Google Cloud, si ce n'est pas déjà fait, et pour partager l'accès au bucket avec l'assistance Google Cloud.
Une fois ces conditions remplies, vous pouvez importer l'instantané à l'aide de la commande suivante :
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name CLUSTER_NAME \ --upload-to BUCKET_NAME \ --service-account-key-file SERVICE_ACCOUNT_KEY_FILE \ --share-with GOOGLE_SUPPORT_SERVICE_ACCOUNT
Remplacez SERVICE_ACCOUNT_KEY_FILE par le nom du fichier de clé de compte de service.
L'option --share-with
peut accepter une liste de noms de comptes de service. Remplacez GOOGLE_SUPPORT_SERVICE_ACCOUNT par le compte de service d'assistance Google fourni par l'assistance Google, ainsi que par tous les autres comptes de service fournis par l'assistance Google.
Si cette option est utilisée, l'option share-with
facultative doit être utilisée avec --upload-to
et --service-account-file
pour que l'instantané puisse d'abord être importé dans Cloud Storage, puis que l'autorisation de lecture puisse être partagée.
Exemple de résultat :
Using "system" snapshot configuration... Taking snapshot of user cluster CLUSTER_NAME... Setting up CLUSTER_NAME ssh key...DONE Using the gke-connect register service account key... Setting up Google Cloud Storage bucket for uploading the snapshot...DONE Taking snapshots in 10 thread(s)... ... Snapshot succeeded. Snapshots saved in "SNAPSHOT_FILE_PATH". Uploading snapshot to Google Cloud Storage...... DONE Uploaded the snapshot successfully to gs://BUCKET_NAME/CLUSTER_NAME/xSNAPSHOT_FILE_NAME. Shared successfully with service accounts: GOOGLE_SUPPORT_SERVICE_ACCOUNT
Problèmes connus
Erreur BundleUnexpectedDiff
La ressource d'API Cluster de Kubernetes gérée par un groupe de Cluster Anthos sur VMware peut être accidentellement modifiée, ce qui peut entraîner l'échec des composants système, ou la mise à niveau ou la mise à jour du cluster.
À partir de la version 1.13 de Clusters Anthos sur VMware, onprem-user-cluster-controller
vérifie régulièrement l'état des objets et signale les différences inattendues par rapport à l'état souhaité via des journaux et des événements. Ces objets incluent le plan de contrôle du cluster d'utilisateur et des modules complémentaires tels que les services et les DaemonSets.
Voici un exemple d'événement :
Type Reason Age From Message ---- ------ ---- ---- ------- Warning BundleUnexpectedDiff 13m onpremusercluster/ci-bundle-diff Detected unexpected difference of user control plane objects: [ConfigMap/istio], please check onprem-user-cluster-controller logs for more details.
Voici un exemple de journaux générés par le sous-réseau onprem-user-cluster-controller
:
2022-08-06T02:54:42.701352295Z W0806 02:54:42.701252 1 update.go:206] Detected unexpected difference of user addon object(ConfigMap/istio), Diff: map[string]string{ 2022-08-06T02:54:42.701376406Z - "mesh": ( 2022-08-06T02:54:42.701381190Z - """ 2022-08-06T02:54:42.701385438Z - defaultConfig: 2022-08-06T02:54:42.701389350Z - discoveryAddress: istiod.gke-system.svc:15012 ... 2022-08-06T02:54:42.701449954Z - """ 2022-08-06T02:54:42.701453099Z - ), 2022-08-06T02:54:42.701456286Z - "meshNetworks": "networks: {}", 2022-08-06T02:54:42.701459304Z + "test-key": "test-data", 2022-08-06T02:54:42.701462434Z }
Les événements et les journaux ne bloquent pas le fonctionnement du cluster. Les objets présentant des différences inattendues par rapport à leur état souhaité seront écrasés dans la prochaine mise à niveau du cluster.