La versione Google Kubernetes Engine (GKE) Enterprise è la modernizzazione delle applicazioni di Google Cloud completamente gestita. È basato su Kubernetes e può essere implementato in Google Cloud, altri cloud e on-premise con Google Distributed Cloud (sia su server VMware che su server bare metal). Anche quando viene gestito da GKE Enterprise, viene eseguito on-premise, è progettato per avere una connessione permanente per diversi motivi, tra cui il monitoraggio e la gestione. Tuttavia, potrebbe essere necessario sapere cosa succederebbe se, per qualsiasi motivo, connessione a Google Cloud viene interrotta (ad esempio a causa di un problema tecnico questo problema). Questo documento illustra l'impatto di una perdita di connettività per i cluster in un deployment solo software Google Distributed Cloud (su Bare Metal o su VMware) e quali soluzioni alternative che puoi utilizzare in questo evento.
Queste informazioni sono utili per gli architetti che devono prepararsi per un evento non pianificato o la disconnessione forzata da Google Cloud e comprenderne le conseguenze. Tuttavia, non dovresti pianificare di utilizzare un deployment Google Distributed Cloud solo software disconnesso da Google Cloud come modalità di lavoro nominale. Ricorda che progettiamo per sfruttare la scalabilità e la disponibilità servizi Google Cloud. Questo documento è basato sulle la progettazione e l'architettura dei vari componenti di GKE Enterprise un'interruzione temporanea. Non possiamo garantire che questo documento è esaustivo.
Questo documento presuppone che tu abbia familiarità con GKE Enterprise. Se non è così in questo caso, ti consigliamo di leggere prima Panoramica tecnica di GKE Enterprise.
Convalida e misurazione della licenza di GKE Enterprise
Se hai abilitato GKE Enterprise, API Anthos (anthos.googleapis.com) sia abilitata nel tuo progetto Google Cloud, la misurazione di GKE Enterprise in esecuzione nel cluster, genera e aggiorna GKE Enterprise. periodicamente. La tolleranza per la disconnessione è di 12 ore. Inoltre, il monitoraggio e la fatturazione vengono gestiti tramite la connessione.
In questa tabella viene elencato il comportamento delle funzionalità relative alle licenze e al monitoraggio in di disconnessione temporanea da Google Cloud.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Convalida della licenza di GKE Enterprise | Il controller di monitoraggio di GKE Enterprise genera e aggiorna Risorsa personalizzata per i diritti GKE Enterprise periodicamente, a condizione che anthos.googleapis.com è abilitato nel progetto Google Cloud. | I componenti che utilizzano la risorsa personalizzata dei diritti supportano un periodo di tolleranza: continuano a funzionare per tutto il tempo in cui il contratto personalizzato la risorsa viene aggiornata entro il periodo di tolleranza. | Attualmente illimitato. Dopo la scadenza del periodo di tolleranza, i componenti inizieranno log degli errori. Non puoi più eseguire l'upgrade del cluster. | Nessuno |
| Misurazione e fatturazione | Il controller di monitoraggio GKE Enterprise segnala la capacità della vCPU di fatturazione all'API Google Cloud Service Control. | C'è un agente nel cluster che rende persistenti i record di fatturazione quando il cluster è disconnesso e i record vengono recuperati una volta che il cluster si riconnette a Google Cloud. | Illimitata. Tuttavia, le informazioni di misurazione di GKE Enterprise sono obbligatorie come indicato nel documento specifico per i servizi Termini di "Software premium". | Nessuno |
Ciclo di vita del cluster
Questa sezione tratta scenari come la creazione, l'aggiornamento, l'eliminazione e il ridimensionamento cluster, nonché il monitoraggio dello stato di queste attività.
Per la maggior parte degli scenari, puoi usare strumenti dell'interfaccia a riga di comando come bmctl, gkectl e
kubectl per eseguire operazioni durante una disconnessione temporanea. Puoi anche
di controllare 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
in un periodo disconnesso.
| Azione | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Creazione del cluster | Puoi utilizzare 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 | Puoi utilizzare 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 | Nessuno |
| Eliminazione del cluster | Per eliminare i cluster, puoi utilizzare gli strumenti dell'interfaccia a riga di comando bmctl o gkectl. Questa operazione
non richiede una connessione a Google Cloud. |
Puoi eliminare i cluster. | Illimitato | - |
| Visualizzazione dello stato del cluster | Puoi visualizzare informazioni sui tuoi cluster nella console Google Cloud, nell'elenco dei cluster Google Kubernetes Engine. | Le informazioni sul cluster non vengono mostrate nella console Google Cloud. | Illimitato | Usa kubectl per eseguire query direttamente sui tuoi cluster e ottenere le informazioni
necessaria. |
| Rimozione di nodi da un cluster | Non è necessaria una connessione a Google Cloud per rimuovere i nodi da un in un cluster Kubernetes. | Puoi rimuovere i nodi da un cluster. | Illimitato | - |
| Aggiunta di nodi a un cluster | Il nuovo nodo esegue il pull delle immagini container da Container Registry per funzionare correttamente. Viene eseguito un controllo preflight per verificare la connettività in Google Cloud. | I controlli preflight eseguiti quando aggiungi un nuovo nodo confermano che per la connettività a Google Cloud. Pertanto, non puoi aggiungere un nuovo nodo a un quando il cluster è disconnesso. | Zero | Nessuno |
Ciclo di vita dell'applicazione
La gestione delle applicazioni in esecuzione in un cluster on-premise non è per lo più influenzata da un disconnessione temporanea da Google Cloud. Solo il Connect Gateway è interessato. Se utilizzi Container Registry, Artifact Registry, Cloud Build o Cloud Deploy per gestire le immagini container o le pipeline CI/CD in in Google Cloud, non sono più disponibili in caso di disconnessione. Le strategie per affrontare la disconnessione di questi prodotti non rientrano nella nell'ambito di questo documento.
| Azione | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Deployment dell'applicazione | Eseguito localmente utilizzando kubectl, mediante strumenti CI/CD o con Connect
Gateway. |
Connect Gateway non è disponibile. Tutti gli altri metodi di deployment continuano a funzionare purché si connettano direttamente all'API Kubernetes. | Illimitato | Se utilizzi Connect Gateway, passa all'utilizzo di kubectl localmente. |
| Rimozione di applicazioni | Eseguito localmente utilizzando kubectl, mediante strumenti CI/CD o con Connect
Gateway. |
Connect Gateway non è disponibile. Tutti gli altri metodi di deployment continuano a funzionare purché si connettano direttamente all'API Kubernetes. | Illimitato | Se utilizzi Connect Gateway, passa all'utilizzo di kubectl localmente. |
| Scale out dell'applicazione | Eseguito localmente utilizzando kubectl, mediante strumenti CI/CD o con Connect
Gateway. |
Connect Gateway non è disponibile. Tutti gli altri metodi di deployment continuano a funzionare purché si connettano direttamente all'API Kubernetes. | Illimitato | Se utilizzi Connect Gateway, passa all'utilizzo di kubectl localmente. |
Logging e monitoraggio
La verificabilità aiuta la tua organizzazione a soddisfare i requisiti normativi e criteri di conformità. GKE Enterprise favorisce la verificabilità offrendo il logging di applicazioni, il logging di Kubernetes e l'audit logging. Molti clienti scegliere di sfruttare Cloud Logging di Google Cloud Monitoring per evitare la gestione di attività di logging e monitoraggio dell'infrastruttura on-prem. Altri clienti preferiscono centralizzare i log in una per l'aggregazione on-prem. Per supportare questi clienti, GKE Enterprise integra direttamente servizi come Prometheus Elastic Splunk, o Datadog. In questo durante la disconnessione temporanea da Google Cloud, non c'è alcun impatto di logging o monitoraggio.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Logging delle applicazioni con Cloud Logging | I log vengono scritti in Cloud Logging. | I log vengono inseriti nel buffer nel disco locale. | Buffer locale da 4,5 ore o 4 GiB per nodo. Quando il buffer si riempie o la disconnessione dura 4,5 ore, dopodiché vengono eliminate le voci meno recenti. | Utilizza una soluzione di logging locale. |
| Logging di sistema/Kubernetes tramite Cloud Logging | I log vengono scritti in Cloud Logging. | I log vengono inseriti nel buffer nel disco locale. | Buffer locale da 4,5 ore o 4 GiB per nodo. Quando il buffer si riempie o la disconnessione dura 4,5 ore, dopodiché vengono eliminate le voci meno recenti. | Utilizza una soluzione di logging locale. |
| Audit logging utilizzando Cloud Audit Logs | I log vengono scritti in Cloud Logging. | I log vengono inseriti nel buffer nel disco locale. | Buffer locale da 10 GiB per nodo del piano di controllo. Quando il buffer si riempie, la le voci meno recenti vengono eliminate. | Configura il forwarding dei log a una soluzione di logging locale. |
| Logging dell'applicazione tramite un altro provider | Puoi usare diversi provider di terze parti come Elastic, Splunk, Datadog, o Loki. | Nessun impatto | Illimitato | - |
| Logging di sistema/Kubernetes tramite un altro provider | Puoi utilizzare provider di terze parti diversi, come Elastic, Splunk o Datadog. | Nessun impatto | Illimitato | - |
| Metriche dell'applicazione e di Kubernetes scritte in Cloud Monitoring | Le metriche vengono scritte in Cloud Monitoring. | Le metriche sono memorizzate nel buffer nel disco locale. | Buffer locale da 24 ore o 6 GiB per nodo per le metriche di sistema e buffer locale da 1 GiB per nodo per le metriche dell'applicazione. Quando il buffer si riempie o si verifica 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 Kubernetes e carichi di lavoro 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 da 24 ore o 6 GiB per nodo per le metriche di sistema e buffer locale da 1 GiB per nodo per le metriche dell'applicazione. Quando il buffer si riempie o si disconnette dura 24 ore, le voci meno recenti vengono eliminate | Utilizza una soluzione di monitoraggio locale. |
| Regole di avviso e impaginazione per le metriche | Cloud Monitoring supporta gli avvisi. Puoi creare e avvisi per qualsiasi metrica. Gli avvisi possono essere inviati da canali diversi. | Gli avvisi non vengono attivati quando si è disconnesso. Gli avvisi vengono attivati solo Dati delle metriche già inviati a Cloud Monitoring | Utilizzare una soluzione di monitoraggio e avviso locale. |
Gestione di configurazione e criteri
Config Sync e Policy Controller consentono di gestire configurazione e criteri su larga scala, in tutti i tuoi cluster. Archivia configurazioni e criteri in un repository Git. Inoltre, vengono sincronizzati automaticamente ai cluster.
Config Sync
Config Sync utilizza gli agenti nel cluster per connettersi
direttamente in un repository Git. Puoi gestire le modifiche all'URL del repository
i parametri di sincronizzazione con gli strumenti gcloud o kubectl.
Durante la disconnessione temporanea, la sincronizzazione non viene interessata se
gli agenti nel cluster possono comunque raggiungere il repository Git. Tuttavia, se modifichi
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. Tutte le modifiche locali vengono sovrascritte al momento della riconnessione.
Policy Controller
Policy Controller consente l'applicazione di criteri completamente programmabili per i cluster. Questi Le norme fungono da "barriere" e impedire qualsiasi modifica che violi la sicurezza, operativi o di conformità da te definiti.
| Azione | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Sincronizzazione della configurazione da un repository Git | 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
con gcloud o nella console Google Cloud, non sono
applicati al cluster durante la disconnessione. Puoi sovrascriverli temporaneamente in locale utilizzando kubectl. Qualsiasi
le modifiche locali vengono sovrascritte al momento della riconnessione. |
Illimitato | Non usare mai l'API Fleet per Config Sync e configuralo 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. Sei tu a gestire 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. Modifiche alla configurazione di sistema di Policy Controller utilizzando Le API Google Cloud non vengono propagate al cluster, ma puoi temporaneamente e sovrascrivirle localmente. Tutte le modifiche locali vengono sovrascritte al momento della riconnessione. | Illimitato | Non usare mai l'API Fleet per Policy Controller e configurarlo 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 nel cluster. Puoi anche utilizzare questa API (o gcloud, o la console Google Cloud) la configurazione di questi agenti. | Gli agenti nel cluster continuano a funzionare normalmente. Non puoi installare, eseguire l'upgrade o configurare agenti nel cluster usando l'API Google Cloud. Eventuali installazioni in attesa, gli upgrade o le configurazioni effettuati utilizzando l'API continuano al momento della riconnessione. | Zero | Non usare mai l'API Fleet per Policy Controller e configurarlo manualmente. |
| Visualizzazione dello stato del sistema o della sincronizzazione nella console Google Cloud | Puoi visualizzare l'integrità degli agenti nel cluster e la 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 su per cluster utilizzando l'API Kubernetes locale. | Zero | Utilizza 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 l'applicazione ruoli utente, per gestire i carichi di lavoro usando Connect o l'autenticazione degli endpoint mediante OIDC. Nel caso di da Google Cloud, anche la connessione a Cloud Identity viene interrotta e queste funzionalità non sono più disponibili. Per carichi di lavoro richiedono resilienza aggiuntiva tramite una disconnessione temporanea, puoi utilizzare GKE Identity Service per l'integrazione con un servizio LDAP o OIDC (tra cui ADFS) per configurare l'autenticazione dell'utente finale.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Cloud Identity come provider di identità, utilizzando il gateway Connect | Puoi accedere alle risorse di GKE Enterprise utilizzando Cloud Identity come il provider di identità e la connessione tramite il gateway Connect. | Il gateway Connect richiede una connessione a Google Cloud. Non puoi per connetterti ai cluster durante la disconnessione. | Zero | Utilizza GKE Identity Service per eseguire la federazione con un'altra identità o il provider di servizi di terze parti. |
| Identità e autenticazione mediante un provider di identità di terze parti | Supporta OIDC e LDAP. Per il primo accesso, utilizzi gcloud CLI. Per OIDC
puoi usare la console Google Cloud per accedere. Puoi quindi autenticarti
di norma con l'API del cluster (ad esempio, utilizzando kubectl). |
Finché il provider di identità rimane accessibile sia a te che al cluster, puoi comunque autenticarti con l'API del cluster. Non puoi tramite la console Google Cloud. Puoi aggiornare solo OIDC o LDAP dei cluster in locale, non puoi utilizzare la console Google Cloud. | Illimitato | - |
| Autorizzazione | GKE Enterprise supporta il controllo dell'accesso basato su ruoli (RBAC, Role-Based Access Control). I ruoli possono essere attribuiti a utenti, gruppi o account di servizio. Identità e gruppi utente può essere recuperato dal provider di identità. | Il sistema RBAC è locale del cluster Kubernetes e non è interessato con la disconnessione da Google Cloud. Tuttavia, se si basa su identità provenienti da Cloud Identity, non sono disponibili nel caso di Cloud Shell. | Illimitato | - |
Gestione di secret e chiavi
La gestione dei secret e delle chiavi è una parte importante della tua security posture. La il comportamento di GKE Enterprise in caso di disconnessione da Google Cloud dipende su quale servizio utilizzi per quelle funzionalità.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Gestione di secret e chiavi tramite Cloud Key Management Service e Secret Manager | Puoi usare direttamente Cloud Key Management Service per le chiavi di crittografia e Secret Manager per i tuoi secret. | Cloud Key Management Service e Secret Manager non sono disponibili. | Zero | Utilizza invece i sistemi locali. |
| Gestione di segreti e chiavi tramite Hashicorp Vault e 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 Anthos ed è interessato anche la disconnessione, l'archiviazione dei secret e la gestione delle chiavi disponibili durante la disconnessione. | Zero | Utilizza invece i sistemi locali. |
| Gestione di segreti e chiavi tramite Hashicorp Vault e servizi on-premise | Configuri Hashicorp Vault in modo che utilizzi un backend di archiviazione on-premise e un sistema di gestione delle chiavi on-premise (come un hardware modulo di sicurezza). | La disconnessione da Google Cloud non ha alcun impatto. | Illimitato | - |
Networking e servizi di rete
Bilanciamento del carico
Per esporre agli utenti i servizi Kubernetes ospitati in un cluster on-premise, hanno la possibilità di utilizzare bilanciatore del carico in bundle (MetalLB su bare metal, altalena o MetalLB su VMware) o il tuo bilanciatore del carico, esterne a GKE Enterprise. Entrambe le opzioni continuano a funzionare in caso di da Google Cloud.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Bilanciatore del carico in bundle L4 | Fornisce il bilanciamento del carico L4 interamente in locale senza dipendenze API o la rete Google Cloud. | Nessuna modifica | Illimitato | - |
| Bilanciatore del carico manuale o integrato | Supporta F5 BIG-IP e altri che sono ospitati anche on-premise. | Nessuna modifica | Illimitato | - |
Cloud Service Mesh
Puoi utilizzare Cloud Service Mesh per gestire, osservare e comunicazioni sicure tra i servizi in esecuzione in un cluster on-premise. Non tutte Le funzionalità di Cloud Service Mesh sono supportate su Google Distributed Cloud: consulta l'elenco delle funzionalità supportate per ulteriori informazioni.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Eseguire il deployment o l'aggiornamento dei criteri (routing, autorizzazione, sicurezza, etc.) | Puoi utilizzare la console Google Cloud, kubectl, asmcli o istioctl per gestire
Cloud Service Mesh. |
Puoi utilizzare solo kubectl o istioctl per gestire i criteri di Cloud Service Mesh. |
Illimitato | Usa kubectl o istioctl |
| Autorità di certificazione (CA) | Puoi utilizzare l'autorità di certificazione nel cluster o l'autorità di certificazione Cloud Service Mesh per gestire i certificati utilizzati da Cloud Service Mesh. | Non ci sono conseguenze sull'utilizzo della CA nel cluster. Se utilizzi la CA nel cluster all'autorità di certificazione Cloud Service Mesh, i certificati scadono dopo 24 ore. Nuovi Le istanze di servizio non possono recuperare i certificati. |
Illimitato per le CA nel cluster. Servizio ridotto per 24 ore e nessun servizio dopo 24 ore per l'autorità di certificazione Cloud Service Mesh. |
Utilizza la CA nel cluster. |
| Cloud Monitoring per Cloud Service Mesh | Puoi utilizzare Cloud Monitoring per archiviare, esplorare e sfruttare 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 strutture di logging Kubernetes locali. La dipende da come hai configurato il logging per GKE Enterprise in un cluster Kubernetes. | Dipende da come hai configurato il logging per il cluster GKE Enterprise. | - | - |
| Gateway in entrata | Puoi definire gli IP esterni con il gateway Ingress Istio. | Nessun impatto | Illimitato | - |
| Interfaccia di rete del container (CNI) Istio | Puoi configurare Cloud Service Mesh in modo che utilizzi Istio CNI anziché iptables per gestire il traffico. | Nessun impatto | Illimitato | - |
| Autenticazione dell'utente finale di Cloud Service Mesh per le 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 sulle applicazioni web che fanno parte della rete mesh. | Nessun impatto | Illimitato | - |
Altri servizi di rete
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa 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 per trovare le regole. | Illimitato | - |
| Proxy in uscita | Puoi configurare GKE Enterprise in modo che utilizzi un proxy per le connessioni in uscita. | Se il proxy viene eseguito on-premise, GKE Enterprise può comunque utilizzarlo. durante una disconnessione temporanea. Tuttavia, se il proxy perde connessione a Google Cloud, quindi tutti gli scenari di questo documento rimangono valide. | Illimitato | - |
Google Cloud Marketplace
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Il deployment e la gestione di applicazioni e servizi Cloud Marketplace | Cloud Marketplace è disponibile nella console Google Cloud per scoprire, acquisire ed eseguire il deployment di soluzioni. | Non puoi utilizzare Cloud Marketplace. Alcune soluzioni Cloud Marketplace potrebbe avere i propri requisiti di connettività che non sono documentati qui. | Zero | Nessuno |
Assistenza
Questa sezione tratta gli scenari che potresti dover affrontare interagendo con l'assistenza Google Cloud o con il tuo partner operativo per un caso relativo ai tuoi cluster GKE on GDC.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima di disconnessione | Perdita della soluzione alternativa di connettività |
|---|---|---|---|---|
| Condivisione di uno snapshot del cluster con il team di assistenza | Puoi creare uno snapshot del cluster in locale utilizzando bmctl check cluster
o gkectl diagnose snapshot. Condividi questo snapshot tramite
la normale procedura di assistenza. |
Puoi comunque generare lo snapshot poiché si tratta di un'operazione locale. Se perso l'accesso a Google Cloud e alle sue interfacce web di assistenza, il team di assistenza a condizione che tu abbia sottoscritto un abbonamento alle versioni Avanzata o Premium di Google Cloud. | Illimitato | - |
| Condivisione dei dati di log pertinenti con il team di assistenza | Puoi raccogliere i log in locale nel cluster e condividerli tramite la normale procedura di assistenza. | Puoi comunque raccogliere i log dal tuo cluster. Se perso l'accesso a Google Cloud e alle sue interfacce web di assistenza, il team di assistenza a condizione che tu abbia sottoscritto un abbonamento alle versioni Avanzata o Premium di Google Cloud. | Illimitato | - |