Configura un'infrastruttura minima

Questa è la prima parte di una guida che illustra la procedura di una piccola proof of concept di Google Distributed Cloud (solo software) per VMware con un singolo cluster utente. Questa pagina è rivolta ad amministratori, architetti e operatori che configurano, monitorano e gestiscono l'infrastruttura tecnica. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.

Questo documento mostra come configurare ambienti vSphere e Google Cloud minimi per questa installazione e pianificare gli indirizzi IP, mentre l'articolo successivo Creare cluster di base mostra come creare una workstation di amministrazione, un cluster di amministrazione e un cluster utente.

L'infrastruttura configurata utilizzando questa guida potrebbe non essere adatta alle tue effettive esigenze di produzione e ai tuoi casi d'uso. Per ulteriori informazioni 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 di questa configurazione:

  1. Configura l'ambiente. Assicurati di soddisfare i requisiti delle risorse. Forniamo una configurazione di esempio per un host ESXi e un datastore vSphere che soddisfano i requisiti per questa installazione.
  2. Configura gli 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 di fornire indirizzi IP per tutti i nodi, oltre agli indirizzi IP virtuali (VIP) per l'accesso di amministratori e utenti al deployment. Per questa configurazione utilizzerai indirizzi IP statici per i nodi del cluster. Forniamo degli esempi, ma ti consigliamo di rivolgerti all'amministratore di rete per scegliere gli indirizzi adatti alla tua rete.
  4. Configura le regole del firewall e del proxy
  5. Configura le risorse Google Cloud, tra cui un progetto Google Cloud da utilizzare per configurare e gestire Google Distributed Cloud, e un account di servizio con le autorizzazioni necessarie per accedere e scaricare il software dei componenti di Google Distributed Cloud.

1. Configura l'ambiente

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

  1. Assicurati che l'host abbia le seguenti capacità minime di CPU, RAM e spazio di archiviazione:

    • 8 CPU fisiche a 2,7 GHz con hyperthreading abilitato
    • 80 gibibyte (GiB) di RAM
    • 470 GiB di spazio di archiviazione
  2. Assicurati di aver installato ESXi versione 7.0u2 o successive.

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

Esempio di host e data store

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

  • Configurazione dell'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 del processore: 2
    • Versione ESXi: 7.0u2 o successive
    • Versione di vCenter Server: 7.0u2 o successive
    • Hyperthreading: abilitato
  • Configurazione del datastore:

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

2. Configura gli oggetti vSphere

Configura i seguenti oggetti nell'ambiente vSphere:

Prendi nota dei nomi del data center, del cluster, del datastore e della rete vSphere, poiché 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 control plane, come i server API Kubernetes, e alle applicazioni in esecuzione sui cluster utente
  • Intervalli CIDR per la comunicazione tra pod e servizi

Per questo motivo, una parte importante della configurazione di Google Distributed Cloud è la pianificazione degli indirizzi IP, inclusa la verifica di non creare conflitti di indirizzi. Potresti aver bisogno dell'aiuto dell'amministratore di rete per trovare valori adatti da configurare, anche per questa semplice installazione. Nel resto di questa sezione forniamo esempi illustrativi di valori che funzionano per questa installazione in una rete ipotetica. I tuoi valori saranno diversi.

  • I cluster di questa installazione minima utilizzano il bilanciatore del carico bundled MetalLB. Questo bilanciatore del carico viene eseguito sui nodi del cluster, pertanto non sono necessarie VM aggiuntive per il bilanciamento del carico.

  • Google Distributed Cloud ti consente di scegliere tra 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 piccola installazione, ti consigliamo di posizionare la workstation di amministrazione, i nodi del cluster di amministrazione e i nodi del cluster utente nella stessa VLAN della rete vSphere. Ad esempio, supponiamo che tutti gli indirizzi IP nell'intervallo 172.16.20.0/24 vengano indirizzati a una determinata VLAN. Supponiamo inoltre che l'amministratore di rete ti dica che puoi utilizzare 172.16.20.49 - 172.16.20.69 per le VM e gli indirizzi IP virtuali (VIP).

