Questa guida descrive l'architettura di riferimento utilizzata per eseguire il deployment Distributed Cloud. Questa guida è rivolta agli amministratori di piattaforma che vogliono eseguire il deployment GKE Enterprise su una piattaforma bare metal in un ambiente ad alta disponibilità, una configurazione geograficamente ridondante. Per comprendere al meglio questa guida, è necessario conoscere i concetti di base di GKE Enterprise, come descritto in Panoramica tecnica di GKE Enterprise. Inoltre, dovresti avere una conoscenza di base dei concetti di base di Kubernetes Google Kubernetes Engine (GKE), come descritto in Nozioni di base di Kubernetes e ai Documentazione di GKE.
Questa guida presenta Repository di codice sorgente GitHub che includa script che puoi usare per eseguire il deployment dell'architettura descritta. Questa guida descrive inoltre i componenti dell'architettura che accompagnano gli script e i moduli utilizzati per creare questi componenti. È consigliabile questi file possono essere utilizzati come modelli per creare moduli che usano best practice e criteri dell'organizzazione.
Modello di architettura cloud distribuito
Nella guida alle nozioni di base dell'architettura di GKE Enterprise, la piattaforma è descritta in livelli. Le risorse a ogni livello forniscono un insieme specifico di funzioni. Queste risorse sono di proprietà e gestite da una o più utenti tipo. Come mostrato nel diagramma seguente, la piattaforma GKE Enterprise per il bare metal è costituito dai seguenti livelli e risorse:
- Infrastruttura: questo livello include archiviazione, computing e networking, e la gestione con costrutti on-premise.
- Gestione dei dati: ai fini di questa guida, la gestione dei dati richiede un database SQL gestito al di fuori di Kubernetes di cluster in fase di deployment.
- Livello di gestione dei container: questo livello utilizza cluster GKE.
- Livello di Service Management: questo livello utilizza Cloud Service Mesh.
- Livello di gestione dei criteri:questo livello utilizza Sincronizzazione di configurazione e Policy Controller.
- Livello di gestione delle applicazioni: questo livello utilizza Cloud Build e Cloud Source Repositories.
- Livello di osservabilità: questo livello utilizza Osservabilità di Google Cloud e Cloud Service Mesh le dashboard.
Ciascuno di questi strati viene ripetuto nello stack per un ciclo di vita diverso di sviluppo, gestione temporanea e produzione.
Le seguenti sezioni includono solo informazioni aggiuntive specifiche per Distributed Cloud. Si basano sulle rispettive sezioni in consulta la guida alle nozioni di base dell'architettura di GKE Enterprise. Ti consigliamo di consulta la guida mentre leggi questo articolo.
Networking
Per ulteriori informazioni sui requisiti di rete, vedi Requisiti di rete.
Per i bilanciatori del carico Distributed Cloud sono disponibili due opzioni disponibili: in bundle e manuale.
In modalità in bundle, il deployment del software di bilanciamento del carico L4 viene eseguito durante la creazione del cluster. I processi del bilanciatore del carico possono essere eseguiti su un pool dedicato di nodi worker o su gli stessi nodi del piano di controllo. Per pubblicizzare gli indirizzi IP virtuali (VIP), Questo bilanciatore del carico offre due opzioni:
- ARP (Address Resolution Protocol): Richiede una connettività di livello 2 tra i nodi che eseguono il carico con il bilanciatore del carico di rete passthrough esterno regionale.
- Border Gateway Protocol (BGP): Utilizza il peering per interconnettere la rete del cluster, che è un sistema autonomo, con un altro sistema autonomo, come una rete esterna.
In modalità manuale, puoi configurare le tue soluzioni di bilanciamento del carico per il controllo e il traffico del piano dati. Sono disponibili molte opzioni hardware e software per i bilanciatori del carico esterni. Devi configurare il carico esterno di controllo per il piano di controllo prima di creare un cluster bare metal. Il bilanciatore del carico del piano di controllo esterno può essere utilizzato anche per il piano dati di rete o puoi configurare un bilanciatore del carico separato per il piano dati. Per determinare la disponibilità, il bilanciatore del carico deve essere in grado di distribuire il traffico a un pool di nodi in base a un controllo di idoneità configurabile.
Per ulteriori informazioni sui bilanciatori del carico Distributed Cloud, vedi Panoramica dei bilanciatori del carico.
Architettura dei cluster
Distributed Cloud supporta più modelli di deployment, per soddisfare diverse esigenze di disponibilità, isolamento e utilizzo delle risorse. Questi modelli di deployment vengono discussi Scelta di un modello di deployment.
Gestione delle identità
Distributed Cloud utilizza il servizio di identità GKE per l'integrazione con i provider di identità. Supporta OpenID Connect (OIDC) e LDAP (Lightweight Directory Access Protocol). Per applicazioni e servizi, è possibile utilizzare Cloud Service Mesh con varie soluzioni di identità.
Per saperne di più sulla gestione delle identità, consulta Gestione delle identità con OIDC in Distributed Cloud e Autenticazione con OIDC o Configurare Anthos Identity Service con LDAP.
Sicurezza e gestione dei criteri
Per la sicurezza e la gestione dei criteri di Distributed Cloud, consigliamo di utilizzare Config Sync e Policy Controller. Policy Controller consente di creare e applicare criteri in tutti i cluster. Configurazione Sync valuta le modifiche e le applica a tutti i cluster per ottenere lo stato appropriato.
Servizi
Quando utilizzi la modalità in bundle di Distributed Cloud per il caricamento
di Google, puoi creare
Tipo LoadBalancer
i servizi di machine learning. Quando crei questi servizi, Distributed Cloud
assegna un indirizzo IP dal pool di indirizzi IP del bilanciatore del carico configurato al
completamente gestito di Google Cloud. Il tipo di servizio LoadBalancer viene utilizzato per esporre Kubernetes
esterno al cluster
traffico da nord a sud.
Quando utilizzi Distributed Cloud,
IngressGateway
viene creato nel cluster per impostazione predefinita. Non puoi creare elementi di tipo LoadBalancer
per Distributed Cloud in modalità manuale. Invece,
puoi creare un'istanza
Ingress
che utilizza IngressGateway o crea
Tipo NodePort
e configurare manualmente il bilanciatore del carico esterno per usare
servizio Kubernetes come backend.
Per la gestione del servizio, noto anche come traffico est-ovest, consigliamo di utilizzare Cloud Service Mesh. Cloud Service Mesh si basa su Istio le API aperte e fornisce osservabilità, autenticazione, crittografia controlli granulari del traffico e altre caratteristiche e funzioni. Per maggiori informazioni informazioni su Service Management, consulta Cloud Service Mesh.
Persistenza e gestione degli stati
Distributed Cloud dipende in gran parte dall'infrastruttura per l'archiviazione temporanea, l'archiviazione in volumi e i volumi archiviazione. I dati temporanei utilizzano le risorse del disco locale sul nodo in cui il pod Kubernetes è pianificato. Per i dati permanenti, GKE Enterprise compatibili con Container Storage Interface (CSI) un'API a standard aperto supportata da molti fornitori di servizi di archiviazione. Per l'archiviazione in produzione, consigliamo di installare un driver CSI da uno spazio di archiviazione GKE Enterprise Ready partner. Per l'elenco completo dei partner di archiviazione GKE Enterprise Ready, vedi Partner di archiviazione GKE Enterprise Ready
Per ulteriori informazioni sullo spazio di archiviazione, vedi Configurazione dello spazio di archiviazione.
Database
Distributed Cloud non fornisce specifiche per i database, oltre a quelle standard la piattaforma GKE Enterprise. La maggior parte dei database viene eseguita su un di gestione dei dati. Anche i carichi di lavoro sulla piattaforma GKE Enterprise deve essere configurata per connettersi a eventuali database esterni accessibili.
Osservabilità
Google Cloud Observability raccoglie log e metriche di monitoraggio per
di cluster distribuiti in un modo simile
di raccolta e monitoraggio dei cluster GKE. Di
predefinita, i log del cluster e le metriche del componente di sistema vengono inviati
Cloud Monitoring.
Per fare in modo che Google Cloud Observability raccolga i log delle applicazioni
abilita l'opzione clusterOperations.enableApplication nel cluster
YAML della configurazione.
Per ulteriori informazioni sull'osservabilità, vedi Configurazione di logging e monitoraggio.
Caso d'uso: deployment di Cymbal Bank
In questa guida, il Cymbal Bank/Bank of Anthos viene utilizzata per simulare la pianificazione, il deployment della piattaforma di deployment delle applicazioni per Distributed Cloud.
La parte restante del documento è costituita da tre sezioni. La Pianificazione che descrive le decisioni prese in base alle opzioni discusse nei del modello di architettura. La Implementazione della piattaforma tratta gli script e i moduli forniti da un'origine per eseguire il deployment della piattaforma GKE Enterprise. Infine, nel Deployment delle applicazioni il deployment dell'applicazione Cymbal Bank viene eseguito completamente gestita.
Questa guida di Distributed Cloud può essere utilizzata per eseguire il deployment o gli host autogestiti Istanze di Compute Engine di Compute Engine. Chiunque può completare questo processo utilizzando le risorse Google Cloud senza dover accedere a hardware fisico. L'utilizzo di Compute Engine è a solo scopo dimostrativo. NON utilizzare queste istanze per carichi di lavoro di produzione. Quando è disponibile l'accesso all'hardware fisico e Vengono utilizzati intervalli di indirizzi IP; puoi utilizzare il repository di origine fornito così com'è. Se ambiente differisce da quanto delineato Pianificazione puoi modificare gli script e i moduli per adattarli alle differenze. La repository di codice sorgente associato contiene istruzioni sia per l'hardware fisico sia per Compute Engine diversi scenari di istanze.
Pianificazione
La sezione seguente descrive in dettaglio le decisioni relative all'architettura prese durante la pianificazione e la progettazione della piattaforma per l'implementazione della Banca Applicazione GKE Enterprise su Distributed Cloud. Questi si concentrano su un ambiente di produzione. Per creare ambienti inferiori, di sviluppo o gestione temporanea, puoi usare passaggi simili.
Progetti Google Cloud
Quando crei progetti in Google Cloud Distributed Cloud, un progetto host del parco risorse è obbligatorio. Sono consigliati progetti aggiuntivi per ogni ambiente funzione aziendale. Questa configurazione di progetto consente di organizzare le risorse in base sull'utente tipo che interagisce con la risorsa.
Le seguenti sottosezioni discutono i tipi di progetto consigliati e la utenti tipo associati.
Progetto Hub
Il progetto hub hub-prod è destinato all'amministratore di rete
utente tipo. Questo progetto è il luogo in cui è collegato il data center on-premise
Google Cloud utilizzando la forma di connettività ibrida che hai selezionato. Per maggiori informazioni
per informazioni sulle opzioni di connettività ibrida vedi
Connettività Google Cloud
Progetto host del parco risorse
La flotta
il progetto host fleet-prodriguarda la piattaforma
Google Workspace for Education. Nel progetto
I cluster Distributed Cloud sono registrati. Questo progetto è
anche dove si trovano le risorse Google Cloud
relative alla piattaforma. Questi
tra cui Google Cloud Observability,
Cloud Source Repositories e altri. Un determinato progetto Google Cloud può avere solo
un'unica flotta (o nessuna flotta) associata. Questa restrizione rafforza
utilizzando i progetti Google Cloud per garantire un maggiore isolamento tra le risorse
che non sono regolati o consumati insieme.
Progetto di applicazione o team
L'applicazione o il progetto del team app-banking-prod è destinato allo sviluppatore
utente tipo. In questo progetto sono presenti
delle risorse Google Cloud. Il progetto include tutto tranne
cluster GKE. A seconda del numero di team o
potrebbero esserci più istanze di questo tipo di progetto. Creazione in corso...
per team diversi ti consente di gestire separatamente
IAM, fatturazione e quota per ogni team.
Networking
Ogni cluster Distributed Cloud richiede il seguente IP subnet di indirizzi:
- Indirizzi IP dei nodi
- Indirizzi IP dei pod Kubernetes
- Indirizzi IP di cluster/servizi Kubernetes
- Indirizzi IP del bilanciatore del carico (modalità in bundle)
Usare gli stessi intervalli di indirizzi IP non instradabili per il pod Kubernetes di servizio in ogni cluster, seleziona un'istanza modello di rete in modalità isola. In questa configurazione, i pod possono comunicare direttamente tra loro all'interno di un cluster, ma non è raggiungibile direttamente dall'esterno di un cluster (utilizzando gli indirizzi IP dei pod). Questa configurazione forma un'isola all'interno della rete che non è connessa verso la rete esterna. I cluster formano un mesh completo tra nodi dei nodi dei cluster all'interno dell'isola, consentendo al pod di raggiungere direttamente gli altri pod all'interno del cluster.
Allocazione degli indirizzi IP
| Cluster | Nodo | Pod | Servizi | Bilanciatore del carico |
|---|---|---|---|---|
| metal-admin-dc1-000-prod | 10.185.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | N/D |
| metal-user-dc1a-000-prod | 10.185.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.1.3-10.185.1.10 |
| metal-user-dc1b-000-prod | 10.185.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.185.2.3-10.185.2.10 |
| metal-admin-dc2-000-prod | 10.195.0.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | N/D |
| metal-user-dc2a-000-prod | 10.195.1.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.1.3-10.195.1.10 |
| metal-user-dc2b-000-prod | 10.195.2.0/24 | 192.168.0.0/16 | 10.96.0.0/12 | 10.195.2.3-10.195.2.10 |
In modalità a isola è importante assicurarsi che le subnet di indirizzi IP scelte i pod e i servizi Kubernetes non sono in uso o instradabili dal nodo in ogni rete.
Requisiti di rete
a fornire un bilanciatore del carico integrato
Distributed Cloud che non richiede configurazione, utilizza
in bundle con la modalità bilanciatore
del carico in ogni cluster. Quando i carichi di lavoro vengono eseguiti LoadBalancer
viene assegnato un indirizzo IP dal pool del bilanciatore del carico.
Per leggere informazioni dettagliate sui requisiti del bilanciatore del carico in bundle per la configurazione, consulta Panoramica dei bilanciatori del carico e Configurazione del bilanciamento del carico in bundle.
Architettura dei cluster
Per un ambiente di produzione, consigliamo di utilizzare una modello di deployment dei cluster di amministrazione e utenti con un cluster di amministrazione e due cluster utente in ciascuna posizione geografica raggiungere la massima ridondanza e tolleranza di errore Distributed Cloud.
Consigliamo di utilizzare un minimo di quattro cluster utente per ogni produzione completamente gestito di Google Cloud. Utilizza due località geograficamente ridondanti che contengono due a tolleranza di errore. Ogni cluster a tolleranza di errore dispone di hardware ridondante e connessioni di rete ridondanti. La riduzione del numero di cluster riduce la ridondanza o la tolleranza di errore dell'architettura.
Per garantire l'alta disponibilità, il piano di controllo per ogni cluster utilizza tre nodi. Con un minimo di tre nodi worker per cluster utente, puoi distribuire carichi di lavoro tra questi nodi per ridurre l'impatto se un nodo passa alla modalità offline. La il numero e il dimensionamento dei nodi worker dipendono in gran parte dal tipo e dal numero carichi di lavoro in esecuzione nel cluster. Il dimensionamento consigliato per ciascuno dei nodi è discusso in Configurazione dell'hardware per Distributed Cloud.
La tabella seguente descrive il ridimensionamento consigliato dei nodi per core CPU, memoria e spazio di archiviazione su disco locale.
| Tipo di nodo | CPU/vCPU | Memoria | Archiviazione |
|---|---|---|---|
| Piano di controllo | 8 core | 32 GiB | 256 GiB |
| Worker | 8 core | 64 GiB | 512 GiB |
Per ulteriori informazioni sui prerequisiti della macchina e sul dimensionamento, vedi Prerequisiti delle macchine dei nodi cluster.
Gestione delle identità
Per la gestione delle identità, consigliamo un'integrazione con OIDC tramite GKE Identity Service. Negli esempi forniti nella fonte repository di codice, l'autenticazione locale viene utilizzata per semplificare i requisiti. Se OIDC , puoi modificare l'esempio per utilizzarlo. Per ulteriori informazioni, vedi Gestione delle identità con OIDC in Distributed Cloud
Sicurezza e gestione dei criteri
Nel caso d'uso di Cymbal Bank, Config Sync e Policy Controller
per la gestione dei criteri. Viene creato un Cloud Source Repositories per archiviare
e i dati di configurazione utilizzati da Config Sync. La
Operatore ConfigManagement, utilizzato per installare e gestire Config Sync
e Policy Controller, deve accedere in sola lettura
repository di origine della configurazione. Per concedere l'accesso, utilizza una forma di
autenticazione. In questo esempio, viene utilizzato un account di servizio Google.
Servizi
Per Service Management in questo caso d'uso, Cloud Service Mesh viene utilizzato per
forniscono una base su cui
creare servizi distribuiti. Per impostazione predefinita,
Viene creata anche la risorsa IngressGateway nel cluster che gestisce il traffico
Oggetti Ingress Kubernetes.
Persistenza e gestione degli stati
Poiché l'archiviazione permanente dipende in gran parte dall'infrastruttura esistente, questo caso d'uso non lo richiede. In altri casi, tuttavia, consigliamo di utilizzare di archiviazione disponibili Partner di archiviazione per GKE Enterprise Ready. Se è disponibile un'opzione di archiviazione CSI, questa può essere installata sul utilizzando le istruzioni fornite dal fornitore. Per proof of concept e casi d'uso avanzati, puoi utilizzare volumi locali. Tuttavia, nella maggior parte dei casi d'uso, sconsigliamo di utilizzare volumi locali in ambienti di produzione.
Database
Molte applicazioni stateful su Distributed Cloud come archivio di persistenza. Un'applicazione di database stateful deve a un database per fornire la sua logica di business ai clienti. Non sono presenti relative al tipo di Datastore utilizzato Distributed Cloud. Le decisioni sull'archiviazione dei dati, di conseguenza, dallo sviluppatore o dai team di gestione dei dati associati. Poiché le differenze possono richiedere datastore diversi, questi datastore possono essere senza alcuna limitazione. I database possono essere gestiti nel cluster, on-premise anche nel cloud.
Cymbal Bank è un'applicazione stateful che accede a due database PostgreSQL. L'accesso al database è configurato tramite variabili di ambiente. Il database PostgreSQL deve essere accessibile nodi che eseguono i carichi di lavoro, anche se il database è gestito esternamente in un cluster Kubernetes. In questo esempio, l'applicazione accede a un account utente esterno PostgreSQL standard. Mentre l'applicazione viene eseguita sulla piattaforma, il database viene gestiti esternamente. Di conseguenza, il database non fa parte la piattaforma GKE Enterprise. Se è disponibile un database PostgreSQL, utilizzalo. In caso contrario, crea e utilizza un database Cloud SQL per l'applicazione Cymbal Bank.
Osservabilità
Ogni cluster nel caso d'uso di Cymbal Bank è configurato fare in modo che Google Cloud Observability raccolga log e metriche sia per applicazioni e componenti di sistema. Esistono diverse dashboard di Cloud Monitoring create dal programma di installazione della console Google Cloud, che possono essere visualizzate il Dashboard di monitoraggio . Per ulteriori informazioni sull'osservabilità, vedi Configurare il logging e il monitoraggio, e Come funzionano Logging e Monitoring per Distributed Cloud.
Deployment della piattaforma
Per ulteriori informazioni, consulta Deployment della piattaforma della documentazione nel repository di codice sorgente GitHub.
Deployment dell'applicazione
Per ulteriori informazioni, consulta Esegui il deployment dell'applicazione della documentazione nel repository di codice sorgente GitHub.
Passaggi successivi
- Scopri di più su Cloud Service Mesh Config Sync, e Policy Controller.
- Dai un'occhiata ad alcune delle altre architetture di riferimento di GKE Enterprise.
- Prova GKE Enterprise su Google Cloud con Deployment di esempio di GKE Enterprise.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.