Architettura di riferimento di GKE Enterprise: Google Distributed Cloud Virtual for Bare Metal

Last reviewed 2023-08-15 UTC

Questa guida descrive l'architettura di riferimento utilizzata per eseguire il deployment di GDCV per Bare Metal. Questa guida è rivolta agli amministratori di piattaforme che vogliono eseguire il deployment di GKE Enterprise su una piattaforma bare metal in una configurazione ad alta disponibilità e con ridondanza geografica. Per comprendere al meglio questa guida, dovresti conoscere i concetti di base di GKE Enterprise, come descritto nella panoramica tecnica di GKE Enterprise. Inoltre, dovresti avere una conoscenza di base dei concetti di Kubernetes e di Google Kubernetes Engine (GKE), come descritto nelle Nozioni di base su Kubernetes e nella documentazione di GKE.

Questa guida ha un repository di codice sorgente GitHub che include script che puoi utilizzare 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. Ti consigliamo di utilizzare questi file come modelli per creare moduli che utilizzano le best practice e i criteri della tua organizzazione.

Modello di architettura GDCV per Bare Metal

Nella guida alle basi dell'architettura di GKE Enterprise, l'architettura della piattaforma è descritta in livelli. Le risorse a ogni livello forniscono un insieme specifico di funzioni. Queste risorse sono di proprietà e gestite da uno o più utenti. Come mostrato nel seguente diagramma, l'architettura della piattaforma GKE Enterprise per bare metal è costituita dai seguenti livelli e risorse:

Un modello mentale GDCV per Bare Metal che mostra gli strati discussi nel documento.

  1. Infrastruttura: questo livello include archiviazione, computing e networking, gestiti con costrutti on-premise.
  2. Gestione dei dati: ai fini di questa guida, il livello di gestione dei dati richiede un database SQL gestito al di fuori dei cluster Kubernetes di cui viene eseguito il deployment.
  3. Livello di gestione dei container: questo livello utilizza cluster GKE.
  4. Livello di Service Management: questo livello utilizza Cloud Service Mesh.
  5. Livello di gestione dei criteri: questo livello utilizza Config Sync e Policy Controller.
  6. Livello di gestione delle applicazioni: questo livello utilizza Cloud Build e Cloud Source Repositories.
  7. Livello di osservabilità: questo livello utilizza le dashboard Google Cloud Observability e Cloud Service Mesh.

Ciascuno di questi strati viene ripetuto nello stack per diversi ambienti del ciclo di vita, come sviluppo, gestione temporanea e produzione.

Le seguenti sezioni includono solo informazioni aggiuntive specifiche per GDCV per Bare Metal. Si basa sulle rispettive sezioni della guida ai concetti di base dell'architettura di GKE Enterprise. Ti consigliamo di consultare la guida durante la lettura di questo articolo.

Networking

Per ulteriori informazioni sui requisiti di rete, vedi Requisiti di rete.

Per i bilanciatori del carico GDCV per Bare Metal sono disponibili due opzioni: 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 sugli stessi nodi del piano di controllo. Per pubblicizzare gli indirizzi IP virtuali (VIP), questo bilanciatore del carico ha due opzioni:

In modalità manuale, configuri le tue soluzioni di bilanciamento del carico per il traffico del piano di controllo e del piano dati. Sono disponibili molte opzioni hardware e software per i bilanciatori del carico esterni. Prima di creare un cluster bare metal, devi configurare il bilanciatore del carico esterno per il piano di controllo. Il bilanciatore del carico del piano di controllo esterno può essere utilizzato anche per il traffico del piano dati oppure 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 per GDCV per Bare Metal, consulta Panoramica dei bilanciatori del carico.

Architettura dei cluster

GDCV per Bare Metal supporta più modelli di deployment, per soddisfare diverse esigenze di disponibilità, isolamento e utilizzo delle risorse. Questi modelli di deployment vengono discussi in Scegliere un modello di deployment.

Gestione delle identità

GDCV per Bare Metal usa GKE Identity Service per l'integrazione con i provider di identità. Supporta OpenID Connect (OIDC) e Lightweight Directory Access Protocol (LDAP). Cloud Service Mesh può essere usato per applicazioni e servizi con varie soluzioni di identità.

Per ulteriori informazioni sulla gestione delle identità, consulta Gestione delle identità con OIDC in GDCV per Bare Metal e Autenticazione con OIDC oppure Configurare Anthos Identity Service con LDAP.

