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 il deployment di GDCV per Bare Metal. Questa guida è rivolta agli amministratori di piattaforma che vogliono eseguire il deployment di GKE Enterprise su una piattaforma bare metal in una configurazione ad alta disponibilità e ridondante geografica. Per comprendere al meglio questa guida, dovresti conoscere i concetti di base di GKE Enterprise, come descritto nella panoramica tecnica di GKE Enterprise. Dovresti inoltre avere una conoscenza di base dei concetti di base di Kubernetes e di Google Kubernetes Engine (GKE), come descritto in Nozioni di base su Kubernetes e documentazione di GKE.

Questa guida contiene un repository di codice sorgente GitHub che include script da 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 utilizzino le best practice e i criteri della tua organizzazione.

Modello di architettura GDCV per Bare Metal

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

Un modello mentale GDCV per Bare Metal che mostra i livelli trattati 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 i cluster GKE.
  4. Livello di gestione dei servizi: questo livello utilizza Anthos 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 Osservabilità di Google Cloud e Anthos Service Mesh.

Ciascuno di questi livelli 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 basano sulle rispettive sezioni della Guida alle basi dell'architettura di GKE Enterprise. Ti consigliamo di consultare la guida mentre leggi questo articolo.

Networking

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

Per i bilanciatori del carico GDCV per Bare Metal sono disponibili due opzioni: in bundle e manuale.

In modalità in bundle, viene eseguito il deployment del software di bilanciamento del carico L4 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 indirizzi IP virtuali (VIP), questo bilanciatore del carico offre due opzioni:

In modalità manuale, puoi configurare le tue soluzioni di bilanciamento del carico per il traffico del piano di controllo e del piano dati. Per i bilanciatori del carico esterni sono disponibili molte opzioni hardware e software. 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, in base alle diverse esigenze di disponibilità, isolamento e utilizzo delle risorse. Questi modelli di deployment sono descritti in Scegliere un modello di deployment.

Gestione delle identità

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

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

Sicurezza e gestione dei criteri

Per la gestione della sicurezza e dei criteri GDCV per Bare Metal, consigliamo di utilizzare Config Sync e Policy Controller. Policy Controller consente di creare e applicare criteri nei 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 creato anche un 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 oppure creare servizi di tipo NodePort e configurare manualmente il bilanciatore del carico esterno per utilizzare il servizio Kubernetes come backend.

Per Service Management, chiamato anche traffico est-ovest, consigliamo di utilizzare Anthos Service Mesh. Anthos Service Mesh è basato su API aperte Istio e fornisce osservabilità, autenticazione, crittografia uniformi, controlli del traffico granulari e altre caratteristiche e funzioni. Per ulteriori informazioni su Service Management, consulta Anthos Service Mesh.

Persistenza e gestione dello stato

Il GDCV per Bare Metal dipende in gran parte dall'infrastruttura esistente per l'archiviazione temporanea, l'archiviazione di volumi 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 sull'archiviazione, consulta Configurazione dell'archiviazione.

Database

GDCV per Bare Metal non fornisce ulteriori funzionalità specifiche del database oltre alle funzionalità 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 essere configurati per la connessione a qualsiasi database esterno accessibile.

Osservabilità

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

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

Caso d'uso: implementazione 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 illustra le decisioni prese in base alle opzioni discusse nelle sezioni del modello 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 dell'applicazione, il deployment dell'applicazione Cymbal Bank viene eseguito sulla piattaforma.

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

Pianificazione

La sezione seguente descrive in dettaglio le decisioni relative all'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 si concentrano su un ambiente di produzione. Puoi utilizzare passaggi simili per creare ambienti di livello inferiore come lo sviluppo o la 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. Questa configurazione di progetto consente di 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 è per l'amministratore di rete. In questo progetto il data center on-premise viene connesso a Google Cloud utilizzando la forma di connettività ibrida selezionata. Per saperne di più sulle opzioni di connettività ibrida, consulta Connettività Google Cloud

