Diagnostica dei problemi relativi ai cluster

Version 1.12 

• Versione più recente
• Versione 1.16
• Versioni precedenti (non supportate)

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 dell'utente se il cluster di destinazione è un cluster utente
• Volumi permanenti vSphere nel cluster
• Segnali vCPU e di cluster di utenti (CPU virtuale) e di contesa di memoria
• Avvisi di utilizzo della CPU host e di memoria preconfigurati per 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 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 dell'utente se il cluster di destinazione è un cluster utente (il piano di controllo del cluster utente viene eseguito nel cluster di amministrazione)

• 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 nello scenario system-logs e all-with-logs.

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

Diagnostica dei cluster

Puoi eseguire gkectl diagnose cluster per cercare problemi comuni con il tuo cluster.

Nota: il flag --kubeconfig deve sempre indirizzare al file kubeconfig del cluster di amministrazione. gkectl diagnose restituisce un errore se fornisci il kubeconfig del cluster utente.

Nota: in caso di problema VIP con il cluster di targeting, usa --config per fornire il file di configurazione del cluster di amministrazione. Avrai così a disposizione più informazioni di debug.

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

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

Per elencare ulteriori flag che puoi passare a gkectl diagnose cluster, nonché il loro comportamento predefinito, esegui questo comando:

gkectl diagnose cluster --help

L'output è simile al seguente:

gkectl diagnose cluster --help
This command performs health checks on the cluster and reports errors if there are any.

Usage:
  gkectl diagnose cluster [flags]

Flags:
  -h, --help                         help for cluster
      --output string                The path to the output file. By default, it will be saved in the current working directory with a filename in format: diagnose-CLUSTER_TYPE-CLUSTER_NAME-DATE.json.
      --validator-timeout duration   The timeout duration for each validator running in 'gkectl diagnose cluster'. By default, the validator timeout is 0 which is no timeout, and the validator will not stop running until it is finished.

Diagnosi di un cluster di amministrazione

Puoi diagnosticare un cluster di amministrazione inserendone il nome o trasmettendolo solo in kubeconfig.

Utilizzo del cluster di amministrazione kubeconfig

Il passaggio a kubeconfig del cluster di amministrazione fa sì che gkectl scelga automaticamente il cluster di amministrazione:

gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG]

Utilizzo del nome del cluster di amministrazione

Per ottenere il nome del cluster di amministrazione, esegui il comando seguente:

kubectl get cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG]

Quindi, trasmetti il nome del cluster di amministrazione a gkectl diagnose cluster:

gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[ADMIN_CLUSTER_NAME]

Se il cluster di amministrazione funziona correttamente, gkectl diagnose cluster restituisce un output simile al seguente:

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!

Diagnosi di un cluster utente

Per diagnosticare un cluster, devi prima recuperare il nome del cluster:

kubectl get cluster --kubeconfig=[USER_CLUSTER_KUBECONFIG]

Quindi, passa kubeconfig del cluster di amministrazione e il nome del cluster utente:

gkectl diagnose cluster --kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
  --cluster-name=[USER_CLUSTER_NAME]

Nota: gkectl diagnose restituisce un errore se fornisci kubeconfig del cluster utente.

Se il cluster utente funziona correttamente, gkectl diagnose cluster restituisce un output simile al seguente:

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
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!

Risoluzione dei problemi di cluster diagnosticati

Se riscontri i seguenti problemi durante l'esecuzione del comando gke 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.

Nota: il flag --kubeconfig deve sempre indirizzare al file kubeconfig del cluster di amministrazione. gkectl diagnose restituisce un errore se fornisci kubeconfig del cluster utente.

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

Nota: in caso di problemi VIP con il cluster di targeting, utilizza --config per fornire il file di configurazione del cluster di amministrazione. Avrai così a disposizione più informazioni di debug.

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 quattro scenari. Per specificare uno scenario, utilizza il flag --scenario. Il seguente elenco mostra i possibili valori:

• all-with-logs: (predefinita) Raccogli uno snapshot di all con i log.

• system: raccogli uno snapshot per gli spazi dei nomi di sistema: kube-system e gke-system.

• system-with-logs: raccogli uno snapshot di system con i log.

• all: raccogli uno snapshot per tutti gli spazi dei nomi.

Puoi utilizzare ciascuno dei quattro scenari con un cluster di amministrazione o con un cluster utente, in modo da ottenere otto possibili permutazioni. I seguenti esempi mostrano alcune delle possibilità.

Per creare uno snapshot del cluster di amministrazione utilizzando lo scenario all-with-logs:

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--scenario=all-with-logs

Per creare uno snapshot del cluster di amministrazione utilizzando lo scenario system:

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--scenario=system

Per creare uno snapshot di un cluster utente utilizzando lo scenario system-with-logs:

gkectl diagnose snapshot \
--kubeconfig=[ADMIN_CLUSTER_KUBECONFIG] \
--cluster-name=[USER_CLUSTER_NAME] \
--scenario=system-with-logs

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

Negli scenari system-with-logs e all-with-logs, 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-with-logs \
--log-since=[DURATION]

Sostituisci [DURATION] con un valore di tempo 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 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 comandi kubectl 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 nomi default.

• 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 Google Cloud Storage

Per semplificare la tenuta dei registri, l'analisi e l'archiviazione, puoi caricare tutti gli snapshot di un cluster specifico in un bucket Google Cloud Storage. Ciò è particolarmente utile se hai bisogno di aiuto dall'assistenza Google Cloud.

Prima di eseguire questo comando, assicurati di aver soddisfatto questi requisiti di configurazione.

• Attiva 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 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 utilizzare l'account di servizio della connessione di 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 Connect Registry.

• Segui le istruzioni per creare un account di servizio Google Cloud, se non l'hai ancora 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 a qualsiasi altro account di servizio fornito dall'Assistenza Google.

Se utilizzato, il flag facoltativo share-with deve essere utilizzato insieme a --upload-to e --service-account-file, in modo che lo snapshot possa essere prima caricato in Google Cloud Storage, quindi può essere condivisa 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

Versione 1.1.2-gke.0: il percorso viene risolto in più data center

Consulta le note di rilascio di Cluster Anthos su VMware.

Versioni 1.1.x: volume non collegato alla macchina

Consulta le note di rilascio di Cluster Anthos su VMware.