Assistenza

L'assistenza clienti Google Cloud ti aiuta a diagnosticare e risolvere gli incidenti di produzione analizzando la configurazione, i log e le metriche e collaborando con i partner.

L'assistenza clienti Google Cloud offre pacchetti per soddisfare le tue esigenze operative, tutti con copertura per GKE e Google Distributed Cloud. Se hai un pacchetto di assistenza esistente, hai già questa copertura. Per saperne di più, consulta l'hub dell'assistenza clienti Google Cloud.

Requisiti per l'assistenza di Google Distributed Cloud

Per risolvere in modo efficace gli incidenti business-critical, devi:

Strumenti di assistenza

Per risolvere un incidente di Google Distributed Cloud, l'assistenza clienti Google Cloud si basa su tre informazioni:

La configurazione dell'ambiente

Quando apri una richiesta di assistenza, fornisci informazioni chiave sulla configurazione del cluster eseguendo i seguenti comandi:

  • Per tutti i tipi di cluster, acquisisci informazioni su Kubernetes e sui tuoi nodi eseguendo il comando bmctl check cluster --snapshot. Allega il file tar risultante alla richiesta di assistenza.

  • Per i cluster di amministrazione, ibridi e autonomi, controlla lo stato di integrità del cluster e dei nodi eseguendo il comando bmctl check cluster. Allega i log risultanti alla richiesta di assistenza. I log devono trovarsi nella directory bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP].

  • Per i cluster utente, crea prima un file YAML di controllo di integrità con il nome e lo spazio dei nomi del cluster, quindi applica il file nel cluster di amministrazione appropriato:

    1. Crea un file YAML con le seguenti proprietà healthcheck. Di seguito sono riportati i contenuti di esempio per un cluster denominato user1 nello spazio dei nomi cluster-user1:

      apiVersion: baremetal.cluster.gke.io/v1
kind: HealthCheck
metadata:
  generateName: healthcheck-
  namespace: cluster-user1
spec:
  clusterName: user1

    2. Dopo aver creato il file YAML, applica la risorsa personalizzata nel cluster di amministrazione che gestisce il cluster utente utilizzando il comando kubectl. Di seguito è riportato un comando di esempio che utilizza il file YAML creato nel passaggio precedente. Nell'esempio, la variabile ADMIN_KUBECONFIG specifica il percorso del file kubeconfig del cluster di amministrazione:

      kubectl --kubeconfig ADMIN_KUBECONFIG create -f healthcheck-user1.yaml

      Il comando restituisce la seguente risposta:

      healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf created

    3. Attendi il completamento del job di controllo di integrità. Per farlo, verifica se il job di controllo di integrità ha terminato la riconciliazione. Nell'esempio precedente, il nome del job di controllo di integrità è healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Di seguito è riportato un test di esempio che utilizza il comando kubectl e attende 30 minuti per il completamento del job di controllo di integrità:

      kubectl --kubeconfig ADMIN_KUBECONFIG wait healthcheck healthcheck-7c4qf \
    -n cluster-user1 --for=condition=Reconciling=False --timeout=30m

      Al termine del job di controllo di integrità, il comando kubectl precedente restituisce:

      healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf condition met

      Puoi visualizzare i risultati del job di controllo di integrità con il seguente comando:

      kubectl --kubeconfig ADMIN_KUBECONFIG get healthcheck healthcheck-7c4qf \
    -n cluster-user1

      Il comando restituisce il seguente risultato:

      NAME                PASS   AGE
healthcheck-7c4qf   true   17m

    4. Raccogli tutti i log per il pod del job di controllo di integrità in un file locale utilizzando il comando kubectl. Di seguito è riportato un esempio che utilizza il job di controllo di integrità di esempio precedente:

      kubectl --kubeconfig ADMIN_KUBECONFIG logs -n cluster-user1 \
    -l baremetal.cluster.gke.io/check-name=healthcheck-7c4qf --tail=-1 > \
    healthcheck-7c4qf.log

