Diagnostica dei problemi relativi ai cluster

Questo documento mostra come utilizzare gkectl diagnose per diagnosticare i problemi nei 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 il cluster di amministrazione che con il cluster utente.

gkectl diagnose cluster

Esegue controlli di integrità sul cluster e segnala gli errori. Esegue controlli di integrità sui seguenti componenti:

  • VCenter
    • Credenziale
    • RE
    • Gruppi anti-affinità
    • Rete
    • Versione
    • Data center
    • Datastore
    • ResourcePool
    • Cartella
    • Rete
  • Bilanciatore del carico (F5, Seesaw, manuale)
  • Cluster utente e pool di nodi
  • Oggetti cluster
  • Preparazione del server di Konnectivity per il 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
  • Indicatori di vCPU (CPU virtuale) e di contesa della memoria del cluster utente e di amministrazione
  • Cluster di utenti e amministrazione ESXi allarmi preconfigurati Utilizzo CPU host e Utilizzo memoria.
  • 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 durante il processo e i file di output vengono inseriti in una nuova cartella nello snapshot denominata /diagnose-report.

La configurazione predefinita del comando gkectl diagnose snapshot acquisisce anche le seguenti informazioni sul cluster:

  • Versione di Kubernetes

  • Stato delle risorse Kubernetes negli spazi dei nomi kube-system e gke-system: cluster, macchina, nodi, servizi, endpoint, ConfigMap, ReplicaSet, CronJob, pod e relativi proprietari, inclusi deployment, DaemonSet e StatefulSet

  • Stato del piano di controllo

  • Dettagli sulla configurazione di ciascun nodo, inclusi indirizzi IP, regole iptables, punti di montaggio, file system, connessioni di rete e 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 oggetti VM e relativi eventi in base al pool di risorse. Anche oggetti data center, cluster, rete e Datastore associati alle VM

  • Informazioni sul bilanciatore del carico F5 BIG-IP, tra cui server virtuale, indirizzo virtuale, pool, nodo e monitoraggio

  • Log dal 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 di snapshot /nodes/<admin_master_node_name>/sudo_kubeadm_certs_check-expiration

  • Un file di indice HTML per tutti i file nell'istantanea.

  • 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 quelle vSphere e F5, vengono rimosse prima della creazione del tarball.

Ricevere assistenza

Per ricevere assistenza sui comandi disponibili:

gkectl diagnose --help

Eseguire la diagnostica di un cluster di amministrazione

Per eseguire la diagnostica di 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.

Esamina l'output:

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

Diagnosi di 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 diagnosticati nei cluster

Se durante l'esecuzione di gkectl diagnose cluster si verificano i seguenti problemi, ecco alcune possibili soluzioni.

.
ProblemaCause possibiliRisoluzione
Il server API Kubernetes non è raggiungibile, né per il cluster di amministrazione, né per i cluster utente. Controlla i grafici sulla latenza OOB (out of box) dell'integrità delle macchine virtuali, che idealmente dovrebbero avere una latenza di memoria attorno allo zero. La contesa della memoria può anche aumentare la contesa della CPU e i grafici di idoneità della CPU potrebbero avere un picco in quanto saranno coinvolti degli scambi. Aumentare la memoria fisica. Per altre opzioni, consulta la pagina relativa ai suggerimenti per la risoluzione dei problemi di VMware.
Timeout della creazione del pool di nodi. Latenza elevata di lettura/scrittura VMDK. Controlla la OOB di integrità della VM per verificare la latenza di lettura e scrittura del disco virtuale. Secondo VMware, una latenza totale superiore a 20 ms indica un problema. Consulta Soluzioni VMware per i problemi di prestazioni del disco.

Acquisizione dello stato del cluster in corso...

Se gkectl diagnose cluster trova errori, devi acquisire lo stato del cluster e fornire le informazioni a Google. Per farlo, puoi utilizzare 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 di GKE 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 esaminare l'elenco dei file prodotti dallo snapshot, esegui questi comandi:

cd EXTRACTION_DIRECTORY_NAME/EXTRACTED_SNAPSHOT_DIRECTORY
ls kubectlCommands
ls nodes/NODE_NAME/commands
ls nodes/NODE_NAME/files

Per vedere i dettagli di una determinata operazione, apri uno dei file.

Specifica della 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 la chiave in modo esplicito utilizzando il parametro --admin-ssh-key-path.

Segui le istruzioni per utilizzare SSH per connetterti a un nodo cluster per scaricare le chiavi SSH.