Progetto host del parco risorse

Il progetto host del parco risorse fleet-prodè destinato all'utente tipo dell'amministratore della piattaforma. È qui che vengono registrati i cluster GDCV per Bare Metal. Questo progetto è anche il luogo in cui risiedono le risorse Google Cloud relative alla piattaforma. Queste risorse includono l'osservabilità di Google Cloud, 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'uso dei progetti Google Cloud per fornire un isolamento più forte tra le risorse che non sono regolate o utilizzate insieme.

Progetto di applicazione o di team

L'applicazione o il progetto del team app-banking-prod è per l'utente sviluppatore. Questo è il luogo in cui risiedono le risorse Google Cloud specifiche dell'applicazione o del 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 di Kubernetes
  3. Indirizzi IP del servizio/cluster Kubernetes
  4. Indirizzi IP del bilanciatore del carico (modalità in bundle)

Per utilizzare gli stessi intervalli di indirizzi IP non instradabili per il pod Kubernetes e le subnet di servizio in ogni 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 sono raggiungibili direttamente dall'esterno di un cluster (mediante 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 da nodo a nodo 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à isola, è importante assicurarsi che le subnet di 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 leggere informazioni dettagliate sui requisiti e sulla configurazione del bilanciatore del carico in bundle, vedi 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 ogni località geografica, al fine di ottenere la massima ridondanza e tolleranza di errore per GDCV per Bare Metal.

Consigliamo di utilizzare almeno 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 un'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 i nodi per ridurre l'impatto se un nodo diventa offline. Il numero e le dimensioni dei nodi worker dipendono in gran parte dal tipo e dal numero di carichi di lavoro eseguiti nel cluster. Il dimensionamento consigliato per ciascuno dei nodi è illustrato in Configurazione dell'hardware per GDCV per Bare Metal.

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

Dimensioni 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 saperne di più sui prerequisiti e sul dimensionamento delle macchine, consulta Prerequisiti delle macchine dei nodi del cluster.

Gestione delle identità

Per la gestione delle identità, consigliamo un'integrazione con OIDC tramite GKE Identity Service. Negli esempi forniti nel repository di codice sorgente, viene utilizzata l'autenticazione locale per semplificare i requisiti. Se OIDC è disponibile, puoi modificare l'esempio per utilizzarlo. Per maggiori 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 utilizzati da Config Sync. L'operatore ConfigManagement, utilizzato per installare e gestire Config Sync e Policy Controller, richiede l'accesso 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

Per la gestione dei servizi in questo caso d'uso, Anthos Service Mesh viene utilizzato per fornire una base su cui vengono creati i servizi distribuiti. Per impostazione predefinita, viene creato un IngressGateway anche nel cluster che gestisce gli oggetti Ingress standard di Kubernetes.

Persistenza e gestione dello stato

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

Database

Molte applicazioni stateful su GDCV per Bare Metal utilizzano i database come archivio di persistenza. Un'applicazione di database stateful deve accedere a un database per fornire la logica di business ai client. Non sono previste limitazioni sul tipo di Datastore utilizzato da GDCV per Bare Metal. Pertanto, le decisioni in merito all'archiviazione dei dati devono 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 limitazioni. I database possono essere gestiti in-cluster, on-premise o anche nel cloud.

L'applicazione 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 dai nodi che eseguono i carichi di lavoro, anche se è gestito esternamente dal cluster. In questo esempio, l'applicazione accede a un database PostgreSQL esterno esistente. Mentre l'applicazione è in esecuzione sulla piattaforma, il database è 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 che Google Cloud Observability raccolga log e metriche sia per i componenti di sistema che 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 maggiori informazioni sull'osservabilità, consulta Configurazione di logging e monitoraggio e Funzionamento di Logging e Monitoring per GDCV per Bare Metal.

Deployment della piattaforma

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

Deployment dell'applicazione

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

Passaggi successivi