Creare snapshot per contribuire a diagnosticare i problemi del cluster

Quando si verifica un problema con uno dei tuoi cluster, puoi ricevere assistenza dall'assistenza clienti Google Cloud. L'assistenza clienti potrebbe chiederti di fare uno "snapshot" del cluster, che può utilizzare per diagnosticare il problema. Uno snapshot acquisisce i file di configurazione del cluster e dei nodi e raggruppa queste informazioni in un unico file tar.

Questo documento descrive come creare snapshot predefiniti o più personalizzati di un cluster. Spiega anche come creare snapshot quando un cluster riscontra errori particolari.

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:

  • Requisiti per l'apertura di una richiesta di assistenza.
  • Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
  • Componenti supportati.

Snapshot predefiniti

Le sezioni seguenti descrivono i contenuti di uno snapshot standard e come crearne uno. Per informazioni sugli snapshot personalizzati, consulta la sezione Snapshot personalizzati.

Quali informazioni contiene uno snapshot predefinito?

Lo snapshot di un cluster è un file tar dei file di configurazione e dei log relativi al cluster. Nello specifico, la configurazione predefinita del comando acquisisce 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 proprietari di questi pod, inclusi deployment, DaemonSet e StatefulSet.

  • Dettagli su ogni configurazione del nodo, inclusi indirizzi IP, regole iptables, punti di montaggio, file system, connessioni di rete e processi in esecuzione.

  • Informazioni su VM Runtime su GDC e su eventuali VM e risorse correlate alle VM in esecuzione nel cluster. Per ulteriori informazioni su cosa viene raccolto per impostazione predefinita e su come creare snapshot specifici per le VM, consulta Informazioni sulle VM negli snapshot in questo documento.

  • Log del comando bmctl check cluster --snapshot.

Le informazioni sulle credenziali di un cluster non sono incluse nello snapshot predefinito. Se l'Assistenza clienti Google Cloud richiede queste informazioni, consulta Recupero delle informazioni sui cluster.

Per un elenco completo delle informazioni raccolte quando esegui il comando snapshot, consulta la sezione successiva relativa al file di configurazione nel dettaglio. Questo file di configurazione mostra i comandi eseguiti quando viene acquisita un'istantanea predefinita.

Crea uno snapshot predefinito

Il comando bmctl check cluster acquisisce uno snapshot di un cluster. Puoi utilizzare questo comando per eseguire una delle seguenti azioni:

  • Crea uno snapshot e caricalo automaticamente in un bucket Cloud Storage.
  • Crea uno snapshot di un cluster e salva il file dello snapshot sulla macchina locale su cui esegui il comando.

Metodo 1: crea uno snapshot predefinito e caricalo automaticamente nel bucket Cloud Storage

Per creare e caricare uno snapshot in un bucket Cloud Storage:

  1. Configura l'API e il account di servizio come descritto in Configurare un account di servizio in grado di accedere a un bucket Cloud Storage.

    Si tratta di un passaggio da eseguire una sola volta.

  2. Esegui il seguente comando bmctl per creare e caricare automaticamente uno snapshot in un bucket Cloud Storage:

    bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --admin-kubeconfig=ADMIN_KUBECONFIG \
    --service-account-key-file SA_KEY_FILE

    Sostituisci le seguenti voci con informazioni specifiche per il tuo ambiente cluster:

    • CLUSTER_NAME: il nome del cluster di cui vuoi creare uno snapshot.
    • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.
    • SA_KEY_FILE: il percorso del file della chiave JSON scaricato per l'account di servizio creato nel passaggio precedente. Se non utilizzi il flag --service-account-key-file, il comando utilizza le credenziali associate alla variabile di ambiente GOOGLE_APPLICATION_CREDENTIALS. La specifica esplicita delle credenziali delaccount di serviziot con il flag ha la precedenza.

    Questo comando genera un file tar dello snapshot e lo salva localmente. Quando il service account è configurato correttamente, il comando carica anche il file tar dello snapshot in un bucket in Cloud Storage. Il comando cerca nel progetto un bucket di archiviazione il cui nome inizia con "anthos-snapshot-". Se esiste un bucket di questo tipo, il comando carica lo snapshot in quel bucket. Se il comando non trova un bucket con un nome corrispondente, ne crea uno nuovo con il nome anthos-snapshot-UUID, dove UUID è un identificatore univoco universale di 32 cifre.

  3. Condividi l'accesso con l'assistenza clienti Google Cloud come descritto in Consentire all'assistenza clienti Google Cloud di visualizzare lo snapshot del cluster caricato.