Il seguente diagramma mostra una VLAN con una workstation di amministrazione, un cluster di amministrazione e un cluster utente. Tieni presente che i VIP non sono mostrati associati a nessun particolar nodo in un cluster. Questo perché il bilanciatore del carico MetalLB può scegliere il nodo che annuncia il VIP per un singolo servizio. Ad esempio, nel cluster utente, un nodo worker potrebbe annunciare 172.16.20.64 e un altro nodo 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)

Indirizzo IP di esempio: workstation di amministrazione

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

Indirizzi IP di esempio: nodi del cluster

La tabella seguente mostra un esempio di come è possibile utilizzare gli indirizzi IP per i nodi del cluster. Tieni presente che la tabella mostra gli indirizzi di due nodi aggiuntivi: admin-vm-6 e user-vm-5. I nodi aggiuntivi sono necessari durante gli upgrade, gli aggiornamenti e la riparazione automatica del cluster. Per saperne di più, consulta Gestire gli indirizzi IP dei nodi.

Nome host della 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

Indirizzi IP di esempio: VIP per il cluster di amministrazione

La tabella seguente mostra un esempio di come specificare un VIP del piano di controllo 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

Indirizzi IP di esempio: VIP per il cluster utente

La tabella seguente fornisce un esempio di come puoi specificare i VIP per il tuo cluster di utenti.

Tieni presente che il VIP per il server API Kubernetes del cluster utente e il VIP di ingresso 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.
Tieni presente che questo intervallo include l'IP virtuale di ingresso. 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 dei nodi del cluster e per accedere al deployment, devi anche specificare gli intervalli di indirizzi che possono essere utilizzati all'interno di ciascun cluster per il traffico all'interno del cluster.

A tale scopo, specifica un intervallo CIDR da utilizzare per gli indirizzi IP dei pod e un altro intervallo CIDR da utilizzare per gli indirizzi ClusterIP dei servizi Kubernetes. Questi vengono specificati nell'ambito della configurazione del cluster, come vedrai nella prossima parte di questa guida.

Nell'ambito della pianificazione IP, decidi quali intervalli CIDR vuoi utilizzare per i pod e i servizi. A meno che non abbia un motivo per farlo, utilizza gli intervalli predefiniti che seguono:

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 di cluster di utenti10.96.0.0/20

I valori predefiniti illustrano questi punti:

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

  • L'intervallo CIDR dei servizi di un cluster non deve sovrapporsi all'intervallo CIDR di servizi di nessun altro cluster.

  • In genere sono necessari più pod che servizi, quindi per un determinato cluster probabilmente vorrai un intervallo CIDR del pod più grande dell'intervallo CIDR del servizio. Ad esempio, l'intervallo di pod predefinito per un cluster utente ha 2^(32-16) = 2^16 indirizzi, ma l'intervallo di servizi predefinito per un cluster utente ha solo 2^(32-20) = 2^12 indirizzi.

Evitare la sovrapposizione

In alcuni casi potrebbe essere necessario utilizzare intervalli CIDR non predefiniti per evitare sovrapposizioni con gli indirizzi IP raggiungibili sulla rete. Gli intervalli di servizi e pod non devono sovrapporsi a nessun indirizzo esterno al cluster che vuoi raggiungere dall'interno del cluster.

Ad esempio, supponiamo che l'intervallo del servizio sia 10.96.232.0/24 e l'intervallo del pod sia 192.168.0.0/16. Qualsiasi traffico inviato da un pod a un indirizzo in uno di questi intervalli verrà considerato all'interno del cluster e non raggiungerà alcuna destinazione al di fuori del 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 del bilanciatore del carico

  • VIP utilizzati dai nodi del control plane e dai bilanciatori del carico

  • Indirizzo IP dei server vCenter, DNS e NTP

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

