Assistenza

L'obiettivo principale dell'assistenza Google è risolvere gli incidenti di produzione il più rapidamente possibile. Lo facciamo comprendendo la tua configurazione, analizzando i log e le metriche e collaborando con i partner per risolvere rapidamente gli incidenti.

L'assistenza clienti Google Cloud offre vari pacchetti di assistenza per soddisfare le tue esigenze di assistenza. Tutti i pacchetti di assistenza clienti Google Cloud includono l'assistenza per GKE e Google Distributed Cloud. Se hai un pacchetto di assistenza clienti Google Cloud esistente, hai già l'assistenza per GKE e Google Distributed Cloud.

Per saperne di più, consulta l'hub dell'assistenza clienti Google Cloud.

Requisiti per l'assistenza Google Distributed Cloud

Per risolvere in modo efficace gli incidenti critici per l'attività, devi:

Strumenti di assistenza

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

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 esistere nella directory bmctl-workspace/[CLUSTER_NAME]/log/check-cluster-[TIMESTAMP].

  • Per i cluster utente, crea prima un file YAML di controllo di integrità dell'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 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à'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 del pod del job di controllo di integrità'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 limitati solo ai 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, vedi Configurare la registrazione nel log e il monitoraggio.

Google Cloud CLI e accesso remoto al 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 Cloud abbia accesso sufficiente per risolvere il problema del cluster da remoto, assicurati di aver installato ed eseguito l'aggiornamento all'ultima versione di Google Cloud CLI. Google Cloud CLI deve essere alla versione 401.0.0 o successive per concedere all'assistenza clienti Google Cloud le autorizzazioni necessarie. Ti consigliamo di aggiornare regolarmente Google Cloud CLI per ottenere le autorizzazioni aggiuntive e altri miglioramenti.

Per installare i componenti più recenti di gcloud CLI, utilizza il comando gcloud components update. Per saperne di più su come concedere all'assistenza clienti Google Cloud l'accesso remoto in 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 che vengono eseguiti negli stessi spazi dei nomi elencati nella sezione Log del cluster.

Per maggiori dettagli, vedi Configurare la registrazione nel log e il monitoraggio.

Come risolviamo i problemi del tuo ambiente

Ecco un esempio di incidente di assistenza tipico:

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

  2. La richiesta di assistenza viene indirizzata a un Technical Support Engineer specializzato in Google Distributed Cloud.

  3. L'ingegnere dell'assistenza esamina i contenuti dello snapshot per acquisire il contesto dell'ambiente.

  4. L'ingegnere dell'assistenza esamina i log e le metriche nel progetto Google Cloud. Inseriscono l'case ID di assistenza come giustificazione commerciale, che viene registrata internamente.

  5. Il tecnico del servizio di assistenza risponde alla richiesta con una valutazione e un consiglio. L'tecnico del servizio di assistenza e l'utente continuano la risoluzione dei problemi finché non trovano una soluzione.

Cosa supporta Google?

In genere, 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 è e non è supportato:

Google Cloud supportati Non supportata
Kubernetes e il runtime del container Scelta del bilanciatore del carico da parte del cliente (bilanciamento del carico manuale)
Connect e l'agente Connect Codice cliente (vedi Assistenza per sviluppatori)
Google Cloud operations, Monitoring, Logging e agenti Scelta 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 supporto delle versioni

L'obiettivo di queste norme di assistenza per le versioni è quello di 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 secondarie vengono rilasciate circa tre volte all'anno. Le patch per ogni versione secondaria supportata vengono rilasciate circa una volta al mese. Come Kubernetes, Google Distributed Cloud supporta contemporaneamente le tre versioni secondarie più recenti.

Google supporta ogni versione secondaria di Google Distributed Cloud per il periodo successivo tra:

  • 12 mesi dopo il rilascio 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 data è successiva.

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

Queste norme di assistenza per le versioni includono:

  • Assistenza per la risoluzione dei problemi da parte dell'assistenza clienti Google Cloud.
  • Vulnerabilità di sicurezza CVE per Kubernetes e 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 assistenza per la risoluzione dei problemi e i test.

Il supporto esteso può essere approvato in modo condizionale come evento una tantum, con il blocco della versione e i requisiti della cronologia degli upgrade futuri. Per ulteriori informazioni, contatta l'ingegnere di assistenza clienti principale del tuo account o l'account manager. In alternativa, puoi presentare una richiesta di assistenza tramite la console Google Cloud . Queste richieste vengono indirizzate al gruppo di ingegneria dei clienti per il tuo account.

Periodo di assistenza

La tabella seguente mostra le versioni secondarie supportate per Google Distributed Cloud e le date di fine ciclo di vita (EOL) precedenti:

Versione di Google Distributed Cloud Data di uscita Data di fine vita*
1,33 2025-09-02 2026-09-02 o data di rilascio della versione 1.36
1.32 2025-05-06 06/05/2026 o data di rilascio della versione 1.35
1,31 2024-12-18 18/12/2025 o data di rilascio della versione 1.34

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

Per scoprire di più sulla compatibilità delle versioni per Google Distributed Cloud e i prodotti Google Cloud correlati, consulta Supporto di versioni e 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. Questo genera un numero di versione nel 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 successiva a Kubernetes 1.28.
Release di patch di Google Distributed Cloud (z-gke.N)
Una release di patch, ad esempio 1.28.300-gke.131, incrementa di 100 la versione della patch (z) 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 rilascio di patch di Google Distributed Cloud non corrisponde a una versione di patch di Kubernetes.

Modello di responsabilità condivisa

L'esecuzione di un'applicazione di produzione critica per l'attività su Google Distributed Cloud richiede che più parti si assumano responsabilità diverse. Sebbene non siano 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 degli 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.31 → 1.32 → 1.33, ma non 1.31 → 1.33). Quando esegui l'upgrade dei pool di nodi, in alcuni casi puoi saltare una versione secondaria. Per saperne di più sulla logica di aggiornamento, consulta Regole di versione.

  • 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.
  • Manutenzione di qualsiasi workload dell'applicazione di cui è stato eseguito il deployment sul cluster.
  • Esecuzione, manutenzione e applicazione di patch all'infrastruttura del data center, inclusi rete, server, sistema operativo, spazio di archiviazione e connettività a Google Cloud.
  • Esecuzione, manutenzione e applicazione di patch ai bilanciatori del carico di rete se è stata scelta l'opzione di bilanciamento del carico manuale.
  • Eseguire regolarmente l'upgrade delle versioni di Google Distributed Cloud.
  • Monitoraggio del cluster e delle applicazioni e risposta a eventuali incidenti.
  • Assicurarsi che gli agenti della Suite operativa di Google Cloud siano sottoposti a deployment nei cluster.
  • Fornire a Google i dettagli ambientali per la risoluzione dei problemi.

Assistenza per sviluppatori

Google non fornisce assistenza specifica per i carichi di lavoro delle applicazioni. Tuttavia, forniamo assistenza per gli sviluppatori al meglio delle nostre capacità per garantire che i tuoi sviluppatori possano eseguire applicazioni su Google Distributed Cloud. Riteniamo che il coinvolgimento anticipato durante lo sviluppo possa prevenire incidenti critici in un secondo momento del deployment.

Questa assistenza per 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 è il più alto.