Impatto della disconnessione temporanea da Google Cloud

Google Distributed Cloud (solo software) si basa su Kubernetes e puoi eseguirne il deployment on-premise su server VMware o bare metal. Sebbene Distributed Cloud venga eseguito on-premise, lo progettiamo in modo che abbia una connessione permanente a Google Cloud per una serie di motivi, tra cui il monitoraggio e la gestione. Tuttavia, potresti aver bisogno di sapere cosa succede se, per qualsiasi motivo, perdi la connessione a Google Cloud (ad esempio, a causa di un problema tecnico). Questo documento descrive l'impatto di una perdita di connettività per i cluster in un deployment solo software di Distributed Cloud (su bare metal o su VMware) e quali soluzioni alternative puoi utilizzare in questo caso.

Queste informazioni sono utili per gli architetti che devono prepararsi a una disconnessione non pianificata o forzata da Google Cloud e comprenderne le conseguenze. Tuttavia, non dovresti pianificare l'utilizzo di un deployment Distributed Cloud solo software disconnesso daGoogle Cloud come modalità di lavoro nominale. Ricorda che progettiamo Distributed Cloud per sfruttare la scalabilità e la disponibilità dei servizi Google Cloud . Questo documento si basa sulla progettazione e sull'architettura dei vari componenti Google Cloud che funzionano in modo compatibile con Distributed Cloud durante un'interruzione temporanea. Non possiamo garantire che questo documento sia esaustivo.

Questo documento presuppone che tu abbia familiarità con GKE. In caso contrario, ti consigliamo di leggere prima la panoramica di GKE.

Convalida e misurazione delle licenze

Se hai abilitato l'API Anthos (anthos.googleapis.com) nel tuo progetto Google Cloud , il controller di misurazione in esecuzione nel cluster genera e aggiorna periodicamente il diritto alla licenza. La tolleranza per la disconnessione è di 12 ore. Inoltre, il sistema richiede la connessione per gestire la misurazione e la fatturazione.

Questa tabella elenca il comportamento delle funzionalità relative alle licenze e alla misurazione in caso di disconnessione temporanea da Google Cloud:

Funzionalità Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Convalida della licenza Il controller di misurazione genera e aggiorna periodicamente la risorsa personalizzata dei diritti di licenza, purché anthos.googleapis.com sia abilitato nel progetto Google Cloud . I componenti che utilizzano la risorsa personalizzata dei diritti supportano un periodo di tolleranza: continuano a funzionare finché la risorsa personalizzata dei diritti viene aggiornata entro il periodo di tolleranza. Illimitato. Allo scadere del periodo di tolleranza, i componenti iniziano a registrare errori. Non puoi più eseguire l'upgrade del cluster. Nessuno
Misurazione e fatturazione Il controller di misurazione segnala la capacità vCPU del cluster all'API Service Control Google Cloud per la fatturazione. Un agente in-cluster conserva i record di fatturazione nel cluster durante la disconnessione e li recupera una volta che il cluster si riconnette a Google Cloud. Illimitato. Tuttavia, le informazioni di misurazione sono necessarie per la conformità, come indicato nei Termini specifici dei servizi per "Software Premium". Nessuno

Ciclo di vita del cluster

Questa sezione illustra scenari come la creazione, l'aggiornamento, l'eliminazione e il ridimensionamento dei cluster, nonché il monitoraggio dello stato di queste attività.

Nella maggior parte degli scenari, puoi utilizzare strumenti dell'interfaccia a riga di comando come bmctl, gkectl e kubectl per eseguire operazioni durante una disconnessione temporanea. Puoi anche monitorare lo stato di queste operazioni con questi strumenti. Al momento della riconnessione, la consoleGoogle Cloud si aggiorna per visualizzare i risultati delle operazioni eseguite durante il periodo di disconnessione.

