Pianifica un'installazione di base sull'hardware

Questa pagina è la prima parte di una guida che illustra l'utilizzo di Google Distributed Cloud (solo software) per bare metal (precedentemente noto come Google Distributed Cloud Virtual, precedentemente noto come cluster Anthos su bare metal) per creare una piccola installazione proof-of-concept di cluster GKE sull'hardware bare metal. Questo documento mostra come configurare un ambiente hardware minimo e pianificare gli indirizzi IP. L'articolo di approfondimento Crea cluster di base mostra come creare un cluster di amministrazione e un cluster utente.

Questa pagina è rivolta ad amministratori, architetti e operatori che configurano, monitorano e gestiscono il ciclo di vita dell'infrastruttura tecnologica sottostante. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti GKE.

L'infrastruttura che configuri utilizzando questa guida potrebbe non essere adatta alle tue esigenze e ai tuoi casi d'uso di produzione reali. Per ulteriori informazioni sulle installazioni di produzione, vedi Scegliere un modello di deployment.

Prima di iniziare

  1. Leggi l'articolo 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. 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.

    Go to project selector

  5. Verify 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.

    Go to project selector

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

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

    9. Panoramica della procedura

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

    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 del 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 tuo networking. Pianifica gli indirizzi IP per le macchine dei nodi, gli indirizzi IP virtuali (VIP) e gli intervalli CIDR di servizi e pod.

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

    1. Configurare la workstation amministrativa

    La workstation di amministrazione ospita strumenti e file di configurazione per creare e utilizzare i 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 workstation di amministrazione soddisfi i seguenti requisiti hardware:

    • Almeno 2 core 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 di sistema operativo (SO) dei nodi. Ogni macchina deve eseguire una versione supportata di Ubuntu.

    Configurare il sistema operativo e il software

    Sulla workstation di amministrazione, installa e configura quanto segue:

    • Configurare Ubuntu

    • Installa gcloud CLI

    • Installare kubectl

    • Installare bmctl

    Configurare il sistema operativo

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

    1. Disattiva Uncomplicated Firewall (UFW) e verifica il suo 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 di eseguire la versione 19.03 o successive di Docker:

      sudo docker version

      Le versioni del client e del 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 al gruppo:

      newgrp docker

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

      timedatectl

      L'output di timedatectl dovrebbe contenere lo stato seguente:

      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 i seguenti 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 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 = my-name@google.com
disable_usage_reporting = False
project = my-project-1234
Your active configuration is: [default]

    Installa kubectl

    Per installare kubectl:

    1. Esegui il comando seguente sulla workstation di amministrazione:

      gcloud components install kubectl

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

      gcloud storage cp gs://anthos-baremetal-release/bmctl/1.32.200-gke.104/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 amministrativa accede a Google Cloud per scaricare e installare strumenti e immagini, elaborare richieste di autorizzazione, creare account di servizio, gestire la registrazione e il monitoraggio e altro ancora. Non puoi creare cluster senza accedere a Google Cloud.

    Accesso dalla workstation di amministrazione

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

    • 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 amministrativa e sui nodi.

    2. Configura le macchine dei nodi del 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 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 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 con le stesse istruzioni utilizzate per la workstation amministrativa.

    Configurare l'accesso SSH ai nodi

    La workstation di amministrazione deve avere l'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.

    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. Disabilita l'autenticazione tramite password sulle macchine dei nodi

    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. I seguenti passaggi devono essere eseguiti sulla workstation amministrativa 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:

      # 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 amministrativa, genera una coppia di chiavi privata e pubblica. Non impostare una passphrase per le chiavi:

      ssh-keygen -t rsa

    2. Nella workstation amministrativa, copia la chiave pubblica generata su 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 del nodo
    Disabilitare l'autenticazione tramite password sulle macchine dei nodi

    A questo punto, non è più necessario attivare l'autenticazione con 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.

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

    1. Sulla workstation di amministrazione, esegui il seguente 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 del nodo

    3. Pianificare il networking

    Quando installi i cluster, è importante pianificare gli indirizzi IP, assicurandoti di non creare conflitti di indirizzamento. Potresti aver bisogno dell'aiuto dell'amministratore di rete per trovare indirizzi adatti, anche per questa semplice installazione. Senza contare i CIDR di pod e servizi, hai bisogno di 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: devi avere un indirizzo IP per ogni macchina nodo
    • Indirizzi IP virtuali (VIP): hai bisogno di 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 ospitare ogni pod e servizio in esecuzione sui tuoi 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 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 indirizzati a un particolare 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 dei nodi e 172.16.0.13 - 172.16.20.24 per gli IP virtuali.

    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.
    Indirizzi IP per un cluster di amministrazione e un cluster utente (fai clic per ingrandire)

    Indirizzi IP dei nodi del cluster di esempio

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

    Computer 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 carichi di lavoro utente 172.16.20.12

    Esempio di indirizzi IP virtuali (VIP)

    La tabella seguente mostra un esempio di come potresti specificare gli indirizzi IP virtuali 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 in bundle 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. Specifichi 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 indirizzi IP nello spazio di indirizzi privati, 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 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 di cluster utenti 10.96.0.0/20

    Gli intervalli suggeriti illustrano questi punti:

    • L'intervallo CIDR del pod può essere lo stesso per più cluster nel modello di rete predefinito, ovvero la modalità isolata.

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

    • In genere, in un cluster sono necessari più pod che servizi, quindi probabilmente ti serve un intervallo CIDR pod più grande dell'intervallo CIDR servizio. Ad esempio, l'intervallo di pod suggerito per un cluster di utenti ha 2(32-16) = 216 indirizzi, ma l'intervallo di servizi suggerito per un cluster di utenti ha solo 2(32-20) = 212 indirizzi.

    Evitare 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 nessun indirizzo esterno al cluster che vuoi raggiungere dall'interno del cluster.

    Ad esempio, supponiamo che l'intervallo di servizio 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 in-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 NTP

    4. Rivedi le risorse Google Cloud obbligatorie

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

    La procedura per creare cluster nella sezione 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 L'agente Connect utilizza questo account di servizio per mantenere una connessione tra il cluster e Google Cloud. In questo modo è possibile accedere al cluster e alle funzionalità di gestione dei carichi di lavoro, inclusa la console Google Cloud e ilgateway 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

    Creare cluster di base