Crea un cluster di amministrazione utilizzando i client API Anthos On-Prem

Questa pagina descrive come creare un cluster di amministrazione utilizzando la console Google Cloud o Google Cloud CLI (gcloud CLI). Entrambi questi client standard di Google Cloud utilizzano l'API Anthos On-Prem per creare il cluster.

Che cos'è l'API Anthos On-Prem?

L'API Anthos On-Prem è un'API ospitata da Google Cloud che ti consente di gestire il ciclo di vita dei cluster on-premise utilizzando Terraform e le applicazioni Google Cloud standard. L'API Anthos On-Prem viene eseguita nell'infrastruttura di Google Cloud. Terraform, la console e gcloud CLI sono client dell'API e utilizzano l'API per creare cluster nel tuo data center.

Per gestire il ciclo di vita dei cluster, l'API Anthos On-Prem deve archiviare metadati sullo stato del cluster in Google Cloud, utilizzando la regione Google Cloud specificata durante la creazione del cluster. Questi metadati consentono all'API di gestire il ciclo di vita del cluster e non includono dati specifici del carico di lavoro.

Quando crei un cluster utilizzando un client API Anthos On-Prem, specifichi un progetto Google Cloud. Una volta creato, il cluster viene registrato automaticamente nel parco risorse del progetto specificato. Questo progetto è denominato progetto host del parco risorse. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.

Se preferisci, puoi creare un cluster di amministrazione creando un file di configurazione del cluster di amministrazione e utilizzando bmctl, come descritto nella sezione Creazione di un cluster di amministrazione.

Se vuoi utilizzare la console o l'gcloud CLI per gestire il ciclo di vita dei cluster creati utilizzando bmctl, consulta la pagina Configurare i cluster da gestire tramite l'API Anthos On-Prem.

Autorizzazioni IAM

Se non sei un proprietario del progetto Google Cloud, devi avere un proprietario del progetto che ti conceda i seguenti ruoli:

Se vuoi accedere alle pagine Anthos e Google Kubernetes Engine nella console, devi avere anche roles/container.viewer.

Per informazioni sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.

Accesso da riga di comando

Dopo aver creato il cluster, se vuoi utilizzare il gateway di connessione per eseguire i comandi kubectl sul cluster su computer diversi dalla workstation di amministrazione, installa i seguenti strumenti a riga di comando sul computer che prevedi di utilizzare.

L'ultima versione dell'interfaccia a riga di comando gcloud.
kubectl per l'esecuzione di comandi contro i cluster Kubernetes. Se devi installare kubectl, segui queste istruzioni.

Scegli il client per creare il cluster di amministrazione

Puoi utilizzare la console o l'gcloud CLI per creare un cluster di amministrazione gestito dall'API Anthos On-Prem. Se è la prima volta che installi Anthos clusters on bare metal, potresti trovare la console più facile da utilizzare rispetto all'interfaccia alla gcloud CLI.

Dopo aver acquisito maggiori informazioni sulle informazioni che devi fornire per la creazione dei cluster, potresti trovare l'interfaccia alla gcloud CLI più comoda perché puoi salvare il comando con i relativi argomenti in un file di testo. Se utilizzi uno strumento CI/CD, ad esempio Cloud Build, puoi usare i comandi gcloud per creare un cluster e specificare il flag --impersonate-service-account per automatizzare la creazione.

Prerequisiti

Console

Nella console Google Cloud, vai alla pagina Cluster Anthos.

Vai a Cluster Anthos di Anthos
Seleziona il progetto Google Cloud in cui vuoi creare il cluster. Il progetto selezionato viene utilizzato anche come progetto host del parco risorse.
Fai clic su Crea cluster.
Nella finestra di dialogo, fai clic su On-premise.
Accanto a Bare metal, fai clic su Configure (Configura). Assicurati che sia selezionato Crea un cluster di amministrazione.