Azione Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Creazione del cluster Utilizza gli strumenti dell'interfaccia a riga di comando bmctl o gkectl per creare i cluster. Questa operazione richiede una connessione a Google Cloud. Non puoi creare cluster. Zero Nessuno
Upgrade del cluster Per eseguire l'upgrade dei cluster, utilizza gli strumenti dell'interfaccia a riga di comando bmctl o gkectl. Questa operazione richiede una connessione a Google Cloud. Non puoi eseguire l'upgrade dei cluster. Zero Nessuno
Eliminazione del cluster Utilizza gli strumenti dell'interfaccia a riga di comando bmctl o gkectl per eliminare i cluster. Questa operazione non richiede una connessione a Google Cloud. Puoi eliminare i cluster. Illimitato -
Visualizzazione dello stato del cluster Puoi visualizzare le informazioni sui tuoi cluster nella console, nell'elenco dei cluster Google Kubernetes Engine. Le informazioni sul cluster non vengono visualizzate nella console. Illimitato Utilizza kubectl per eseguire query direttamente sui cluster e ottenere le informazioni di cui hai bisogno.
Rimozione di nodi da un cluster Non è necessaria una connessione a Google Cloud per rimuovere i nodi da un cluster. Puoi rimuovere i nodi da un cluster. Illimitato -
Aggiunta di nodi a un cluster Per funzionare correttamente, il nuovo nodo esegue il pull delle immagini container da Container Registry. Viene eseguito un controllo preflight per verificare la connettività a Google Cloud. I controlli preflight eseguiti durante l'aggiunta di un nuovo nodo convalidano la connettività a Google Cloud. Pertanto, non puoi aggiungere un nuovo nodo a un cluster quando è disconnesso. Zero Nessuno

Ciclo di vita dell'applicazione

Una disconnessione temporanea da Google Cloud non influisce sulla gestione delle tue applicazioni in esecuzione in un cluster on-premise. Solo il gateway di connessione è interessato. Se utilizzi Container Registry, Artifact Registry, Cloud Build o Cloud Deploy per gestire le immagini container o le pipeline CI/CD inGoogle Cloud, queste non saranno disponibili in caso di disconnessione. Le strategie per gestire la disconnessione per questi prodotti non rientrano nell'ambito di questo documento.

Azione Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Deployment dell'applicazione Esegui il deployment delle applicazioni localmente utilizzando kubectl, tramite gli strumenti CI/CD o utilizzando il gateway di connessione. Il gateway di connessione non è disponibile. Tutti gli altri metodi di deployment continuano a funzionare, purché si connettano direttamente all'API Kubernetes. Illimitato Se utilizzi il gateway di connessione, passa all'utilizzo di kubectl localmente.
Rimozione di applicazioni Puoi rimuovere le applicazioni localmente utilizzando kubectl, tramite gli strumenti CI/CD o utilizzando il gateway di connessione. Il gateway di connessione non è disponibile. Tutti gli altri metodi di deployment continuano a funzionare, purché si connettano direttamente all'API Kubernetes. Illimitato Se utilizzi il gateway di connessione, passa all'utilizzo di kubectl localmente.
Scale out dell'applicazione Puoi fare lo scale out delle applicazioni localmente utilizzando kubectl, tramite gli strumenti CI/CD o utilizzando il gateway di connessione. Il gateway di connessione non è disponibile. Tutti gli altri metodi di deployment continuano a funzionare, purché si connettano direttamente all'API Kubernetes. Illimitato Se utilizzi il gateway di connessione, passa all'utilizzo di kubectl localmente.

Logging e monitoraggio

La possibilità di eseguire audit aiuta la tua organizzazione a soddisfare i requisiti normativi e le policy di conformità. Distributed Cloud semplifica l'auditabilità offrendo il logging delle applicazioni, di Kubernetes e di audit. Molti clienti scelgono di utilizzare Cloud Logging e Cloud Monitoring di Google per evitare di gestire un'infrastruttura di logging e monitoraggio on-premise. Altri clienti preferiscono centralizzare i log in un sistema on-premise per l'aggregazione. Per supportare questi clienti, Distributed Cloud supporta l'integrazione diretta con servizi come Prometheus. In questa modalità, durante la disconnessione temporanea da Google Cloud, non si verifica alcun impatto sulle funzionalità di logging o monitoraggio.

