Assistenza

L'obiettivo principale dell'assistenza di Google è risolvere gli incidenti di produzione il più rapidamente possibile. Comprendere la configurazione, analizzare log e metriche e collaborare con i partner ci consente di risolvere rapidamente gli incidenti.

Google Cloud offre vari pacchetti di assistenza per soddisfare ogni tua esigenza. Tutti i pacchetti di assistenza per Google Cloud includono il supporto per la versione Google Kubernetes Engine (GKE) Enterprise e Google Distributed Cloud. Se disponi già di un pacchetto di assistenza Google Cloud, puoi già usufruire del supporto per GKE Enterprise e Google Distributed Cloud.

Per ulteriori informazioni, consulta la documentazione dell'assistenza Google Cloud.

Requisiti per l'assistenza di Google Distributed Cloud

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

Strumenti di assistenza

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

La configurazione del tuo ambiente

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

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

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

  • Per i cluster utente, crea prima un file YAML del 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. Ecco il contenuto 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 con il comando kubectl. Ecco un comando di esempio che utilizza il file YAML creato nel passaggio precedente. Nell'esempio, la variabile ADMIN_KUBECONFIG specifica il percorso al 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à eseguendo test per vedere se la riconciliazione del job di controllo di integrità è stata terminata. Nel caso di esempio precedente, il nome del job di controllo di integrità è healthcheck.baremetal.cluster.gke.io/healthcheck-7c4qf. Ecco un test di esempio con il comando kubectl che 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
      

      Una volta completato, il comando restituisce:

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

      Puoi vedere 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 dei pod del job di controllo di integrità in un file locale con il comando kubectl. Ecco un esempio in cui viene utilizzato il job di controllo di integrità precedente di esempio:

      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 vengono abilitati per impostazione predefinita e limitati esclusivamente ai componenti a livello di sistema. Ciò replica i log a livello di sistema 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

È possibile eseguire query sui log dalla console Cloud Logging.

Per maggiori dettagli, consulta Logging e Monitoring.

Google Cloud CLI e accesso remoto al cluster

Se apri una richiesta di assistenza, l'assistenza clienti Google Cloud potrebbe chiederti l'accesso remoto in sola lettura ai cluster per diagnosticare e risolvere i problemi in modo più efficace. Per consentire al team di assistenza di disporre dell'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 recuperare autorizzazioni aggiuntive 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 cluster, consulta Assistenza Google Cloud per i cluster registrati.

Metriche del cluster

Oltre ai log, l'agente Cloud Monitoring acquisisce anche le metriche. Ciò replica le metriche a livello di sistema 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 in Log.

Per maggiori dettagli, consulta Logging e Monitoring.

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 o in Google Cloud Support Center e seleziona Google Kubernetes Engine (GKE) Enterprise e Google Distributed Cloud rispettivamente come categoria e componente. Inseriscono le informazioni richieste e allegano l'output dei comandi bmctl pertinenti alla richiesta.

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

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

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

  5. Il tecnico del servizio di assistenza risponde alla richiesta con una valutazione e un consiglio. Il tecnico del servizio di assistenza e l'utente continuano la procedura di risoluzione dei problemi.

Che cosa supporta Google?

In genere, il team di assistenza Cloud supporta tutti i componenti software forniti come parte di Google Distributed Cloud e Cloud Service Mesh, Policy Controller, Config Sync e Config Controller. Per un elenco più completo delle funzionalità supportate e non supportate, consulta la tabella seguente:

Supporto per Google Cloud Funzionalità 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 gli sviluppatori)
Operazioni, Monitoring, Logging e agenti di Google Cloud Sistema operativo scelto dal cliente
Bilanciatore del carico in bundle Server fisico o virtuale, archiviazione e rete
Controller Ingress DNS esterni, DHCP e sistemi di identità
Servizio di identità GKE
Cloud Service Mesh
Policy Controller
Config Sync
Config Controller

Criterio di supporto della versione

Il supporto per Google Distributed Cloud segue i criteri per l'assistenza della versione della versione Google Kubernetes Engine (GKE) Enterprise. A partire dalla versione 1.14 di Google Kubernetes Engine (GKE) Enterprise, Google supporta ogni versione secondaria di Google Distributed Cloud per 12 mesi dopo il rilascio iniziale della versione secondaria o fino al rilascio della terza versione secondaria successiva, a seconda di quale sia la durata più lunga.

Per gli elenchi delle versioni Google Distributed Cloud supportate e non supportate, consulta Controllo delle versioni.

Per informazioni sulla versione relative agli upgrade dei cluster, consulta Regole di versione per gli upgrade.

Funzionalità supportate

Questo documento elenca la disponibilità di funzioni per Google Distributed Cloud per le release supportate. La tabella non è pensata per essere un elenco esaustivo, ma evidenzia alcuni dei vantaggi dell'upgrade dei cluster all'ultima versione supportata.

Le funzionalità elencate come Anteprima sono coperte dai Termini dell'offerta pre-GA dei Termini di servizio di Google Cloud. I prodotti e le funzionalità pre-GA potrebbero avere supporto limitato e le modifiche ai prodotti e alle funzionalità pre-GA potrebbero non essere compatibili con altre versioni pre-GA. Per ulteriori informazioni, consulta le descrizioni della fase di lancio. Le offerte in anteprima sono destinate solo all'uso in ambienti di test.