Nella pagina Prerequisiti vengono visualizzati i requisiti per la workstation di amministrazione e le macchine dei nodi del cluster. Lo strumento di pianificazione degli indirizzi IP nella sezione Requisiti di rete consente di pianificare gli indirizzi IP necessari per un'installazione minima di un cluster di amministrazione e di un cluster utente.

Prerequisiti della workstation di amministrazione

Espandi questa sezione per visualizzare i requisiti hardware, del sistema operativo e di connettività per la workstation di amministrazione.

Prerequisiti delle macchine dei nodi cluster

Espandi questa sezione per visualizzare i requisiti hardware, del sistema operativo e di connettività per le macchine dei nodi del cluster.

Requisiti di rete

Questa sezione consente di pianificare gli indirizzi IP necessari per un ambiente minimo. Facoltativamente, nella sezione IP IP e indirizzi IP virtuali, puoi fornire un indirizzo IP del nodo iniziale e un indirizzo IP virtuale (VIP) e la console mostra una tabella degli indirizzi IP necessari. Questi indirizzi IP non sono applicati alla configurazione del cluster di amministrazione. che costituiscono una guida per aiutarti a pianificare gli indirizzi IP per l'installazione. Puoi scaricare la tabella in un file CSV e importarla in un foglio di lavoro o in uno strumento di pianificazione degli indirizzi IP da utilizzare come punto di partenza per monitorare gli indirizzi IP necessari per i tuoi cluster.

Consulta le risorse Google Cloud:

Assicurati che tutte le API Google richieste siano abilitate nel progetto host del parco risorse. Inoltre, devi abilitare l'API Anthos On-Prem:

gcloud services enable --project FLEET_HOST_PROJECT_ID \
  gkeonprem.googleapis.com

Sostituisci FLEET_HOST_PROJECT_ID con l'ID del progetto host del parco risorse.

Prima di creare il cluster, esegui il comando bmctl register bootstrap sulla workstation di amministrazione come descritto in Preparare l'ambiente bootstrap. Questo comando può creare gli account di servizio richiesti con le autorizzazioni IAM minime richieste per creare il cluster di amministrazione. Se preferisci, puoi configurare gli account di servizio manualmente.

Quando è tutto pronto per iniziare, fai clic su Installa ambiente bootstrap nella barra di navigazione a sinistra.

Interfaccia a riga di comando gcloud

Prerequisiti per hardware, networking e sistema operativo

La creazione di un cluster di amministrazione con un client API Anthos On-Prem richiede gli stessi prerequisiti dell'hardware, del networking e del sistema operativo della creazione del cluster utilizzando bmctl. Per i dettagli, consulta i Prerequisiti di installazione.

API di Google richieste

Assicurati che tutte le API Google richieste siano abilitate nel progetto host del parco risorse. Inoltre, devi abilitare l'API Anthos On-Prem:

gcloud services enable --project FLEET_HOST_PROJECT_ID \
  gkeonprem.googleapis.com

Sostituisci FLEET_HOST_PROJECT_ID con l'ID del progetto host del parco risorse.

Account di servizio e autorizzazioni richiesti

Pianificare gli indirizzi IP

Prima di creare il cluster di amministrazione, devi pianificare gli indirizzi IP per i tuoi cluster. Consulta Pianifica i tuoi indirizzi IP per un esempio di come allocare gli indirizzi IP per un cluster di amministrazione ad alta disponibilità e due cluster utente ad alta disponibilità. Anche se utilizzerai lgcloud CLI per creare il cluster di amministrazione, ti consigliamo di seguire i passaggi della console in questa sezione per utilizzare lo strumento di pianificazione degli indirizzi IP.

Prepara l'ambiente bootstrap

Prima di creare il cluster di amministrazione, devi eseguire il comando bmctl register bootstrap sulla workstation di amministrazione. Questo comando esegue il deployment di un cluster Kubernetes in Docker (tipo) sulla workstation di amministrazione. Questo cluster bootstrap ospita i controller Kubernetes necessari per creare il cluster di amministrazione. Quando crei il cluster di amministrazione, i controller sul cluster di bootstrap eseguono il provisioning dei nodi, eseguono i controlli preflight e registrano il cluster di amministrazione al parco risorse. Il cluster bootstrap viene eliminato automaticamente dopo la creazione del cluster.

