Google Kubernetes Engine (GKE) Enterprise è la piattaforma di modernizzazione delle applicazioni di Google Cloud. È basato su Kubernetes e può essere implementato su Google Cloud, su altri cloud, su VMware e su server bare metal. Anche quando un cluster gestito da GKE Enterprise viene eseguito on-premise come parte di Google Distributed Cloud Virtual, è progettato per avere una connessione permanente a Google Cloud per diversi motivi, tra cui il monitoraggio e la gestione. Tuttavia, potrebbe essere necessario sapere cosa succede se, per qualsiasi motivo, si perde la connessione a Google Cloud (ad esempio a causa di un problema tecnico). Questo documento descrive l'impatto di una perdita di connettività per GKE sui cluster Google Distributed Cloud (GKE su Bare Metal e GKE su VMware) e le soluzioni che puoi utilizzare in questo evento.
Queste informazioni sono utili per gli architect che devono prepararsi a una disconnessione non pianificata o forzata da Google Cloud e comprenderne le conseguenze. Tuttavia, non dovresti pianificare di utilizzare Distributed Cloud Virtual disconnesso da Google Cloud come modalità di lavoro nominale. Ricorda che progettiamo GKE Enterprise in modo da sfruttare la scalabilità e la disponibilità dei servizi Google Cloud. Questo documento si basa sulla progettazione e sull'architettura dei vari componenti di GKE Enterprise durante un'interruzione temporanea. Non possiamo garantire che questo documento sia esaustivo.
Questo documento presuppone che tu abbia familiarità con GKE Enterprise. In caso contrario, ti consigliamo di leggere prima la panoramica tecnica di GKE Enterprise.
Convalida e misurazione delle licenze GKE Enterprise
Se hai abilitato GKE Enterprise, significa che l'API Anthos (anthos.googleapis.com) è abilitata nel tuo progetto Google Cloud, il controller di misurazione di GKE Enterprise, in esecuzione nel cluster, genera e aggiorna periodicamente il diritto GKE Enterprise. La tolleranza di disconnessione è di 12 ore. Inoltre, il monitoraggio e la fatturazione vengono gestiti tramite la connessione.
In questa tabella è elencato il comportamento delle funzionalità relative alle licenze e al monitoraggio in caso di disconnessione temporanea da Google Cloud.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| Convalida delle licenze GKE Enterprise | Il controller di misurazione di GKE Enterprise genera e aggiorna periodicamente la risorsa personalizzata del diritto GKE Enterprise, a condizione che 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. | Attualmente illimitato. Dopo la scadenza del periodo di tolleranza, i componenti iniziano a registrare errori. Non puoi più eseguire l'upgrade del cluster. | Nessun valore |
| Misurazione e fatturazione | Il controller di misurazione GKE Enterprise segnala la capacità vCPU del cluster all'API Google Cloud Service Control ai fini della fatturazione. | È presente un agente nel cluster che conserva i record di fatturazione nel cluster quando è disconnesso. I record vengono recuperati una volta che il cluster si riconnette a Google Cloud. | Illimitato. Tuttavia, le informazioni di monitoraggio di GKE Enterprise sono necessarie per la conformità, come indicato nei Termini specifici dei servizi per "Software Premium". | Nessun valore |
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 di 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 console Google Cloud si aggiorna per visualizzare i risultati delle operazioni eseguite durante il periodo di disconnessione.
| Action (Azione) | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa 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 | Nessun valore |
| Upgrade del cluster | Utilizza gli strumenti dell'interfaccia a riga di comando bmctl o gkectl per eseguire l'upgrade dei cluster. Questa operazione richiede una connessione a Google Cloud. |
Non puoi eseguire l'upgrade dei cluster. | Zero | Nessun valore |
| 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 Google Cloud, nell'elenco dei cluster di Google Kubernetes Engine. | Le informazioni sul cluster non vengono visualizzate nella console Google Cloud. | Illimitato | Utilizza kubectl per eseguire query direttamente sui cluster e ottenere le informazioni
di cui hai bisogno. |
| Rimozione dei 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 | Il nuovo nodo estrae le immagini container da Container Registry in modo che funzionino correttamente. Viene eseguito un controllo preflight per verificare che sia presente una connettività a Google Cloud. | I controlli preflight eseguiti durante l'aggiunta di un nuovo nodo convalidano l'esistenza di connettività a Google Cloud. Di conseguenza, non puoi aggiungere un nuovo nodo a un cluster quando è disconnesso. | Zero | Nessun valore |
Ciclo di vita dell'applicazione
La gestione delle applicazioni in esecuzione in un cluster GKE su Google Distributed Cloud è per lo più influenzata da una disconnessione temporanea da Google Cloud. È interessato solo il gateway di connessione. Se utilizzi Container Registry, Artifact Registry, Cloud Build o Cloud Deploy per gestire le immagini container o le pipeline CI/CD in Google Cloud, queste non sono più disponibili in caso di disconnessione. Le strategie per affrontare la disconnessione per questi prodotti non rientrano nell'ambito di questo documento.
| Action (Azione) | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| Deployment dell'applicazione | Viene eseguita in locale utilizzando kubectl, gli strumenti CI/CD o Connect
Gateway. |
Connect Gateway non è disponibile. Tutti gli altri metodi di deployment continuano a funzionare, purché si connettano direttamente all'API Kubernetes. | Illimitato | Se utilizzavi Connect Gateway, passa all'utilizzo di kubectl localmente. |
| Rimozione di applicazioni | Viene eseguita in locale utilizzando kubectl, gli strumenti CI/CD o Connect
Gateway. |
Connect Gateway non è disponibile. Tutti gli altri metodi di deployment continuano a funzionare, purché si connettano direttamente all'API Kubernetes. | Illimitato | Se utilizzavi Connect Gateway, passa all'utilizzo di kubectl localmente. |
| Scale out dell'applicazione | Viene eseguita in locale utilizzando kubectl, gli strumenti CI/CD o Connect
Gateway. |
Connect Gateway non è disponibile. Tutti gli altri metodi di deployment continuano a funzionare, purché si connettano direttamente all'API Kubernetes. | Illimitato | Se utilizzavi Connect Gateway, passa all'utilizzo di kubectl localmente. |
Logging e monitoraggio
La verificabilità aiuta l'organizzazione a soddisfare i requisiti normativi e i criteri di conformità. GKE Enterprise favorisce la verificabilità offrendo logging delle applicazioni, logging di Kubernetes e audit logging. Molti clienti scelgono di sfruttare Cloud Logging e Cloud Monitoring di Google per evitare di gestire un'infrastruttura di logging e monitoraggio on-prem. Altri clienti preferiscono centralizzare i log in un sistema on-prem per l'aggregazione. Per supportare questi clienti, GKE Enterprise fornisce un'integrazione diretta con servizi come Prometheus, Elastic, Splunk o Datadog. In questa modalità, la disconnessione temporanea da Google Cloud non ha alcun impatto sulla funzionalità di logging o monitoraggio.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| Logging delle applicazioni mediante Cloud Logging | I log vengono scritti in Cloud Logging. | I log vengono memorizzati nel buffer sul disco locale. | 4,5 ore o 4 GiB di buffer locale per nodo. Quando il buffer si riempie o la disconnessione dura 4,5 ore, le voci meno recenti vengono eliminate. | Utilizza una soluzione di logging locale. |
| Logging di sistema/Kubernetes mediante Cloud Logging | I log vengono scritti in Cloud Logging. | I log vengono memorizzati nel buffer sul disco locale. | 4,5 ore o 4 GiB di buffer locale per nodo. Quando il buffer si riempie o la disconnessione dura 4,5 ore, le voci meno recenti vengono eliminate. | Utilizza una soluzione di logging locale. |
| Audit logging con Cloud Audit Logs | I log vengono scritti in Cloud Logging. | I log vengono memorizzati nel buffer sul disco locale. | 10 GiB di buffer locale per nodo del piano di controllo. Quando il buffer si riempie, le voci meno recenti vengono eliminate. | Configura l'inoltro dei log a una soluzione di logging locale. |
| Logging delle applicazioni con un altro provider | Puoi utilizzare diversi provider di terze parti, come Elastic, Splunk, Datadog o Loki. | Nessun impatto | Illimitato | - |
| Logging di sistema/Kubernetes tramite un altro provider | Puoi utilizzare diversi provider di terze parti, come Elastic, Splunk o Datadog. | Nessun impatto | Illimitato | - |
| Metriche di applicazioni e Kubernetes scritte in Cloud Monitoring | Le metriche vengono scritte in Cloud Monitoring. | Le metriche vengono memorizzate nel buffer sul disco locale. | buffer locale di 24 ore o 6 GiB per nodo per le metriche di sistema e 1 GiB di buffer locale per nodo per le metriche delle applicazioni. Quando il buffer si riempie o la disconnessione dura 24 ore, le voci meno recenti vengono eliminate | Utilizza una soluzione di monitoraggio locale. |
| Accesso e lettura dei dati di monitoraggio da carichi di lavoro Kubernetes e delle applicazioni | Tutte le metriche sono disponibili nella console Google Cloud e tramite l'API Cloud Monitoring. | Le metriche non vengono aggiornate in Cloud Monitoring durante la disconnessione. | buffer locale di 24 ore o 6 GiB per nodo per le metriche di sistema e 1 GiB di buffer locale per nodo per le metriche delle applicazioni. Quando il buffer si riempie o la disconnessione dura 24 ore, le voci meno recenti vengono eliminate | 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. Gli avvisi possono essere inviati attraverso diversi canali. | Gli avvisi non vengono attivati in caso di disconnessione. Gli avvisi vengono attivati solo dai dati delle metriche già inviati a Cloud Monitoring | Usare una soluzione locale di monitoraggio e avviso. |
Gestione di configurazione e criteri
Config Sync e Policy Controller consentono di gestire la configurazione e i criteri su larga scala, in tutti i cluster. Le configurazioni e i criteri vengono archiviati in un repository Git, i quali vengono sincronizzati automaticamente con i cluster.
Config Sync
Config Sync utilizza gli agenti in-cluster per connettersi
direttamente a un repository Git. Puoi gestire le modifiche all'URL del repository o
ai parametri di sincronizzazione con gli strumenti gcloud o kubectl.
Durante la disconnessione temporanea, la sincronizzazione non è interessata se gli agenti nel cluster possono ancora raggiungere il repository Git. Tuttavia, se modifichi i parametri di sincronizzazione con Google Cloud CLI o con la console Google Cloud, non vengono applicati al cluster durante la disconnessione. Puoi sovrascriverli temporaneamente
in locale utilizzando kubectl. Le modifiche locali vengono sovrascritte alla riconnessione.
Policy Controller
Policy Controller consente l'applicazione di criteri completamente programmabili per i cluster. Questi criteri agiscono come "barriere" e impediscono qualsiasi modifica che violi i controlli di sicurezza, operativi o di conformità da te definiti.
| Action (Azione) | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| Sincronizzazione della configurazione da un repository Git in corso... | Gli agenti nel 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 delle configurazioni non è interessata. Se modifichi i parametri di sincronizzazione con gcloud o nella console Google Cloud, non vengono applicati al cluster durante la disconnessione. Puoi sovrascriverli temporaneamente localmente utilizzando kubectl. Eventuali modifiche locali vengono sovrascritte alla riconnessione. |
Illimitato | Non utilizzare mai l'API Fleet per Config Sync e configurala solo manualmente. |
| Applicazione di criteri sulle richieste all'API Kubernetes | L'agente nel cluster applica i vincoli grazie alla sua integrazione con l'API Kubernetes. Per gestire i criteri, devi utilizzare l'API Kubernetes locale. Puoi gestire la configurazione di sistema di Policy Controller con un'API Google Cloud. | L'applicazione dei criteri non è interessata. I criteri vengono comunque gestiti utilizzando l'API Kubernetes locale. Le modifiche alla configurazione di sistema di Policy Controller utilizzando l'API Google Cloud non vengono propagate al cluster, ma puoi sovrascriverle temporaneamente localmente. Le modifiche locali vengono sovrascritte alla riconnessione. | Illimitato | Non utilizzare mai l'API Fleet per Policy Controller e configurala solo manualmente. |
| Installazione, configurazione o upgrade di Config Sync utilizzando l'API Google Cloud | Puoi utilizzare l'API Google Cloud per gestire l'installazione e l'upgrade degli agenti nel cluster. Puoi utilizzare questa API (o gcloud o la console Google Cloud) anche per gestire la configurazione di questi agenti. | Gli agenti nel cluster continuano a funzionare normalmente. Non puoi installare, eseguire l'upgrade o configurare gli agenti nel cluster utilizzando l'API Google Cloud. Eventuali installazioni, upgrade o configurazioni in sospeso eseguite utilizzando l'API verranno eseguiti al momento della riconnessione. | Zero | Non utilizzare mai l'API Fleet per Policy Controller e configurala solo manualmente. |
| Visualizzazione dello stato del sistema o della sincronizzazione nella console Google Cloud | Puoi visualizzare l'integrità degli agenti nel cluster e lo stato della sincronizzazione utilizzando un'API Google Cloud o la console Google Cloud. | Le informazioni sullo stato nell'API Google Cloud o nella console Google Cloud diventano obsolete. L'API mostra un errore di connessione. Tutte le informazioni rimangono disponibili a livello di cluster utilizzando l'API Kubernetes locale. | Zero | Usa l'interfaccia a riga di comando nomos o l'API Kubernetes locale. |
Sicurezza
Identità, autenticazione e autorizzazione
GKE Enterprise può connettersi direttamente a Cloud Identity per i ruoli utente e applicazione, per gestire i carichi di lavoro utilizzando Connect o per l'autenticazione degli endpoint utilizzando OIDC. In caso di disconnessione da Google Cloud, la connessione a Cloud Identity viene interrotta e queste funzionalità non sono più disponibili. Per i carichi di lavoro che richiedono una maggiore resilienza tramite una disconnessione temporanea, puoi utilizzare GKE Identity Service per integrarlo con un provider LDAP o OIDC (incluso ADFS) per configurare l'autenticazione dell'utente finale.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| Cloud Identity come provider di identità, utilizzando il gateway di Connect | Puoi accedere alle risorse GKE Enterprise utilizzando Cloud Identity come provider di identità e connettendoti tramite il gateway di Connect. | Il gateway Connect richiede una connessione a Google Cloud. Non puoi connetterti ai tuoi cluster durante la disconnessione. | Zero | Utilizza il servizio di identità GKE per eseguire la federazione con un altro provider di identità. |
| Identità e autenticazione mediante un provider di identità di terze parti | Supporta OIDC e LDAP. Per il primo accesso devi utilizzare gcloud CLI. Per i provider OIDC, puoi utilizzare la console Google Cloud per accedere. Puoi quindi eseguire l'autenticazione normalmente utilizzando l'API cluster (ad esempio, utilizzando kubectl). |
Finché il provider di identità rimane accessibile sia a te che al cluster, puoi comunque autenticarti nell'API del cluster. Non puoi accedere tramite la console Google Cloud. Puoi aggiornare la configurazione OIDC o LDAP dei tuoi cluster solo localmente, non puoi utilizzare la console Google Cloud. | Illimitato | - |
| Autorizzazione | GKE Enterprise supporta controllo dell'accesso basato su ruoli (RBAC). I ruoli possono essere attribuiti a utenti, gruppi o account di servizio. Le identità e i gruppi degli utenti possono essere recuperati dal provider di identità. | Il sistema RBAC è locale rispetto al cluster Kubernetes e non è interessato dalla disconnessione da Google Cloud. Tuttavia, se si basa su identità provenienti da Cloud Identity, non sono disponibili in caso di disconnessione. | Illimitato | - |
Gestione di segreti e chiavi
La gestione dei segreti e delle chiavi è una parte importante della strategia di sicurezza. Il comportamento di GKE Enterprise in caso di disconnessione da Google Cloud dipende dal servizio che utilizzi per queste funzionalità.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| Gestione di secret e chiavi mediante 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 sia Secret Manager non sono disponibili. | Zero | Usa invece sistemi locali. |
| Gestione di chiavi e secret mediante Hashicorp Vault e i servizi Google Cloud | Puoi configurare 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 Anthos e anche se è interessato dalla disconnessione, l'archiviazione dei secret e la gestione delle chiavi non sono disponibili durante la disconnessione. | Zero | Usa invece sistemi locali. |
| Gestione di chiavi e secret mediante Hashicorp Vault e servizi on-premise | Puoi configurare Hashicorp Vault in modo da utilizzare 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 | - |
Servizi di networking e rete
Bilanciamento del carico
Per esporre agli utenti i servizi Kubernetes ospitati in un cluster GKE su Google Distributed Cloud, puoi scegliere di utilizzare un bilanciatore del carico in bundle (Google Distributed Cloud Virtual for Bare Metal with MetalLB, Google Distributed Cloud Virtual with Seesaw o MetalLB) o il tuo bilanciatore del carico, esterno a GKE Enterprise. Entrambe le opzioni continuano a funzionare in caso di disconnessione da Google Cloud.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| Bilanciatore del carico in bundle L4 | Fornisce il bilanciamento del carico L4 interamente in locale senza dipendenza dalle API Google Cloud o dalla rete. | Nessuna modifica | Illimitato | - |
| Bilanciatore del carico manuale o integrato | Supporta F5 BIG-IP e altri servizi ospitati on-premise. | Nessuna modifica | Illimitato | - |
Anthos Service Mesh
Puoi utilizzare Anthos Service Mesh per gestire, osservare e proteggere le comunicazioni tra i servizi in esecuzione in un cluster GKE su Google Distributed Cloud. Non tutte le funzionalità di Anthos Service Mesh sono supportate su GKE su Bare Metal e GKE su VMware: per ulteriori informazioni, consulta l'elenco delle funzionalità supportate.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| Deployment o aggiornamento di criteri (routing, autorizzazione, sicurezza, controllo e così via) | Puoi utilizzare la console Google Cloud, kubectl, asmcli o istioctl per gestire i criteri di Anthos Service Mesh. |
Puoi utilizzare solo kubectl o istioctl per gestire i criteri di Anthos Service Mesh. |
Illimitato | Usa kubectl o istioctl |
| Autorità di certificazione (CA) | Puoi utilizzare la CA nel cluster o la CA mesh per gestire i certificati utilizzati da Anthos Service Mesh. | Non è previsto alcun impatto se utilizzi la CA nel cluster. Se utilizzi la CA mesh, i certificati scadono dopo 24 ore. Le nuove istanze di servizio non possono recuperare i certificati. |
Illimitata per CA in-cluster. Servizio ridotto per 24 ore e nessun servizio dopo 24 ore per Mesh CA. |
Utilizza la CA nel cluster. |
| Cloud Monitoring per Anthos Service Mesh | Puoi utilizzare Cloud Monitoring per archiviare, esplorare e sfruttare le metriche relative a HTTP provenienti da Anthos Service Mesh. | Le metriche non vengono archiviate. | Zero | Utilizza una soluzione di monitoraggio locale compatibile come Prometheus. |
| Audit logging di Anthos Service Mesh | Anthos Service Mesh si basa sulle strutture di logging Kubernetes locali. Il comportamento dipende da come hai configurato il logging per il cluster GKE Enterprise. | Dipende da come hai configurato il logging per il cluster GKE Enterprise. | - | - |
| Gateway in entrata | Puoi definire gli IP esterni con il gateway Istio Ingress. | Nessun impatto | Illimitato | - |
| Interfaccia di rete del container Istio (CNI) | Puoi configurare Anthos Service Mesh in modo che utilizzi Istio CNI anziché iptables per gestire il traffico. | Nessun impatto | Illimitato | - |
| Autenticazione dell'utente finale di Anthos Service Mesh per le applicazioni web | Puoi utilizzare il gateway in entrata di Anthos Service Mesh per eseguire l'integrazione con il tuo provider di identità (tramite OIDC) per autenticare e autorizzare gli utenti finali sulle applicazioni web che fanno parte del mesh. | Nessun impatto | Illimitato | - |
Altri servizi di rete
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| DNS | Il server DNS di Kubernetes viene eseguito all'interno del cluster. | Il servizio DNS di Kubernetes funziona normalmente mentre viene eseguito all'interno del cluster stesso. | Illimitato | - |
| Proxy in uscita | Puoi configurare GKE Enterprise in modo da utilizzare un proxy per le connessioni in uscita. | Se il proxy viene eseguito on-premise, GKE Enterprise è comunque in grado di utilizzarlo durante una disconnessione temporanea. Tuttavia, se il proxy perde la connessione a Google Cloud, si applicano comunque tutti gli scenari riportati in questo documento. | Illimitato | - |
Google Cloud Marketplace
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| Deployment e gestione di applicazioni e servizi da Cloud Marketplace | Cloud Marketplace è disponibile nella console Google Cloud 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 | Nessun valore |
Assistenza
Questa sezione copre gli scenari che potresti dover affrontare durante l'interazione con l'assistenza Google Cloud o con il tuo partner operativo per una richiesta relativa ai tuoi cluster GKE su Google Distributed Cloud.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Soluzione alternativa perdita di connettività |
|---|---|---|---|---|
| Condivisione di uno snapshot del cluster con il team di assistenza | Puoi creare uno snapshot del cluster in locale utilizzando i comandi bmctl check cluster
o gkectl diagnose snapshot. Puoi condividere questo snapshot tramite il normale processo di assistenza. |
Puoi comunque generare lo snapshot poiché è un'operazione locale. Se hai perso l'accesso a Google Cloud e alle sue interfacce web di assistenza, puoi chiamare il team di assistenza a condizione che tu abbia sottoscritto un abbonamento ai piani di assistenza Avanzata o Premium. | Illimitato | - |
| Condividere i dati dei log pertinenti con il team di assistenza | Puoi raccogliere i log in locale dal cluster e condividerli tramite il normale processo di assistenza. | Puoi comunque raccogliere i log dal cluster. Se hai perso l'accesso a Google Cloud e alle sue interfacce web di assistenza, puoi chiamare il team di assistenza a condizione che tu abbia sottoscritto un abbonamento ai piani di assistenza Avanzata o Premium. | Illimitato | - |