Ecco un motivo per cui consigliamo di utilizzare gli indirizzi RFC 1918. Supponiamo che l'intervallo del pod o del servizio contenga indirizzi IP esterni. Qualsiasi traffico inviato da un pod a uno di questi indirizzi esterni verrà trattato come traffico all'interno del 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 che contiene la workstation di amministrazione e i nodi del cluster. Ad esempio, supponiamo che la workstation di amministrazione, i nodi del cluster di amministrazione e i nodi del cluster utente si trovino tutti nella subnet 172.16.20.0/24. L'indirizzo del gateway predefinito per la subnet potrebbe essere 172.16.20.1.

4. Configura il firewall e il proxy

Configura il firewall e il proxy in modo da consentire il traffico necessario di Google Distributed Cloud, seguendo le regole di proxy e firewall. Per eseguire questa operazione, avrai bisogno degli indirizzi IP dei nodi del 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 del firewall pertinenti si applichino a tutti gli indirizzi IP di ciascun cluster.

5. Configurare 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 l'utilizzo dei progetti Google Cloud, puoi trovare molte altre informazioni nell'articolo Creare e gestire i progetti.

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

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

Configurare 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 lo hai creato tu), 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 assicurarvi che il vostro Account Google disponga delle autorizzazioni necessarie.

I seguenti ruoli IAM ti consentono di creare un account di servizio, assegnargli ruoli IAM, attivare le API e assicurarti che lo strumento gkeadm possa creare e gestire gli account di servizio per te nella seconda parte di questa configurazione:

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

Per informazioni dettagliate sulle autorizzazioni necessarie per concedere autonomamente i ruoli IAM, consulta Concessione, modifica e revoca dell'accesso alle risorse. Se non disponi di queste autorizzazioni, un altro utente della tua organizzazione deve concederti i ruoli.

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 che identifica il tuo Account Google

Configurare gli account di servizio

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

  • Account di servizio Connect-register (generato automaticamente)
  • Account di servizio di monitoraggio e logging (generato automaticamente)
  • Account di servizio per il logging di controllo (da creare manualmente)
  • Account di servizio di accesso ai componenti (da creare manualmente)

Account di servizio per l'audit logging

  1. Nel tuo progetto Google Cloud, crea un account di servizio che Google Distributed Cloud possa utilizzare per inviare gli audit log di Kubernetes dal tuo cluster a Cloud Audit Logs. Questo è il tuo account di servizio per i logging di controllo.

    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 per i log di controllo appena creato:

    gcloud iam service-accounts list \
        --project PROJECT_ID
    
  3. Crea una chiave JSON per l'account di servizio di registrazione degli audit:

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

    Sostituisci SERVICE_ACCOUNT_EMAIL_AUDIT_LOGGING con l'indirizzo email del tuo account di servizio di registrazione dei controlli.

    Non è necessario concedere alcun ruolo all'account di servizio per i log di controllo.

Account di servizio di accesso ai componenti

  1. Nel tuo progetto Google Cloud, crea un account di servizio che Google Distributed Cloud possa utilizzare per scaricare il codice dei componenti del cluster per tuo conto da Container Registry. Si tratta del tuo account di servizio di accesso ai componenti.

    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. Ottieni 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 l'account di servizio di accesso al componente:

    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 del tuo account di servizio di accesso ai componenti.

  4. Aggiungi i seguenti ruoli IAM all'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"
    

Attivare le API di Google

  1. Abilita le seguenti API Google nel tuo progetto Google Cloud. In questo modo, puoi utilizzare tutti i servizi Google Cloud necessari per Google Distributed Cloud nel tuo 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 attivi l'API GKE On-Prem (gkeonprem.googleapis.com) nel tuo progetto, devi inizializzarla. Per farlo, chiama un comando gcloud CLI che mostra le versioni disponibili che puoi utilizzare per creare un cluster di utenti:

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

    Passaggi successivi

Creare cluster di base