Pianifica l'installazione

Questa pagina è la prima parte di una guida che illustra l'utilizzo del software Google Distributed Cloud (precedentemente noto come Google Distributed Cloud Virtual) per creare una piccola installazione proof of concept dei cluster GKE sul tuo hardware bare metal. Questo documento illustra come configurare un ambiente hardware minimo e pianificare gli indirizzi IP. Il follow-up Creare cluster di base mostra come creare 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 ulteriori informazioni sulle installazioni di produzione, consulta Scegliere un modello di deployment.

Prima di iniziare

1. Leggi Informazioni su Google Distributed Cloud.
2. Acquisisci familiarità con alcuni concetti di base di Google Cloud, tra cui i progetti, le autorizzazioni IAM e gli account di servizio.
3. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

5. Make sure that billing is enabled for your Google Cloud project.

6. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

7. Make sure that billing is enabled for your Google Cloud project.

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

Panoramica della procedura

La configurazione minima dell'infrastruttura è composta dai seguenti passaggi principali:

1. Configura la tua workstation di amministrazione. e configurare una workstation di amministrazione Linux per le attività di gestione on-premise. Potrebbe essere una macchina esistente o dedicata che può gestire più cluster.

2. Configura le macchine dei nodi cluster. Configura almeno tre macchine per i nodi: un nodo del cluster di amministrazione, un nodo del piano di controllo del cluster utente e un nodo worker del cluster utente.

3. Pianifica il networking. Pianifica gli indirizzi IP per le macchine nodo, gli indirizzi IP virtuali (VIP) e gli intervalli CIDR servizi e pod.

4. Esamina le risorse Google Cloud richieste. Per creare cluster, il tuo progetto Google Cloud richiede API e account di servizio Google specifici.

1. Configura la workstation di amministrazione

La workstation di amministrazione ospita gli strumenti e i file di configurazione per creare e utilizzare i cluster.

Requisiti hardware

La workstation di amministrazione richiede una potenza di calcolo, memoria e spazio di archiviazione significativi per eseguire gli strumenti e archiviare le risorse associate alla creazione e alla gestione del cluster.

Assicurati che la workstation di amministrazione soddisfi i seguenti requisiti hardware:

• Almeno 2 core CPU
• Almeno 4 GiB di RAM
• Almeno 128 GiB di spazio di archiviazione

Configura il sistema operativo e il software

Nella workstation di amministrazione, installi e configuri quanto segue:

• Configura Ubuntu

• Installa l'interfaccia a riga di comando gcloud

• Installa kubectl

• Installa bmctl

Configura il sistema operativo

Per eseguire bmctl e creare un cluster, la workstation di amministrazione ha gli stessi requisiti del sistema operativo dei nodi. Ogni macchina deve eseguire una versione supportata di Ubuntu, ad esempio Ubuntu 20.04.

Nota: sebbene Google Distributed Cloud sia supportato su più sistemi operativi Linux, in questo esempio minimo viene utilizzato Ubuntu per semplicità. Eventuali passaggi o comportamenti specifici di Ubuntu sono evidenziati nei documenti.

Esegui i comandi seguenti per aggiornare le impostazioni del firewall, installare e configurare Docker e assicurarti che ogni macchina utilizzi la sincronizzazione dell'ora:

1. Disabilita Uncomplicated Firewall (UFW) e verificane lo stato:

   sudo ufw disable
   sudo ufw status
   

2. Rimuovi qualsiasi versione precedente di Docker, aggiorna il gestore di pacchetti e installa la versione più recente di Docker:

   sudo apt-get remove docker docker-engine docker.io containerd runc
   sudo apt-get update
   sudo apt-get install \
     apt-transport-https \
     ca-certificates \
     curl \
     gnupg-agent \
     software-properties-common \
     docker.io
   

3. Verifica di eseguire la versione 19.03 o successive di Docker:

   sudo docker version
   

   Entrambe le versioni client e server devono essere 19.03 o successive, come mostrato nella seguente risposta di esempio:

   Client:
    Version:           20.10.21
    API version:       1.41
    Go version:        go1.18.1
    ...
   
   Server:
    Engine:
     Version:          20.10.21
     API version:      1.41 (minimum version 1.12)
     Go version:       go1.18.1
     ...
   