Metodo n. 2: crea uno snapshot predefinito solo sulla macchina locale

Utilizza il flag --local per assicurarti che lo snapshot del cluster venga salvato solo localmente. Puoi acquisire lo stato dei cluster creati con il seguente comando:

bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --admin-kubeconfig=ADMIN_KUBECONFIG --local

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster di destinazione.

  • ADMIN_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

Questo comando genera un file tar sulla tua macchina locale. Il nome di questo file tar è nel formato snapshot-CLUSTER_NAME-TIMESTAMP.tar.gz, dove TIMESTAMP indica la data e l'ora di creazione del file. Questo file tar include informazioni di debug pertinenti sui componenti di sistema e sulle macchine di un cluster.

Quando esegui questo comando, vengono raccolte informazioni sui pod dai seguenti spazi dei nomi: gke-system, gke-connect, capi-system, capi-webhook-system, cert-manager e capi-kubeadm-bootstrap-system.

Tuttavia, puoi ampliare l'ambito delle informazioni diagnostiche raccolte utilizzando il flag --snapshot-scenario all. Questo flag aumenta l'ambito dello snapshot diagnostico in modo da includere tutti i pod in un cluster:

bmctl check cluster --snapshot --snapshot-scenario all \
    --cluster=CLUSTER_NAME \
    --kubeconfig=KUBECONFIG_PATH \
    --local

Scenari di snapshot

Il comando bmctl check cluster --snapshot supporta due scenari. Per specificare uno scenario, utilizza il flag --scenario. Il seguente elenco mostra i valori possibili:

  • system: raccogli uno snapshot dei componenti di sistema, inclusi i relativi log.

  • all: raccogli un'istantanea di tutti i pod, inclusi i relativi log.

Puoi utilizzare ciascuno dei due scenari con un cluster di amministrazione o un cluster utente. Il seguente esempio crea uno snapshot del cluster di amministrazione utilizzando lo scenario system:

bmctl check cluster --snapshot --snapshot-scenario system \
    --cluster=ADMIN_CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

Il seguente esempio crea uno snapshot di un cluster utente utilizzando lo scenario all:

bmctl check cluster --snapshot --snapshot-scenario all \
    --cluster=USER_CLUSTER_NAME \
    --kubeconfig=USER_KUBECONFIG_PATH

Eseguire una prova per uno snapshot

Quando utilizzi il flag --snapshot-dry-run, il comando non crea uno snapshot. Mostra invece le azioni che il comando snapshot eseguirebbe e restituisce un file di configurazione dello snapshot. Per informazioni sul file di configurazione dello snapshot, vedi Come creare uno snapshot personalizzato.

Per eseguire una simulazione di snapshot sul cluster di amministrazione, inserisci questo comando:

bmctl check cluster --snapshot --snapshot-dry-run \
    --cluster=ADMIN_CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

Per eseguire una simulazione di snapshot su un cluster utente, inserisci questo comando:

bmctl check cluster --snapshot --snapshot-dry-run \
    --cluster=USER_CLUSTER_NAME \
    --kubeconfig=USER_KUBECONFIG_PATH

Recuperare i log di un periodo specifico

Puoi utilizzare il flag --since per recuperare i log di un periodo di tempo che ti interessa particolarmente. In questo modo, puoi creare snapshot più piccoli e più mirati dei log che si sono verificati negli ultimi secondi, minuti o ore.

Ad esempio, il seguente comando bmctl crea uno snapshot della registrazione avvenuta nelle ultime tre ore:

