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. Il follow-up Crea cluster mostra come creare un cluster di amministrazione in un cluster utente.
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
- Leggi Informazioni su Google Distributed Cloud.
- Acquisisci familiarità con alcuni concetti di base di Google Cloud, tra cui: projects, autorizzazioni IAM e account di servizio.
- Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
- 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:
Configura la tua workstation di amministrazione. Configura una workstation di amministrazione Linux per delle attività di gestione on-premise. Potrebbe trattarsi di un account esistente o di un che può gestire più cluster.
Configura le macchine dei nodi cluster. Configura almeno tre macchine per nodi: un nodo del cluster di amministrazione, un nodo del piano di controllo del cluster utente e uno nodo worker del cluster utente.
Pianifica il networking. Pianifica gli indirizzi IP per le macchine nodo, indirizzi IP virtuali (VIP) e intervalli CIDR servizi e pod.
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 potenza di calcolo, memoria e spazio di archiviazione significativi per eseguire gli strumenti e archiviare le risorse associate alla creazione del cluster gestione dei dispositivi.
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, come Ubuntu 20.04.
Esegui questi comandi per aggiornare le impostazioni del firewall, installare e configurare Docker e assicurarti che ogni macchina utilizzi la sincronizzazione dell'ora:
Disabilita Uncomplicated Firewall (UFW) e verificane lo stato:
sudo ufw disable sudo ufw status
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
Verifica di eseguire 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 illustrato nella la 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 ai gruppi:
newgrp docker
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 in questo guida all'installazione.
Esegui i seguenti passaggi sulla workstation di amministrazione per configurare gcloud CLI:
Accedi per impostare la proprietà
account
della gcloud CLI:gcloud auth login
Imposta la proprietà
project
della gcloud CLI: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 proprietario per Google Distributed Cloud che
per la creazione e la gestione del cluster.
Per installare bmctl
sulla workstation di amministrazione:
Crea una directory
baremetal
e aggiungila al tuo del tuo percorso di apprendimento. Se ti trovi nella tua home directory, i comandi sono:mkdir baremetal export PATH="$HOME/baremetal:$PATH"
Esegui questo comando per scaricare l'ultima versione dell'
bmctl
binario e rendilo eseguibile:gcloud storage cp gs://anthos-baremetal-release/bmctl/1.29.300--gke.185/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 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 in 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 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 privilegisudo
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
Configura Ubuntu
Configura Ubuntu su ogni nodo con lo stesso 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 tutti i nodi del cluster
machine learning. 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:
Installare e configurare SSH su tutte le macchine
Crea chiavi SSH e copia la chiave pubblica su ogni macchina nodo
Disabilita 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
Google Distributed Cloud richiede la comunicazione SSH senza password tra alla workstation di amministrazione e ai nodi del cluster. È necessario eseguire i seguenti passaggi sulla workstation di amministrazione e su ogni macchina nodo.
Per configurare SSH su macchine che eseguono Ubuntu:
Se non hai già un server SSH in esecuzione, installane uno ora:
sudo apt update sudo apt install openssh-server sudo systemctl status ssh
Attiva l'autenticazione della password SSH di
root
rimuovendo il commento o aggiungendo il tokenPermitRootLogin
ePasswordAuthentication
nelle righe/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 il funzionamento di SSH stabilendo una connessione SSH da un altro in una macchina virtuale.
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, creare una chiave SSH sulla workstation di amministrazione e condividere la chiave pubblica nodi.
Sulla workstation di amministrazione, genera una coppia di chiavi privata e pubblica. Non impostare una passphrase per le chiavi:
ssh-keygen -t rsa
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:
Apri
/etc/ssh/sshd_config
e impostaPasswordAuthentication
suno
e salvare 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 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:
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. Pianifica 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: hai bisogno di un indirizzo IP per ogni macchina nodo
- Indirizzi IP virtuali (VIP): hai bisogno di VIP per accedere all'API Kubernetes server, il proxy in entrata e i servizi di tipo LoadBalancer
- Pod e servizi: hai bisogno di intervalli di indirizzi CIDR per contenere ogni pod 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 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.
Il seguente diagramma illustra un dominio di livello 2 con un amministratore una workstation, un cluster di amministrazione e un cluster utente:
Indirizzi IP dei nodi cluster di esempio
La tabella seguente fornisce un esempio di come è possibile utilizzare gli indirizzi IP per nodi 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 degli utenti | 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 cluster:
VIP | Descrizione | Indirizzo IP |
---|---|---|
Indirizzo VIP del control plane del cluster di amministrazione | Indirizzo VIP del piano di controllo del cluster di amministrazione (API Kubernetes del cluster di amministrazione (server) | 172/16/20/13 |
Indirizzo VIP del control plane del cluster utente | Indirizzo VIP del piano di controllo del cluster utente (API Kubernetes del cluster utente (server) | 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 servizi di tipo
LoadBalancer . Gli indirizzi vengono assegnati all'utente in base alle esigenze
nodi del cluster.
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. Devi specificare
Intervallo CIDR da impostare
per gli indirizzi IP dei pod e un altro intervallo CIDR da usare per
ClusterIP
indirizzi dei servizi Kubernetes. Utilizza gli indirizzi IP nella
di indirizzi IP privati, come descritto
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 utilizzare per i pod e servizi. A meno che tu non abbia un motivo per procedere diversamente, usa quanto segue 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 valore predefinito, un modello di rete 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 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 la sovrapposizione con gli indirizzi IP raggiungibili sulla tua rete, potrebbe essere necessario 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 il pod
è 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 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 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.
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
Nella tabella seguente sono descritti gli account di servizio creati automaticamente:
Account di servizio | Finalità | Ruoli |
---|---|---|
anthos-baremetal-gcr | Google Distributed Cloud utilizza questo account di servizio per scaricare le immagini container da Container Registry. | Nessuno |
anthos-baremetal-connect | L'agente Connect utilizza per mantenere una connessione tra il cluster e in Google Cloud. Ciò consente l'accesso al cluster e alla gestione dei carichi di lavoro tra cui la console Google Cloud e collega il gateway a a interagire con il tuo 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 a Cloud Logging e Cloud Monitoring. |
ruoli/logging.logWriter roles/monitoring.metricWriter roles/stackdriver.resourceMetadata.writer roles/opsconfigmonitoring.resourceMetadata.writer ruoli/monitoring.dashboardEditor |