Console

Inserisci un Nome per il cluster di amministrazione. Tieni presente che il nome del cluster bootstrap deriva da prima dell'assegnazione di bootstrap- al nome del cluster di amministrazione.
Seleziona la versione di Anthos clusters on bare metal per il tuo cluster di amministrazione.
Nel campo Google Cloud API Location, seleziona l'area geografica di Google Cloud dall'elenco. Questa impostazione specifica la regione in cui viene eseguita l'API Anthos On-Prem e la regione in cui sono archiviati i seguenti elementi:
- I metadati del cluster necessari all'API Anthos On-Prem per gestire il ciclo di vita del cluster
- I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
- Il log di controllo della Console di amministrazione creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.
La console mostra i comandi da eseguire sulla workstation di amministrazione. Lo strumento a riga di comando bmctl deve corrispondere alla versione del cluster che stai creando. Se hai già scaricato la versione applicabile di bmctl nella tua workstation di amministrazione, non è necessario scaricarla di nuovo.

Interfaccia a riga di comando gcloud

Assicurati di disporre della versione più recente dell'interfaccia a riga di comando gcloud, inclusi i componenti beta gcloud CLI.
Se non hai ancora i componenti beta, esegui il comando seguente per installarli:
```
gcloud components install beta
```
Aggiorna i componenti dell'interfaccia a riga di comando gcloud, se necessario:
```
gcloud components update
```
Esegui questo comando per accedere con il tuo Account Google:
```
gcloud auth login
```
Elenca i cluster Anthos disponibili sulle versioni bare metal che puoi installare. La versione di bmctl che scarichi per creare l'ambiente bootstrap deve corrispondere a quella che installerai sul cluster di amministrazione.
```
gcloud beta container bare-metal admin-clusters query-version-config \
  --location=REGION
```
Sostituisci REGION con la regione Google Cloud in cui viene eseguita l'API Anthos On-Prem. Specifica us-west1 o un'altra regione supportata.

Crea il cluster bootstrap

Completa i seguenti passaggi sulla tua workstation di amministrazione. Questi comandi vengono visualizzati nella console.

Imposta le tue credenziali utente come credenziali predefinite dell'applicazione:
```
gcloud auth application-default login
```
Segui le istruzioni per selezionare il tuo Account Google per l'ADC.
Se necessario, scarica lo strumento a riga di comando bmctl nella directory di lavoro corrente.
```
gsutil cp gs://anthos-baremetal-release/bmctl/VERSION/linux-amd64/bmctl .
chmod a+x ./bmctl
```
Sostituisci VERSION con la versione di Anthos clusters on bare metal che vuoi installare. Se hai copiato il comando dalla console, la versione è già presente nel comando.
Crea il cluster di bootstrap. Puoi consentire a bmctl di creare gli account di servizio (SA) richiesti oppure puoi creare gli account di servizio e i file delle chiavi e trasferirli al comando bmctl register bootstrap.

`bmctl` crea servizi di assistenza tecnica

Utilizza il comando seguente se vuoi che bmctl crei gli account di servizio richiesti con le autorizzazioni minime necessarie per creare il cluster di amministrazione. Questo comando presuppone che bmctl si trovi nella directory di lavoro corrente.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --name=bootstrap-ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID

Sostituisci quanto segue:

YOUR_PRIVATE_KEY: il percorso della chiave SSH privata. Hai creato la chiave SSH quando hai configurato l'accesso root SSH ai nodi.

Se hai copiato il comando visualizzato nella console, i seguenti campi sono già compilati.

ADMIN_CLUSTER_NAME: il nome del tuo cluster di amministrazione. Il formato del nome del cluster bootstrap deve essere bootstrap-ADMIN_CLUSTER_NAME.
FLEET_HOST_PROJECT_ID: il progetto in cui il cluster di amministrazione verrà registrato automaticamente dopo la creazione del cluster.