bmctl check cluster --snapshot --since=3h \
    --cluster=CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

Specifica una directory in cui l'istantanea viene salvata temporaneamente

Puoi utilizzare il flag --snapshot-temp-output-dir per specificare una directory in cui lo snapshot viene salvato temporaneamente:

bmctl check cluster --snapshot --snapshot-temp-output-dir=TEMP_OUTPUT_DIR \
    --cluster=CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

Se non specifichi una directory, lo snapshot viene salvato temporaneamente nella directory /tmp. L'utilizzo dell'opzione --snapshot-temp-output-dir è una buona idea quando lo spazio è limitato nella directory /tmp predefinita, ad esempio.

Disattiva la registrazione nella console

Puoi utilizzare il flag --quiet per impedire la visualizzazione dei messaggi di log nella console durante l'esecuzione di uno snapshot. I log della console vengono invece salvati nel file 'bmctl_diagnose_snapshot.log' come parte dello snapshot.

Esegui questo comando per impedire la visualizzazione dei messaggi di log nella console:

bmctl check cluster --snapshot --quiet \
    --cluster=CLUSTER_NAME \
    --kubeconfig=ADMIN_KUBECONFIG_PATH

Regola il threading parallelo dalla riga di comando

La routine di snapshot in genere esegue numerosi comandi. Più thread paralleli ti consentono di eseguire i comandi contemporaneamente, il che aiuta la routine a essere eseguita più rapidamente.

Nella release 1.31 e successive, il comando bmctl check cluster supporta un flag --num-of-parallel-threads. Utilizza questo flag per impostare il numero di thread paralleli utilizzati per creare snapshot.

Per impostazione predefinita, la routine di snapshot utilizza 10 thread. Se gli snapshot richiedono troppo tempo, aumenta questo valore.

Il seguente comando di esempio imposta il numero di thread paralleli su 30.

bmctl check cluster --snapshot --cluster=cluster1 \
    --admin-kubeconfig=bmctl-workspace/admin-cluster/admin-cluster-kubeconfig \
    --num-of-parallel-threads=30

Questa funzionalità è simile al campo numOfParallelThreads nel file di configurazione dello snapshot, quando crei snapshot personalizzati.

Snapshot personalizzati

Potresti voler creare uno snapshot personalizzato di un cluster per i seguenti motivi:

  • Per includere più informazioni sul cluster rispetto a quelle fornite nell'istantanea predefinita.
  • Per escludere alcune informazioni presenti nello snapshot predefinito.

Creare uno snapshot personalizzato

La creazione di uno snapshot personalizzato richiede l'utilizzo di un file di configurazione dello snapshot. I seguenti passaggi spiegano come creare il file di configurazione, modificarlo e utilizzarlo per creare uno snapshot personalizzato di un cluster:

  1. Crea un file di configurazione dello snapshot eseguendo questo comando sul cluster e scrivendo l'output in un file:

    bmctl check cluster \
    --snapshot --snapshot-dry-run --cluster CLUSTER_NAME \
    --kubeconfig KUBECONFIG_PATH

  2. Definisci il tipo di informazioni che vuoi visualizzare nel tuo snapshot personalizzato. Per farlo, modifica il file di configurazione dello snapshot che hai creato nel passaggio 1. Ad esempio, se vuoi che lo snapshot contenga informazioni aggiuntive, ad esempio per quanto tempo è stato in esecuzione un determinato nodo, aggiungi il comando Linux uptime alla sezione pertinente del file di configurazione.

    Il seguente snippet di un file di configurazione mostra come fare in modo che il comando snapshot fornisca informazioni uptime sul nodo 10.200.0.3. Queste informazioni non vengono visualizzate in uno snapshot standard.

    ...
nodeCommands:
- nodes:
  - 10.200.0.3
  commands:
  - uptime
...

  3. Dopo aver modificato il file di configurazione per definire il tipo di snapshot che vuoi, crea lo snapshot personalizzato eseguendo il seguente comando:

    bmctl check cluster --snapshot --snapshot-config SNAPSHOT_CONFIG_FILE \
    --cluster CLUSTER_NAME--kubeconfig KUBECONFIG_PATH

    Il flag --snapshot-config indica al comando bmctl di utilizzare i contenuti del file di configurazione dello snapshot per definire le informazioni visualizzate nello snapshot.