Funzionalità Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Logging delle applicazioni tramite Cloud Logging Il sistema scrive i log in Cloud Logging. Il sistema memorizza i log nel buffer sul disco locale. Buffer locale di 4,5 ore o 4 GiB per nodo. Quando il buffer si riempie o la disconnessione dura 4,5 ore, il sistema elimina le voci meno recenti. Utilizza una soluzione di logging locale.
Logging di sistema/Kubernetes tramite Cloud Logging Il sistema scrive i log in Cloud Logging. Il sistema memorizza i log nel buffer sul disco locale. Buffer locale di 4,5 ore o 4 GiB per nodo. Quando il buffer si riempie o la disconnessione dura 4,5 ore, il sistema elimina le voci meno recenti. Utilizza una soluzione di logging locale.
Audit logging con Cloud Audit Logs Il sistema scrive i log in Cloud Logging. Il sistema memorizza i log nel buffer sul disco locale. Buffer locale di 10 GiB per nodo del control plane. Quando il buffer si riempie, il sistema elimina le voci meno recenti. Configura l'inoltro dei log a una soluzione di logging locale.
Logging delle applicazioni tramite un altro provider Puoi utilizzare diversi provider di terze parti come Elastic, Splunk, Datadog o Loki. Nessun impatto Illimitato -
Logging di sistema/Kubernetes utilizzando un altro provider Puoi utilizzare diversi provider di terze parti come Elastic, Splunk o Datadog. Nessun impatto Illimitato -
Metriche dell'applicazione e di Kubernetes scritte in Cloud Monitoring Il sistema scrive le metriche in Cloud Monitoring. Il sistema memorizza nel buffer le metriche sul disco locale. Buffer locale di 24 ore o 6 GiB per nodo per le metriche di sistema e buffer locale di 1 GiB per nodo per le metriche dell'applicazione. Quando il buffer si riempie o la disconnessione dura 24 ore, il sistema elimina le voci meno recenti. Utilizza una soluzione di monitoraggio locale.
Accesso e lettura dei dati di monitoraggio dai workload di Kubernetes e delle applicazioni Tutte le metriche sono disponibili nella console e tramite l'API Cloud Monitoring. Il sistema non aggiorna le metriche in Cloud Monitoring durante la disconnessione. Buffer locale di 24 ore o 6 GiB per nodo per le metriche di sistema e buffer locale di 1 GiB per nodo per le metriche dell'applicazione. Quando il buffer si riempie o la disconnessione dura 24 ore, il sistema elimina le voci meno recenti. Utilizza una soluzione di monitoraggio locale.
Regole di avviso e paging per le metriche Cloud Monitoring supporta gli avvisi. Puoi creare avvisi per qualsiasi metrica. Il sistema può inviare avvisi tramite canali diversi. Il sistema non attiva avvisi quando è disconnesso. Il sistema attiva gli avvisi solo in base ai dati delle metriche già inviati a Cloud Monitoring. Utilizza una soluzione di monitoraggio e avviso locale.

Gestione della configurazione e delle policy

Config Sync e Policy Controller ti consentono di gestire la configurazione e le policy su larga scala in tutti i tuoi cluster. Le configurazioni e le policy vengono archiviate in un repository Git e il sistema le sincronizza automaticamente con i tuoi cluster.

Config Sync

Config Sync utilizza agenti in-cluster per connettersi direttamente a un repository Git. Puoi gestire le modifiche all'URL del repository o ai parametri di sincronizzazione con Google Cloud CLI o gli strumenti kubectl.

Durante la disconnessione temporanea, la sincronizzazione non viene influenzata se gli agenti in-cluster possono ancora raggiungere il repository Git. Tuttavia, se modifichi i parametri di sincronizzazione con gcloud CLI o la console, il cluster non li applica durante la disconnessione. Puoi sovrascriverli temporaneamente in locale utilizzando kubectl. La riconnessione sovrascrive le modifiche locali.

Policy Controller

Policy Controller consente l'applicazione di policy completamente programmabili per i cluster. Queste policy agiscono come "barriere" e impediscono qualsiasi modifica che violi i controlli di sicurezza, operativi o di conformità che hai definito.

