Panoramica di Distributed Cloud solo software per VMware

Distributed Cloud (solo software) per VMware consente di eseguire il deployment e gestire i cluster Google Kubernetes Engine (GKE) in un ambiente VMware vSphere. Puoi eseguire ed eseguire l'upgrade di applicazioni containerizzate nel tuo data center utilizzando le funzionalità e l'infrastruttura di Google Cloud .

Per eseguire cluster solo software direttamente su server fisici, consulta la panoramica di Distributed Cloud solo software per bare metal.

Perché utilizzare Distributed Cloud (solo software) per VMware?

L'esecuzione di Distributed Cloud solo software per VMware sulla tua infrastruttura vSphere esistente ti consente di modernizzare le applicazioni con GKE, mantenendo al contempo la piattaforma di virtualizzazione, lo spazio di archiviazione e i processi operativi già utilizzati dai tuoi team.

Integrazione con l'ambiente vSphere

Google Distributed Cloud esegue i nodi del cluster come macchine virtuali nel tuo ambiente vCenter esistente, in modo da poter aggiungere workload containerizzati agli host vSphere che utilizzi già. I cluster archiviano i dati in datastore vSphere supportati da vSAN, VMFS o NFS e puoi assegnare datastore diversi a singoli pool di nodi. Il driver CSI (Container Storage Interface) di vSphere esegue il provisioning dei volumi permanenti per i workload stateful. Per maggiori dettagli, vedi Spazio di archiviazione.

Gestione centralizzata con dati on-premise

Gestisci, monitora e risolvi i problemi dei cluster dalla console Google Cloud , da Google Cloud CLI o da Terraform utilizzando l'API GKE On-Prem, senza accedere alla workstation di amministrazione. Le tue applicazioni e i tuoi dati aziendali rimangono nel tuo data center; Google Cloud riceve solo i metadati del cluster, lo stato e le informazioni sull'utilizzo. Per maggiori dettagli, consulta Dati che rimangono nel data center.

Affidabilità e operazioni aziendali

Google Distributed Cloud include funzionalità operative pronte per la produzione:

  • Alta affidabilità: i cluster di amministrazione e i control plane dei cluster utente ad alta affidabilità utilizzano tre nodi del control plane, in modo da poter amministrare l'ambiente anche in caso di errore di un nodo.
  • Riparazione automatica dei nodi: i controlli di integrità periodici rilevano i nodi non integri e la riparazione automatica dei nodi li ripara automaticamente. Questa funzione è attivata per impostazione predefinita.
  • Scalabilità automatica dei cluster: il gestore della scalabilità automatica dei cluster aggiunge o rimuove i nodi in un pool di nodi in base alle richieste di risorse dei tuoi workload.
  • Bilanciamento del carico flessibile: utilizza il bilanciatore del carico MetalLB in bundle, che viene eseguito sui nodi del cluster, o configura un bilanciatore del carico di terze parti, come F5 BIG-IP o Citrix. Per maggiori dettagli, consulta Panoramica del bilanciamento del carico.

Come funziona

Google Distributed Cloud estende GKE per consentirti di creare cluster su server fisici in un ambiente vSphere. Puoi gestire questi cluster on-premise in Google Cloud insieme ai cluster basati su cloud come parte di un parco risorse unificato.

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 viene scaricato e di cui viene eseguito il deployment sulle tue macchine virtuali vSphere nell'ambito dei processi di installazione e upgrade.

Il seguente diagramma mostra l'architettura di un'installazione completata con un cluster di amministrazione e un cluster utente:

Diagramma di un cluster di amministrazione e di un cluster utente
Architettura Google Distributed Cloud su VMware con un cluster di amministrazione e un cluster utente

Componenti chiave

I seguenti componenti costituiscono un'installazione di Distributed Cloud solo software per VMware:

  • Cluster di amministrazione: gestisce uno o più cluster utente. I cluster di amministrazione sono costituiti da uno o più nodi del control plane in esecuzione su macchine virtuali dedicate.
  • Cluster utente: esegue i workload containerizzati. Ogni cluster utente è costituito da almeno un nodo del control plane e da uno o più nodi worker.
  • Workstation di amministrazione: una macchina virtuale dedicata che include i file di configurazione del cluster e gli strumenti di gestione:
    • gkectl: crea, aggiorna e gestisce i deployment dei cluster.
    • kubectl: interagisce con i cluster di amministrazione e utente per gestire i workload.
  • ConsoleGoogle Cloud : un'interfaccia web in Google Cloud per visualizzare l'integrità del cluster ed eseguire operazioni del ciclo di vita senza accedere alla workstation di amministrazione.
  • Indirizzi IP virtuali (VIP): IP virtuali configurati durante l'installazione. Gli amministratori e gli sviluppatori dei cluster utilizzano kubectl e i VIP del control plane per controllo dell'accesso plane nei cluster di amministrazione e utente. Gli utenti e gli sviluppatori di applicazioni utilizzano i VIP di servizio e Ingress per accedere ed esporre i workload, rispettivamente. Per maggiori dettagli, consulta Pianifica gli indirizzi IP.