Log del cluster

Quando crei un nuovo cluster Google Distributed Cloud, gli agenti Cloud Logging sono abilitati per impostazione predefinita e hanno come ambito solo i componenti a livello di sistema. In questo modo, i log a livello di sistema vengono replicati nel progetto Google Cloud associato al cluster. I log a livello di sistema provengono dai pod Kubernetes nei seguenti spazi dei nomi:

  • kube-system
  • gke-system
  • gke-connect
  • istio-system
  • config-management-system
  • gatekeeper-system
  • cnrm-system
  • knative-serving

Puoi eseguire query sui log da Esplora log.

Per maggiori dettagli, consulta Configura il logging e il monitoraggio.

Google Cloud CLI e accesso remoto ai cluster

Se apri una richiesta di assistenza, l'assistenza clienti Google Cloud potrebbe chiederti l'accesso remoto di sola lettura ai tuoi cluster per diagnosticare e risolvere i problemi in modo più efficace. Affinché l'assistenza clienti Google Cloud disponga di un accesso sufficiente per risolvere i problemi del cluster da remoto, assicurati di aver installato e aggiornato l'ultima versione di Google Cloud CLI. Google Cloud CLI deve essere alla versione 401.0.0 o successiva per concedere all'assistenza clienti Google Cloud le autorizzazioni necessarie. Ti consigliamo di aggiornare regolarmente Google Cloud CLI per acquisire le autorizzazioni aggiunte e altri miglioramenti.

Per installare i componenti più recenti di gcloud CLI, utilizza il comando gcloud components update. Per ulteriori informazioni su come concedere all'assistenza clienti Google Cloud l'accesso remoto di sola lettura ai tuoi cluster, consulta Assistenza remota per i cluster GKE.

Metriche del cluster

Oltre ai log, l'agente Cloud Monitoring acquisisce anche le metriche. In questo modo, le metriche a livello di sistema vengono replicate nel progetto Google Cloud associato al cluster. Le metriche a livello di sistema provengono dai pod Kubernetes in esecuzione negli stessi spazi dei nomi elencati nella sezione Log del cluster.

Per maggiori dettagli, consulta Configura il logging e il monitoraggio.

Come risolviamo i problemi del tuo ambiente

Ecco un esempio di un tipico incidente di assistenza:

  1. L'amministratore del cluster apre una richiesta di assistenza nella console Google Cloud con l'assistenza clienti Google Cloud. Quindi, seleziona GKE e Google Distributed Cloud rispettivamente come Categoria e Componente. Inseriscono le informazioni richieste e allegano alla richiesta l'output dei comandi bmctl pertinenti.

  2. La richiesta di assistenza viene inoltrata a un tecnico dell'assistenza tecnica specializzato in Google Distributed Cloud.

  3. Il tecnico del servizio di assistenza esamina i contenuti dello snapshot per comprendere il contesto dell'ambiente.

  4. Il tecnico del servizio di assistenza esamina i log e le metriche nel progetto Google Cloud. Inserisce l'case ID di assistenza come giustificazione aziendale, che viene registrato internamente.

  5. Il tecnico del servizio di assistenza risponde alla richiesta con una valutazione e un suggerimento. Il tecnico del servizio di assistenza e l'utente continuano la risoluzione dei problemi fino a quando non trovano una soluzione.

Cosa supporta Google?

In genere, l'assistenza clienti Google Cloud supporta tutti i componenti software forniti come parte di Google Distributed Cloud e Cloud Service Mesh, Policy Controller, Config Sync e Config Controller. La tabella seguente fornisce un elenco più completo di ciò che è supportato e di ciò che non lo è:

