Questa pagina è stata tradotta dall'API Cloud Translation.

Prerequisiti della workstation di amministrazione

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.

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.

Scarichi ed esegui 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 da poter utilizzare kubectl per interagire con i cluster di cui è stato eseguito il provisioning. Puoi anche accedere ai log per le operazioni del cluster critiche sulla workstation di amministrazione. Una singola workstation di amministrazione può essere utilizzata 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 control plane, la workstation amministrativa ha gli stessi requisiti del sistema operativo (SO) dei nodi. La workstation amministrativa richiede Docker, ma non per l'utilizzo come runtime del container. Quando Google Distributed Cloud crea i cluster, esegue il deployment di un cluster Kubernetes in Docker (kind) sulla workstation amministrativa. Questo cluster bootstrap ospita i controller Kubernetes necessari per creare cluster. Se non diversamente specificato, il cluster di bootstrap viene rimosso al termine della creazione del cluster. Il cluster di bootstrap richiede Docker per eseguire 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 e delle versioni supportati, consulta Seleziona il sistema operativo. Questa pagina contiene link alle istruzioni di configurazione, inclusa la configurazione Docker, per ogni sistema operativo.
È installata la versione 19.03 o successiva di Docker. Tuttavia, se il tuo sistema utilizza cgroup v2, l'installazione di Docker sulla workstation di amministrazione deve essere la versione 20.10.0 o successive. Puoi sapere se il tuo sistema utilizza cgroup v2 dalla presenza del file /sys/fs/cgroup/cgroup.controllers.

Avviso: Docker installato da snap è in modalità di isolamento rigida per impostazione predefinita, il che significa che Docker non può accedere ai file al di fuori della directory $HOME. Verifica che Docker sia in modalità di isolamento rigida eseguendo snap info --verbose docker | grep confinement sulla workstation amministrativa. Se è il tuo caso, assicurati che la cartella bmctl-workspace si trovi nella directory $HOME.
L'utente non root è membro del gruppo docker (per istruzioni, vai a Gestire Docker come utente non root).
Google Cloud CLI è installata.

Utilizzi gli strumenti kubectl e bmctl per creare e gestire i cluster. Per installare questi strumenti, devi disporre dello strumento gcloud. Gli strumenti a riga di comando gcloud e kubectl sono componenti della gcloud CLI. Per istruzioni di installazione, incluse quelle per l'installazione dei componenti, vedi Installa gcloud CLI.
kubectl è installato. Utilizza gcloud CLI per installare kubectl con il seguente comando:
```
gcloud components install kubectl
```
bmctl è installato per la versione del cluster che stai creando o utilizzando.

L'installazione consiste nell'utilizzare gcloud per scaricare il pacchetto binario o di immagini bmctl. Per istruzioni, vedi Download di Google Distributed Cloud per Bare Metal.

Requisiti delle risorse 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.

Per impostazione predefinita, le operazioni di upgrade e creazione del cluster utilizzano un cluster bootstrap. Quando viene utilizzato un cluster di bootstrap, si verifica un aumento significativo dell'utilizzo di CPU e memoria. Se intendi utilizzare la workstation amministrativa come nodo del control plane, utilizza almeno la quantità consigliata più elevata di CPU e RAM per evitare che le attività della workstation amministrativa interrompano le funzioni del control plane del cluster.

A seconda delle dimensioni del database etcd e del numero di nodi del control plane, le operazioni di backup e ripristino del cluster consumano una quantità significativa di RAM. La stima approssimativa della RAM necessaria per i backup è di 3-5 GiB per nodo del control plane. Il processo di backup non riesce perché non c'è memoria sufficiente. Pianifica i requisiti di 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 RHEL: 6 GiB	Ubuntu: 8 GiB RHEL: 12 GiB
Spazio di archiviazione	128 GiB	256 GiB

^* Google Distributed Cloud supporta solo CPU e vCPU x86-64 a livello di microarchitettura della CPU v3 (x86-64-v3) e versioni successive.

Requisiti di networking

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.

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, vedi Installazione tramite un proxy.

Per informazioni sulle conseguenze dell'interruzione dell'accesso a Google Cloud, vedi 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 dei nodi:

Connettività di livello 3 a tutte le macchine nodo del cluster.
Accesso SSH senza password a tutte le macchine dei nodi del cluster come root o come utente utente root con privilegi sudo senza password. Questo elevato livello di autorizzazioni è richiesto dagli strumenti di automazione per eseguire attività a livello di nodo che eseguono il provisioning dei nodi durante l'installazione del cluster.
Accesso al VIP del control plane.

Inoltro IP

L'IP forwarding deve essere abilitato sulla workstation di amministrazione. Senza l'inoltro IP, non è possibile creare il cluster di bootstrap, il che blocca la creazione del cluster. Se l'inoltro IP è disattivato, quando tenti di creare un cluster viene visualizzato un errore simile al seguente:

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 inoltro IP con il seguente comando:

cat /proc/sys/net/ipv4/ip_forward

Un valore pari a 1 indica che l'inoltro IP è attivato. Se l'inoltro IP è disattivato (0), utilizza il seguente comando per attivarlo:

echo '1' | sudo tee /proc/sys/net/ipv4/ip_forward

Configura l'accesso SSH `root` ai nodi

Per attivare connessioni sicure e senza password tra la workstation di amministrazione e le macchine dei nodi del cluster, crea una chiave SSH sulla workstation di amministrazione e condividi la chiave pubblica con i nodi del cluster.

Attiva l'autenticazione con password SSH su ogni macchina nodo del cluster rimuovendo il commento o aggiungendo le righe PermitRootLogin e PasswordAuthentication nel file /etc/ssh/sshd_config e impostando i valori su yes.root
```
# $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 dei 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 privata e pubblica sulla workstation di amministrazione. Non impostare una frase di accesso per le chiavi. Genera le chiavi con il seguente comando:
```
ssh-keygen -t rsa
```
Puoi anche utilizzare l'accesso utente sudo alle macchine dei nodi del cluster per configurare SSH. Tuttavia, per le connessioni utente non root senza password, devi aggiornare il file di configurazione del cluster con il campo spec.nodeAccess.loginUser. Questo campo è commentato per impostazione predefinita. Puoi specificare il nome utente non root con loginUser durante la creazione del cluster o in qualsiasi momento successivo. Per maggiori informazioni, vedi loginUser.
Aggiungi la chiave pubblica generata alle macchine dei nodi del 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 stai aggiungendo la chiave pubblica SSH.
Disattiva l'autenticazione tramite password SSH sulle macchine dei nodi del cluster impostando PasswordAuthentication su no nel file sshd_config e riavviando il servizio SSH.
Utilizza il seguente comando sulla workstation di amministrazione per verificare che l'autenticazione con chiave pubblica funzioni tra la workstation e le macchine dei nodi.
```
ssh -o IdentitiesOnly=yes -i PATH_TO_IDENTITY_FILE root@CLUSTER_NODE_IP
```
Quando SSH è configurato correttamente, puoi accedere alla macchina del nodo dalla workstation di amministrazione (come root) senza dover inserire una password.

Passaggi successivi

Prerequisiti delle macchine dei nodi