Azione Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Sincronizzazione della configurazione da un repository Git Gli agenti in-cluster si connettono direttamente al repository Git. Puoi modificare l'URL del repository o i parametri di sincronizzazione con un'API Google Cloud . La sincronizzazione della configurazione rimane invariata. Se modifichi i parametri di sincronizzazione con gcloud CLI o nella console, il cluster non li applica durante la disconnessione. Puoi sovrascriverli temporaneamente a livello locale utilizzando kubectl. La riconnessione sovrascrive le modifiche locali. Illimitato Non utilizzare mai l'API Fleet per Config Sync e configurala solo utilizzando l'API Kubernetes.
Applicazione delle policy alle richieste all'API Kubernetes L'agente in-cluster applica i vincoli grazie alla sua integrazione con l'API Kubernetes. Puoi gestire le policy utilizzando l'API Kubernetes locale. Puoi gestire la configurazione di sistema di Policy Controller con un'API Google Cloud. L'applicazione delle policy rimane invariata. Puoi comunque gestire le policy utilizzando l'API Kubernetes locale. Il sistema non propaga le modifiche alla configurazione di sistema di Policy Controller utilizzando l'API Google Cloud al cluster, ma puoi sovrascriverle temporaneamente in locale. La riconnessione sovrascrive le modifiche locali. Illimitato Non utilizzare mai l'API Fleet per Policy Controller e configuralo solo utilizzando l'API Kubernetes.
Installazione, configurazione o upgrade di Config Sync utilizzando l'API Google Cloud Utilizza l'API Google Cloud per gestire l'installazione e l'upgrade degli agenti in-cluster. Utilizzi questa API (o gcloud CLI o la console) anche per gestire la configurazione di questi agenti. Gli agenti in-cluster continuano a funzionare normalmente. Non puoi installare, eseguire l'upgrade o configurare gli agenti in-cluster utilizzando l'API Google Cloud . Eventuali installazioni, upgrade o configurazioni in attesa eseguite utilizzando l'API procedono dopo la riconnessione. Zero Non utilizzare mai l'API Fleet per Policy Controller e configuralo solo utilizzando l'API Kubernetes.
Visualizzazione dello stato del sistema o della sincronizzazione nella console Puoi visualizzare lo stato degli agenti in-cluster e lo stato della sincronizzazione utilizzando un'API Google Cloud o la console. Le informazioni sullo stato nell'API Google Cloud o nella console diventano obsolete. L'API mostra un errore di connessione. Tutte le informazioni rimangono disponibili per cluster utilizzando l'API Kubernetes locale. Zero Utilizza l'interfaccia a riga di comando nomos o l'API Kubernetes locale.

Sicurezza

Questa sezione descrive in che modo le funzionalità di sicurezza, tra cui identità, autenticazione, autorizzazione e gestione dei secret, sono interessate da una disconnessione temporanea da Google Cloud.

Identità, autenticazione e autorizzazione

Distributed Cloud può connettersi direttamente a Cloud Identity per i ruoli di applicazioni e utenti, per gestire i workload utilizzando Connect o per l'autenticazione degli endpoint utilizzando OIDC. Una disconnessione da Google Cloud interrompe la connessione a Cloud Identity, rendendo queste funzionalità non disponibili. Per i workload che richiedono una maggiore resilienza tramite una disconnessione temporanea, puoi utilizzare GKE Identity Service per l'integrazione con un provider LDAP o OIDC (incluso ADFS) per configurare l'autenticazione degli utenti finali.