Google Cloud supportato Non supportata
Kubernetes e il runtime del container Scelta personalizzata del bilanciatore del carico da parte del cliente (bilanciamento manuale del carico)
Connect e l'agente Connect Codice cliente (consulta l'assistenza per gli sviluppatori)
Google Cloud operations, Monitoring, Logging e agenti Scelta personalizzata del sistema operativo da parte del cliente
Bilanciatore del carico in bundle Server, spazio di archiviazione e rete fisici o virtuali
Controller Ingress Sistemi DNS, DHCP e di identità esterni
GKE Identity Service
Cloud Service Mesh
Policy Controller
Config Sync
Config Controller

Policy di assistenza per le versioni

L'obiettivo di questa policy di assistenza per le versioni è offrirti la flessibilità di pianificare gli upgrade in base alle tue esigenze aziendali, bilanciando al contempo la rapida evoluzione di Kubernetes e Google Distributed Cloud.

Il software Google Distributed Cloud segue solo lo schema di controllo delle versioni e il ciclo di rilascio di Kubernetes. Le release minori vengono rilasciate circa tre volte l'anno. Le patch per ogni versione secondaria supportata vengono rilasciate all'incirca ogni mese. Come Kubernetes, Google Distributed Cloud supporta contemporaneamente le ultime tre versioni secondarie.

Assistenza Google supporta ogni versione secondaria di Google Distributed Cloud per il periodo più lungo tra:

  • 12 mesi dopo la release iniziale della versione secondaria.
  • Il rilascio della terza versione secondaria successiva.

Ad esempio, la versione secondaria 1.33 rilasciata il 2 settembre 2025. Questa versione secondaria e tutte le relative patch sono supportate fino al 2 settembre 2026 o alla data di rilascio della versione secondaria 1.36, a seconda di quale sia la data successiva.

Ti invitiamo a mantenere l'ambiente Google Distributed Cloud con l'ultima release secondaria del prodotto e la versione patch consigliata.

Queste norme di assistenza per le versioni includono:

  • Assistenza per la risoluzione dei problemi dall'assistenza clienti Google Cloud.
  • Vulnerabilità di sicurezza CVE per Kubernetes e i componenti correlati.
  • Patch generali per Kubernetes e i componenti correlati.

Quando la tua versione raggiunge la fine del ciclo di vita, puoi continuare ad aprire richieste per ricevere assistenza per quanto segue:

  • Assistenza per problemi tecnici.
  • Assistenza per problemi di fatturazione.
  • Indicazioni sull'utilizzo del prodotto, inclusa l'assistenza per la risoluzione dei problemi e i test.

L'assistenza estesa può essere approvata in via condizionale come evento una tantum, con blocco della versione e requisiti di tempistica per l'upgrade futuro. Per ulteriori informazioni, contatta il Customer Engineer principale del tuo account o l'account manager. In alternativa, puoi presentare una richiesta di assistenza tramite la console Google Cloud . Queste richieste vengono inoltrate al gruppo di Customer Engineering per il tuo account.

Periodo di assistenza

La tabella seguente mostra le release minori supportate per Google Distributed Cloud e le date di fine del ciclo di vita (EOL) più prossime:

Versione di Google Distributed Cloud Data di uscita Data di fine del ciclo di vita*
1,35 2026-04-29 29/04/2027 o data di rilascio della versione 1.38
1,34 2025-12-11 11/12/2026 o data di rilascio della versione 1.37
1,33 2025-09-02 02/09/2026 o data di rilascio della versione 1.36
1.32 2025-05-06 06/05/2026 o data di rilascio della versione 1.35

* La data di fine del ciclo di vita sarà la più recente di queste due date.

Per scoprire di più sulla compatibilità delle versioni per Google Distributed Cloud e i prodottiGoogle Cloud correlati, consulta Supporto delle versioni e degli upgrade.

Schema di controllo delle versioni

Google Distributed Cloud utilizza il controllo delle versioni semantico di Kubernetes per fare riferimento alle versioni di Kubernetes supportate, ma aggiunge una versione patch di GKE. In questo modo, il numero di versione avrà il seguente formato: x.y.z-gke.N.

