Pianifica un'installazione di base sull'hardware

Questa è la prima parte di una guida che illustra l'uso dei il software Google Distributed Cloud (precedentemente noto come Google Distributed Cloud) una piccola installazione proof-of-concept dei cluster GKE il tuo hardware Bare Metal. Questo documento illustra come configurare un'istanza dell'ambiente hardware e di pianificare gli indirizzi IP. L'articolo successivo Creare cluster di base spiega come creare un cluster di amministrazione e un cluster utente.

Questa pagina è rivolta agli amministratori, agli architetti e agli operatori che configurano, monitorare e gestire il ciclo di vita dell'infrastruttura tecnica sottostante. Per approfondire i ruoli comuni e le attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

L'infrastruttura che configuri con questa guida potrebbe non essere adatta al tuo le esigenze di produzione e i casi d'uso effettivi. Per ulteriori informazioni sulla produzione per le installazioni, consulta Scegli 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 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.

    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.

    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é ti servirà in seguito.

Panoramica della procedura

La configurazione dell'infrastruttura minima è composta 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 con 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, indirizzi IP virtuali (VIP) e intervalli CIDR servizi e pod.

  4. Esamina le risorse Google Cloud richieste. Per creare cluster, Il 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 mentre lavori con i tuoi cluster.

Requisiti hardware

La workstation di amministrazione richiede una notevole potenza di calcolo, memoria e spazio di archiviazione 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 del sistema operativo dei nodi. Ogni macchina deve eseguire una versione supportata di Ubuntu.

Configura il sistema operativo e il software

Nella workstation di amministrazione, installa e configura quanto segue:

  • Configurare Ubuntu

  • Installa l'interfaccia a riga di comando gcloud

  • 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. 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 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

    Sia la versione del client sia quella 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 ai gruppi:

    newgrp docker

  7. Esegui il seguente 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 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 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 = 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 per la creazione e la gestione del cluster.

Per installare bmctl sulla workstation di amministrazione:

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

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

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

    gcloud storage cp gs://anthos-baremetal-release/bmctl/1.30.0-gke.1930/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 le richieste di autorizzazione, creare account di servizio, gestire il logging il monitoraggio, 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, è necessario 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 la configurazione di SSH nell'interfaccia di amministrazione la workstation e le macchine nodo.

2. Configura le macchine dei nodi cluster

Per l'installazione minima di un singolo cluster di amministrazione non ad alta disponibilità e 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 worker nodo.

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 del nodo deve eseguire una versione supportata di Ubuntu.

Configura Ubuntu

Configura Ubuntu su ogni nodo con lo stesso istruzioni utilizzate per la workstation di amministrazione.

Configurare 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 non ha password sudo privilegi.

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

  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. È necessario eseguire i seguenti passaggi sulla workstation di amministrazione e su ogni macchina nodo.

Per configurare SSH sulle macchine con 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 il token PermitRootLogin e PasswordAuthentication nelle righe /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 di 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 le chiavi SSH e copia la chiave pubblica su ogni macchina del nodo

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

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

    ssh-keygen -t rsa

  2. Sulla workstation di amministrazione, copia la chiave pubblica generata in ciascuno dei tuoi di macchine nodo:

    ssh-copy-id -i PUBLIC_KEY root@CLUSTER_NODE_IP

    Sostituisci quanto segue:

    • PUBLIC_KEY: il percorso del file contenente l'SSH chiave pubblica. 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 e imposta PasswordAuthentication su no e salvare 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

Quando SSH è configurato correttamente, puoi stabilire una connessione SSH alla macchina del nodo dalla workstation di amministrazione (come utente root) senza una 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 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, è /home/USERNAME/.ssh/id_rsa
    • CLUSTER_NODE_IP: l'indirizzo IP della macchina nodo

3. Pianificare il networking

Quando installi i cluster, è importante pianificare gli indirizzi IP, assicurarsi di non creare conflitti di indirizzi. Potresti l'amministratore di rete ti aiuti a trovare indirizzi adatti, anche per questa semplice installazione. Senza contare i CIDR di pod e servizi, occorre Almeno 15 indirizzi IP univoci per un cluster di amministrazione e un cluster utente minimi. dell'installazione.

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

  • Nodi del cluster: devi avere un indirizzo IP per ogni macchina del 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: sono necessari intervalli di indirizzi CIDR per ogni pod e servizio in esecuzione sui tuoi cluster

Il resto di questa sezione contiene esempi illustrativi di valori utilizzabili 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 dei nodi del cluster utente nello stesso dominio di livello 2. Ad esempio, supponiamo che tutti gli indirizzi IP gli indirizzi nell'intervallo 172.16.20.0/24 vengono indirizzati a un particolare livello 2 dominio. 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 i VIP.

Il seguente diagramma illustra un dominio di livello 2 con un amministratore una workstation, 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)

Esempi di indirizzi IP dei nodi cluster

La tabella seguente mostra un esempio di come è possibile utilizzare 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 piano di controllo per l'amministratore cluster 172.16.20.10
Nodo del control plane del cluster utente Macchina fisica che funge da nodo del piano di controllo per l'utente cluster 172.16.20.11
Nodo worker del cluster utente Macchina fisica che esegue i carichi di lavoro utente 172.16.20.12

Esempi di indirizzi IP virtuali (VIP)

La tabella riportata di seguito fornisce un esempio di come è possibile specificare i VIP per clusters:

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 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 gli indirizzi per pod e 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 indirizzi IP nello spazio di indirizzi privato, come descritto nel documento RFC 1918. Questi indirizzi vengono specificati come parte della configurazione del cluster, come illustrato 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 tu non abbia un motivo per farlo, utilizza gli intervalli suggeriti che seguono:

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 di utenti 10.96.0.0/20

Gli intervalli suggeriti illustrano i seguenti punti:

  • L'intervallo CIDR del 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 che servizi in un cluster, quindi se vuoi un intervallo CIDR pod più grande dell'intervallo CIDR servizio. Per Ad esempio, l'intervallo di pod suggerito per un cluster utente è 2(32-16) = 216 indirizzi, ma l'intervallo di servizi suggerito per un utente ha solo 2(32-20) = 212 indirizzi.

Evita sovrapposizioni

Per evitare sovrapposizioni con gli indirizzi IP raggiungibili sulla tua rete, potrebbe essere necessario utilizzare intervalli CIDR diversi da quelli suggeriti in precedenza. 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. Traffico inviato da un pod a un indirizzo in uno dei due seguenti stati: questi intervalli vengono trattati come nel cluster e non possono raggiungere 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 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 richieste

Prima di poter creare cluster, Google Distributed Cloud richiede un set specifico di API Google da abilitare nel progetto Google Cloud associato. Per utilizzare le API di Google, Google Distributed Cloud richiede servizio account configurati con specifiche Ruoli IAM nel progetto Google Cloud associato.

Il processo di creazione dei cluster nella prossima parte di questa guida Crea cluster di base, abilita le API e crea automaticamente gli account di servizio.

Di seguito sono riportate le API Google 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

Nella tabella seguente sono descritti 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. 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 alle funzionalità di gestione del cluster e dei carichi di lavoro, tra cui la console Google Cloud e il gateway di connessione, per interagire con il cluster. ruoli/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 in Cloud Logging e Cloud Monitoring. ruoli/logging.logWriter
roles/monitoring.metricWriter
ruoli/stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

Passaggi successivi

Creare cluster di base