Il file di configurazione nel dettaglio

Il seguente file di configurazione di esempio dello snapshot mostra i comandi e i file standard utilizzati per creare uno snapshot, ma puoi aggiungere altri comandi e file quando sono necessarie informazioni diagnostiche aggiuntive:

numOfParallelThreads: 10
excludeWords:
- password
nodeCommands:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  commands:
  - uptime
  - df --all --inodes
  - ip addr
  - ip neigh
  - iptables-save --counters
  - mount
  - ip route list table all
  - top -bn1 || true
  - docker info || true
  - docker ps -a || true
  - crictl ps -a || true
  - docker ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo docker logs || true
  - docker ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo docker logs || true
  - crictl ps -a | grep anthos-baremetal-haproxy | cut -d ' ' -f1 | head -n 1 | xargs
    sudo crictl logs || true
  - crictl ps -a | grep anthos-baremetal-keepalived | cut -d ' ' -f1 | head -n 1 |
    xargs sudo crictl logs || true
  - ps -edF
  - ps -eo pid,tid,ppid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm,args,cgroup
  - conntrack --count
  - dmesg
  - systemctl status -l docker || true
  - journalctl --utc -u docker
  - journalctl --utc -u docker-monitor.service
  - systemctl status -l kubelet
  - journalctl --utc -u kubelet
  - journalctl --utc -u kubelet-monitor.service
  - journalctl --utc --boot --dmesg
  - journalctl --utc -u node-problem-detector
  - systemctl status -l containerd || true
  - journalctl --utc -u containerd
  - systemctl status -l docker.haproxy || true
  - journalctl --utc -u docker.haproxy
  - systemctl status -l docker.keepalived || true
  - journalctl --utc -u docker.keepalived
  - systemctl status -l container.haproxy || true
  - journalctl --utc -u container.haproxy
  - systemctl status -l container.keepalived || true
  - journalctl --utc -u container.keepalived
nodeFiles:
- nodes:
  - 10.200.0.3
  - 10.200.0.4
  files:
  - /proc/sys/fs/file-nr
  - /proc/sys/net/netfilter/nf_conntrack_max
  - /proc/sys/net/ipv4/conf/all/rp_filter
  - /lib/systemd/system/kubelet.service
  - /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
  - /lib/systemd/system/docker.service || true
  - /etc/systemd/system/containerd.service || true
  - /etc/docker/daemon.json || true
  - /etc/containerd/config.toml || true
  - /etc/systemd/system/container.keepalived.service || true
  - /etc/systemd/system/container.haproxy.service || true
  - /etc/systemd/system/docker.keepalived.service || true
  - /etc/systemd/system/docker.haproxy.service || true
nodeSSHKey: ~/.ssh/id_rsa # path to your ssh key file

Le seguenti voci nel file di configurazione probabilmente differiscono da quelle che compaiono nel file di configurazione di esempio precedente:

  • Gli indirizzi IP dei nodi nelle sezioni nodeCommands e nodeFiles
  • Il percorso del nodeSSHKey del cluster

Campi nel file di configurazione

