Questa è la prima parte di una guida che illustra una piccola installazione proof of concept di GDCV per Bare Metal. Questo documento mostra 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 reali. Per ulteriori informazioni sulle installazioni in produzione, consulta Scegliere un modello di deployment.
Prima di iniziare
- Leggi Informazioni su GKE su Bare Metal.
- Acquisisci familiarità con alcuni concetti di base di Google Cloud, tra cui progetti, autorizzazioni IAM e account di servizio.
- 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.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
- Prendi nota dell'ID progetto Google Cloud, perché sarà necessario in seguito.
Panoramica della procedura
La configurazione minima dell'infrastruttura è costituita dai seguenti passaggi principali:
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.
Configura le macchine nodo del 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.
Pianifica il networking. Pianifica gli indirizzi IP per le macchine dei nodi, gli indirizzi IP virtuali (VIP) e gli intervalli CIDR per servizi e pod.
Rivedi le risorse Google Cloud richieste. Per creare i 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 strumenti e file di configurazione per la creazione e l'utilizzo dei cluster.
Requisiti hardware
La workstation di amministrazione richiede potenza di calcolo, memoria e 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 CPU
- Almeno 4 GiB di RAM
- Almeno 128 GiB di spazio di archiviazione
Configurare il sistema operativo e il software
Sulla workstation di amministrazione devi installare e configurare quanto segue:
Configurare Ubuntu
Installa gcloud CLI
Installa
kubectl
Installa
bmctl
Configurare il 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, ad esempio Ubuntu 20.04.
Esegui i comandi seguenti per aggiornare le impostazioni del firewall, installare e configurare Docker e assicurarti che ogni macchina utilizzi la sincronizzazione dell'ora:
Disattiva Uncomplicated Firewall (UFW) e verificane lo stato:
sudo ufw disable sudo ufw status
Rimuovi qualsiasi versione Docker precedente, 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
Verifica che sia ora in esecuzione la versione 19.03 o successive di Docker:
sudo docker version
Sia la versione client che quella 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 ...
Crea il gruppo
docker
.sudo groupadd docker
Aggiungiti al gruppo Docker:
sudo usermod -aG docker $USER
Esegui questo comando per attivare le modifiche al gruppo:
newgrp docker
Esegui questo comando per verificare che l'orologio di sistema sia sincronizzato:
timedatectl
L'output di
timedatectl
deve contenere il seguente stato:System clock synchronized: yes
Installa Google Cloud CLI
Per installare Google Cloud CLI su Ubuntu, segui le istruzioni in questa guida all'installazione.
Esegui i seguenti passaggi sulla workstation di amministrazione per configurare gcloud CLI:
Accedi per impostare la proprietà
account
gcloud CLI:gcloud auth login
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.Verifica che le proprietà
account
eproject
siano impostate correttamente:gcloud config list
L'output mostra i valori delle proprietà
account
eproject
. Ad esempio:[core] account = my-name@google.com disable_usage_reporting = False project = my-project-1234 Your active configuration is: [default]
Installazione di kubectl
Per installare kubectl
:
Esegui il comando seguente sulla workstation di amministrazione:
gcloud components install kubectl
Installazione di bmctl
bmctl
è lo strumento a riga di comando di proprietà per GKE su Bare Metal, che puoi utilizzare per la creazione e la gestione dei cluster.
Per installare bmctl
sulla workstation di amministrazione:
Crea una directory
baremetal
e aggiungila al tuo percorso. Se ti trovi nella home directory, i comandi sono:mkdir baremetal export PATH="$HOME/baremetal:$PATH"
Esegui questo comando per scaricare la versione più recente del file binario
bmctl
e renderlo eseguibile:gsutil cp gs://anthos-baremetal-release/bmctl/1.16.8/linux-amd64/bmctl . chmod +x ./bmctl
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 richieste di autorizzazione, creare account di servizio, gestire logging e 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 nodo del cluster.
- Accesso al VIP del piano di controllo.
- Accesso
root
senza password a tutte le macchine dei nodi del cluster tramite SSH. L'accesso SSH può essere diretto o tramitesudo
.
La seguente sezione contiene le istruzioni per configurare SSH sulla workstation di amministrazione e sulle macchine nodo.
2. Configura le macchine nodo 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 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 con le stesse istruzioni utilizzate per la workstation di amministrazione.
Configura l'accesso SSH ai nodi
La workstation di amministrazione richiede l'accesso root
senza password a tutte le macchine dei nodi del cluster tramite SSH. L'accesso a root
può essere diretto o tramite sudo
.
Questi sono i passaggi di alto livello per configurare SSH per GKE su Bare Metal:
Installare e configurare SSH su tutte le macchine
Crea chiavi SSH e copia la chiave pubblica su ogni macchina nodo
Disattivare l'autenticazione tramite password sulle macchine nodo
Verifica l'accesso SSH tra la workstation di amministrazione e le macchine nodo
Installa e configura SSH su tutte le macchine
GKE su Bare Metal richiede la comunicazione SSH senza password tra la workstation di amministrazione e i nodi del cluster. I passaggi seguenti devono essere eseguiti sulla workstation di amministrazione e su ogni macchina nodo.
Per configurare SSH su macchine che eseguono Ubuntu:
Se non disponi ancora di un server SSH in esecuzione, installane uno ora:
sudo apt update sudo apt install openssh-server sudo systemctl status ssh
Abilita l'autenticazione tramite password SSH di
root
rimuovendo il commento o aggiungendo le righePermitRootLogin
ePasswordAuthentication
nel file/etc/ssh/sshd_config
e impostando i valori suyes
:# Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 ... PasswordAuthentication yes
Imposta una password root:
sudo passwd root
Per applicare le modifiche alla configurazione SSH, riavvia il servizio SSH:
sudo systemctl restart ssh.service
Riavvia il computer.
Verifica che SSH funzioni stabilendo una connessione SSH da un'altra macchina.
Creare chiavi SSH e copiare 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.
Sulla workstation di amministrazione, genera una coppia di chiavi pubbliche e private. Non impostare una passphrase per le chiavi:
ssh-keygen -t rsa
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 attivare l'autenticazione tramite password.
Per ogni macchina nodo:
Apri
/etc/ssh/sshd_config
, impostaPasswordAuthentication
suno
e salva il file.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 del 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:
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 tuo networking
Quando installi i cluster, è importante pianificare gli indirizzi IP, assicurandoti anche di non creare conflitti di indirizzi. È possibile che ti venga utile l'amministratore di rete per trovare gli indirizzi più adatti, anche per questa semplice installazione. Senza contare i CIDR di pod e servizi, sono necessari almeno 15 indirizzi IP univoci per l'installazione minima di cluster di amministrazione e cluster utente.
Pianifica e specifica gli indirizzi IP per i seguenti componenti del cluster:
- Nodi cluster: è necessario 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: sono necessari intervalli di indirizzi CIDR per soddisfare tutti i pod e servizi in esecuzione sui cluster
Il resto di questa sezione contiene esempi illustrativi di valori validi per questa installazione in una rete ipotetica; i valori saranno diversi.
Per questa installazione ridotta, 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, supponi che tutti gli indirizzi IP nell'intervallo 172.16.20.0/24
vengano instradati 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 dei nodi e 172.16.0.13
-
172.16.20.24
per i VIP.
Il seguente diagramma illustra un dominio di livello 2 con una workstation di amministrazione, un cluster di amministrazione e un cluster utente:
Esempi di indirizzi IP dei nodi cluster
La tabella seguente fornisce un esempio di come gli indirizzi IP possono essere utilizzati per i nodi cluster:
Macchina | 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 | 10/16/20172 |
Nodo del piano di controllo del cluster utente | Macchina fisica che funge da nodo del piano di controllo per il cluster utente | 11/16/2020 |
Nodo worker del cluster utente | Macchina fisica che esegue carichi di lavoro degli utenti | 12/16/20/172 |
Esempi di indirizzi IP virtuali (VIP)
La tabella seguente fornisce un esempio di come puoi specificare i VIP per i tuoi 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) | 13/16/20/172 |
Indirizzo VIP del piano di controllo del cluster utente | Indirizzo VIP del piano di controllo del cluster utente (server API Kubernetes del cluster utente) | 14/17/2014 |
Indirizzo VIP in entrata | VIP in entrata (incluso nell'intervallo di pool di indirizzi MetalLB) | 15/16/20/172 |
Indirizzi VIP del servizio | Dieci indirizzi da utilizzare come indirizzi IP esterni per i servizi di tipo LoadBalancer . Gli indirizzi vengono allocati secondo necessità sui nodi dei 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 i nodi del cluster e i VIP,
devi specificare gli indirizzi per pod e servizi. Puoi specificare un intervallo CIDR da utilizzare per gli indirizzi IP dei pod e un altro intervallo CIDR per gli indirizzi ClusterIP
dei servizi Kubernetes. Utilizza gli indirizzi IP nello spazio degli indirizzi privati, come descritto nel documento 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 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 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 dei servizi può essere lo stesso per più cluster.
In un cluster hai bisogno di un numero maggiore di pod che servizi, pertanto probabilmente ti serve un intervallo CIDR pod superiore all'intervallo CIDR servizio. Ad esempio, l'intervallo di pod suggerito per un cluster utente ha 2(32-16) = 216 indirizzi, ma l'intervallo di servizi suggerito per un cluster utente ha solo 2(32-20) = 212 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, supponi 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 trattato come nel cluster e non può raggiungere alcuna destinazione esterna al 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 piano di controllo e dai bilanciatori del carico
Indirizzo IP dei server DNS o NTP
4. Rivedi le risorse Google Cloud richieste
Prima di poter creare cluster, GKE su Bare Metal richiede l'abilitazione di un set specifico di API di Google nel progetto Google Cloud associato. Per utilizzare le API di Google, GKE su Bare Metal richiede account di servizio configurati con ruoli IAM specifici nel progetto Google Cloud associato.
Il processo per la creazione dei cluster nella parte successiva di questa guida, Creazione di cluster di base, abilita le API e crea automaticamente account di servizio.
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:
Account di servizio | Finalità | Ruoli |
---|---|---|
anthos-baremetal-gcr | GDCV per Bare Metal utilizza questo account di servizio per scaricare immagini container da Container Registry. | Nessun valore |
anthos-baremetal-connect | L'agente Connect utilizza questo account di servizio per mantenere una connessione tra il cluster e Google Cloud. 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. |
role/logging.logWriter roles/monitoring.metricWriter roles/stackdriver.resourceMetadata.writer roles/opsconfigmonitoring.resourceMetadata.writer roles/monitoring.dashboardEditor |