Funzionalità Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Cloud Identity come provider di identità, utilizzando il gateway di connessione Puoi accedere alle risorse Distributed Cloud utilizzando Cloud Identity come provider di identità e connettendoti tramite il gateway di connessione. Il gateway di connessione richiede una connessione a Google Cloud. Non potrai connetterti ai tuoi cluster durante la disconnessione. Zero Utilizza GKE Identity Service per eseguire la federazione con un altro provider di identità.
Identità e autenticazione tramite un provider di identità di terze parti Supporta OIDC e LDAP. Utilizza gcloud CLI per accedere. Per i provider OIDC, puoi utilizzare la console per accedere. Puoi quindi autenticarti normalmente nell'API del cluster (ad esempio, utilizzando kubectl). Finché il provider di identità rimane accessibile sia a te che al cluster, puoi comunque eseguire l'autenticazione con l'API del cluster. Non puoi accedere tramite la console. Puoi aggiornare la configurazione OIDC o LDAP dei tuoi cluster solo localmente, non puoi utilizzare la console. Illimitato -
Autorizzazione Distributed Cloud supporta controllo dell'accesso basato su ruoli (RBAC). I ruoli possono essere attribuiti a utenti, gruppi o service account. Il sistema recupera le identità e i gruppi di utenti dal provider di identità. Il sistema RBAC è locale nel cluster Kubernetes e la disconnessione da Google Cloud non lo influisce. Tuttavia, se si basa su identità provenienti da Cloud Identity, queste non sono disponibili in caso di disconnessione. Illimitato -

Gestione di secret e chiavi

La gestione di secret e chiavi è una parte importante della tua security posture. Il comportamento di Distributed Cloud in caso di disconnessione daGoogle Cloud dipende dal servizio che utilizzi per queste funzionalità.

Funzionalità Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Gestione di secret e chiavi utilizzando Cloud Key Management Service e Secret Manager Utilizzi direttamente Cloud Key Management Service per le chiavi di crittografia e Secret Manager per i secret. Sia Cloud Key Management Service che Secret Manager non sono disponibili. Zero Utilizza invece i sistemi locali.
Gestione di secret e chiavi utilizzando Hashicorp Vault e i servizi Google Cloud Configura Hashicorp Vault in modo che utilizzi Cloud Storage o Spanner per archiviare i secret e Cloud Key Management Service per gestire le chiavi. Se Hashicorp Vault viene eseguito sul tuo cluster on-premise e la disconnessione lo interessa, l'archiviazione dei secret e la gestione delle chiavi non sono disponibili durante la disconnessione. Zero Utilizza invece i sistemi locali.
Gestione di secret e chiavi utilizzando Hashicorp Vault e servizi on-premise Configura Hashicorp Vault in modo che utilizzi un backend di archiviazione on-premise per i secret e un sistema di gestione delle chiavi on-premise (ad esempio un modulo di sicurezza hardware). La disconnessione da Google Cloud non ha alcun impatto. Illimitato -

Networking e servizi di rete

Questa sezione illustra il networking e i servizi di rete per i cluster on-premise, incluso l'impatto di una disconnessione temporanea daGoogle Cloud. Fornisce informazioni sul bilanciamento del carico, su Cloud Service Mesh e su altri servizi di rete.

Bilanciamento del carico

Per esporre agli utenti i servizi Kubernetes ospitati in un cluster on-premise, hai le seguenti opzioni:

Queste opzioni di bilanciamento del carico rimangono operative anche se disconnesse daGoogle Cloud.

Funzionalità Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Bilanciatore del carico in bundle L4 Fornisce il bilanciamento del carico L4 interamente a livello locale, senza dipendenza dalle API o dalla reteGoogle Cloud . Nessuna modifica Illimitato -
Bilanciatore del carico manuale o integrato Supporta F5 BIG-IP e altri servizi ospitati anche on-premise. Nessuna modifica Illimitato -

Cloud Service Mesh

Puoi utilizzare Cloud Service Mesh per gestire, osservare e proteggere le comunicazioni tra i servizi in esecuzione in un cluster on-premise. Distributed Cloud non supporta tutte le funzionalità di Cloud Service Mesh: consulta l'elenco delle funzionalità supportate per ulteriori informazioni.

