Configura l'infrastruttura minima

Questa è la prima parte di una guida che illustra un piccolo installazione proof-of-concept di Google Distributed Cloud (solo software) per VMware con un singolo cluster utente.

Questo documento mostra come configurare ambienti vSphere e Google Cloud minimi per questa installazione e pianificare i tuoi indirizzi IP, mentre il follow-up Creazione di cluster di base mostra come creare una workstation di amministrazione, un cluster di amministrazione e un cluster utente.

L'infrastruttura che configuri utilizzando questa guida potrebbe non essere adatta alle tue esigenze di produzione e ai tuoi casi d'uso effettivi. Per saperne di più sulle installazioni di produzione, consulta la panoramica dell'installazione e le guide.

Prima di iniziare

Panoramica della procedura

Di seguito sono riportati i passaggi principali necessari per questa configurazione:

  1. Configura l'ambiente. Assicurati di soddisfare i requisiti delle risorse. Viene fornita una configurazione di esempio per un host ESXi e un datastore vSphere che soddisfano i requisiti di questa installazione.
  2. Configura oggetti vSphere. I componenti di Google Distributed Cloud vengono eseguiti all'interno di una gerarchia di oggetti vSphere.
  3. Pianifica gli indirizzi IP. Google Distributed Cloud richiede che tu fornisca gli indirizzi IP per tutti i nodi, oltre agli indirizzi IP virtuali (VIP) per l'accesso come amministratore e utente al tuo deployment. Per questa configurazione utilizzerai indirizzi IP statici per i nodi del cluster. Forniamo alcuni esempi, anche se ti consigliamo di consultare il tuo amministratore di rete per scegliere gli indirizzi adatti per la tua rete.
  4. Configura le regole del firewall e del proxy
  5. Configura le risorse Google Cloud, tra cui un progetto Google Cloud che utilizzerai durante la configurazione e la gestione di Google Distributed Cloud e un account di servizio con le autorizzazioni necessarie per accedere e scaricare il software del componente Google Distributed Cloud.

1. Configura l'ambiente

Per questa installazione minima, puoi utilizzare un singolo host fisico in esecuzione ESXi.

  1. Assicurati che l'host disponga della seguente capacità minima di CPU, RAM e spazio di archiviazione:

    • 8 CPU fisiche con hyperthreading a 2,7 GHz abilitato
    • 80 gibibyte (GiB) di RAM
    • 470 GiB di spazio di archiviazione

  2. Assicurati di avere installato ESXi versione 7.0u2 o successiva.

  3. Assicurati di utilizzare vCenter Server versione 7.0u2 o successiva.

Host e datastore di esempio

Ecco un esempio di Host ESXi e un vSphere datastore che soddisfano i requisiti:

  • Configurazione host ESXi:

    • Produttore: Dell Inc.
    • CPU fisiche: 8 CPU a 2,7 GHz
    • Tipo di processore: CPU Intel(R) Xeon(R) Platinum 8168 a 2,70 GHz
    • Socket processore: 2
    • Versione ESXi: 7.0u2 o successiva
    • vCenter Server versione: 7.0u2 o successiva
    • Hyperthreading: abilitato

  • Configurazione Datastore:

    • Tipo: VMFS 6.82
    • Tipo di unità: SSD
    • Fornitore: DELL
    • Tipo di unità: logico
    • Livello RAID: RAID1

2. Configura oggetti vSphere

Configura i seguenti oggetti nel tuo ambiente vSphere:

Prendi nota dei nomi di data center, cluster, datastore e rete vSphere, che ti serviranno durante la configurazione della workstation di amministrazione in Creare cluster di base.

Se hai configurato un datastore vSAN, utilizza govc per creare una cartella nella directory datastore da utilizzare per il disco della macchina virtuale (VMDK) di Google Distributed Cloud:

govc datastore.mkdir -namespace=true data-disks

3. Pianifica gli indirizzi IP