Un file di configurazione dello snapshot è in formato YAML. Il file di configurazione include i seguenti campi:

  • numOfParallelThreads: la routine di snapshot in genere esegue numerosi comandi. Più thread paralleli aiutano la routine a essere eseguita più rapidamente. Ti consigliamo di impostare numOfParallelThreads su 10 come mostrato nel file di configurazione di esempio precedente. Se gli snapshot richiedono troppo tempo, aumenta questo valore.

  • excludeWords: lo snapshot contiene una grande quantità di dati per i nodi del cluster. Utilizza excludeWords per ridurre i rischi per la sicurezza quando condividi il tuo snapshot. Ad esempio, escludi password in modo che le stringhe di password corrispondenti non possano essere identificate.

  • nodeCommands: questa sezione specifica le seguenti informazioni:

    • nodes: un elenco di indirizzi IP per i nodi del cluster da cui vuoi raccogliere informazioni. Per creare uno snapshot quando il cluster di amministrazione non è raggiungibile, specifica almeno un indirizzo IP del nodo.

    • commands: un elenco di comandi (e argomenti) da eseguire su ogni nodo. L'output di ogni comando è incluso nello snapshot.

  • nodeFiles: questa sezione specifica le seguenti informazioni:

    • nodes: un elenco di indirizzi IP dei nodi del cluster da cui vuoi raccogliere i file. Per creare uno snapshot quando il cluster di amministrazione non è raggiungibile, specifica almeno un indirizzo IP del nodo.

    • files: un elenco di file da recuperare da ogni nodo. Quando i file specificati vengono trovati su un nodo, vengono inclusi nello snapshot.

  • nodeSSHKey: il percorso del file della chiave SSH. Quando il cluster di amministrazione non è raggiungibile, questo campo è obbligatorio.

Creare snapshot quando si verificano errori particolari

Potrebbero essere necessari passaggi o parametri di comando aggiuntivi per creare correttamente uno snapshot quando si verificano determinati eventi, ad esempio un upgrade bloccato.

Creare uno snapshot predefinito durante installazioni o upgrade bloccati

Durante l'installazione o l'upgrade di cluster di amministrazione, ibridi o autonomi, bmctl può a volte bloccarsi in punti in cui è possibile visualizzare i seguenti output:

  • In attesa che kubeconfig del cluster sia pronto.
  • In attesa che il cluster sia pronto.
  • In attesa che i pool di nodi siano pronti.
  • In attesa del completamento dell'upgrade.

Se l'installazione o l'upgrade si blocca, puoi creare uno snapshot di un cluster utilizzando il cluster di bootstrap, come mostrato nell'esempio seguente:

bmctl check cluster --snapshot --cluster=CLUSTER_NAME \
    --kubeconfig=WORKSPACE_DIR/.kindkubeconfig

Crea uno snapshot personalizzato durante installazioni o upgrade bloccati

I seguenti passaggi mostrano come creare uno snapshot personalizzato di un cluster quando un'installazione o un upgrade è bloccato:

  1. Recupera un file di configurazione dello snapshot del cluster dagli archivi.

  2. Modifica il file di configurazione dello snapshot in modo che contenga le informazioni che ti interessano.

  3. Crea lo snapshot personalizzato eseguendo questo comando:

    bmctl check cluster --snapshot
    --snapshot-config=SNAPSHOT_CONFIG_FILE \
    --cluster=CLUSTER_NAME
    --kubeconfig=WORKSPACE_DIR/.kindkubeconfig

Crea uno snapshot personalizzato quando il cluster di amministrazione non è raggiungibile

Quando il cluster di amministrazione non è raggiungibile, puoi creare uno snapshot personalizzato del cluster eseguendo questo comando:

bmctl check cluster --snapshot --cluster CLUSTER_NAME
    --node-ssh-key SSH_KEY_FILE
    --nodes NODE_1_IP_ADDRESS, NODE_2_IP_ADDRESS, ...

Nel comando, sostituisci le seguenti voci con informazioni specifiche per il tuo ambiente cluster:

  • CLUSTER_NAME: il nome del cluster di cui vuoi creare uno snapshot.
  • SSH_KEY_FILE: il percorso del file della chiave SSH del nodo.
  • NODE_x_IP_ADDRESS: l'indirizzo IP di un nodo del cluster di cui vuoi informazioni.

In alternativa, puoi elencare gli indirizzi IP dei nodi su righe separate:

bmctl check cluster
    --snapshot --cluster CLUSTER_NAME \
    --node-ssh-key SSH_KEY_FILE \
    --nodes NODE_1_IP_ADDRESS \
    --nodes NODE_2_IP_ADDRESS
  ...

Informazioni sulla VM negli snapshot

