Pianificare un'installazione di base sull'hardware

Il software Distributed Cloud consente solo di creare una piccola installazione proof of concept dei cluster GKE sul tuo hardware bare metal. In questa prima parte di un tutorial in due parti, configurerai un ambiente hardware minimo e pianificherai i tuoi indirizzi IP. Nella seconda parte, Crea cluster di base, crei un cluster di amministrazione e un cluster utente.

Questo documento è rivolto ad amministratori, architetti e operatori che configurano, monitorano e gestiscono il ciclo di vita dell'infrastruttura. Per scoprire di più sui ruoli e sulle attività comuni, consulta Ruoli e attività comuni degli utenti GKE.

Questa infrastruttura minima non è destinata ai workload di produzione. Per le installazioni di produzione, consulta Scegli un modello di deployment.

Nota: Il software Distributed Cloud solo per bare metal era precedentemente noto come Google Distributed Cloud Virtual, che a sua volta era precedentemente noto come Anthos clusters on bare metal.

Prima di iniziare

1. Leggi Informazioni su Google Distributed Cloud.
2. Acquisisci familiarità con alcuni concetti di base di Google Cloud , tra cui progetti, autorizzazioni IAM e service account.

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

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
   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

4. Verify that billing is enabled for your Google Cloud project.

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

Panoramica della procedura

Per configurare un'infrastruttura minima, devi completare i seguenti passaggi:

1. Configura la workstation di amministrazione. Configura 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 control plane del cluster utente e un nodo worker del cluster utente.

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

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

1. Configura la workstation di amministrazione

La workstation di amministrazione ospita strumenti e file di configurazione per la creazione e l'utilizzo dei cluster.

Requisiti hardware

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

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

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

Requisiti del sistema operativo

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

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

Configura il sistema operativo e il software

Sulla workstation di amministrazione, installi e configuri quanto segue:

• Configura Ubuntu

• Installa gcloud CLI

• Installa kubectl

• Installa bmctl

Configura il sistema operativo

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

1. Disattiva Uncomplicated Firewall (UFW) e verifica lo stato:

   sudo ufw disable
   sudo ufw status
   

2. Rimuovi eventuali versioni precedenti di Docker, aggiorna il gestore di pacchetti e installa l'ultima versione 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 che sia in esecuzione la versione 19.03 o successive di Docker:

   sudo docker version
   

   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. Attiva le modifiche al gruppo:

   newgrp docker
   

7. Verifica che l'orologio di sistema sia sincronizzato:

   timedatectl
   

   L'output di timedatectl contiene il seguente stato:

   System clock synchronized: yes
   

Installa Google Cloud CLI

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

Esegui questi passaggi sulla workstation di amministrazione per configurare gcloud CLI:

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

   gcloud auth login
   

2. Imposta la proprietà project di gcloud CLI:

   gcloud config set project PROJECT_ID
   

   Sostituisci PROJECT_ID con l'ID del tuo progettoGoogle 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]
   

Installa kubectl

Per installare kubectl:

1. Esegui questo comando sulla workstation di amministrazione:

   gcloud components install kubectl
   

Installa bmctl

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

Installa bmctl sulla tua 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 l'ultima versione del file binario bmctl e renderlo eseguibile:

   gcloud storage cp gs://anthos-baremetal-release/bmctl/1.36.200-gke.118/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 avere accesso 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 richieste di autorizzazione, creare service account, gestire il logging e il monitoraggio e altro ancora. Non puoi creare cluster senza l'accesso aGoogle 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 nodo del cluster.
• Accesso al VIP del control plane.
• Accesso SSH senza password a tutte le macchine dei nodi del cluster come root o come utente con privilegi sudo senza password.

La sezione seguente contiene le istruzioni per configurare SSH sulla workstation di amministrazione e sulle macchine dei nodi.

2. Configura le macchine dei nodi del cluster

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

• Una macchina per un cluster di amministrazione con un nodo del control plane.

• Due macchine per un cluster utente con un nodo del control plane e un nodo worker.

Requisiti hardware

Ogni macchina nodo deve soddisfare i seguenti requisiti hardware:

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

Requisiti del sistema operativo

Ogni macchina nodo deve eseguire una versione supportata di Ubuntu.

Configura Ubuntu

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

Configura l'accesso SSH ai nodi

La workstation di amministrazione deve avere accesso SSH senza password a tutte le macchine dei nodi del 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 Imposta un utente di accesso.

Di seguito sono riportati i passaggi di alto livello per configurare SSH per Google Distributed Cloud:

1. Installa e configura SSH su tutte le macchine.

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

3. Disattiva l'autenticazione tramite password sulle macchine nodo.

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

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 sulle 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 tramite password SSH 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 è abilitato temporaneamente 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. Nella 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 abilitare l'autenticazione tramite password.

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 dei nodi

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