Funzionalità Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Deployment o aggiornamento delle policy (routing, autorizzazione, sicurezza, audit ecc.) Puoi utilizzare la console, kubectl, asmcli o istioctl per gestire le policy di Cloud Service Mesh. Puoi utilizzare solo kubectl o istioctl per gestire le policy di Cloud Service Mesh. Illimitato Utilizza kubectl o istioctl
Autorità di certificazione (CA) Puoi utilizzare la CA in-cluster o l'autorità di certificazione Cloud Service Mesh per gestire i certificati utilizzati da Cloud Service Mesh. Non vi è alcun impatto se utilizzi la CA in-cluster.
Se utilizzi l'autorità di certificazione Cloud Service Mesh, i certificati scadono dopo 24 ore. Le nuove istanze di servizio non possono recuperare i certificati.		 Illimitato per la CA in-cluster.
Servizio ridotto per 24 ore e nessun servizio dopo 24 ore per l'autorità di certificazione Cloud Service Mesh.		 Utilizza la CA interna al cluster.
Cloud Monitoring per Cloud Service Mesh Puoi utilizzare Cloud Monitoring per archiviare, esplorare e sfruttare le metriche relative ad HTTP provenienti da Cloud Service Mesh. Le metriche non vengono archiviate. Zero Utilizza una soluzione di monitoraggio locale compatibile, come Prometheus.
Audit logging di Cloud Service Mesh Cloud Service Mesh si basa sulle funzionalità di logging di Kubernetes locali. Il comportamento dipende da come hai configurato il logging per il cluster on-premise. Dipende da come hai configurato il logging per il cluster on-premise. - -
Gateway in entrata Puoi definire IP esterni con il gateway in entrata Istio. Nessun impatto Illimitato -
Container Network Interface (CNI) di Istio Puoi configurare Cloud Service Mesh in modo che utilizzi Istio CNI anziché iptables per gestire il traffico. Nessun impatto Illimitato -
Autenticazione utente finale di Cloud Service Mesh per applicazioni web Puoi utilizzare il gateway in entrata di Cloud Service Mesh per l'integrazione con il tuo provider di identità (tramite OIDC) per autenticare e autorizzare gli utenti finali nelle applicazioni web che fanno parte del mesh. Nessun impatto Illimitato -

Altri servizi di rete

Funzionalità Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
DNS Il server DNS di Kubernetes viene eseguito all'interno del cluster. Il servizio DNS di Kubernetes funziona normalmente, poiché viene eseguito all'interno del cluster stesso. Illimitato -
Proxy in uscita Puoi configurare i cluster on-premise in modo che utilizzino un proxy per le connessioni in uscita. Se il proxy viene eseguito on-premise, il cluster può comunque utilizzarlo durante una disconnessione temporanea. Tuttavia, se il proxy perde la connessione a Google Cloud, tutti gli scenari di questo documento continuano a essere applicabili. Illimitato -

Google Cloud Marketplace

Funzionalità Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Deployment e gestione di applicazioni e servizi da Cloud Marketplace Cloud Marketplace è disponibile nella console e puoi utilizzarlo per scoprire, acquisire ed eseguire il deployment di soluzioni. Non puoi utilizzare Cloud Marketplace. Alcune soluzioni di Cloud Marketplace potrebbero avere requisiti di connettività propri non documentati qui. Zero Nessuno

Assistenza

Questa sezione illustra gli scenari che potresti dover affrontare durante l'interazione con l'assistenzaGoogle Cloud o il tuo partner operativo per una richiesta relativa ai cluster GKE su GDC.

Funzionalità Comportamento connesso Comportamento in caso di disconnessione temporanea Tolleranza massima di disconnessione Soluzione alternativa per la perdita di connettività
Condivisione di uno snapshot del cluster con il team di assistenza Puoi creare uno snapshot del cluster localmente utilizzando i comandi bmctl check cluster o gkectl diagnose snapshot. Puoi condividere questo snapshot tramite la normale procedura di assistenza. Puoi comunque generare lo snapshot, poiché si tratta di un'operazione locale. Se hai perso l'accesso a Google Cloud e alle relative interfacce web di assistenza, puoi contattare telefonicamente il team di assistenza, a condizione che tu abbia sottoscritto i piani di assistenza Avanzata o Premium. Illimitato -
Condivisione dei dati di log pertinenti con il team di assistenza Puoi raccogliere i log localmente dal tuo cluster e condividerli tramite la normale procedura di assistenza. Puoi comunque raccogliere i log dal tuo cluster. Se hai perso l'accesso a Google Cloud e alle relative interfacce web di assistenza, puoi contattare telefonicamente il team di assistenza, a condizione che tu abbia sottoscritto i piani di assistenza Avanzata o Premium. Illimitato -