Questo documento mostra come utilizzare gkectl diagnose
per diagnosticare i problemi nei tuoi cluster.
Panoramica
Lo strumento gkectl
dispone di due comandi per la risoluzione dei problemi con i cluster:
gkectl diagnose cluster
e gkectl diagnose snapshot
. I comandi funzionano sia con i cluster di amministrazione sia con i cluster utente.
gkectl diagnose cluster
Esegue controlli di integrità sul cluster e segnala errori. Esegue controlli di integrità sui seguenti componenti:
- VCenter
- Credenziale
- DRS
- Gruppi anti-affinità
- Rete
- Versione
- Data center
- Datastore
- Pool di risorse
- Cartella
- Rete
- Bilanciatore del carico (F5, Seesaw, Manuale)
- Pool di nodi e cluster utente
- Oggetti cluster
- Preparazione del server Konnectivity del cluster utente
- Oggetti macchina e nodi cluster corrispondenti
- Pod negli spazi dei nomi kube-system e gke-system
- Piano di controllo
- Volumi permanenti vSphere nel cluster
- Segnali vCPU e di cluster di utenti (CPU virtuale) e di contesa di memoria
- Avvisi di utilizzo della CPU e di memoria dell'host preconfigurati da cluster utente e amministratore ESXi
- Ora del giorno (TOD)
- Criterio di rete dei nodi per un cluster con Dataplane V2 abilitato
- Integrità complessiva dell'agente nodo Dataplane V2
gkectl diagnose snapshot
Questo comando comprime lo stato, le configurazioni e i log di un cluster in un file tarball. Se esegui gkectl diagnose snapshot
, il comando esegue automaticamente gkectl diagnose cluster
come parte del processo e i file di output vengono inseriti in una nuova cartella nello snapshot chiamato /diagnose-report
.
La configurazione predefinita del comando gkectl diagnose snapshot
acquisisce anche le seguenti informazioni sul tuo cluster:
Versione di Kubernetes
Stato delle risorse Kubernetes negli spazi dei nomi kube-system e gke-system: cluster, macchina, nodi, servizi, endpoint, ConfigMap, ReplicaSet, CronJobs, pod e proprietari di tali pod, inclusi Deployment, DaemonSet e StatefulSet
Stato del piano di controllo
Dettagli su ogni configurazione dei nodi, tra cui indirizzi IP, regole iptables, punti di montaggio, file system, connessioni di rete ed processi in esecuzione
Log dei container dal nodo del piano di controllo del cluster di amministrazione, quando il server API Kubernetes non è disponibile
Informazioni su vSphere inclusi gli oggetti VM e i relativi eventi in base al pool di risorse. Inoltre, oggetti Datacenter, Cluster, Network e Datastore associati alle VM
Informazioni sul bilanciatore del carico BIG-IP di F5, inclusi server virtuale, indirizzo virtuale, pool, nodo e monitoraggio
Log del comando
gkectl diagnose snapshot
Log dei job preflight
Log dei container negli spazi dei nomi in base agli scenari
Informazioni sulla scadenza del certificato Kubernetes del cluster di amministrazione nel file snapshot
/nodes/<admin_master_node_name>/sudo_kubeadm_certs_check-expiration
Un file indice HTML per tutti i file nello snapshot
Facoltativamente, il file di configurazione del cluster di amministrazione utilizzato per installare ed eseguire l'upgrade del cluster con il flag
--config
.
Le credenziali, incluse vSphere e F5, vengono rimosse prima della creazione del tarball.
Ricevere assistenza
Per ricevere assistenza sui comandi disponibili:
gkectl diagnose --help
Diagnosticare un cluster di amministrazione
Per diagnosticare un cluster di amministrazione:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.
Output dell'esame:
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!
Se si verifica un problema con un indirizzo IP virtuale (VIP) nel cluster di destinazione, utilizza il flag --config
per fornire il file di configurazione del cluster di amministrazione. In questo modo avrai a disposizione più informazioni di debug.
gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config CLUSTER_CONFIG
Sostituisci CLUSTER_CONFIG con il percorso del file di configurazione del cluster di amministrazione o utente.
Output di esempio:
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]"... ...
Diagnosticare un cluster utente
Per ottenere il nome di un cluster utente:
kubectl get cluster --kubeconfig=USER_CLUSTER_KUBECONFIG
Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.
Per diagnosticare un cluster utente:
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME
Sostituisci USER_CLUSTER_NAME con il nome del cluster utente.
Output di esempio:
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!
Risoluzione dei problemi di cluster diagnosticati
Se riscontri i seguenti problemi durante l'esecuzione di gkectl diagnose cluster
, ecco alcune possibili soluzioni.
Problema | Cause possibili | Risoluzione |
---|---|---|
Il server API di Kubernetes non è raggiungibile, per il cluster di amministrazione o per i cluster utente. | Dai un'occhiata ai grafici di latenza della memoria OOB (out-of-box) delle macchine virtuali, che idealmente dovrebbero avere una latenza della memoria intorno allo zero. La contesa della memoria può anche aumentare la contesa della CPU e i grafici di preparazione della CPU potrebbero avere un picco poiché sarà coinvolto lo scambio. | Aumentare la memoria fisica. Per altre opzioni, consulta la pagina Suggerimenti per la risoluzione dei problemi con VMware. |
Timeout della creazione del pool di nodi. | VMDK, latenza di lettura/scrittura elevata. Controlla l'OOB dell'integrità delle VM per la latenza di lettura e scrittura del disco virtuale. Secondo VMware, una latenza totale superiore a 20 ms indica un problema. | Consulta le soluzioni VMware per i problemi di prestazioni del disco. |
Acquisizione dello stato del cluster
Se gkectl diagnose cluster
rileva errori, devi acquisire lo stato del cluster e fornire le informazioni a Google. Per farlo, utilizza il comando
gkectl diagnose snapshot
.
gkectl diagnose snapshot
ha un flag facoltativo --config
. Oltre a raccogliere informazioni sul cluster, questo flag raccoglie il file di configurazione Cluster Anthos su VMware che è stato utilizzato per creare o eseguire l'upgrade del cluster.
Acquisizione dello stato del cluster di amministrazione
Per acquisire lo stato di un cluster di amministrazione, esegui questo comando, dove --config
è facoltativo:
gkectl diagnose snapshot --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] --config
L'output include un elenco di file e il nome di un file 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.Per estrarre il file tarball in una directory, esegui questo comando:
tar -zxf TARBALL_FILE_NAME --directory EXTRACTION_DIRECTORY_NAME
Per vedere l'elenco dei file prodotti dallo snapshot, esegui i comandi seguenti:
cd EXTRACTION_DIRECTORY_NAME/EXTRACTED_SNAPSHOT_DIRECTORY ls kubectlCommands ls nodes/NODE_NAME/commands ls nodes/NODE_NAME/files
Per visualizzare i dettagli di un'operazione specifica, apri uno dei file.
Specifica la chiave SSH per il cluster di amministrazione
Quando ottieni uno snapshot del cluster di amministrazione, gkectl
trova automaticamente la chiave SSH privata per il cluster di amministrazione. Puoi anche specificare esplicitamente la chiave utilizzando il parametro --admin-ssh-key-path
.
Segui le istruzioni per utilizzare SSH per connetterti a un nodo del cluster per scaricare le chiavi SSH.
Quindi, nel comando gkectl diagnose snapshot
, imposta --admin-ssh-key-path
sul percorso del file della chiave decodificato:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --admin-ssh-key-path=PATH_TO_DECODED_KEY
Acquisizione dello stato del cluster utente
Per acquisire lo stato di un cluster utente, esegui questo comando:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME
L'output include un elenco di file e il nome di un file 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.
Scenari snapshot
Il comando gkectl diagnose snapshot
supporta due scenari per il cluster utente. Per specificare uno scenario, utilizza il flag --scenario
. Il seguente elenco mostra i possibili valori:
Sistema(predefinito): raccogli gli snapshot con i log negli spazi dei nomi di sistema supportati.
Tutte: raccogli gli snapshot con i log in tutti gli spazi dei nomi, inclusi gli spazi dei nomi definiti dall'utente
I seguenti esempi mostrano alcune delle possibilità.
Per creare uno snapshot del cluster di amministrazione, non è necessario specificare uno scenario:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG
Per creare uno snapshot di un cluster utente utilizzando lo scenario system
:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=system
Per creare uno snapshot di un cluster utente utilizzando lo scenario all
:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=all
Utilizzo di --log-since
per limitare uno snapshot
Puoi utilizzare il flag --log-since
per limitare la raccolta dei log a un periodo di tempo recente. Ad esempio, potresti raccogliere solo i log degli ultimi due giorni o delle ultime tre ore. Per impostazione predefinita, diagnose snapshot
raccoglie tutti i log.
Per limitare il periodo di tempo per la raccolta dei log:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=CLUSTER_NAME \ --scenario=system \ --log-since=DURATION
Sostituisci DURATION con un valore di tempo come 120m
o 48h
.
Note:
- Il flag
--log-since
è supportato solo per i logkubectl
ejournalctl
. - I flag di comando come
--log-since
non sono consentiti nella configurazione degli snapshot personalizzati.
Esecuzione di una prova per uno snapshot
Puoi utilizzare il flag --dry-run
per mostrare le azioni da eseguire e la configurazione degli snapshot.
Per eseguire una prova nel cluster di amministrazione, inserisci questo comando:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=ADMIN_CLUSTER_NAME \ --dry-run
Per eseguire una prova su un cluster utente, inserisci il comando seguente:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --dry-run
usando una configurazione di snapshot.
Se i quattro scenari non soddisfano le tue esigenze, puoi creare un'istantanea personalizzata passando un file di configurazione di snapshot utilizzando il flag --snapshot-config
:
gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --snapshot-config=SNAPSHOT_CONFIG_FILE
Generazione di una configurazione di snapshot
Puoi generare una configurazione di snapshot per un determinato scenario trasmettendo i flag --scenario
e --dry-run
. Ad esempio, per visualizzare la configurazione dello snapshot per lo scenario predefinito (system
) di un cluster utente, inserisci il comando seguente:
gkectl diagnose snapshot \ --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \ --cluster-name=USER_CLUSTER_NAME \ --scenario=system --dry-run
L'output è simile al seguente:
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
: numero di thread paralleli utilizzati per acquisire gli snapshot.excludeWords
: elenco di parole da escludere dallo snapshot (senza distinzione tra maiuscole e minuscole). Le righe contenenti queste parole vengono rimosse dai risultati degli snapshot. "password" viene sempre esclusa, indipendentemente dalla sua specifica.kubectlCommands
: elenco dei comandi kubectl da eseguire. I risultati vengono salvati. I comandi vengono eseguiti sugli spazi dei nomi corrispondenti. Per i comandikubectl logs
, tutti i pod e i container negli spazi dei nomi corrispondenti vengono aggiunti automaticamente. Le espressioni regolari sono supportate per specificare gli spazi dei nomi. Se non specifichi uno spazio dei nomi, si presume lo spazio dei nomidefault
.nodeCommands
: elenco di comandi da eseguire sui nodi corrispondenti. I risultati vengono salvati. Quando non sono specificati nodi, tutti i nodi nel cluster di destinazione vengono considerati.nodeFiles
: elenco di file da raccogliere dai nodi corrispondenti. I file vengono salvati. Quando non sono specificati nodi, tutti i nodi nel cluster di destinazione vengono considerati.seesawCommands
: elenco di comandi da eseguire per raccogliere informazioni sul bilanciatore del carico di Seesaw. I risultati vengono salvati se il cluster utilizza il bilanciatore del carico di Seesaw.seesawFiles
: elenco di file da raccogliere per il bilanciatore del carico di Seesaw.nodeCollectors
: un raccoglitore in esecuzione per i nodi Cilium per raccogliere informazioni eBPF.f5
: un flag per abilitare la raccolta di informazioni relative al bilanciatore del carico BIG-IP di F5.vCenter
: un flag per consentire la raccolta di informazioni relative a vCenter.prometheusRequests
: elenco delle richieste Prometheus. I risultati vengono salvati.
Carica snapshot in un bucket Cloud Storage
Per semplificare la conservazione, l'analisi e l'archiviazione dei record, puoi caricare tutte le istantanee di un cluster specifico in un bucket Cloud Storage. Ciò è particolarmente utile se hai bisogno di assistenza da parte dell'assistenza clienti Google Cloud.
Prima di eseguire questo comando, assicurati di aver soddisfatto questi requisiti di configurazione.
Abilitare
storage.googleapis.com
nel progetto host del parco risorse. Anche se puoi utilizzare un progetto diverso, è consigliabile utilizzare il progetto host del parco risorse.gcloud services enable --project=FLEET_HOST_PROJECT_ID storage.googleapis.com
Concedi all'account di servizio
roles/storage.admin
il progetto padre e trasmettilo nel file della chiave JSON dell'account di servizio utilizzando il parametro--service-account-key-file
. Puoi utilizzare qualsiasi account di servizio, ma è consigliabile utilizzare l'account di servizio Connect Connect. Per ulteriori informazioni, consulta Account di servizio.gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \ --member "serviceAccount:CONNECT_REGISTER_SERVICE_ACCOUNT" \ --role "roles/storage.admin"
Sostituisci CONNECT_REGISTER_SERVICE_ACCOUNT con l'account di servizio di connessione del registro.
Segui le istruzioni per creare un account di servizio Google Cloud, se non l'hai già fatto, e per condividere l'accesso al bucket con l'assistenza Google Cloud.
Una volta soddisfatti questi requisiti, puoi caricare lo snapshot con questo comando:
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
Sostituisci SERVICE_ACCOUNT_KEY_FILE con il nome del file della chiave dell'account di servizio.
Il flag --share-with
può accettare un elenco di nomi di account di servizio. Sostituisci GOOGLE_SUPPORT_SERVICE_ACCOUNT con l'account di servizio dell'Assistenza Google fornito dall'Assistenza Google insieme agli altri account di servizio forniti dall'Assistenza Google.
Se utilizzato, il flag facoltativo share-with
deve essere utilizzato insieme a --upload-to
e --service-account-file
, in modo da poter prima caricare lo snapshot in
Cloud Storage, quindi condividere l'autorizzazione di lettura.
Output di esempio:
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
Problemi noti
BundleUnexpectedDiff
errore
La risorsa API Kubernetes Cluster gestita da un cluster Cluster Anthos su VMware potrebbe essere modificata per errore, con la possibilità di causare l'errore dei componenti di sistema o l'upgrade o l'aggiornamento del cluster.
Da Cluster Anthos su VMware versione 1.13, onprem-user-cluster-controller
controlla periodicamente lo stato degli oggetti e segnala eventuali differenze impreviste dallo stato desiderato tramite log ed eventi. Questi oggetti
includono il piano di controllo del cluster utente e i componenti aggiuntivi come Service e DaemonSet.
Ecco un esempio di evento:
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.
Di seguito è riportato un esempio di log generati da 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 }
Gli eventi e i log non bloccheranno il funzionamento del cluster. Gli oggetti con differenze impreviste dallo stato desiderato verranno sovrascritti nell'upgrade successivo del cluster.