Le funzionalità elencate come disponibilità generale (GA) sono completamente supportate, aperte a tutti i clienti e pronte per l'uso in produzione.

Funzione/funzionalità 1,15 (non supportata) 1,16 1,28 1,29 (più recente)
Supporto dei cluster di amministrazione per più versioni del cluster utente - - - Anteprima
criteri di avviso Anteprima Anteprima Anteprima Anteprima
Runtime VM su Google Distributed Cloud GA GA GA GA
Gruppi di Azure Active Directory (AD) GA GA GA GA
Supporto del bilanciatore del carico basato su BGP per IPv6 GA GA GA GA
Autorizzazione binaria Anteprima GA GA GA
Bilanciamento del carico in bundle con BGP GA GA GA GA
Audit logging di Cloud GA GA GA GA
Supporto dell'interfaccia a riga di comando per il backup e il ripristino dei cluster GA GA GA GA
Rotazione delle autorità di certificazione (CA) dei cluster GA GA GA GA
Supporto dell'interfaccia a riga di comando della reimpostazione dei nodi cluster GA GA GA GA
Messa in pausa e ripresa dell'upgrade del cluster - - Anteprima Anteprima
runtime container containerd GA GA GA GA
Gruppo di controllo v2 GA GA GA GA
Autorità di certificazione personalizzate - Anteprima GA GA
Modalità di inoltro del bilanciamento del carico con bilanciamento del carico Dataplane V2 Direct Server Return (DSR) - Anteprima GA GA
IP fisso dinamico con BGP (Border Gateway Protocol) GA GA GA GA
Gateway NAT in uscita GA GA GA GA
Modalità IPv4 flat (statica) GA GA GA GA
Supporto IPv6 fisso (modalità BGP) GA GA GA GA
GKE Identity Service v2 - - Anteprima GA
Dual stack IPv4/IPv6 GA GA GA GA
Assistenza in Arabia Saudita GA GA GA GA
Raccoglitore gestito per Google Cloud Managed Service per Prometheus GA GA GA GA
Connettività multi-cluster Anteprima Anteprima Anteprima Anteprima
NIC multipli per i pod GA GA GA GA
Gateway di rete per GDC Anteprima Anteprima Anteprima Anteprima
Rilevatore di problemi dei nodi GA GA GA GA
Upgrade di nodi paralleli GA GA GA GA
Upgrade di pool di nodi paralleli Anteprima GA GA GA
Operatore di ottimizzazione delle prestazioni - Anteprima Anteprima Anteprima
Supporto del registry privato per i nodi - - - Anteprima
Supporto del mirroring del registro GA GA GA GA
Modalità di computing sicura (seccomp) GA GA GA GA
Salta l'upgrade della versione del pool di nodi - - Anteprima GA
Networking SR-IOV GA GA GA GA
Metriche dell'API di riepilogo GA GA GA GA
Controlli di servizio VPC Anteprima GA GA GA
Rollback dell'upgrade del pool di nodi worker - - - Anteprima
Workload Identity GA GA GA GA

Modello di responsabilità condivisa

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

Responsabilità di Google

  • Manutenzione e distribuzione del pacchetto software Google Distributed Cloud.
  • Avvisare gli utenti degli upgrade disponibili per Google Distributed Cloud e produrre script di upgrade per la versione precedente; Google Distributed Cloud supporta solo upgrade sequenziali (ad esempio: 1.2 → 1.3 → 1.4 e non 1.2 → 1.4).
  • Uso dei servizi Connect e Suite operativa di Google Cloud.
  • Risoluzione dei problemi, soluzioni alternative e correzione della causa principale di eventuali problemi relativi ai componenti forniti da Google

Responsabilità degli utenti

  • Amministrazione generale del sistema per cluster on-premise.
  • Mantenimento dei carichi di lavoro delle applicazioni di cui è stato eseguito il deployment nel cluster.
  • Esecuzione, manutenzione e applicazione di patch all'infrastruttura dei data center, compresi networking, server, sistema operativo, archiviazione e connettività a Google Cloud.
  • Esecuzione, manutenzione e applicazione di patch dei bilanciatori del carico di rete se si sceglie l'opzione manuale.
  • Upgrade regolari delle versioni di Google Distributed Cloud.
  • Monitoraggio del cluster e delle applicazioni e risposta a eventuali incidenti.
  • Assicurarsi che il deployment degli agenti nella suite operativa di Google Cloud venga eseguito nei cluster.
  • Fornire a Google dettagli ambientali per la risoluzione dei problemi.

Assistenza per gli sviluppatori

Google non fornisce assistenza specifica per i carichi di lavoro delle applicazioni. Tuttavia, forniamo assistenza agli sviluppatori con il best effort per garantire che i tuoi sviluppatori possano eseguire applicazioni su Google Distributed Cloud. Riteniamo che un intervento anticipato durante lo sviluppo possa prevenire incidenti critici nelle fasi successive del deployment.

L'Assistenza per gli sviluppatori basata sul best effort è disponibile per i clienti con qualsiasi pacchetto di assistenza a pagamento ed è considerata una priorità P3 per un problema che blocca un lancio o una priorità P4 per la consulenza generale. In questa classificazione, il livello di priorità 0 è la priorità più alta.