Come hai visto nella panoramica di Google Distributed Cloud, un'installazione di Google Distributed Cloud richiede una serie di indirizzi IP, tra cui:

  • Indirizzi IP per tutti i nodi
  • Indirizzi IP virtuali (VIP) per l'accesso ai componenti del piano di controllo, come i server API di Kubernetes, e alle applicazioni in esecuzione sui tuoi cluster utente
  • Intervalli CIDR per la comunicazione tra pod e servizi

Per questo motivo, una parte importante della configurazione di Google Distributed Cloud consiste nella pianificazione degli indirizzi IP e nell'assicurarsi che non si creino conflitti di indirizzo. Potrebbe essere necessario che l'amministratore di rete ti aiuti a trovare i valori adatti da configurare, anche per questa semplice installazione. Nel resto di questa sezione forniamo esempi illustrativi di valori utilizzabili per questa installazione in una rete ipotetica (i valori saranno diversi).

  • I cluster in questa installazione minima utilizzano MetalLB con il bilanciatore del carico di rete passthrough esterno regionale. Questo bilanciatore del carico viene eseguito sui nodi del cluster, quindi non Le VM sono necessarie per il bilanciamento del carico.

  • Google Distributed Cloud consente di scegliere se fornire indirizzi IP statici per i nodi del cluster o utilizzare un server DHCP. In questa semplice installazione, utilizzerai indirizzi IP statici.

VLAN di esempio

Per questa installazione ridotta, ti consigliamo di collocare la workstation di amministrazione, nodi del cluster di amministrazione e nodi del cluster utente sulla stessa VLAN nella tua rete vSphere in ogni rete. Ad esempio, supponiamo che tutti gli indirizzi IP nell'intervallo 172.16.20.0/24 siano a una determinata VLAN. Supponiamo inoltre che l'amministratore di rete ti abbia può utilizzare 172.16.20.49-172.16.20.69 per VM e indirizzi IP virtuali (VIP).

Il seguente diagramma illustra una VLAN con una workstation di amministrazione, un amministratore un cluster utente e un cluster utente. Come puoi notare, i VIP non vengono mostrati associati a nessun di un nodo specifico in un cluster. Questo perché il bilanciatore del carico MetalLB può scegli quale nodo annuncia il VIP per un singolo servizio. Ad esempio, nel nel cluster utente, un nodo worker potrebbe annunciare 172.16.20.64 e un altro worker potrebbe annunciare 172.16.20.65.

Indirizzi IP per un cluster di amministrazione e un cluster utente.
Indirizzi IP per un cluster di amministrazione e un cluster utente (fai clic per ingrandire)

Esempio di indirizzo IP: workstation di amministrazione

Per la workstation di amministrazione, questo esempio utilizza il primo indirizzo dell'intervallo fornito dall'amministratore di rete: 172.16.20.49.

Indirizzi IP di esempio: nodi cluster

La tabella seguente fornisce un esempio di come è possibile utilizzare gli indirizzi IP per nodi del cluster. Tieni presente che la tabella mostra gli indirizzi di due nodi aggiuntivi: admin-vm-6 e user-vm-5. La sono necessari nodi aggiuntivi durante gli upgrade, gli aggiornamenti e la riparazione automatica. Per ulteriori informazioni, vedi Gestisci gli indirizzi IP dei nodi.

Nome host VM Descrizione Indirizzo IP
admin-vm-1 Nodo del piano di controllo per il cluster di amministrazione. 172.16.20.50
admin-vm-2 Nodo del piano di controllo per il cluster di amministrazione. 172.16.20.51
admin-vm-3 Nodo del piano di controllo per il cluster di amministrazione. 172/16/20/52
user-vm-1 Nodo del piano di controllo per il cluster utente. 172.16.20.53
user-vm-2 Nodo worker del cluster utente 172.16.20.54
user-vm-3 Nodo worker del cluster utente 172.16.20.55
user-vm-4 Nodo worker del cluster utente 172.16.20.56
user-vm-5 172.16.20.57

Esempi di indirizzi IP: VIP per il cluster di amministrazione

La tabella seguente fornisce un esempio di come specificare un piano di controllo VIP per il cluster di amministrazione.

