La workstation di amministrazione ospita strumenti di interfaccia a riga di comando (CLI) e file di configurazione per eseguire il provisioning dei cluster durante l'installazione, nonché strumenti di interfaccia a riga di comando per interagire con i cluster di cui è stato eseguito il provisioning dopo l'installazione.
Puoi scaricare ed eseguire strumenti come bmctl
e Google Cloud CLI sulla workstation di amministrazione per interagire con i cluster e le risorse Google Cloud. La workstation di amministrazione ospita i file di configurazione per eseguire il provisioning dei cluster durante l'installazione, gli upgrade e gli aggiornamenti. Dopo l'installazione, la workstation di amministrazione ospita i file kubeconfig
in modo che tu possa utilizzare kubectl
per interagire con i cluster di cui è stato eseguito il provisioning. Potrai anche accedere ai log per le operazioni critiche del cluster sulla workstation di amministrazione. Puoi usare un'unica workstation di amministrazione
per creare e gestire molti cluster.
Assicurati che la workstation di amministrazione soddisfi i prerequisiti descritti nelle sezioni seguenti.
Sistema operativo e software
Per eseguire bmctl
e funzionare come nodo del piano di controllo, la workstation di amministrazione ha gli stessi requisiti del sistema operativo dei nodi. La workstation di amministrazione richiede Docker, ma non l'uso come runtime dei container. Quando GKE su Bare Metal crea i cluster, esegue il deployment di un cluster Kubernetes in Docker (kind) sulla workstation di amministrazione. Questo cluster bootstrap ospita i controller Kubernetes necessari per
creare i cluster. Se non diversamente specificato, il cluster di bootstrap viene rimosso al termine della creazione del cluster. Il cluster di bootstrap richiede Docker per il pull delle immagini container.
Prima di poter installare un cluster, la workstation di amministrazione deve soddisfare i seguenti requisiti:
Il sistema operativo è una distribuzione Linux supportata.
Per un elenco dei sistemi operativi Linux supportati e delle versioni, vedi Selezionare il sistema operativo. La pagina contiene link alle istruzioni di configurazione, inclusa la configurazione Docker, per ogni sistema operativo.
Docker 19.03 o versioni successive è installato. Tuttavia, se il sistema utilizza cgroup v2, l'installazione Docker sulla workstation di amministrazione deve essere la versione 20.10.0 o successiva. Puoi capire se il sistema utilizza cgroup v2 in base alla presenza del file
/sys/fs/cgroup/cgroup.controllers
. cgroup v2 è supportato solo come funzionalità di anteprima. Sconsigliamo l'utilizzo di funzionalità e funzionalità in anteprima negli ambienti di produzione.L'utente non root fa parte del gruppo
docker
(per istruzioni, vai a Gestire Docker come utente non root).Google Cloud CLI è installato.
Usi gli strumenti
kubectl
ebmctl
per creare e gestire i cluster. Per installare questi strumenti, devi avere gli strumentigcloud
egsutil
. Gli strumenti a riga di comandogcloud
,gsutil
ekubectl
sono componenti di gcloud CLI. Per le istruzioni di installazione, incluse quelle relative all'installazione dei componenti, consulta Installa gcloud CLI.L'app
kubectl
è installata. Utilizza gcloud CLI per installarekubectl
con il seguente comando:gcloud components install kubectl
bmctl
è installato per la versione del cluster che stai creando o operando.L'installazione prevede l'utilizzo di
gsutil
per scaricare il pacchetto di immagini o file binari dibmctl
. Per le istruzioni, consulta la pagina relativa ai download dei cluster Anthos on bare metal.
Requisiti delle risorse 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.
Per impostazione predefinita, le operazioni di upgrade del cluster e di creazione del cluster utilizzano un cluster di bootstrap. Quando viene utilizzato un cluster di bootstrap, si verifica un aumento significativo dell'utilizzo di CPU e memoria. Se intendi utilizzare la workstation di amministrazione come nodo del piano di controllo, utilizza almeno la quantità consigliata di CPU e RAM superiore per evitare che le attività della workstation di amministrazione interrompano le funzioni del piano di controllo del cluster.
A seconda delle dimensioni del database etcd e del numero di nodi del piano di controllo, le operazioni di backup del cluster e ripristino consumano molta RAM. La stima approssimativa della RAM richiesta per i backup è di 3-5 GiB per nodo del piano di controllo. Il processo di backup non riesce e memoria insufficiente. Pianifica i requisiti della RAM di conseguenza.
La tabella seguente fornisce i requisiti hardware minimi e consigliati per la workstation di amministrazione:
Risorsa | Minimo | Consigliato |
---|---|---|
CPU / vCPU* | 2 core | 4 core |
RAM | Ubuntu: 4 GiB CentOS/RHEL: 6 GiB |
Ubuntu: 8 GiB CentOS/RHEL: 12 GiB |
Spazio di archiviazione | 128 GiB | 256 GiB |
* GKE su Bare Metal supporta solo CPU e vCPU x86-64 a livello di microarchitettura della CPU v3 (x86-64-v3) e superiore.
Requisiti di networking
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.
L'accesso a Google Cloud può essere diretto o tramite un server proxy. Per informazioni sui diversi modi per connettersi a Google Cloud, consulta Connettersi a Google. Per informazioni sulla configurazione di un server proxy, consulta Installazione tramite proxy.
Per informazioni sulle conseguenze dell'interruzione dell'accesso a Google Cloud, consulta Impatto della disconnessione temporanea da Google Cloud.
Accesso ai nodi
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
root
senza password a tutte le macchine dei nodi del cluster tramite SSH. L'accesso SSH può essere diretto o tramitesudo
. - Accesso al VIP del piano di controllo.
Inoltro IP
L'IP forwarding deve essere abilitato sulla workstation di amministrazione. Senza l'inoltro IP, non è possibile creare il cluster di bootstrap, che blocca la creazione del cluster. Se l'inoltro IP è disabilitato, verrà visualizzato un errore come il seguente quando tenti di creare un cluster:
Error message: E0202 14:53:25.979322 225917 console.go:110] Error creating cluster: create kind cluster failed: error creating bootstrap cluster: failed to init node with kubeadm: command "docker exec --privileged bmctl-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1
Puoi controllare l'impostazione di IP forwarding con il seguente comando:
cat /proc/sys/net/ipv4/ip_forward
Il valore 1
indica che l'inoltro IP è abilitato. Se l'IP forwarding è disabilitato (0
), utilizza il seguente comando per abilitarlo:
echo '1' | sudo tee /proc/sys/net/ipv4/ip_forward
Configura l'accesso SSH di root
ai nodi
Per abilitare connessioni sicure e senza password tra la workstation di amministrazione e le macchine nodo del cluster, crea una chiave SSH sulla workstation di amministrazione e condividi la chiave pubblica con i nodi del cluster.
Abilita l'autenticazione tramite password SSH di
root
su ogni macchina dei nodi del cluster rimuovendo il commento o aggiungendo le righePermitRootLogin
ePasswordAuthentication
nel file/etc/ssh/sshd_config
e impostando i valori suyes
.# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. ... # Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 ... PasswordAuthentication yes
Inizialmente, devi abilitare l'autenticazione tramite password SSH sulle macchine nodi del cluster remoto per condividere le chiavi dalla workstation di amministrazione.
Per applicare le modifiche alla configurazione SSH, riavvia il servizio SSH:
sudo systemctl restart ssh.service
Genera una coppia di chiavi pubblica e privata sulla workstation di amministrazione. Non impostare una passphrase per le chiavi. Genera le chiavi con il seguente comando:
ssh-keygen -t rsa
Puoi anche utilizzare l'accesso utente
sudo
alle macchine nodo del cluster per configurare SSH. Tuttavia, per le connessioni utente non-root e senza password, devi aggiornare il file di configurazione del cluster con il campospec.nodeAccess.loginUser
. Questo campo è commentato per impostazione predefinita. Puoi specificare il tuo nome utente non root conloginUser
durante la creazione del cluster o in qualsiasi momento successivo. Per saperne di più, consultaloginUser
.Aggiungi la chiave pubblica generata alle macchine dei nodi cluster:
ssh-copy-id -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP
Sostituisci quanto segue:
PATH_TO_IDENTITY_FILE
: il percorso del file contenente la chiave pubblica SSH. Per impostazione predefinita, il percorso del file di identità contenente la chiave pubblica è/home/USERNAME/.ssh/id_rsa.pub
.CLUSTER_NODE_IP
: l'indirizzo IP della macchina del nodo a cui aggiungi la chiave pubblica SSH.
Disabilita l'autenticazione tramite password SSH sulle macchine nodo del cluster impostando
PasswordAuthentication
suno
nel filesshd_config
e riavviando il servizio SSH.Utilizza il seguente comando sulla workstation di amministrazione per verificare il funzionamento dell'autenticazione della chiave pubblica tra la workstation e le macchine nodo.
ssh -o IdentitiesOnly=yes -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP
Se SSH è configurato correttamente, puoi accedere alla macchina del nodo dalla workstation di amministrazione (come
root
) senza dover inserire una password.