Diagnostiquer les problèmes de cluster

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
    • ResourcePool
    • 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 préconfigurées d'utilisation du processeur hôte et d'utilisation de la mémoire ESXi des clusters d'utilisateur et d'administrateur
  • 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 de 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 des espaces de noms basés sur les 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

Diagnostiquer un cluster d'administrateur

Pour diagnostiquer un cluster d'administrateur, procédez comme suit:

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'option --config pour fournir le fichier de configuration du cluster d'administrateur. Vous obtenez ainsi plus d'informations de débogage.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG

Remplacez CLUSTER_CONFIG par le chemin d'accès du fichier de configuration du cluster d'administrateur ou d'utilisateur.

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]"...
...

Diagnostiquer 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, procédez comme suit:

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

ProblèmeCauses 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 GKE sur VMware qui a été utilisé pour créer ou mettre à niveau 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 pour vous connecter à un nœud de cluster via SSH 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 indique les valeurs possibles:

  • Système(par défaut): collecte un instantané avec des journaux dans les espaces de noms système compatibles.

  • Tous: collecte d'instantanés avec les journaux dans tous les espaces de noms, y compris ceux 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'option --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 journaux kubectl et journalctl.
  • 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 ces deux scénarios (--scenario system ou all) ne répondent pas à vos besoins, vous pouvez créer un instantané personnalisé en transmettant un fichier de configuration d'instantané à l'aide de l'indicateur --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 commandes kubectl 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 noms default 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 tenue de registres, 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 que vous avez respecté les exigences de configuration.

  • 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
    
  • Attribuez le roles/storage.admin au compte de service sur 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 d'enregistrement des connexions. 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.

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 \
    --share-with GOOGLE_SUPPORT_SERVICE_ACCOUNT

L'option --share-with peut accepter une liste de noms de comptes de service. Remplacez GOOGLE_SUPPORT_SERVICE_ACCOUNT par le compte de service fourni par l'assistance Google, ainsi que par tout autre compte de service fourni par l'assistance Google. Lorsque vous utilisez l'option --upload, la commande recherche dans votre projet un bucket de stockage dont le nom commence par "anthos-snapshot-". Si un tel bucket se ferme, la commande importe l'instantané dans ce bucket. Si la commande ne trouve pas de bucket portant le nom correspondant, elle crée un bucket portant le nom anthos-snapshot-UUID, où UUID est un identifiant universel unique à 32 chiffres.

Lorsque vous utilisez l'option --share-with, vous n'avez pas besoin de partager manuellement l'accès au bucket avec l'assistance Google Cloud.

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://anthos-snapshot-a4b17874-7979-4b6a-a76d-e49446290282/xSNAPSHOT_FILE_NAME.
Shared successfully with service accounts:
GOOGLE_SUPPORT_SERVICE_ACCOUNT

Problèmes connus

BundleUnexpectedDiff erreur

La ressource d'API Kubernetes Cluster gérée par un bundle GKE sur VMware peut être modifiée accidentellement, ce qui peut entraîner la défaillance des composants système, ou l'échec de la mise à niveau ou de la mise à jour du cluster.

À partir de la version 1.13 de GKE sur VMware, onprem-user-cluster-controller vérifie régulièrement l'état des objets et signale toute différence inattendue 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 à l'état souhaité seront écrasés lors de la prochaine mise à niveau du cluster.