Sicurezza e gestione dei criteri

Per la gestione dei criteri e della sicurezza di GDCV per Bare Metal, consigliamo di utilizzare Config Sync e Policy Controller. Policy Controller consente di creare e applicare criteri in tutti i cluster. Config Sync valuta le modifiche e le applica a tutti i cluster per ottenere lo stato appropriato.

Servizi

Quando utilizzi la modalità in bundle di GDCV per Bare Metal per il bilanciamento del carico, puoi creare servizi di tipo LoadBalancer. Quando crei questi servizi, GDCV per Bare Metal assegna al servizio un indirizzo IP dal pool di indirizzi IP del bilanciatore del carico configurato. Il tipo di servizio LoadBalancer viene utilizzato per esporre il servizio Kubernetes all'esterno del cluster per il traffico nord-sud. Quando utilizzi GDCV per Bare Metal, per impostazione predefinita viene creata anche una IngressGateway nel cluster. Non puoi creare servizi di tipo LoadBalancer per GDCV per Bare Metal in modalità manuale. Puoi invece creare un oggetto Ingress che utilizza IngressGateway o creare servizi di tipo NodePort e configurare manualmente il bilanciatore del carico esterno per utilizzare il servizio Kubernetes come backend.

Per Service Management, noto anche come traffico est-ovest, consigliamo di utilizzare Cloud Service Mesh. Cloud Service Mesh si basa sulle API aperte di Istio e fornisce funzioni e funzioni uniformi di osservabilità, autenticazione, crittografia, controlli granulari del traffico e altre funzionalità. Per ulteriori informazioni su Service Management, consulta Cloud Service Mesh.

Persistenza e gestione degli stati

GDCV per Bare Metal dipende in gran parte dall'infrastruttura esistente per l'archiviazione temporanea, l'archiviazione di volume e l'archiviazione PersistentVolume. I dati temporanei utilizzano le risorse del disco locale sul nodo in cui è pianificato il pod Kubernetes. Per i dati permanenti, GKE Enterprise è compatibile 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 un partner di archiviazione GKE Enterprise Ready. Per l'elenco completo dei partner di archiviazione GKE Enterprise Ready, consulta Partner di archiviazione GKE Enterprise Ready.

Per ulteriori informazioni sullo spazio di archiviazione, consulta Configurazione dello spazio di archiviazione.

Database

GDCV per Bare Metal non fornisce ulteriori funzionalità specifiche del database, oltre a quelle standard della piattaforma GKE Enterprise. La maggior parte dei database viene eseguita su un sistema di gestione dei dati esterno. I carichi di lavoro sulla piattaforma GKE Enterprise possono anche essere configurati per connettersi a qualsiasi database esterno accessibile.

Osservabilità

Google Cloud Observability raccoglie log e metriche di monitoraggio per i cluster GDCV per i cluster Bare Metal in modo simile ai criteri di raccolta e monitoraggio dei cluster GKE. Per impostazione predefinita, i log del cluster e le metriche del componente di sistema vengono inviati a Cloud Monitoring. Per fare in modo che Google Cloud Observability raccolga log e metriche delle applicazioni, abilita l'opzione clusterOperations.enableApplication nel file YAML di configurazione del cluster.

Per ulteriori informazioni sull'osservabilità, consulta Configurazione di logging e monitoraggio.

Caso d'uso: deployment di Cymbal Bank

Per questa guida, l'applicazione Cymbal Bank/Bank of Anthos viene utilizzata per simulare il processo di pianificazione, deployment della piattaforma e deployment delle applicazioni per GDCV per Bare Metal.

La parte restante del documento è costituita da tre sezioni. La sezione Pianificazione delinea le decisioni prese in base alle opzioni discusse nelle sezioni relative ai modelli di architettura. La sezione Deployment della piattaforma illustra gli script e i moduli forniti da un repository di origine per il deployment della piattaforma GKE Enterprise. Infine, nella sezione Deployment di applicazioni, viene eseguito il deployment dell'applicazione Cymbal Bank sulla piattaforma.