VIP Descrizione Indirizzo IP
VIP per il server API Kubernetes del cluster di amministrazione Configurato sul bilanciatore del carico per il cluster di amministrazione. 172.16.20.58

Esempi di indirizzi IP: VIP per il cluster utente

La tabella seguente fornisce un esempio di come è possibile specificare i VIP per un utente in un cluster Kubernetes.

Nota che il VIP per il server API Kubernetes del cluster utente e I VIP in entrata si trovano entrambi nella stessa VLAN dei nodi worker e dei nodi del piano di controllo.

VIP Descrizione Indirizzo IP
VIP per il server API Kubernetes del cluster utente Configurato sul bilanciatore del carico per il cluster di amministrazione. 172.16.20.59
VIP in entrata Configurato sul bilanciatore del carico per il cluster utente. 172/16/20/60
VIP di servizio Dieci indirizzi per i servizi di tipo LoadBalancer.
Configurato in base alle esigenze sul bilanciatore del carico per il cluster utente.
Nota che questo intervallo include il VIP in entrata. Questo è un requisito per il bilanciatore del carico MetalLB.		 172.16.20.60 - 172.16.20.69

Indirizzi IP per pod e servizi

Oltre agli indirizzi IP per i nodi del cluster e per accedere al deployment, devi specificare anche gli intervalli di indirizzi che possono essere utilizzati all'interno di ciascun cluster per il traffico nel cluster.

A questo scopo, specifica CIDR per gli indirizzi IP dei pod e un altro intervallo CIDR da utilizzare per gli indirizzi ClusterIP dei servizi Kubernetes. Queste vengono specificate come parte della configurazione del cluster, come vedrai nella parte successiva di questa guida.

Nell'ambito della pianificazione IP, decidi quali intervalli CIDR utilizzare per pod e servizi. A meno che tu non un motivo diverso, utilizza i seguenti intervalli predefiniti:

FinalitàIntervallo CIDR predefinito
Pod del cluster di amministrazione192.168.0.0/16
Pod del cluster utente192.168.0.0/16
Servizi del cluster di amministrazione10.96.232.0/24
Servizi del cluster utente10.96.0.0/20

I valori predefiniti indicano questi punti:

  • L'intervallo CIDR dei pod può essere lo stesso per più cluster.

  • L'intervallo CIDR del servizio di un cluster non deve sovrapporsi al CIDR del servizio di qualsiasi altro cluster.

  • In genere hai bisogno di più pod che servizi, quindi per un dato cluster è probabile che tu voglia un intervallo CIDR pod più grande dell'intervallo CIDR servizio. Ad esempio, l'intervallo di pod predefinito per un cluster utente ha 2^(32-16) = 2^16 indirizzi IP, ma l'intervallo di servizi predefinito per un cluster utente ha 2^(32-20) = 2^12 indirizzi.

Evita sovrapposizioni

In alcuni casi potresti dover utilizzare intervalli CIDR non predefiniti per evitare la sovrapposizione con indirizzi IP raggiungibili sulla tua rete. Gli intervalli di servizi e pod devono Non sovrapporsi ad alcun indirizzo esterno al cluster da cui vuoi effettuare la copertura all'interno del cluster.

Ad esempio, supponiamo che l'intervallo di servizi sia 10.96.232.0/24 e che l'intervallo di pod sia 192.168.0.0/16. Il traffico inviato da un pod a un indirizzo in uno di questi verranno trattati come nel cluster e non raggiungeranno nessuna destinazione all'esterno nel cluster.

In particolare, gli intervalli di servizi e pod non devono sovrapporsi a:

  • Indirizzi IP dei nodi in qualsiasi cluster

  • Indirizzi IP utilizzati dalle macchine dei bilanciatori del carico

  • VIP utilizzati dai nodi del piano di controllo e dai bilanciatori del carico

  • Indirizzo IP di server vCenter, server DNS e server NTP

Ti consigliamo di utilizzare gli intervalli di indirizzi IP interni definiti RFC 1918 per gli intervalli di pod e servizi.