Connessione al parco risorse

Tutti i cluster utente sono membri di un parco risorse, ovvero un gruppo logico di cluster Kubernetes che fornisce una gestione unificata in tutti gli ambienti. I parchi risorse ti consentono di visualizzare i cluster insieme nella console Google Cloud e di 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 il software Distributed Cloud solo per VMware.

Prezzi

I cluster on-premise creati utilizzando Google Distributed Cloud vengono fatturati per vCPU. Per abilitare la fatturazione, abilita l'API Anthos nel tuo progetto Google Cloud.

Per informazioni complete sui prezzi, incluso come contattare il team di vendita, consulta Prezzi di Google Kubernetes Engine.

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.

Per le versioni supportate e le policy di rilascio, consulta le seguenti risorse:

A partire dalla versione 1.29, non creiamo più una directory per la release secondaria precedente. Le differenze di comportamento sono indicate nella documentazione. Quando una nuova funzionalità diventa disponibile, la versione supportata per la funzionalità viene documentata.

La documentazione per la versione 1.16 e precedenti è archiviata all'indirizzo:

https://cloud.google.com/anthos/clusters/docs/on-prem/VERSION/

Sostituisci VERSION con una versione secondaria da 1.0 a 1.16 e copia l'URL nella barra degli indirizzi del browser.

Dove vengono memorizzati i tuoi dati

Quando esegui Distributed Cloud solo software per VMware, 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, ad esempio impostazioni, stato e 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 e i dati elaborati dalle tue applicazioni.
  • Tutti gli oggetti Kubernetes sono archiviati nel control plane e nel database etcd.
  • Il control plane del cluster di amministrazione archivia le chiavi private etcd autofirmate, le chiavi del cluster utente e le autorità di certificazione (CA) del cluster.
  • Secret dell'applicazione, token OAuth, chiavi private SSH, credenziali del container registry, credenziali vCenter e F5 BIG-IP e file delle chiavi dei account di servizio, archiviati in etcd o sulla tua workstation di amministrazione. Non vengono inviati all'API GKE On-Prem e vengono rimossi dagli snapshot di diagnostica.
  • I file di configurazione del cluster di amministrazione, del cluster utente e delle credenziali sono archiviati sulla workstation di amministrazione.
  • Gli audit log vengono scritti sul disco nei nodi del control plane del cluster di amministrazione e nei cluster utente.
  • Puoi scegliere di caricare gli snapshot di diagnostica su Cloud Storage.

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)
  • Identità del cluster: Google Cloud progetto, nome dell'appartenenza al parco risorse, UID del cluster, chiavi pubbliche, versione di Kubernetes, dimensioni del cluster e configurazione del provider di identità.
  • Dati Kubernetes richiesti dalla console Google Cloud o dal gateway di connessione.
  • Il token Kubernetes criptato nel tuo profilo utente finché non esci dalla console Google Cloud .
 Gestisci i cluster dalla consoleGoogle Cloud , dal gateway di connessione e dal parco risorse con l'agente Connect. Il tuo kube-apiserver autentica, autorizza e registra ogni richiesta. Obbligatorio
Impostazioni e stato del cluster
(gkeonprem.googleapis.com)
  • Nome, UID, descrizione, annotazioni, versione, stato del ciclo di vita e VIP del control plane.
  • Nomi dei pool di nodi, impostazioni IP o DHCP dei nodi, CIDR di pod e servizi, VIP del bilanciatore del carico, impostazioni del bilanciatore del carico.
  • Indirizzo vCenter, datacenter, cluster, pool di risorse, datastore, cartella e nome della policy di archiviazione (non le credenziali vCenter).
  • Indirizzi email degli amministratori del cluster.
 Consente di gestire i cluster con la console Google Cloud , Google Cloud CLI o Terraform. L'API GKE On-Prem archivia questi dati nella regione impostata in gkeOnPremAPI.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)
  • Metriche: utilizzo di CPU, memoria, disco e rete, metriche kubelet e kube-state-metrics per nodi e pod di sistema.
  • Log dei container e risultati dei controlli di integrità di tutti i componenti del cluster di amministrazione e degli spazi dei nomi del cluster utente kube-system, gke-system, gke-connect, istio-system e config-management-system.
  • Metadati: nomi ed etichette di nodi, pod, deployment e servizi.
 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 stackdriver.projectID. Metriche archiviate nella regione stackdriver.clusterLocation e log che 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: 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 progetto Google Cloud impostato in cloudAuditLogging.projectID, nel bucket _Required e conservati per 400 giorni. (Facoltativo) Per attivarla, compila la sezione cloudAuditLogging. Per i cluster di amministrazione, puoi attivarla solo al momento della creazione. Per disattivarlo per un cluster utente, elimina la sezione e aggiorna il cluster.

Passaggi successivi