4. Crea il gruppo docker.

   sudo groupadd docker
   

5. Aggiungiti al gruppo Docker:

   sudo usermod -aG docker $USER
   

6. Esegui questo comando per attivare le modifiche ai gruppi:

   newgrp docker
   

7. Esegui questo comando per verificare che l'orologio di sistema sia sincronizzato:

   timedatectl
   

   L'output di timedatectl dovrebbe contenere il seguente stato:

   System clock synchronized: yes
   

Installa Google Cloud CLI

Per installare Google Cloud CLI su Ubuntu, segui le istruzioni di questa guida all'installazione.

Esegui i seguenti passaggi sulla workstation di amministrazione per configurare gcloud CLI:

1. Accedi per impostare la proprietà account gcloud CLI:

   gcloud auth login
   

2. Imposta la proprietà project dell'interfaccia a riga di comando gcloud:

   gcloud config set project PROJECT_ID
   

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

3. Verifica che le proprietà account e project siano impostate correttamente:

   gcloud config list
   

   L'output mostra i valori delle proprietà account e project. Ad esempio:

   [core]
   account = [e-mail]
   disable_usage_reporting = False
   project = my-project-1234
   Your active configuration is: [default]
   

Installazione di kubectl

Per installare kubectl:

1. Esegui il comando seguente sulla workstation di amministrazione:

   gcloud components install kubectl
   

Installazione di bmctl

bmctl è lo strumento a riga di comando proprietario per Google Distributed Cloud che puoi utilizzare per la creazione e la gestione dei cluster.

Per installare bmctl sulla workstation di amministrazione:

1. Crea una directory baremetal e aggiungila al tuo percorso. Se ti trovi nella tua home directory, i comandi sono:

   mkdir baremetal
   export PATH="$HOME/baremetal:$PATH"
   

2. Esegui questo comando per scaricare la versione più recente del file binario bmctl e renderlo eseguibile:

   gsutil cp gs://anthos-baremetal-release/bmctl/1.29.100-gke.251/linux-amd64/bmctl .
   chmod +x ./bmctl
   

3. Verifica che bmctl sia installato ed eseguibile:

   bmctl version
   

   La risposta dovrebbe essere simile alla seguente:

   [2023-05-12 17:36:16+0000] bmctl version: 1.14.2-gke.11, git commit: 4ff1347446a93925a079000b50437d4ecebcdf3a, build date: Mon Feb 27 14:07:30 PST 2023
   

Connettività

La workstation di amministrazione deve accedere a Google Cloud e a tutti i nodi del cluster.

Accesso a Google Cloud

La workstation di amministrazione accede a Google Cloud per scaricare e installare strumenti e immagini, elaborare le richieste di autorizzazione, creare account di servizio, gestire il logging e il monitoraggio e altro ancora. Non puoi creare cluster senza accesso a Google Cloud.

Accesso dalla workstation di amministrazione

Per creare e gestire i cluster dalla workstation di amministrazione, devi disporre del seguente accesso alle macchine nodo:

• Connettività di livello 3 a tutte le macchine con nodi cluster.
• Accesso al VIP del piano di controllo.
• Accesso SSH senza password a tutte le macchine dei nodi cluster come root o come utente con privilegi sudo senza password.

La seguente sezione contiene le istruzioni per la configurazione di SSH sulla workstation di amministrazione e sulle macchine nodo.

2. Configura le macchine dei nodi cluster

Per l'installazione minima di un singolo cluster di amministrazione non ad alta disponibilità e di un singolo cluster utente non ad alta disponibilità, sono necessarie tre macchine:

• Una macchina per un cluster di amministrazione con un nodo del piano di controllo.

• Due macchine per un cluster utente con un nodo del piano di controllo e un nodo worker.

Requisiti hardware

Ogni macchina nodo deve soddisfare i seguenti requisiti hardware:

• Almeno 2 core CPU
• Almeno 4 GiB di RAM
• Almeno 128 GiB di spazio di archiviazione

Configura Ubuntu

Configura Ubuntu su ciascun nodo seguendo le stesse istruzioni utilizzate per la workstation di amministrazione.