Il comando bmctl register bootstrap crea i seguenti account di servizio. Le chiavi dell'account di servizio sono archiviate nella directory bmctl-workspace/.sa-keys.

Account di servizio	Finalità	Ruoli IAM
anthos-baremetal-gcr	Anthos on bare metal utilizza questo account di servizio per scaricare immagini container da Google Container Registry.	Nessuno
connessione-Anthos-Baremetal	L'agente Connect utilizza questo account di servizio per mantenere una connessione tra il cluster e Google Cloud	roles/gkehub.connect
registrazione-anthos-baremetal	L'agente Connect utilizza questo account di servizio per registrare i tuoi cluster nel parco risorse Google Cloud.	roles/gkehub.admin
anthos-baremetal-cloud-ops	L'agente Stackdriver utilizza questo account di servizio per esportare i log e le metriche dai cluster a Cloud Logging e Cloud Monitoring.	roles/logging.logWriter roles/monitoring.metricWriter roles/stackdriver.resourceMetadata.writer roles/opsconfigmonitoring.resourceMetadata.writer roles/monitoring.dashboardEditor

Specifica i file della chiave SA

Se preferisci, puoi trasmettere bmctl i file della chiave dell'account di servizio che hai creato. Il comando seguente utilizza i nomi dei file della chiave in Configura manualmente gli account di servizio e presume che bmctl e i file della chiave si trovino nella directory di lavoro attuale.

./bmctl register bootstrap \
  --ssh-key=YOUR_PRIVATE_KEY \
  --name=bootstrap-ADMIN_CLUSTER_NAME \
  --project-id=FLEET_HOST_PROJECT_ID \
  --gcr-service-account-key=anthos-baremetal-gcr.json \
  --gke-agent-service-account-key=connect-agent.json \
  --gke-register-service-account-key=connect-register.json \
  --cloud-operation-service-account-key=anthos-baremetal-cloud-ops.json

Sostituisci quanto segue:

YOUR_PRIVATE_KEY: il percorso della chiave SSH privata. Hai creato la chiave SSH quando hai configurato l'accesso root SSH ai nodi.
ADMIN_CLUSTER_NAME: il nome del tuo cluster di amministrazione. Il formato del nome del cluster bootstrap deve essere bootstrap-ADMIN_CLUSTER_NAME.
FLEET_HOST_PROJECT_ID: il progetto in cui il cluster di amministrazione verrà registrato automaticamente dopo la creazione del cluster.

I seguenti flag specificano il percorso dei file della chiave:

-gcr-service-account-key: il percorso del file della chiave per l'account di servizio che esegue il pull delle immagini container (anthos-baremetal-gcr).
--gke-agent-service-account-key: il percorso del file della chiave per l'account di servizio dell'agente Connect (anthos-baremetal-connect).
--gke-register-service-account-key: il percorso del file della chiave per l'account di servizio dell'agente Connect che registra il cluster nel parco risorse (anthos-baremetal-register).
--cloud-operation-service-account-key: il percorso del file della chiave per l'account di servizio per eseguire il controllo degli audit log e monitorare i progetti (anthos-baremetal-cloud-ops).

Dopo che bmctl avrà creato correttamente il cluster di bootstrap, visualizzerai un output simile al seguente:

[2023-03-22 17:35:24+0000] Waiting for the temporary cluster to be registered... OK
[2023-03-22 17:35:37+0000] Please go to https://console.cloud.google.com/home/dashboard?project=example-project-12345 to create the cluster
[2023-03-22 17:35:37+0000] Waiting for preflight checks and cluster to run..

Crea il cluster di amministrazione

Console

Nella pagina Installa ambiente bootstrap, fai clic su Verifica connessione.

Se l'operazione riesce, la console mostra Connessione stabilita.