Ecco uno dei motivi per cui si consiglia di utilizzare indirizzi RFC 1918. Supponiamo che se il pod o l'intervallo di servizi contiene indirizzi IP esterni. Qualsiasi traffico inviato da un pod a uno di questi indirizzi esterni verrà trattato come traffico nel cluster e non raggiungerà la destinazione esterna.

Server DNS e gateway predefinito

Prima di creare i cluster di amministrazione e utente, devi conoscere anche gli indirizzi IP di:

  • Un server DNS che può essere utilizzato dalla workstation di amministrazione e dai nodi del cluster

  • Un server NTP che può essere utilizzato dai nodi del cluster

  • L'indirizzo IP del gateway predefinito per la subnet con alla workstation di amministrazione e ai nodi del cluster. Ad esempio, supponiamo che l'amministratore i nodi della workstation, del cluster di amministrazione e del cluster utente 172.16.20.0/24. È possibile che l'indirizzo del gateway predefinito per la subnet essere 172.16.20.1.

4. Configura il firewall e il proxy

Configura il firewall e il proxy per consentire il traffico Google Distributed Cloud necessario, seguendo le Regole proxy e firewall. Per eseguire questa attività, avrai bisogno degli indirizzi IP dei nodi cluster che hai identificato nella sezione precedente. Tieni presente che, poiché gli indirizzi IP dei cluster utente e di amministrazione non sono assegnati a nodi specifici, devi assicurarti che tutte le regole firewall pertinenti vengano applicate a tutti gli indirizzi IP di ciascun cluster.

5. configura le risorse Google Cloud

I progetti Google Cloud sono la base per creare, abilitare e utilizzare tutti i servizi Google Cloud, inclusi quelli utilizzati per installare e gestire Google Distributed Cloud. Se non hai dimestichezza con i progetti Google Cloud, puoi trovare molte altre informazioni nella pagina Creazione e gestione dei progetti.

  1. Scegli un progetto Google Cloud esistente o creane uno nuovo.

  2. Prendi nota dell'ID progetto Google Cloud, perché sarà necessario in seguito.

Configura Google Cloud CLI

Google Cloud CLI è uno strumento a riga di comando che puoi utilizzare per lavorare con il tuo progetto. Segui le istruzioni riportate in Installazione di Google Cloud SDK per assicurarti di avere la versione più aggiornata.

Autorizzazioni obbligatorie

Se sei il proprietario del progetto (ad esempio se hai creato tu il progetto), disponi già di tutte le autorizzazioni necessarie per eseguire il resto di questa semplice installazione. Se non sei il proprietario del progetto, tu o l'amministratore del progetto dovete garantire che il tuo Account Google disponga delle autorizzazioni necessarie.

Le seguenti I ruoli IAM consentono di creare un account di servizio, assegnargli ruoli IAM, abilitare le API e garantire che lo strumento gkeadm possa creare e e gestire gli account di servizio per conto tuo nella seconda parte di questa configurazione:

  • resourcemanager.projectIamAdmin
  • serviceusage.serviceUsageAdmin
  • iam.serviceAccountCreator
  • iam.serviceAccountKeyAdmin

Per maggiori dettagli sulle autorizzazioni necessarie per concedere autonomamente i ruoli IAM, consulta Concessione, modifica e revoca dell'accesso alle risorse. Se non disponi di queste autorizzazioni, i ruoli devono essere concessi da un'altra persona della tua organizzazione.

Per concedere i ruoli:

Linux e macOS

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/resourcemanager.projectIamAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/serviceusage.serviceUsageAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/iam.serviceAccountCreator"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:ACCOUNT" \
    --role="roles/iam.serviceAccountKeyAdmin"

Windows

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/resourcemanager.projectIamAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/serviceusage.serviceUsageAdmin"

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/iam.serviceAccountCreator"

gcloud projects add-iam-policy-binding PROJECT_ID ^
    --member="user:ACCOUNT" ^
    --role="roles/iam.serviceAccountKeyAdmin"

