Google Distributed Cloud è una soluzione software e hardware completamente gestita che estende l'infrastruttura e i serviziGoogle Cloud nel tuo data center. Google Distributed Cloud è disponibile anche come prodotto solo software che viene eseguito sul tuo hardware. Il software Google Distributed Cloud può essere installato su VMware o su bare metal. Questa guida è rivolta al software Google Distributed Cloud che viene eseguito direttamente sulle tue macchine bare metal.
Il software Google Distributed Cloud si basa su Google Kubernetes Engine (GKE), con il proprio pacchetto Kubernetes che estende GKE per l'utilizzo in un ambiente on-premise. Con Google Distributed Cloud puoi creare, gestire ed eseguire l'upgrade dei cluster GKE on-premise utilizzando le funzionalità diGoogle Cloud , nonché eseguire il deployment e gestire le applicazioni containerizzate sui tuoi cluster su larga scala utilizzando l'infrastruttura di Google.
Perché utilizzare Distributed Cloud (solo software) per bare metal?
L'esecuzione del software Distributed Cloud solo per bare metal sulla tua infrastruttura aziendale esistente fornisce accesso diretto all'hardware, sicurezza aziendale e gestione centralizzata negli ambienti.
Controllo diretto dell'hardware e prestazioni
Il deployment direttamente su server fisici ti offre il controllo diretto su scalabilità, latenza e prestazioni delle applicazioni, riducendo al contempo i costi grazie all'utilizzo dell'infrastruttura esistente. Google Distributed Cloud gestisce il deployment e l'integrità delle applicazioni nei tuoi data center aziendali esistenti per un'operatività più efficiente. Puoi ottimizzare i workload per tipi di hardware specializzati, come GPU e SSD, ed eseguire applicazioni a bassa latenza sul perimetro della rete senza l'overhead dell'hypervisor.
Sicurezza a livello di sistema operativo
Poiché mantieni il controllo diretto sui sistemi operativi dei nodi e sulle configurazioni di rete, puoi personalizzare le policy di sicurezza in base ai tuoi requisiti di conformità. I cluster comunicano con le API di Google tramite connessioni sicure e leggere, eliminando la complessità delle macchine virtuali e mantenendo i controlli di sicurezza esistenti.
Gestione e monitoraggio centralizzati
Gestisci, monitora e risolvi i problemi dei cluster dalla consoleGoogle Cloud utilizzando Cloud Monitoring e l'agente Connect. Questa visibilità centralizzata ti aiuta a mantenere l'affidabilità e ad adattare la scalabilità delle applicazioni nei data center distribuiti.
Affidabilità e operazioni aziendali
Google Distributed Cloud include funzionalità operative pronte per la produzione:
- Alta affidabilità: il supporto di più nodi del control plane garantisce che tu possa amministrare il tuo ambiente anche se un nodo non funziona.
- Controlli preflight automatici: la convalida integrata consente di verificare le configurazioni dell'hardware e del sistema operativo prima dell'installazione.
- Bilanciamento del carico integrato: i meccanismi di bilanciamento del carico di livello 4 e livello 7 vengono implementati automaticamente durante la creazione del cluster.
- Manutenzione del database: la deframmentazione automatica (
etcddefrag) recupera lo spazio di archiviazione per mantenere l'integrità e la stabilità dietcd.
Come funziona
Nei cluster GKE in esecuzione in Google Cloud, Google gestisce il control plane e l'infrastruttura di rete di Kubernetes. Per i cluster Google Distributed Cloud in esecuzione nel tuo data center, Google Cloud fornisce il software di amministrazione e del control plane che scarichi e installi sui tuoi server Linux fisici. Puoi gestire questi cluster on-premise in Google Cloud insieme ai cluster basati su cloud come parte di un parco risorse unificato.
Il seguente diagramma mostra l'architettura di un'installazione completata con un cluster di amministrazione e un cluster utente:
Componenti chiave
Un deployment bare metal solo software è costituito dai seguenti componenti:
- Cluster di amministrazione: gestisce il ciclo di vita dei cluster utente utilizzando Kubernetes Resource Management (KRM). Il deployment standard è costituito da un cluster di amministrazione che gestisce il ciclo di vita di uno o più cluster utente. Un cluster di amministrazione è composto da una o più macchine Linux fisiche che fungono da nodi del control plane. Ogni macchina nodo nell'installazione ha il proprio indirizzo IP.
- Cluster utente: esegue i workload containerizzati. Ogni cluster utente è composto da almeno un nodo del control plane e un nodo worker.
- Workstation di amministrazione: una macchina dedicata che ospita i file di configurazione e gli strumenti amministrativi:
bmctl: crea, aggiorna e gestisce i cluster.kubectl: interagisce con i cluster di amministrazione e utente e gestisce i workload.
- API GKE On-Prem: l'API ospitata da Google Cloudper la gestione del ciclo di vita dei cluster. I client, come la console Google Cloud , Google Cloud CLI e Terraform, ti consentono di gestire i cluster on-premise senza accedere alla workstation di amministrazione.
- ConsoleGoogle Cloud : fornisce un'interfaccia web per il tuo progetto Google Cloud, inclusi i cluster on-premise. La console Google Cloud mostra le metriche chiave dei tuoi cluster per aiutarti a monitorare l'integrità dei cluster e lo stato del parco risorse.
- Indirizzi IP virtuali (VIP): IP virtuali configurati durante l'installazione.
Gli amministratori e gli sviluppatori dei cluster utilizzano
kubectlper accedere ai control plane dei cluster tramite i VIP del control plane. Gli utenti e gli sviluppatori di applicazioni utilizzano i VIP di Service e Ingress per accedere ai workload ed esporli.
Connessione al parco risorse
I cluster utente e, facoltativamente, i cluster di amministrazione sono registrati in un parco risorse, ovvero un gruppo logico di cluster Kubernetes che fornisce una gestione unificata tra gli ambienti. I parchi risorse consentono alla tua organizzazione di passare dal livello di gestione dei singoli cluster a quello di interi gruppi di cluster e possono aiutare i tuoi team ad adottare best practice simili a quelle utilizzate da Google. Puoi visualizzare i cluster insieme nella consoleGoogle Cloud e utilizzare le funzionalità abilitate per il parco risorse per gestire, controllare e utilizzare i workload su larga scala.
Ogni cluster si connette a Google Cloud tramite l'agente Connect, di cui viene eseguito il deployment automatico durante l'installazione del cluster. L'appartenenza al parco risorse determina anche la fatturazione per Google Distributed Cloud.
Prezzi
I cluster on-premise creati con Google Distributed Cloud vengono fatturati per vCPU. Per abilitare la fatturazione, abilita l'API Anthos nel tuo progetto Google Cloud.
Per i dettagli sui prezzi e i dati di contatto del team di vendita, consulta Prezzi di Google Kubernetes Engine.
Versioni
Per scoprire di più sulle versioni di Google Distributed Cloud, consulta la policy di assistenza delle versioni.
Questa documentazione riguarda tutte le versioni supportate di Google Distributed Cloud. Ove pertinente, Google conserva anche informazioni limitate per le versioni precedenti non supportate in questa documentazione. Le differenze nei requisiti e nel comportamento specifiche per ogni versione sono indicate nella documentazione. Quando una nuova funzionalità diventa disponibile, viene documentata la versione supportata per la funzionalità.
Per un elenco delle versioni secondarie supportate e delle patch disponibili, consulta Controllo delle versioni.
A partire dalla release 1.29, non creiamo più una directory numerata per la documentazione della release secondaria precedente. Puoi trovare la documentazione archiviata per la versione 1.16 e precedenti aggiungendo il numero di versione secondaria nel seguente URL:
https://cloud.google.com/anthos/clusters/docs/bare-metal/VERSION/
Sostituisci VERSION con una versione secondaria da 1.0 a 1.16 e copia l'URL nella barra degli indirizzi del browser.
Installazione del software Distributed Cloud solo per bare metal
Poiché i cluster creati utilizzando Google Distributed Cloud vengono eseguiti nella tua infrastruttura, sono altamente configurabili. Dopo aver selezionato il modello di deployment che soddisfa le esigenze specifiche della tua organizzazione e del tuo caso d'uso, puoi scegliere tra una gamma di modalità di bilanciamento del carico, opzioni di indirizzamento IP, funzionalità di sicurezza, opzioni di connettività e altro ancora. La configurazione di un cluster comporta l'adozione di decisioni prima e durante l'installazione. Questo set di documentazione include guide per aiutare il tuo team a decidere le funzionalità e le opzioni più adatte alle tue esigenze. Per assicurarti che l'installazione soddisfi le esigenze della tua organizzazione, consulta i team di networking e delle applicazioni.
Dove vengono memorizzati i tuoi dati
Quando esegui il software Distributed Cloud solo per bare metal, i cluster, le applicazioni e i dati aziendali rimangono nel tuo data center. Per impostazione predefinita, Google Distributed Cloud invia Google Cloud informazioni sui tuoi cluster, come le impostazioni, l'integrità e l'utilizzo, ma non invia i dati delle tue applicazioni.
Dati che rimangono nel tuo data center
I seguenti dati rimangono nel tuo data center:
- Container, pod, PersistentVolume, backend di archiviazione locale e i dati elaborati dalle tue applicazioni.
- Il control plane (
kube-apiserver,kube-schedulerekube-controller-manager) e il databaseetcd, che archivia tutti gli oggetti Kubernetes. - Chiavi private per le autorità di certificazione (CA), tra cui la CA del cluster, la CA
etcde la CA del proxy front-end. Lo spazio dei nomi del cluster utente del cluster di amministrazione archivia le CA del cluster utente. - I secret dell'applicazione, i token OAuth, le chiavi private SSH, le credenziali del Container Registry e i file delle chiavi dei account di servizio sono archiviati in
etcdo sulla tua workstation di amministrazione. Non vengono inviate all'API GKE On-Prem e l'istantanea diagnostica predefinita non include le credenziali del cluster. - Il file di configurazione del cluster è archiviato sulla workstation di amministrazione. Se un cluster è registrato nell'API GKE On-Prem, vengono inviate alcune impostazioni. Per saperne di più, consulta Dati inviati a Google Cloud.
- Gli audit log vengono scritti su disco solo se disattivi Cloud Audit Logs sui nodi del control plane.
- Se configuri un account di servizio per i caricamenti di snapshot di diagnostica, il file viene caricato su Cloud Storage. Puoi scegliere se condividere o meno uno snapshot con l'assistenza clienti Google Cloud.
Dati inviati a Google Cloud
La tabella seguente mostra cosa viene inviato, come viene utilizzato e archiviato e se puoi disattivarlo:
| Dati | Contenuti inviati | Utilizzo e conservazione | Predefinito |
|---|---|---|---|
| Connessione e registrazione del parco risorse ( gkehub.googleapis.com,
gkeconnect.googleapis.com) |
|
Gestisci i cluster dalla consoleGoogle Cloud , dal gateway di connessione e dal parco risorse con l'agente Connect. | Obbligatorio |
| Impostazioni e stato del cluster ( gkeonprem.googleapis.com) |
|
Consente di gestire i cluster con la console Google Cloud , Google Cloud CLI o Terraform. Archiviati dall'API GKE On-Prem nella regione impostata in gkeOnPremAPI.location, che per impostazione predefinita è clusterOperations.location. |
On nella versione 1.16 e successive, se l'API GKE On-Prem è abilitata nel tuo progetto Google Cloud . Per disattivarla, imposta
gkeOnPremAPI.enabled su false. |
| Utilizzo della fatturazione ( anthos.googleapis.com) |
Capacità vCPU, numero di nodi e stato dei diritti di licenza. | Utilizzato per la misurazione, la fatturazione e i controlli delle licenze. | Obbligatorio. I record di fatturazione vengono memorizzati nel buffer durante un'interruzione e inviati in un secondo momento. |
| Dati sulla salute del sistema ( logging.googleapis.com, monitoring.googleapis.com,
opsconfigmonitoring.googleapis.com) |
|
Utilizzato per Cloud Monitoring, le visualizzazioni dello stato della console Google Cloud e la risoluzione dei problemi dell'assistenza clienti. Archiviati nel progetto Google Cloud impostato in clusterOperations.projectID. Le metriche vengono archiviate nella regione impostata in clusterOperations.location, mentre i log seguono le impostazioni del router dei log. |
On per le metriche e i log di sistema, necessari per la copertura completa dell'assistenza clienti e dello SLA. Off
per le metriche e i log delle applicazioni, a meno che non imposti
enableCloudLoggingForApplications o
enableGMPForApplications su true nella
risorsa Stackdriver. |
| Audit log ( anthosaudit.googleapis.com) |
Audit log delle attività di amministrazione (audit-proxy): chi ha modificato cosa tramite kube-apiserver e quando. Le voci includono l'ora, il cluster, l'host o la VM, l'utente o il account di servizio, il ruolo RBAC, l'operazione e il risultato. Le richieste di lettura non vengono registrate. |
Archiviati in Cloud Audit Logs nel tuo progetto Google Cloud , nel bucket_Required, e conservati per 400 giorni. |
On. Per disattivarla, imposta clusterOperations.disableCloudAuditLogging su true.
Gli audit log vengono quindi conservati solo sui dischi dei nodi del control plane. |
Passaggi successivi
Per iniziare a utilizzare Google Distributed Cloud, consulta le seguenti guide:
- Crea cluster di amministrazione e utente Google Distributed Cloud demo su VM di Compute Engine
- Pianifica un'installazione di base sul tuo hardware
- Crea cluster di base sul tuo hardware