La connessione al cluster bootstrap deve essere stabilita prima di continuare. Se la connessione non è stabilita, controlla gli argomenti che hai specificato nel comando bmctl register bootstrap:
- Assicurati che il valore di --name corrisponda al nome del bootstrap derivato visualizzato nella sezione Nozioni di base sull'ambiente bootstrap.
- Assicurati che il valore di --project-id corrisponda all'ID del progetto selezionato nella console.
Se devi modificare il nome del cluster bootstrap o l'ID progetto, inserisci Ctrl-C per uscire da bmctl register bootstrap ed eseguire nuovamente il comando.
Fai clic su Avanti per iniziare a configurare il cluster di amministrazione. La maggior parte delle impostazioni nella console corrisponde ai campi del file di configurazione del cluster.
In Configurazione nodo, inserisci un valore compreso tra 64 e 250 in Numero massimo di pod per nodo o accetta il valore predefinito, 110. Dopo la creazione del cluster, non puoi aggiornare questo valore.

Il numero massimo di pod per nodo (noto come densità di pod} è limitato anche dalle risorse IP disponibili del tuo cluster. Per maggiori dettagli, consulta Networking dei pod.
Tocca Next (Avanti).
Nella pagina Networking, definisci la modalità di comunicazione tra nodi e componenti del cluster e con il piano di controllo Kubernetes.

Per informazioni dettagliate, tieni il puntatore sul accanto a ciascun campo.
Fai clic su Verifica e crea.

Nella console vengono visualizzati messaggi di stato durante la verifica delle impostazioni e la creazione del cluster nel tuo data center.

Se si verifica un problema con la configurazione, la console visualizza un messaggio di errore che deve essere abbastanza chiaro da consentirti di risolvere il problema di configurazione e riprova a creare il cluster.

Interfaccia a riga di comando gcloud

Prima di creare il cluster di amministrazione, verifica che il cluster di bootstrap sia stato registrato come membro del parco risorse:

gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

Se il cluster bootstrap non è in elenco, controlla il nome e l'ID del progetto bootstrap specificati in bmctl register bootstrap. Se devi modificare il nome del cluster bootstrap o l'ID progetto, inserisci Ctrl-C per uscire da bmctl register bootstrap ed eseguire nuovamente il comando.

Utilizza il comando seguente per creare un cluster di amministrazione:

gcloud beta container bare-metal admin-clusters create

La maggior parte dei flag specificati nel comando corrisponde ai campi nel file di configurazione del cluster utente.

Per creare un cluster di amministrazione con il bilanciatore del carico in bundle:

gcloud beta container bare-metal admin-clusters create ADMIN_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --version=VERSION \
  --max-pods-per-node=MAX_PODS_PER_NODE \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LOAD_BALANCER_PORT \
  --control-plane-node-configs 'CONTROL_PLANE_NODE_CONFIG' \
  --island-mode-service-address-cidr-blocks=SERVICE_ADDR_CIDR \
  --island-mode-pod-address-cidr-blocks=POD_ADDR_CIDR \
  --lvp-share-path=/mnt/localpv-share \
  --lvp-share-storage-class=local-shared \
  --lvp-node-mounts-config-path=/mnt/localpv-disk \
  --lvp-node-mounts-config-storage-class=local-disks

Se vuoi utilizzare il bilanciamento del carico manuale, aggiungi --enable-manual-lb al comando.

Sostituisci quanto segue:

ADMIN_CLUSTER_NAME: il nome del tuo cluster di amministrazione. Il nome non può essere modificato dopo la creazione del cluster.
FLEET_HOST_PROJECT_ID: il progetto in cui il cluster di amministrazione verrà registrato automaticamente dopo la creazione del cluster. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.
REGION: la regione di Google Cloud in cui viene eseguita l'API Anthos On-Prem. Specifica us-west1 o un'altra regione supportata. La regione non può essere modificata dopo la creazione del cluster. Questa impostazione specifica la regione in cui sono archiviati i seguenti elementi:
- I metadati del cluster necessari all'API Anthos On-Prem per gestire il ciclo di vita del cluster
- I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
- Il log di controllo della Console di amministrazione creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.
VERSION: la versione di Anthos clusters on bare metal. La versione deve corrispondere alla versione di bmctl che hai utilizzato per eseguire bmctl register bootstrap. Puoi controllare la versione di bmctl eseguendo bmctl version sulla workstation di amministrazione.
MAX_PODS_PER_NODE : per i cluster di amministrazione, i valori consentiti sono 32-250 e 64-250 per i cluster non ad alta disponibilità. Il valore predefinito se --max-pods-per-node non è incluso nel comando è 110. Una volta creato il cluster, questo valore non può essere aggiornato.