Questa guida di GDCV per Bare Metal può essere utilizzata per eseguire il deployment su host autogestiti o istanze di istanze di Compute Engine. Utilizzando le risorse Google Cloud, chiunque può completare questa guida senza bisogno di accedere a hardware fisico. L'utilizzo delle istanze di Compute Engine è solo a scopo dimostrativo. NON utilizzare queste istanze per carichi di lavoro di produzione. Quando è disponibile l'accesso all'hardware fisico e vengono utilizzati gli stessi intervalli di indirizzi IP, puoi utilizzare il repository di origine fornito così com'è. Se l'ambiente è diverso da quanto indicato nella sezione Pianificazione, puoi modificare gli script e i moduli per adattarli alle differenze. Il repository di origine associato contiene istruzioni sia per gli scenari di hardware fisico che per gli scenari di istanze Compute Engine.

Pianificazione

La seguente sezione descrive le decisioni nell'architettura prese durante la pianificazione e la progettazione della piattaforma per il deployment dell'applicazione Bank of GKE Enterprise su GDCV per Bare Metal. Queste sezioni sono incentrate su un ambiente di produzione. Puoi usare passaggi simili per creare ambienti di sviluppo o gestione temporanea.

Progetti Google Cloud

Quando crei progetti in Google Cloud per GDCV per Bare Metal, è richiesto un progetto host del parco risorse. Sono consigliati progetti aggiuntivi per ogni ambiente o funzione aziendale. con cui puoi organizzare le risorse in base all'utente tipo che interagisce con la risorsa.

Le seguenti sottosezioni discutono i tipi di progetto consigliati e gli utenti associati.

Progetto Hub

Il progetto hub hub-prod è destinato all'amministratore di rete. In questo progetto il data center on-premise viene connesso a Google Cloud utilizzando la forma di connettività ibrida che hai scelto. Per ulteriori informazioni sulle opzioni di connettività ibrida, vedi Google Cloud Connectivity.

Progetto host del parco risorse

Il progetto host del fleet fleet-prodè destinato all'utente tipo degli amministratori della piattaforma. Nel progetto vengono registrati i cluster GDCV per Bare Metal. In questo progetto si trovano anche le risorse Google Cloud relative alla piattaforma. Queste risorse includono Google Cloud Observability, Cloud Source Repositories e altre. A un progetto Google Cloud può essere associato un solo parco risorse (o nessun parco risorse). Questa limitazione rafforza l'utilizzo dei progetti Google Cloud per garantire un maggiore isolamento tra le risorse non regolate o utilizzate insieme.

Progetto di applicazione o team

L'applicazione o il progetto del team app-banking-prod è destinato agli sviluppatori. In questo progetto si trovano le risorse Google Cloud specifiche per l'applicazione o per il team. Il progetto include tutto tranne i cluster GKE. A seconda del numero di team o applicazioni, potrebbero esserci più istanze di questo tipo di progetto. La creazione di progetti separati per team diversi ti consente di gestire separatamente IAM, fatturazione e quota per ogni team.

Networking

Ogni cluster GDCV per Bare Metal richiede le seguenti subnet di indirizzi IP:

  1. Indirizzi IP dei nodi
  2. Indirizzi IP dei pod Kubernetes
  3. Indirizzi IP di cluster/servizi Kubernetes
  4. Indirizzi IP del bilanciatore del carico (modalità in bundle)

Per utilizzare gli stessi intervalli di indirizzi IP non instradabili per le subnet di servizio e pod Kubernetes in ciascun cluster, seleziona un modello di rete in modalità isola. In questa configurazione, i pod possono comunicare direttamente tra loro all'interno di un cluster, ma non possono essere raggiunti direttamente dall'esterno di un cluster (utilizzando gli indirizzi IP dei pod). Questa configurazione forma un'isola all'interno della rete che non è connessa alla rete esterna. I cluster formano un mesh completo tra nodi tra i nodi del cluster all'interno dell'isola, consentendo al pod di raggiungere direttamente 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/A
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/A
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 degli indirizzi IP scelte per i pod e i servizi Kubernetes non siano in uso o instradabili dalla rete di nodi.

Requisiti di rete

Per fornire un bilanciatore del carico integrato per GDCV per Bare Metal che non richiede configurazione, utilizza la modalità del bilanciatore del carico in bundle in ogni cluster. Quando i carichi di lavoro eseguono i servizi LoadBalancer, viene assegnato un indirizzo IP dal pool del bilanciatore del carico.

Per informazioni dettagliate sui requisiti e sulla configurazione del bilanciatore del carico in bundle, 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 un modello di deployment dei cluster di amministrazione e utente con un cluster di amministrazione e due cluster utente in ciascuna posizione geografica per ottenere la massima ridondanza e tolleranza di errore per GDCV per Bare Metal.

