La versione Enterprise di Google Kubernetes Engine (GKE) è la piattaforma di modernizzazione delle applicazioni di Google Cloud . Si basa su Kubernetes e può essere implementato su Google Cloud, su altri cloud e on-premise con Google Distributed Cloud (sia su VMware che su server bare metal). Anche se un cluster gestito da GKE Enterprise viene eseguito on-premise, è progettato per avere una connessione permanente aGoogle Cloud per una serie di motivi, tra cui il monitoraggio e la gestione. Tuttavia, potresti dover sapere cosa succederebbe se, per qualsiasi motivo, la connessione a Google Cloud viene persa (ad esempio a causa di un problema tecnico). Questo documento illustra l'impatto della perdita di connettività per i cluster in un deployment di Google Distributed Cloud solo software (on bare metal o su VMware) e le soluzioni alternative che 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 di utilizzare un deployment di Google Distributed Cloud solo software disconnesso da Google Cloud come modalità di lavoro nominale. Ricorda che progettiamo GKE Enterprise per sfruttare la scalabilità e la disponibilità dei servizi diGoogle Cloud . Questo documento si basa sul design 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 conosca 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 attivato GKE Enterprise, ovvero se l'API Anthos (anthos.googleapis.com) è abilitata nel tuo progetto Google Cloud , il controller di misurazione GKE Enterprise, in esecuzione nel cluster, genera e aggiorna periodicamente il diritto GKE Enterprise. La tolleranza per la disconnessione è di 12 ore. Inoltre, la misurazione e la fatturazione vengono gestite tramite la connessione.
Questa tabella elenca il comportamento delle funzionalità relative a licenze e misurazione in caso di disconnessione temporanea da Google Cloud.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima alle disconnessioni | Soluzione alternativa per la perdita di connettività |
|---|---|---|---|---|
| Convalida della licenza GKE Enterprise | Il controller di misurazione di GKE Enterprise genera e aggiorna periodicamente la risorsa personalizzata dei diritti di 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. Al termine 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 di GKE Enterprise registra la capacità vCPU del cluster all'API Service Control di Google Cloud a fini di fatturazione. | Esiste un agente all'interno del cluster che mantiene i record di fatturazione nel cluster quando è disconnesso e i record vengono recuperati quando il cluster si riconnette a Google Cloud. | Illimitato. Tuttavia, le informazioni di misurazione di GKE Enterprise sono obbligatorie per la conformità, come indicato nei Termini specifici per il servizio 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à.
Per la maggior parte degli scenari, puoi utilizzare strumenti CLI come bmctl, gkectl e
kubectl per eseguire operazioni durante una disconnessione temporanea. Puoi anche monitorare lo stato di queste operazioni con questi strumenti. Al termine del ricollaudo, la consoleGoogle Cloud si aggiorna per mostrare i risultati delle operazioni eseguite durante il periodo di disconnessione.
| Azione | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima alle disconnessioni | Soluzione alternativa per la perdita di connettività |
|---|---|---|---|---|
| Creazione del cluster | Utilizza gli strumenti CLI 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 | Per eliminare i cluster, utilizza 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 le informazioni sui tuoi cluster nella console Google Cloud , nell'elenco dei cluster Google Kubernetes Engine. | Le informazioni sul cluster non vengono visualizzate nella console Google Cloud . | Illimitato | Utilizza kubectl per eseguire query direttamente sui tuoi 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 estrae le immagini container da Container Registry. Viene eseguito un controllo preliminare per verificare la connettività a Google Cloud. | I controlli preliminari eseguiti quando viene aggiunto un nuovo nodo verificano la connettività a Google Cloud. Pertanto, non puoi aggiungere un nuovo nodo a un cluster se è disconnesso. | Zero | Nessuno |
Ciclo di vita dell'applicazione
La gestione delle applicazioni in esecuzione in un cluster on-premise non è quasi interessata da una disconnessione temporanea da Google Cloud. È interessato solo Connect Gateway. Se utilizzi Container Registry, Artifact Registry, Cloud Build o Cloud Deploy per gestire le immagini container o le pipeline CI/CD inGoogle Cloud, questi strumenti non sono più disponibili in caso di disconnessione. Le strategie per gestire la disconnessione di questi prodotti non rientrano nell'ambito di questo documento.
| Azione | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima alle disconnessioni | Soluzione alternativa per la perdita di connettività |
|---|---|---|---|---|
| Deployment dell'applicazione | Eseguito localmente utilizzando kubectl, tramite strumenti CI/CD o utilizzando Connect
Gateway. |
Connect Gateway non è disponibile. Tutti gli altri metodi di implementazione funzionano ancora a condizione che si connettano direttamente all'API Kubernetes. | Illimitato | Se utilizzavi Connect Gateway, passa all'utilizzo di kubectl localmente. |
| Rimozione di applicazioni | Eseguito localmente utilizzando kubectl, tramite strumenti CI/CD o utilizzando Connect
Gateway. |
Connect Gateway non è disponibile. Tutti gli altri metodi di implementazione funzionano ancora a condizione che si connettano direttamente all'API Kubernetes. | Illimitato | Se utilizzavi Connect Gateway, passa all'utilizzo di kubectl localmente. |
| Scale out dell'applicazione | Eseguito localmente utilizzando kubectl, tramite strumenti CI/CD o utilizzando Connect
Gateway. |
Connect Gateway non è disponibile. Tutti gli altri metodi di implementazione funzionano ancora a condizione che si connettano direttamente all'API Kubernetes. | Illimitato | Se utilizzavi Connect Gateway, passa all'utilizzo di kubectl localmente. |
Logging e monitoraggio
La verificabilità consente alla tua organizzazione di soddisfare i requisiti normativi e le norme di conformità. GKE Enterprise semplifica la verifica grazie al logging delle applicazioni, al logging di Kubernetes e al logging di controllo. 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, GKE Enterprise offre l'integrazione diretta con servizi come Prometheus, Elastic, Splunk o Datadog. In questa modalità, durante la disconnessione temporanea da Google Cloud, le funzionalità di logging o monitoraggio non sono interessate.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima alle disconnessioni | Soluzione alternativa per la perdita di connettività |
|---|---|---|---|---|
| Logging delle applicazioni utilizzando Cloud Logging | I log vengono scritti in Cloud Logging. | I log vengono memorizzati nella memoria intermedia sul disco locale. | Buffer locale di 4,5 ore o 4 GB per nodo. Quando l'area buffer si riempie o la connessione si interrompe per 4 ore e mezza, le voci meno recenti vengono eliminate. | Utilizza una soluzione di logging locale. |
| Log di sistema/Kubernetes utilizzando Cloud Logging | I log vengono scritti in Cloud Logging. | I log vengono memorizzati nella memoria intermedia sul disco locale. | Buffer locale di 4,5 ore o 4 GB per nodo. Quando l'area buffer si riempie o la connessione si interrompe per 4 ore e mezza, le voci meno recenti vengono eliminate. | Utilizza una soluzione di logging locale. |
| Audit logging utilizzando Cloud Audit Logs | I log vengono scritti in Cloud Logging. | I log vengono memorizzati nella memoria intermedia sul disco locale. | Buffer locale di 10 GB 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 utilizzando un altro provider | Puoi utilizzare diversi provider di terze parti come Elastic, Splunk, Datadog o Loki. | Nessun impatto | Illimitato | - |
| Log di sistema/Kubernetes utilizzando un altro provider | Puoi utilizzare diversi fornitori di terze parti come Elastic, Splunk o Datadog. | Nessun impatto | Illimitato | - |
| Metriche di Kubernetes e dell'applicazione scritte in Cloud Monitoring | Le metriche vengono scritte in Cloud Monitoring. | Le metriche vengono messe in un buffer 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 l'area buffer si riempie o la disconnessione dura 24 ore, le voci meno recenti vengono eliminate | Utilizza una soluzione di monitoraggio locale. |
| Accedere e leggere i dati di monitoraggio dai 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 buffer locale di 1 GiB per nodo per le metriche dell'applicazione. Quando l'area 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 paginazione per le metriche | Cloud Monitoring supporta gli avvisi. Puoi creare avvisi per qualsiasi metrica. Gli avvisi possono essere inviati tramite diversi canali. | Gli avvisi non vengono attivati quando il dispositivo è disconnesso. Gli avvisi vengono attivati solo dai dati delle metriche già inviati a Cloud Monitoring | Utilizza una soluzione di monitoraggio e avviso locale. |
Gestione della configurazione e dei criteri
Config Sync e Policy Controller ti consentono di gestire la configurazione e i criteri su larga scala in tutti i tuoi cluster. Memorizzi configurazioni e criteri in un repository Git e questi vengono sincronizzati 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 gli strumenti gcloud o kubectl.
Durante la disconnessione temporanea, la sincronizzazione non viene interessata se gli agenti in cluster possono ancora raggiungere il repository Git. Tuttavia, se modifichi i parametri di sincronizzazione con Google Cloud CLI o la console Google Cloud , non vengono applicati al cluster durante la disconnessione. Puoi sovrascriverli temporaneamente
localmente utilizzando kubectl. Eventuali modifiche locali vengono sovrascritte al momento della 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à che hai definito.
| Azione | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima alle disconnessioni | 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 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 al momento della riconnessione. |
Illimitato | Non utilizzare mai l'API Fleet per Config Sync e configurala solo utilizzando l'API Kubernetes. |
| Applicazione dei criteri alle richieste all'API Kubernetes | L'agente nel cluster applica i vincoli grazie alla sua integrazione con l'API Kubernetes. Gestisci i criteri utilizzando l'API Kubernetes locale. Gestisci la configurazione di sistema di Policy Controller con un'API Google Cloud . | L'applicazione delle norme non è interessata. I criteri vengono comunque gestiti utilizzando l'API Kubernetes locale. Le modifiche alla configurazione di sistema del controller dei criteri utilizzando l'API Google Cloud non vengono propagate al cluster, ma puoi sovrascriverle temporaneamente localmente. Eventuali modifiche locali vengono sovrascritte al momento della riconnessione. | Illimitato | Non utilizzare mai l'API Fleet per Policy Controller e configurala 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 o la console Google Cloud ) anche per gestire la configurazione di questi agenti. | Gli agenti all'interno del 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 vengono eseguite al termine del ricoinvolgimento. | Zero | Non utilizzare mai l'API Fleet per Policy Controller e configurala solo utilizzando l'API Kubernetes. |
| Visualizzazione dello stato del sistema o della sincronizzazione nella console Google Cloud | Puoi visualizzare lo stato di salute degli agenti all'interno del 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 su ciascun 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 i ruoli di applicazioni e utenti, per gestire i carichi di lavoro utilizzando Connect o per l'autenticazione degli endpoint utilizzando OIDC. In caso di disconnessione da Google Cloud, viene interrotta anche la connessione a Cloud Identity 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 integrarti con un provider LDAP o OIDC (incluso ADFS) per configurare l'autenticazione degli utenti finali.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima alle disconnessioni | Soluzione alternativa per la perdita di connettività |
|---|---|---|---|---|
| Cloud Identity come provider di identità, utilizzando il gateway Connect | Puoi accedere alle risorse di GKE Enterprise utilizzando Cloud Identity come provider di identità e connettendoti tramite il gateway Connect. | Il gateway Connect richiede una connessione a Google Cloud. Non riesci a 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 utilizzando un provider di identità di terze parti | Supporta OIDC e LDAP. Utilizza lgcloud CLI per il primo accesso. Per i fornitori OIDC, puoi utilizzare la console Google Cloud per accedere. A questo punto puoi 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 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 sui ruoli (RBAC). I ruoli possono essere attribuiti a utenti, gruppi o account di servizio. Le identità e i gruppi di utenti possono essere recuperati dal provider di identità. | Il sistema RBAC è locale per il cluster Kubernetes e non è interessato dalla disconnessione da Google Cloud. 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 segreti e chiavi è una parte importante della tua 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 alle disconnessioni | 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 tuoi segreti. | Sia Cloud Key Management Service che Secret Manager non sono disponibili. | Zero | Utilizza invece i sistemi locali. |
| Gestione di segreti e chiavi utilizzando Hashicorp Vault e i servizi Google Cloud | Configura Hashicorp Vault in modo da utilizzare Cloud Storage o Spanner per memorizzare i segreti e Cloud Key Management Service per gestire le chiavi. | Se Hashicorp Vault viene eseguito nel tuo cluster Anthos ed è interessato anche dalla disconnessione, lo spazio di archiviazione delle chiavi e la gestione delle chiavi non sono disponibili durante la disconnessione. | Zero | Utilizza invece i sistemi locali. |
| Gestione di secret e chiavi mediante Hashicorp Vault e servizi on-premise | Configura 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 | - |
Networking e servizi di rete
Bilanciamento del carico
Per esporre agli utenti i servizi Kubernetes ospitati in un cluster on-premise, puoi scegliere di utilizzare il bilanciatore del carico fornito in bundle (MetalLB su bare metal, Seesaw o MetalLB su VMware) 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 alle disconnessioni | Soluzione alternativa per la perdita di connettività |
|---|---|---|---|---|
| Bilanciatore del carico in bundle L4 | Fornisce il bilanciamento del carico L4 interamente localmente senza dipendenze dalle API o dalla rete diGoogle Cloud . | Nessuna modifica | Illimitato | - |
| Bilanciatore del carico manuale o integrato | Supporta F5 BIG-IP e altri prodotti 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. Non tutte le funzionalità di Cloud Service Mesh sono supportate su Google Distributed Cloud: per saperne di più, consulta l'elenco delle funzionalità supportate.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima alle disconnessioni | Soluzione alternativa per la perdita di connettività |
|---|---|---|---|---|
| Implementazione o aggiornamento dei criteri (routing, autorizzazione, sicurezza, controllo e così via) | Puoi utilizzare la console Google Cloud , kubectl, asmcli o istioctl per gestire
i criteri di Cloud Service Mesh. |
Puoi utilizzare solo kubectl o istioctl per gestire i criteri di Cloud Service Mesh. |
Illimitato | Utilizza kubectl o istioctl |
| Autorità di certificazione (CA) | Puoi utilizzare l'autorità di certificazione in-cluster o l'autorità di certificazione Cloud Service Mesh per gestire i certificati utilizzati da Cloud Service Mesh. | Non ci sono conseguenze se utilizzi l'autorità di certificazione all'interno del 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. |
Il numero di CA all'interno del cluster è illimitato. Il servizio viene degradato per 24 ore e non è disponibile dopo 24 ore per l'autorità di certificazione Cloud Service Mesh. |
Utilizza l'autorità di certificazione all'interno del cluster. |
| Cloud Monitoring per Cloud Service Mesh | Puoi utilizzare Cloud Monitoring per archiviare, esplorare ed sfruttare le metriche relative a HTTP provenienti da Cloud Service Mesh. | Le metriche non vengono memorizzate. | 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 tuo cluster GKE Enterprise. | Dipende da come hai configurato il logging per il tuo cluster GKE Enterprise. | - | - |
| Gateway di ingresso | Puoi definire gli IP esterni con il gateway Istio Ingress. | Nessun impatto | Illimitato | - |
| Istio Container Network Interface (CNI) | Puoi configurare Cloud Service Mesh in modo da utilizzare CNI Istio anziché iptables per gestire il traffico. | Nessun impatto | Illimitato | - |
| Autenticazione degli utenti finali di Cloud Service Mesh per le applicazioni web | Puoi utilizzare il gateway di ingresso Cloud Service Mesh per integrarti 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 alle disconnessioni | 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 perché viene eseguito all'interno del cluster stesso. | 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 è 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 di questo documento. | Illimitato | - |
Google Cloud Marketplace
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima alle disconnessioni | Soluzione alternativa per la perdita di connettività |
|---|---|---|---|---|
| Eseguire il deployment e gestire applicazioni e servizi da Cloud Marketplace | Cloud Marketplace è disponibile nella console Google Cloud e puoi usarlo 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'assistenza di Google Cloud o con il tuo partner operativo per una richiesta relativa ai tuoi cluster GKE su GDC.
| Funzionalità | Comportamento connesso | Comportamento di disconnessione temporanea | Tolleranza massima alle disconnessioni | 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. Condividi questa istantanea tramite la normale procedura di assistenza. |
Puoi comunque generare lo snapshot perché si tratta di un'operazione locale. Se hai perso l'accesso a Google Cloud e alle relative interfacce web di assistenza, puoi chiamare il team di assistenza a condizione che tu abbia sottoscritto i piani di assistenza Avanzata o Premium. | Illimitato | - |
| Condivisione dei dati dei 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 chiamare il team di assistenza a condizione che tu abbia sottoscritto i piani di assistenza Avanzata o Premium. | Illimitato | - |