Il numero massimo di pod per nodo (noto come densità di pod) è limitato dalle risorse IP disponibili del tuo cluster. Per maggiori dettagli, consulta Networking dei pod.
CONTROL_PLANE_VIP: l'IP virtuale (VIP) nel bilanciatore del carico del server API Kubernetes del cluster. Includi il VIP del piano di controllo nella stessa subnet dei nodi del bilanciatore del carico. Non includere il VIP del piano di controllo nei pool di indirizzi del bilanciatore del carico.
CONTROL_PLANE_LOAD_BALANCER_PORT: la porta su cui il bilanciatore del carico gestisce il piano di controllo. Anche se puoi configurare un altro valore, la porta 443 è la porta standard utilizzata per le connessioni HTTPS.
CONTROL_PLANE_NODE_CONFIG: l'indirizzo IPv4 di un nodo del piano di controllo. I nodi del piano di controllo eseguono il carico di lavoro del sistema. Specifica questo flag per ciascun nodo del piano di controllo. In genere, hai una singola macchina se utilizzi un deployment minimo o tre macchine se utilizzi un deployment ad alta disponibilità (HA). Specifica un numero dispari di nodi per avere un quorum di maggioranza per l'alta disponibilità. Puoi modificare questi indirizzi ogni volta che aggiorni o esegui l'upgrade del cluster.

Il valore del flag ha il seguente formato:
```
'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
```
Il valore contiene segmenti che iniziano con le parole chiave node-ip e labels. Separa ogni segmento con una virgola.
- node-ip: l'indirizzo IP di un nodo del piano di controllo. Puoi specificare un solo node-ip per flag. Se devi specificare più nodi, includi di nuovo il flag per ciascun nodo.
- labels: una o più coppie chiave-valore collegate al nodo.
Tieni presente le seguenti regole di sintassi:
- Racchiudi l'intero valore tra virgolette singole.
- Non sono consentiti spazi vuoti.
- Separa ogni coppia chiave-valore nel segmento labels con un punto e virgola.
Ecco alcuni esempi:
```
--control-plane-node-configs 'node-ip=192.0.2.1' \
--control-plane-node-configs 'node-ip=192.0.2.2,labels=key2.1=value2.1' \
--control-plane-node-configs 'node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
```
SERVICE_ADDR_CIDR: un intervallo di indirizzi IPv4, in formato CIDR, per i servizi nel cluster. L'intervallo CIDR deve essere compreso tra /24 e /12, dove /12 fornisce il maggior numero di indirizzi IP. Ti consigliamo di utilizzare un intervallo nello spazio di indirizzi IP per i Internet privati, definito in RFC 1918, ad esempio 172.26.232.0/24.
POD_ADDR_CIDR: un intervallo di indirizzi IPv4, in formato CIDR, da utilizzare per i pod nel cluster utente. L'intervallo CIDR deve essere compreso tra /18 e /8, dove /8 fornisce il maggior numero di indirizzi IP. Ti consigliamo di utilizzare un intervallo nello spazio di indirizzi IP per i Internet privati, definito in RFC 1918, ad esempio 192.168.0.0/16.

Devi specificare i seguenti flag di archiviazione. Il comando di esempio include valori tipici. Per maggiori informazioni, consulta la pagina Configurare lo spazio di archiviazione locale.