Sostituisci quanto segue:

  • PROJECT_ID: l'ID del tuo progetto Google Cloud
  • ACCOUNT: l'indirizzo email di identificazione del tuo account Google Account

Configurare gli account di servizio

Il tuo progetto Google Cloud deve avere quattro account di servizio per Google Distributed Cloud. In questo esercizio, due di questi account di servizio vengono generati automaticamente. ma devi creare gli altri due servizi manualmente:

  • Connetti e registra l'account di servizio (generato automaticamente)
  • Account di servizio di monitoraggio dei log (generato automaticamente)
  • Account di servizio di audit logging (crea manualmente)
  • Account di servizio di accesso ai componenti (creazione manuale)

Account di servizio di audit logging

  1. Nel tuo progetto Google Cloud, crea un account di servizio Google Distributed Cloud può utilizzare per inviare audit log Kubernetes dal tuo cluster in Cloud Audit Logs. Questa operazione è chiamata log di controllo dell'account di servizio.

    gcloud iam service-accounts create audit-logging-sa \
    --display-name "Audit Logging Service Account" \
    --project PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.

  2. Ottieni l'indirizzo email dell'account di servizio di audit logging appena creato:

    gcloud iam service-accounts list \
    --project PROJECT_ID

  3. Crea una chiave JSON per il tuo account di servizio di audit logging:

    gcloud iam service-accounts keys create audit-logging-key.json \
    --iam-account SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING

    Sostituisci SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING con dell'account di servizio degli audit log.

    Non è necessario concedere nessun ruolo all'account di servizio di audit logging.

Account di servizio di accesso ai componenti

  1. Nel tuo progetto Google Cloud, crea un account di servizio Google Distributed Cloud può scaricare il codice del componente del cluster sul tuo da Container Registry. Questa azione è denominata accesso ai componenti dell'account di servizio.

    gcloud iam service-accounts create component-access-sa \
    --display-name "Component Access Service Account" \
    --project PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.

  2. Recupera l'indirizzo email dell'account di servizio di accesso ai componenti appena creato:

    gcloud iam service-accounts list \
    --project PROJECT_ID

  3. Crea una chiave JSON per il tuo account di servizio di accesso ai componenti:

    gcloud iam service-accounts keys create component-access-key.json \
   --iam-account SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS

    Sostituisci SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS con L'indirizzo email dell'account di servizio di accesso ai componenti.

  4. Aggiungi quanto segue Ruoli IAM al tuo account di servizio di accesso ai componenti:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --role "roles/serviceusage.serviceUsageViewer"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --role "roles/iam.roleViewer"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SERVICE_ACCOUNT_EMAIL_COMPONENT_ACCESS" \
    --role "roles/iam.serviceAccountViewer"

Abilita le API di Google

  1. Abilita le seguenti API di Google nel tuo progetto Google Cloud. Ciò consente puoi utilizzare tutti i servizi Google Cloud necessari a Google Distributed Cloud in del progetto.

    gcloud services enable --project PROJECT_ID \
    anthos.googleapis.com \
    anthosgke.googleapis.com \
    anthosaudit.googleapis.com \
    cloudresourcemanager.googleapis.com \
    connectgateway.googleapis.com \
    container.googleapis.com \
    gkeconnect.googleapis.com \
    gkehub.googleapis.com \
    gkeonprem.googleapis.com \
    kubernetesmetadata.googleapis.com \
    serviceusage.googleapis.com \
    stackdriver.googleapis.com \
    opsconfigmonitoring.googleapis.com \
    monitoring.googleapis.com \
    logging.googleapis.com \
    iam.googleapis.com \
    storage.googleapis.com

  2. Se è la prima volta che abiliti l'API GKE On-Prem (gkeonprem.googleapis.com) nel tuo progetto, inizializzare l'API. Puoi farlo chiamando un comando gcloud CLI che mostra le versioni che puoi utilizzare per creare un cluster utente:

    gcloud container vmware clusters query-version-config \
    --project=PROJECT_ID \
    --location="us-central1"

    Passaggi successivi

Crea cluster di base