Configura l'accesso SSH ai nodi

La workstation di amministrazione ha bisogno dell'accesso SSH senza password a tutte le macchine dei nodi cluster. Puoi configurare SSH come root o con un utente che dispone di privilegi sudo senza password.

Nota: le seguenti istruzioni configurano l'accesso SSH senza password ai nodi per l'utente root. In alternativa, puoi utilizzare un utente non root con privilegi sudo senza password. Questo utente non root deve essere specificato nel file di configurazione del cluster (nodeAccess.loginUser). Per ulteriori informazioni, consulta Impostare un utente di accesso.

Di seguito sono riportati i passaggi generali per la configurazione di SSH per Google Distributed Cloud:

1. Installare e configurare SSH su tutte le macchine

2. Crea chiavi SSH e copia la chiave pubblica su ogni macchina nodo

3. Disabilita l'autenticazione tramite password sulle macchine nodo

4. Verifica l'accesso SSH tra la workstation di amministrazione e le macchine nodo

Installa e configura SSH su tutte le macchine

Google Distributed Cloud richiede la comunicazione SSH senza password tra la workstation di amministrazione e i nodi del cluster. Esegui i seguenti passaggi sulla workstation di amministrazione e su ogni macchina nodo.

Per configurare SSH su macchine che eseguono Ubuntu:

1. Se non hai già un server SSH in esecuzione, installane uno ora:

   sudo apt update
   sudo apt install openssh-server
   sudo systemctl status ssh
   

2. Attiva l'autenticazione della password SSH di root rimuovendo il commento o aggiungendo le righe PermitRootLogin e PasswordAuthentication nel file /etc/ssh/sshd_config e impostando i valori su yes:

   Nota: PasswordAuthentication è temporaneamente abilitato per facilitare la configurazione di SSH. PasswordAuthentication è disabilitato sulle macchine nodo in una sezione successiva.

   # Authentication:
   
   #LoginGraceTime 2m
   PermitRootLogin yes
   #StrictModes yes
   #MaxAuthTries 6
   #MaxSessions 10
   ...
   PasswordAuthentication yes
   

3. Imposta una password root:

   sudo passwd root
   

4. Per applicare le modifiche alla configurazione SSH, riavvia il servizio SSH:

   sudo systemctl restart ssh.service
   

5. Riavvia il computer.

6. Verifica che SSH funzioni stabilendo una connessione SSH da un'altra macchina.

crea chiavi SSH e copia la chiave pubblica su ogni macchina nodo

Per connessioni sicure e senza password tra la workstation di amministrazione e i nodi, crea una chiave SSH sulla workstation di amministrazione e condividi la chiave pubblica con i nodi.

1. Sulla workstation di amministrazione, genera una coppia di chiavi privata e pubblica. Non impostare una passphrase per le chiavi:

   ssh-keygen -t rsa
   

2. Sulla workstation di amministrazione, copia la chiave pubblica generata in ciascuna delle macchine nodo:

   ssh-copy-id -i PUBLIC_KEY root@CLUSTER_NODE_IP
   

   Sostituisci quanto segue:

   • PUBLIC_KEY: il percorso del file contenente la chiave pubblica SSH. Per impostazione predefinita, il percorso è /home/USERNAME/.ssh/id_rsa.pub
   • CLUSTER_NODE_IP: l'indirizzo IP della macchina nodo

Disabilita l'autenticazione tramite password sulle macchine nodo

A questo punto, non è più necessario che l'autenticazione della password sia attivata.

Per ogni macchina nodo:

1. Apri /etc/ssh/sshd_config, imposta PasswordAuthentication su no e salva il file.

2. Riavvia il servizio SSH.

   sudo systemctl restart ssh.service
   

Verifica l'accesso SSH tra la workstation di amministrazione e le macchine nodo

Se SSH è configurato correttamente, puoi stabilire una connessione SSH alla macchina nodo dalla workstation di amministrazione (come root) senza password.

Per verificare che l'autenticazione a chiave pubblica funzioni tra la workstation di amministrazione e i nodi del cluster:

1. Sulla workstation di amministrazione, esegui questo comando per ogni macchina nodo:

   ssh -o IdentitiesOnly=yes -i PRIVATE_KEY root@CLUSTER_NODE_IP
   

   Sostituisci quanto segue:

   • PRIVATE_KEY: il percorso del file contenente la chiave privata SSH. Per impostazione predefinita, il percorso è /home/USERNAME/.ssh/id_rsa
   • CLUSTER_NODE_IP: l'indirizzo IP della macchina nodo

3. Pianifica il networking

Durante l'installazione dei cluster, è importante pianificare gli indirizzi IP, e assicurarsi di non creare conflitti di indirizzi. Potrebbe essere necessario rivolgersi all'amministratore di rete per trovare gli indirizzi adatti, anche per questa semplice installazione. Senza contare i CIDR dei pod e dei servizi, sono necessari almeno 15 indirizzi IP univoci per un'installazione minima del cluster di amministrazione e del cluster utente.

Pianifica e specifica gli indirizzi IP per i seguenti componenti del cluster:

• Nodi del cluster: hai bisogno di un indirizzo IP per ogni macchina nodo
• Indirizzi IP virtuali (VIP): sono necessari VIP per accedere ai server API Kubernetes, al proxy in entrata e ai servizi di tipo LoadBalancer
• Pod e servizi: hai bisogno di intervalli di indirizzi CIDR per contenere ogni pod e servizio in esecuzione sui tuoi cluster

Il resto della sezione contiene esempi illustrativi di valori che funzionano per questa installazione in una rete ipotetica. I valori saranno diversi.

Per questa piccola installazione, inserisci la workstation di amministrazione, il nodo del cluster di amministrazione e i nodi del cluster utente nello stesso dominio di livello 2. Ad esempio, supponiamo che tutti gli indirizzi IP nell'intervallo 172.16.20.0/24 vengano instradati a un particolare dominio di livello 2. Supponi inoltre che l'amministratore di rete abbia indicato che puoi utilizzare 172.16.20.10 - 172.16.20.12 per gli indirizzi delle macchine dei nodi e 172.16.0.13 - 172.16.20.24 per i VIP.

Importante: gli esempi di indirizzi IP utilizzati in questo documento soddisfano i requisiti per Google Distributed Cloud. Devi però usare gli indirizzi IP disponibili nella tua rete. Se stai installando Google Distributed Cloud su una rete di casa, probabilmente dovrai regolare gli indirizzi per le macchine nodo e i VIP del cluster.

Il seguente diagramma illustra un dominio di livello 2 con una workstation di amministrazione, un cluster di amministrazione e un cluster utente:

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

Indirizzi IP dei nodi cluster di esempio

La tabella seguente fornisce un esempio di come è possibile utilizzare gli indirizzi IP per i nodi cluster:

Computer	Descrizione	Indirizzo IP
Nodo del piano di controllo del cluster di amministrazione	Macchina fisica che funge da nodo del piano di controllo per il cluster di amministrazione	172/16/20/10
Nodo del piano di controllo del cluster utente	Macchina fisica che funge da nodo del piano di controllo per il cluster utente	172/16/20/11
Nodo worker del cluster utente	Macchina fisica che esegue i carichi di lavoro degli utenti	172/16/20/12

Esempi di indirizzi IP virtuali (VIP)

La tabella seguente fornisce un esempio di come è possibile specificare i VIP per i cluster:

VIP	Descrizione	Indirizzo IP
Indirizzo VIP del piano di controllo del cluster di amministrazione	Indirizzo VIP del piano di controllo del cluster di amministrazione (server API Kubernetes del cluster di amministrazione)	172/16/20/13
Indirizzo VIP del piano di controllo del cluster utente	Indirizzo VIP del piano di controllo del cluster utente (server API Kubernetes del cluster utente)	172/16/20/14
Indirizzo VIP in entrata	VIP in entrata (incluso nell'intervallo di pool di indirizzi MetalLB)	172/16/20/15
Indirizzi VIP del servizio	Dieci indirizzi da utilizzare come indirizzi IP esterni per i servizi di tipo LoadBalancer. Gli indirizzi vengono allocati in base alle esigenze sui nodi del cluster utente. Questo intervallo include il VIP in entrata. Questa sovrapposizione di indirizzi IP è un requisito per MetalLB, il bilanciatore del carico in bundle predefinito.	172.16.20.15 - 172.16.20.24

Indirizzi IP per pod e servizi

Oltre agli indirizzi IP che hai specificato per nodi cluster e VIP, devi specificare anche gli indirizzi per pod e servizi. Puoi specificare 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. Utilizza gli indirizzi IP nello spazio degli indirizzi privati, come descritto in RFC 1918. Questi indirizzi vengono specificati come parte della configurazione del cluster, come illustrato 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 abbia un motivo per farlo, utilizza i seguenti intervalli suggeriti:

Finalità	Intervallo CIDR precompilato
Pod del cluster di amministrazione	192.168.0.0/16
Servizi del cluster di amministrazione	10.96.0.0/20
Pod del cluster utente	192.168.0.0/16
Servizi del cluster utente	10.96.0.0/20

Gli intervalli suggeriti illustrano questi punti:

• L'intervallo CIDR dei pod può essere lo stesso per più cluster nel modello di rete predefinito in modalità Isola.

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

• In genere hai bisogno di più pod rispetto ai servizi in un cluster, quindi probabilmente vorrai un intervallo CIDR pod più ampio dell'intervallo CIDR servizio. Ad esempio, l'intervallo di pod suggerito per un cluster utente ha 2^(32-16) = 2¹⁶ indirizzi, ma l'intervallo di servizi suggerito per un cluster utente ha solo 2^(32-20) = 2¹² indirizzi.

Evita sovrapposizioni

Per evitare la sovrapposizione con gli indirizzi IP raggiungibili sulla tua rete, potresti dover utilizzare intervalli CIDR diversi dai suggerimenti precedenti. Gli intervalli di servizi e pod non devono sovrapporsi ad alcun indirizzo esterno al cluster che vuoi raggiungere dall'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 intervalli viene considerato nel cluster e non può raggiungere nessuna 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 dei bilanciatori del carico

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

• Indirizzo IP dei server DNS o NTP

4. Esamina le risorse Google Cloud richieste

Prima di poter creare cluster, Google Distributed Cloud richiede che sia abilitato un set specifico di API di Google nel progetto Google Cloud associato. Per utilizzare le API di Google, Google Distributed Cloud richiede account di servizio configurati con ruoli IAM specifici nel progetto Google Cloud associato.

Il processo per la creazione di cluster nella parte successiva di questa guida, Creare cluster di base, abilita le API e crea account di servizio automaticamente.

Ecco le API di Google che vengono abilitate automaticamente:

• anthos.googleapis.com
• anthosaudit.googleapis.com
• anthosgke.googleapis.com
• cloudresourcemanager.googleapis.com
• connectgateway.googleapis.com
• container.googleapis.com
• gkeconnect.googleapis.com
• gkehub.googleapis.com
• gkeonprem.googleapis.com
• iam.googleapis.com
• logging.googleapis.com
• monitoring.googleapis.com
• opsconfigmonitoring.googleapis.com
• serviceusage.googleapis.com
• stackdriver.googleapis.com
• storage.googleapis.com

La seguente tabella descrive gli account di servizio creati automaticamente:

Service account	Finalità	Ruoli
anthos-baremetal-gcr	Google Distributed Cloud utilizza questo account di servizio per scaricare immagini container da Container Registry.	Nessuna
anthos-baremetal-connect	L'agente Connect utilizza questo account di servizio per mantenere una connessione tra il cluster e Google Cloud. Ciò consente l'accesso al cluster e alle funzionalità di gestione dei carichi di lavoro, tra cui la console Google Cloud e il gateway di connessione per interagire con il cluster.	roles/gkehub.connect
anthos-baremetal-register	L'agente Connect utilizza questo account di servizio per registrare i cluster con un parco risorse.	roles/gkehub.admin
anthos-baremetal-cloud-ops	L'agente Stackdriver utilizza questo account di servizio per esportare log e metriche dai cluster a Cloud Logging e Cloud Monitoring.	ruoli/logging.logWriter roles/monitoring.metricWriter roles/stackdriver.resourceMetadata.writer roles/opsconfigmonitoring.resourceMetadata.writer roles/monitoring.dashboardEditor

Passaggi successivi

Crea cluster di base