--lvp-share-path: questo è il percorso della macchina host in cui possono essere create le sottodirectory. Per ogni sottodirectory viene creato un oggetto PersistentVolume (PV) locale.
--lvp-share-storage-class: questo è l'oggetto StorageClass da utilizzare per creare volumi permanenti. Il valore StorageClass viene creato durante la creazione del cluster.
--lvp-node-mounts-config-path: questo è il percorso della macchina host in cui possono essere rilevati i dischi montati. Per ogni montaggio viene creato un oggetto PersistentVolume (PV) locale.
--lvp-node-mounts-config-storage: la classe di archiviazione con cui vengono creati i volumi permanenti durante la creazione del cluster.

Per un elenco completo dei flag e delle relative descrizioni, consulta il riferimento per l'interfaccia a riga di comando gcloud.

L'output del comando è simile al seguente:

Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.

Nell'output di esempio, la stringa operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 è il valore OPERATION_ID dell'operazione a lunga esecuzione. Puoi controllare lo stato dell'operazione con il seguente comando:

gcloud beta container bare-metal operations describe OPERATION_ID \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION

Per ulteriori informazioni, consulta Operazioni beta bare metal del container gcloud.

Correggere gli errori preflight

Prima di creare il cluster, bmctl esegue una serie di controlli preflight per verificare la configurazione. Se si verifica un problema con la configurazione, il comando gcloud ... create esce con un errore simile a:

ERROR: (gcloud.alpha.container.bare-metal.admin-clusters.create) Invalid resource state for "projects/694677185633/locations/us-west1/bareMetalAdminClusters/abm-cluster-1": cluster preflight checks failed

Ad esempio, supponi che un controllo preflight non sia riuscito perché non è stato possibile raggiungere il nodo del piano di controllo. Nella workstation di amministrazione vedrai qualcosa di simile al seguente:

[2023-03-27 20:34:38+0000] Waiting for preflight check job to finish... OK
[2023-03-27 20:35:58+0000] - Validation Category: machines and network
[2023-03-27 20:35:58+0000]    - [PASSED] pod-cidr
[2023-03-27 20:35:58+0000]    - [FAILED] node-network (log: bmctl-workspace/log/register-bootstrap-20230327-201548/node-network)
[2023-03-27 20:35:58+0000]        - Failed to connect to the host via ssh: ssh: connect to host 10.100.0.5 port 22: Connection timed out
[2023-03-27 20:35:58+0000] Flushing logs... OK
[2023-03-27 20:35:58+0000] Error polling the preflight check abm-cluster-mar-27 in the cluster-abm-cluster-mar-27: preflight check failed

Nella workstation di amministrazione, assicurati che il processo bmctl register bootstrap sia ancora in esecuzione. In caso contrario, esegui nuovamente il comando con gli stessi argomenti e aggiungi il flag --reuse-bootstrap-cluster=true.

Esegui gcloud ... update per correggere l'indirizzo IP non valido:

gcloud beta container bare-metal admin-clusters update ADMIN_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --control-plane-node-configs 'node-ip=NEW_NODE_ID_ADDRESS'

Per maggiori informazioni, consulta l'articolo sull'aggiornamento dei cluster di amministrazione bare-metal del container beta gcloud.

I dettagli sul processo di creazione del cluster vengono restituiti sulla tua workstation di amministrazione. Se i controlli preflight vengono superati, vedrai quanto segue:

[2023-03-22 23:12:47+0000] Waiting for cluster kubeconfig to become ready OK
[2023-03-22 23:15:47+0000] Writing kubeconfig file
[2023-03-22 23:15:47+0000] kubeconfig of cluster being created is present at bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig
[2023-03-22 23:15:47+0000] Please restrict access to this file as it contains authentication credentials of your cluster.
[2023-03-22 23:15:47+0000] Waiting for cluster to become ready OK
[2023-03-22 23:20:17+0000] Please run
[2023-03-22 23:20:17+0000] kubectl --kubeconfig bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig get nodes
[2023-03-22 23:20:17+0000] to get cluster nodes status.
[2023-03-22 23:20:17+0000] Waiting for node pools to become ready OK
[2023-03-22 23:20:37+0000] Waiting for metrics to become ready in GCP OK
[2023-03-22 23:25:38+0000] Waiting for cluster API provider to install in the created admin cluster OK
[2023-03-22 23:25:48+0000] Moving admin cluster resources to the created admin cluster
[2023-03-22 23:25:51+0000] Waiting for node update jobs to finish OK
[2023-03-22 23:27:41+0000] Flushing logs... OK
[2023-03-22 23:27:41+0000] Deleting membership... OK
[2023-03-22 23:27:42+0000] Deleting bootstrap cluster.