Verifica 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

Quando installi i cluster, è importante pianificare gli indirizzi IP, anche per assicurarti di non creare conflitti di indirizzamento. Potresti aver bisogno dell'aiuto dell'amministratore di rete per trovare gli indirizzi adatti, anche per questa semplice installazione. Senza contare i CIDR di pod e servizi, sono necessari almeno 15 indirizzi IP univoci per un'installazione minima di cluster di amministrazione e cluster utente.

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

• Nodi del cluster: è necessario un indirizzo IP per ogni macchina nodo
• Indirizzi IP virtuali (VIP): sono necessari VIP per l'accesso ai server API Kubernetes, al proxy in entrata e ai servizi di tipo LoadBalancer
• Pod e servizi: sono necessari intervalli di indirizzi CIDR per ospitare ogni pod e servizio in esecuzione sui cluster

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

Per questa installazione di piccole dimensioni, 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 indirizzati a un determinato dominio di livello 2. Supponiamo inoltre che l'amministratore di rete ti dica che puoi utilizzare 172.16.20.10 - 172.16.20.12 per gli indirizzi delle macchine nodo 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. Tuttavia, devi utilizzare indirizzi IP disponibili nella tua rete. Se installi Google Distributed Cloud su una rete di casa, probabilmente dovrai modificare gli indirizzi delle 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)

Esempio di indirizzi IP dei nodi del cluster

La tabella seguente fornisce un esempio di come gli indirizzi IP potrebbero essere utilizzati per i nodi del cluster:

Macchina	Descrizione	Indirizzo IP
Nodo del control plane del cluster di amministrazione	Macchina fisica che funge da nodo del control plane per il cluster di amministrazione	172.16.20.10
Nodo del control plane del cluster utente	Macchina fisica che funge da nodo del control plane per il cluster utente	172.16.20.11
Nodo worker del cluster utente	Macchina fisica che esegue i workload degli utenti	172.16.20.12

Esempi di indirizzi IP virtuali (VIP)

La tabella seguente mostra un esempio di come puoi specificare i VIP per i tuoi cluster:

VIP	Descrizione	Indirizzo IP
Indirizzo VIP del control plane del cluster di amministrazione	Indirizzo VIP del control plane del cluster di amministrazione (server API Kubernetes del cluster di amministrazione)	172.16.20.13
Indirizzo VIP del control plane del cluster utente	Indirizzo VIP del control plane 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 necessità 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 integrato predefinito.	172.16.20.15 - 172.16.20.24

Indirizzi IP per pod e servizi

Oltre agli indirizzi IP specificati per i nodi del cluster e i VIP, devi specificare gli indirizzi per i pod e i servizi. 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. Utilizza gli indirizzi IP nello spazio di indirizzi privato, come descritto in RFC 1918. Questi indirizzi vengono specificati nell'ambito della configurazione del cluster, come illustrato nella parte successiva di questa guida.

Nell'ambito della pianificazione degli IP, decidi quali intervalli CIDR vuoi utilizzare per pod e servizi. A meno che tu non abbia un motivo per fare diversamente, 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, modalità isola.

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

• In genere, in un cluster sono necessari più pod che servizi, quindi probabilmente vorrai un intervallo CIDR dei pod più ampio dell'intervallo CIDR dei servizi. 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 la sovrapposizione

Per evitare sovrapposizioni 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 a indirizzi esterni al cluster che vuoi raggiungere dall'interno del cluster.

Ad esempio, supponiamo che l'intervallo di servizi sia 10.96.232.0/24 e 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 interno al cluster e non può raggiungere 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 DNS o dei server NTP

4. Esamina le risorse Google Cloud richieste

Prima di poter creare cluster, Google Distributed Cloud richiede l'abilitazione di un insieme specifico di API di Google nel progetto Google Cloud associato. Per utilizzare le API di Google, Google Distributed Cloud richiede service account configurati con ruoli IAM specifici nel progetto Google Cloud associato.

La procedura per la creazione di cluster nella parte successiva di questa guida, Crea cluster di base, abilita le API e crea automaticamente i service account.

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 tabella seguente descrive i service account creati automaticamente:

Service account	Finalità	Ruoli
anthos-baremetal-gcr	Google Distributed Cloud utilizza questo account di servizio per scaricare immagini container da Artifact Registry.	Nessuno
anthos-baremetal-connect	Connect Agent utilizza questo account di servizio per mantenere una connessione tra il cluster e Google Cloud. In questo modo, puoi accedere al cluster e alle funzionalità di Workload Manager, 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 in 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.	roles/logging.logWriter roles/monitoring.metricWriter roles/stackdriver.resourceMetadata.writer roles/opsconfigmonitoring.resourceMetadata.writer roles/monitoring.dashboardEditor

Passaggi successivi

Crea cluster di base