Versione principale di Kubernetes (x)
Le versioni principali vengono in genere incrementate se vengono introdotte modifiche incompatibili con le versioni precedenti nell'API pubblica. Una versione principale incrementa la versione di Kubernetes da x.y a x+1.y.
Versione secondaria di Kubernetes (y)
Kubernetes rilascia una nuova versione secondaria tre volte all'anno. Ogni ciclo di rilascio dura circa 15 settimane. Le API ritirate potrebbero essere rimosse con una nuova versione secondaria. Una versione secondaria incrementa la versione di Kubernetes da 1.y a 1.y+1, ad esempio Kubernetes 1. 29 è la release secondaria che segue Kubernetes 1.28.
Release della patch di Google Distributed Cloud (z-gke.N)
Una release di patch, ad esempio 1.28.300-gke.131, incrementa la versione della patch (z) di 100 e include un suffisso -gke.N, che indica la build. Le release delle patch includono aggiornamenti della sicurezza e correzioni di bug. Una versione di release di patch di Google Distributed Cloud non è correlata a una versione di patch di Kubernetes.

Modello di responsabilità condivisa

L'esecuzione di un'applicazione di produzione business-critical su Google Distributed Cloud richiede che più parti si assumano responsabilità diverse. Sebbene non costituiscano un elenco esaustivo, le sezioni seguenti elencano i ruoli e le responsabilità delle diverse parti.

Responsabilità di Google

  • Manutenzione e distribuzione del pacchetto software Google Distributed Cloud.

  • Notifica agli utenti gli upgrade disponibili per Google Distributed Cloud e produzione di script di upgrade per la versione precedente.

    Google Distributed Cloud supporta solo gli upgrade sequenziali dei cluster (ad esempio: 1.34 → 1.35 → 1.36, ma non 1.34 → 1.36). Quando esegui l'upgrade dei pool di nodi, in alcuni casi puoi saltare una versione secondaria. Per saperne di più sulla logica di upgrade, consulta Regole per le versioni.

  • Gestione dei servizi Connect e Suite operativa di Google Cloud.

  • Risoluzione dei problemi, fornitura di soluzioni alternative e correzione della causa principale di eventuali problemi relativi ai componenti forniti da Google.

Responsabilità degli utenti

  • Amministrazione generale del sistema per i cluster on-premise.
  • Mantenere qualsiasi workload dell'applicazione di cui è stato eseguito il deployment nel cluster.
  • Esecuzione, manutenzione e applicazione di patch all'infrastruttura del data center, tra cui networking, server, sistema operativo, spazio di archiviazione e connettività aGoogle Cloud.
  • Esecuzione, manutenzione e applicazione di patch ai bilanciatori del carico di rete se viene scelta l'opzione di bilanciatore del carico manuale.
  • Eseguire regolarmente l'upgrade delle versioni di Google Distributed Cloud.
  • Monitoraggio del cluster e delle applicazioni e risposta a eventuali incidenti.
  • Assicurati che gli agenti di Cloud Operations siano distribuiti nei cluster.
  • Fornire a Google i dettagli dell'ambiente per la risoluzione dei problemi.

Assistenza per sviluppatori

Google non fornisce assistenza specifica per i workload delle tue applicazioni. Tuttavia, forniamo assistenza agli sviluppatori best-effort per garantire che i tuoi sviluppatori possano eseguire applicazioni su Google Distributed Cloud. Riteniamo che un coinvolgimento tempestivo durante lo sviluppo possa prevenire incidenti critici in un secondo momento durante il deployment.

Questa assistenza per gli sviluppatori best-effort è disponibile per i clienti con qualsiasi pacchetto di assistenza a pagamento e viene trattata come priorità P3 per un problema che blocca un lancio o come priorità P4 per una consulenza generale. In questa classificazione, il livello di priorità 0 è quello con la priorità più alta.