Consigliamo di utilizzare un minimo di quattro cluster utente per ogni ambiente di produzione. Utilizza due località geograficamente ridondanti, ciascuna contenente due cluster 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 i carichi di lavoro tra questi nodi per ridurre l'impatto se un nodo passa alla modalità offline. Il numero e il dimensionamento dei nodi worker dipendono in gran parte dal tipo e dal numero di carichi di lavoro eseguiti nel cluster. Il dimensionamento consigliato per ciascun nodo è discusso nella sezione Configurazione dell'hardware per GDCV per Bare Metal.

La tabella seguente descrive il dimensionamento consigliato dei nodi per core CPU, memoria e spazio di archiviazione su disco locale in questo caso d'uso.

Dimensionamento dei nodi
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 delle macchine 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 nel repository di origine, viene utilizzata l'autenticazione locale per semplificare i requisiti. Se OIDC è disponibile, puoi modificare l'esempio per utilizzarlo. Per ulteriori informazioni, consulta Gestione delle identità con OIDC in GDCV per Bare Metal.

Sicurezza e gestione dei criteri

Nel caso d'uso di Cymbal Bank, Config Sync e Policy Controller vengono utilizzati per la gestione dei criteri. Viene creato un repository Cloud Source Repositories per archiviare i dati di configurazione usati da Config Sync. L'operatore ConfigManagement, utilizzato per installare e gestire Config Sync e Policy Controller, deve accedere di sola lettura al repository di origine della configurazione. Per concedere l'accesso, utilizza una forma di autenticazione accettabile. In questo esempio, viene utilizzato un account di servizio Google.

Servizi

In questo caso d'uso, per Service Management, Cloud Service Mesh viene utilizzato per fornire una base su cui creare i servizi distribuiti. Per impostazione predefinita, nel cluster viene creato anche un IngressGateway che gestisce gli oggetti Ingress di Kubernetes standard.

Persistenza e gestione degli stati

Poiché l'archiviazione permanente dipende in gran parte dall'infrastruttura esistente, questo caso d'uso non la richiede. In altri casi, tuttavia, consigliamo di utilizzare le opzioni di archiviazione dei partner di archiviazione di GKE Enterprise Ready. Se è disponibile un'opzione di archiviazione CSI, può essere installata sul cluster seguendo le istruzioni fornite dal fornitore. Per casi d'uso proof of concept e avanzati, puoi utilizzare i volumi locali. Tuttavia, nella maggior parte dei casi d'uso, sconsigliamo di utilizzare volumi locali negli ambienti di produzione.

Database

Molte applicazioni stateful in GDCV per Bare Metal utilizzano database come archivio di persistenza. Un'applicazione di database stateful ha bisogno di accedere a un database per fornire la sua logica di business ai client. Non sono previste limitazioni sul tipo di Datastore utilizzato da GDCV per Bare Metal. Le decisioni in merito all'archiviazione dei dati devono quindi essere prese dallo sviluppatore o dai team di gestione dei dati associati. Poiché applicazioni diverse potrebbero richiedere datastore diversi, anche questi possono essere utilizzati senza alcuna limitazione. I database possono essere gestiti in-cluster, on-premise o anche nel cloud.

Cymbal Bank è un'applicazione stateful che accede a due database PostgreSQL. L'accesso al database viene configurato tramite variabili di ambiente. Il database PostgreSQL deve essere accessibile dai nodi che eseguono i carichi di lavoro, anche se il database viene gestito esternamente dal cluster. In questo esempio, l'applicazione accede a un database PostgreSQL esterno. Mentre l'applicazione viene eseguita sulla piattaforma, il database viene gestito esternamente. Pertanto, il database non fa parte della 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 in modo da consentire a Google Cloud Observability di raccogliere log e metriche sia per i componenti del sistema sia per le applicazioni. Esistono diverse dashboard di Cloud Monitoring create dal programma di installazione della console Google Cloud, che possono essere visualizzate dalla pagina Dashboard di Monitoring. Per ulteriori informazioni sull'osservabilità, consulta Configurazione di logging e monitoraggio e Come funzionano Logging e Monitoring per GDCV per Bare Metal.

Deployment della piattaforma

Per maggiori informazioni, consulta la sezione relativa al deployment della piattaforma della documentazione nel repository di codice sorgente di GitHub.

Deployment dell'applicazione

Per maggiori informazioni, consulta la sezione relativa al deployment dell'applicazione della documentazione nel repository di codice sorgente di GitHub.

Passaggi successivi