Poi, 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 in corso...

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 di 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 snapshot con i log negli spazi dei nomi di sistema supportati.

  • Tutti: raccogli snapshot con i log in tutti gli spazi dei nomi, inclusi quelli 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 temporale come 120m o 48h.

Note:

  • Il flag --log-since è supportato solo per i log kubectl e journalctl.
  • I flag di comando come --log-since non sono consentiti nella configurazione degli snapshot personalizzata.

Esecuzione di una prova per uno snapshot

Puoi utilizzare il flag --dry-run per mostrare le azioni da eseguire e la configurazione dello snapshot.

Per eseguire una prova sul cluster di amministrazione, inserisci il comando seguente:

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

Utilizzo di una configurazione di snapshot

Se questi due scenari (--scenario system o all) non soddisfano le tue esigenze, puoi creare uno snapshot personalizzato passando un file di configurazione degli 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 in corso

Puoi generare una configurazione di snapshot per un determinato scenario passando i flag --scenario e --dry-run. Ad esempio, per vedere la configurazione degli snapshot per lo scenario predefinito (system) di un cluster utente, inserisci questo comando:

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 dell'istantanea. "password" viene sempre esclusa, indipendentemente dal fatto che la specifichi o meno.

  • kubectlCommands: elenco dei comandi kubectl da eseguire. I risultati vengono salvati. I comandi vengono eseguiti sugli spazi dei nomi corrispondenti. Per i comandi kubectl logs, tutti i pod e i container negli spazi dei nomi corrispondenti vengono aggiunti automaticamente. Per specificare gli spazi dei nomi sono supportate espressioni regolari. Se non specifichi uno spazio dei nomi, viene utilizzato lo spazio dei nomi default.

  • nodeCommands: elenco dei comandi da eseguire sui nodi corrispondenti. I risultati vengono salvati. Quando i nodi non sono specificati, vengono presi in considerazione tutti i nodi nel cluster di destinazione.

  • nodeFiles: elenco di file da raccogliere dai nodi corrispondenti. I file vengono salvati. Quando i nodi non sono specificati, vengono presi in considerazione tutti i nodi nel cluster di destinazione.

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

  • f5: un flag per consentire 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 dei record, l'analisi e l'archiviazione, puoi caricare tutti gli snapshot 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 il comando, assicurati di soddisfare questi requisiti di configurazione.

  • Abilita storage.googleapis.com nel progetto host del parco risorse. Anche se puoi utilizzare un progetto diverso, è consigliato il progetto host del parco risorse.

    gcloud services enable --project=FLEET_HOST_PROJECT_ID storage.googleapis.com

  • Concedi il roles/storage.admin all'account di servizio nel relativo progetto padre e trasmetti il file della chiave JSON dell'account di servizio utilizzando il parametro --service-account-key-file. Puoi utilizzare qualsiasi account di servizio, ma è consigliabile collegare l'account di servizio del registro. 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 Connect Register.

Una volta soddisfatti questi requisiti, puoi caricare l'istantanea con questo comando:

gkectl diagnose snapshot --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name CLUSTER_NAME \
    --upload \
    --share-with GOOGLE_SUPPORT_SERVICE_ACCOUNT

Il flag --share-with accetta 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 a qualsiasi altro account di servizio fornito dall'Assistenza Google. Quando utilizzi il flag --upload, il comando cerca nel progetto un bucket di archiviazione il cui nome inizia con "anthos-snapshot-". Se un bucket di questo tipo viene chiuso, il comando carica lo snapshot in quel bucket. Se il comando non trova un bucket con un nome corrispondente, crea un nuovo bucket con il nome anthos-snapshot-UUID, dove UUID è un identificatore univoco universale di 32 cifre.

Quando utilizzi il flag --share-with, non è necessario condividere manualmente l'accesso al bucket con l'assistenza Google Cloud.

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

Problemi noti

BundleUnexpectedDiff errore

La risorsa dell'API Kubernetes Cluster gestita da un bundle GKE su VMware potrebbe essere modificata accidentalmente, causando un errore nei componenti di sistema oppure nell'upgrade o nell'aggiornamento del cluster.

A partire dalla versione 1.13 di GKE su VMware, onprem-user-cluster-controller controllerà periodicamente lo stato degli oggetti e segnalerà eventuali differenze impreviste rispetto allo 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.

Ecco 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 rispetto allo stato desiderato verranno sovrascritti nell'upgrade successivo del cluster.