Se utilizzi il runtime VM su GDC per creare e gestire macchine virtuali (VM) su Google Distributed Cloud, puoi raccogliere informazioni diagnostiche pertinenti negli snapshot. Gli snapshot sono una risorsa fondamentale per diagnosticare e risolvere i problemi delle tue VM.

Cosa viene raccolto per impostazione predefinita

Quando crei uno snapshot predefinito, questo contiene le informazioni sul runtime delle VM su GDC e sulle risorse correlate. Il runtime VM su GDC è incluso in Google Distributed Cloud e la risorsa personalizzata VMRuntime è disponibile sui cluster che eseguono i carichi di lavoro. Anche se non hai attivato il runtime delle VM su GDC, lo snapshot contiene comunque la descrizione YAML della risorsa personalizzata VMRuntime.

Se hai attivato VM Runtime su GDC, gli snapshot contengono informazioni sullo stato e sulla configurazione delle risorse correlate alle VM (quando gli oggetti sono presenti) nel cluster. Le risorse correlate alle VM includono oggetti Kubernetes, come pod, deployment, DaemonSet e ConfigMap.

Oggetti nello spazio dei nomi vm-system

Le informazioni sullo stato e sulla configurazione dei seguenti oggetti si trovano in kubectlCommands/vm-system nello snapshot generato:

  • KubeVirt
  • VirtualMachineType
  • VMHighAvailabilityPolicy

Oggetti in altri spazi dei nomi

Quando crei una VM (VirtualMachine), puoi specificare lo spazio dei nomi. Se non specifichi uno spazio dei nomi, la VM riceve lo spazio dei nomi default. Gli altri oggetti in questa sezione, come VirtualMachineInstance, sono tutti associati allo spazio dei nomi della VM corrispondente.

Le informazioni sullo stato e sulla configurazione dei seguenti oggetti si trovano in kubectlCommands/VM_NAMESPACE nell'istantanea generata. Se non hai impostato uno spazio dei nomi specifico per la tua VM, le informazioni si trovano in kubectlCommands/default:

  • VirtualMachine
  • VirtualMachineInstance
  • VirtualMachineDisk
  • GuestEnvironmentData
  • VirtualMachineAccessRequest
  • VirtualMachinePasswordResetRequest

Oggetti senza spazio dei nomi

I seguenti oggetti non sono spazi dei nomi, quindi le informazioni corrispondenti si trovano direttamente in kubectlCommands nello snapshot generato:

  • VMRuntime
  • DataVolume
  • CDI
  • GPUAllocation

Utilizzare un file di configurazione dello snapshot per acquisire solo i dettagli della VM

Se stai diagnosticando problemi specifici per le VM, puoi utilizzare un file di configurazione dello snapshot per limitare le informazioni raccolte ai soli dettagli relativi alle VM e personalizzare le informazioni raccolte.

Il seguente file di configurazione dello snapshot illustra come potresti creare uno snapshot specifico per la VM. Puoi includere comandi aggiuntivi per raccogliere più informazioni per lo snapshot.

---
kubectlCommands:
- commands:
    - kubectl get vm -o wide
    - kubectl get vmi -o wide
    - kubectl get gvm -o wide
    - kubectl get vm -o yaml
    - kubectl get vmi -o yaml
    - kubectl get gvm -o yaml
    - kubectl describe vm
    - kubectl describe vmi
    - kubectl describe gvm
  namespaces:
    - .*
- commands:
    - kubectl get virtualmachinetype -o wide
    - kubectl get virtualmachinedisk -o wide
    - kubectl get virtualmachinetype -o yaml
    - kubectl get virtualmachinedisk -o yaml
    - kubectl describe virtualmachinetype
    - kubectl describe virtualmachinedisk
  namespaces:
    - vm-system

Per ulteriori informazioni sull'utilizzo dei file di configurazione degli snapshot, consulta la sezione Snapshot personalizzati in questo documento.

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud. Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:

  • Requisiti per l'apertura di una richiesta di assistenza.
  • Strumenti per aiutarti a risolvere i problemi, ad esempio la configurazione dell'ambiente, i log e le metriche.
  • Componenti supportati.