Connettiti al cluster di amministrazione

Il comando bmctl register bootstrap crea un file kubeconfig per il cluster di amministrazione sulla workstation di amministrazione. La directory in cui si trova kubeconfig e il nome file si basano sul nome del cluster di amministrazione come segue:

bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

Devi limitare l'accesso a questo kubeconfig perché contiene credenziali di autenticazione per il cluster.

Se vuoi utilizzare la tua identità Google per accedere al cluster, puoi configurare il gateway Connect nel seguente modo:

Sulla workstation di amministrazione, imposta la variabile di ambiente KUBECONFIG:

export KUBECONFIG=$HOME/bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

Imposta il contesto corrente in una variabile di ambiente:
```
export CONTEXT="$(kubectl config current-context)"
```

Esegui questo comando gcloud. Il comando seguente:

Concede al tuo account utente il ruolo clusterrole/view Kubernetes sul cluster.
Configura il cluster in modo da poter eseguire i comandi kubectl di sola lettura sul computer locale senza dover accedere tramite SSH alla workstation di amministrazione.

Sostituisci GOOGLE_ACCOUNT_EMAIL con l'indirizzo email associato al tuo account Google Cloud. Ad esempio: --users=alex@example.com.

gcloud container fleet memberships generate-gateway-rbac  \
    --membership=ADMIN_CLUSTER_NAME \
    --role=clusterrole/view \
    --users=GOOGLE_ACCOUNT_EMAIL \
    --project=FLEET_HOST_PROJECT_ID \
    --kubeconfig=$KUBECONFIG \
    --context=$CONTEXT\
    --apply

L'output di questo comando è simile al seguente, troncato per la leggibilità:

Validating input arguments.
Specified Cluster Role is: clusterrole/view
Generated RBAC policy is:
--------------------------------------------
...

Writing RBAC policy for user: GOOGLE_ACCOUNT_EMAIL to cluster.
Successfully applied the RBAC policy to cluster.

Una volta implementati questi criteri RBAC, puoi accedere al cluster dalla console utilizzando la tua identità Google. Inoltre, puoi eseguire comandi kubectl di sola lettura su computer diversi dalla workstation di amministrazione utilizzando uno speciale kubeconfig che instrada le richieste tramite il gateway Connect.

Esegui questo comando su un computer diverso dalla workstation di amministrazione per ottenere la voce kubeconfig che può accedere al cluster tramite il gateway Connect.

gcloud container fleet memberships get-credentials ADMIN_CLUSTER_NAME \
    --project=FLEET_HOST_PROJECT_ID

L'output è simile al seguente:

Starting to build Gateway kubeconfig...
Current project_id: FLEET_HOST_PROJECT_ID
A new kubeconfig entry "connectgateway_FLEET_HOST_PROJECT_ID_global_ADMIN_CLUSTER_NAME" has been generated and set as the current context.

Ora puoi eseguire comandi kubectl tramite il gateway Connect:
```
kubectl get pods -A
```

Crea un cluster di amministrazione utilizzando i client API Anthos On-Prem

Che cos'è l'API Anthos On-Prem?

Autorizzazioni IAM

Accesso da riga di comando

Scegli il client per creare il cluster di amministrazione

Prerequisiti

Console

Interfaccia a riga di comando gcloud

Prepara l'ambiente bootstrap

Console

Interfaccia a riga di comando gcloud

Crea il cluster bootstrap

bmctl crea servizi di assistenza tecnica

Specifica i file della chiave SA

Crea il cluster di amministrazione

Console

Interfaccia a riga di comando gcloud

Connettiti al cluster di amministrazione

Passaggi successivi

`bmctl` crea servizi di assistenza tecnica