Questa pagina è stata tradotta dall'API Cloud Translation.

Creare un cluster utente utilizzando i client dell'API GKE On-Prem

Questa pagina descrive come creare un cluster utente utilizzando la console Google Cloud , Google Cloud CLI (gcloud CLI) o Terraform.

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

L'API GKE On-Prem è un'API ospitata su Google Cloudche ti consente di gestire il ciclo di vita dei tuoi cluster on-premise utilizzando Terraform e applicazioniGoogle Cloud standard. L'API GKE On-Prem viene eseguita nell'infrastruttura di Google Cloud. Terraform, la console e la gcloud CLId sono client dell'API e la utilizzano per creare cluster nel tuo data center.

Per gestire il ciclo di vita dei cluster, l'API GKE On-Prem deve archiviare i metadati sullo stato del cluster in Google Cloud, utilizzando la regioneGoogle Cloud che specifichi 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 GKE On-Prem, specifichi un progettoGoogle Cloud . Dopo la creazione, 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 utente creando un file di configurazione del cluster utente e utilizzando bmctl, come descritto in Creazione di un cluster utente.

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

Prima di iniziare

Questa sezione descrive i requisiti per la creazione di un cluster utente utilizzando i client API GKE On-Prem.

Concedi autorizzazioni IAM

Se non sei il proprietario del progetto, devi disporre del ruolo roles/gkeonprem.admin.

Se vuoi accedere alle pagine Google Kubernetes Engine nella console, devi disporre anche dei seguenti ruoli:

Dopo aver creato il cluster, se non sei il proprietario del progetto e vuoi utilizzare il gateway di connessione per connetterti al cluster utente tramite la riga di comando, sono necessari i seguenti ruoli:

roles/gkehub.gatewayAdmin: Questo ruolo consente di accedere all'API Connect Gateway. Se hai bisogno solo dell'accesso di sola lettura al cluster, è sufficiente roles/gkehub.gatewayReader.
roles/gkehub.viewer: questo ruolo ti consente di recuperare le credenziali del cluster.

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

API di Google obbligatorie

Assicurati che tutte le API di Google richieste siano abilitate nel progetto host del parco risorse.

Se utilizzerai gcloud CLI per creare il cluster, devi abilitare l'API GKE On-Prem. Se utilizzi la console per creare il cluster, l'API GKE On-Prem viene abilitata automaticamente.

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

Prerequisiti del cluster di amministrazione

Prima di poter creare un cluster utente, devi avere un cluster di amministrazione funzionante. Il cluster amministrativo deve:

Avere accesso al server API Kubernetes sul cluster utente dopo la creazione.
Disporre della connettività di rete a tutti i nodi del cluster utente dopo la creazione.
Deve essere registrato in un parco risorse. L'ID progetto configurato nel campo gkeConnect.projectID del cluster di amministrazione, denominato progetto host del parco risorse, deve essere lo stesso progetto in cui creerai il cluster utente.

Prerequisiti delle macchine dei nodi del cluster

Esamina i prerequisiti delle macchine dei nodi del cluster per assicurarti che le macchine che eseguiranno il cluster utente soddisfino i prerequisiti.

Accesso da riga di comando

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

L'ultima versione della gcloud CLI.
kubectl per l'esecuzione di comandi sui cluster Kubernetes. Se devi installare kubectl, segui queste istruzioni.

Creazione di un cluster utente

Puoi utilizzare Terraform, la console Google Cloud o Google Cloud CLI (gcloud CLI) per creare un cluster gestito dall'API GKE On-Prem. Se è la prima volta che installi Google Distributed Cloud, la console potrebbe essere lo strumento più semplice da utilizzare.

Una volta acquisita familiarità con le informazioni da fornire per creare cluster, potresti trovare Terraform o gcloud CLI più pratici, soprattutto se devi creare più di un cluster. Terraform è uno strumento Infrastructure as Code standard del settore. Se la tua organizzazione utilizza già Terraform, probabilmente vorrai utilizzarlo per creare cluster e gestire il ciclo di vita del cluster.

Con la gcloud CLI, puoi salvare il comando con i relativi argomenti in un file di testo e apportare le modifiche necessarie per creare cluster aggiuntivi. Se utilizzi uno strumento CI/CD, come Cloud Build, puoi utilizzare i comandi gcloud per creare un cluster e un pool di nodi e specificare il flag --impersonate-service-account per automatizzare la creazione.

Console

La maggior parte delle impostazioni nella console corrisponde ai campi del file di configurazione del cluster.

Nella console, vai alla pagina Crea un cluster bare metal.

Vai a Crea un cluster bare metal
Seleziona il Google Cloud progetto in cui vuoi creare il cluster. Il progetto selezionato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto a cui è registrato il cluster di amministrazione. Dopo la creazione del cluster utente, questo viene registrato automaticamente nel parco risorse del progetto selezionato.
Fai clic su Avanti per iniziare a configurare il cluster.

Le sezioni seguenti illustrano la procedura di configurazione del cluster utente.

Impostazioni di base del cluster

Inserisci le informazioni di base sul cluster.

Inserisci un nome per il cluster di utenti.
In Cluster di amministrazione, seleziona il cluster di amministrazione dall'elenco.
Nel campo Posizione API Google Cloud, seleziona la regione Google Cloud dall'elenco. Questa impostazione specifica la regione in cui vengono eseguiti i seguenti servizi e API:
- API GKE On-Prem (gkeonprem.googleapis.com)
- Servizio flotta (gkehub.googleapis.com)
- Servizio Connect (gkeconnect.googleapis.com)
Questa impostazione controlla anche la regione in cui vengono archiviati:
- I metadati del cluster utente necessari all'API GKE 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 amministrativo creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.
Seleziona la versione del cluster utente. I cluster utente devono avere la stessa versione secondaria del cluster di amministrazione o una versione secondaria inferiore rispetto a quella del cluster di amministrazione.
In qualità di creatore del cluster, ti vengono concessi i privilegi di amministratore del cluster. (Facoltativo) Inserisci l'indirizzo email di un altro utente che amministrerà il cluster nel campo Utente amministratore.

Quando viene creato il cluster, l'API GKE On-Prem applica i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes al cluster per concedere a te e ad altri utenti amministratori il ruolo Kubernetes clusterrole/cluster-admin, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

Nota: oltre ai criteri RBAC di Kubernetes, devi concedere alcuni ruoli Identity and Access Management (IAM) agli utenti che non sono proprietari del progetto. Per informazioni dettagliate sulla concessione dei ruoli IAM, consulta Concedere i ruoli richiesti.
Nella sezione Configurazione nodo, specifica quanto segue:
- Numero massimo di pod per nodo: inserisci il numero massimo di pod che possono essere eseguiti su un singolo nodo. I valori consentiti sono compresi tra 32 e 250, inclusi. Kubernetes assegna un blocco CIDR (Classless Inter-Domain Routing) a ogni nodo in modo che ogni pod possa avere un indirizzo IP univoco. Le dimensioni del blocco CIDR corrispondono al numero massimo di pod per nodo. Per ulteriori informazioni sull'impostazione del numero massimo di pod per nodo, consulta la sezione Networking dei pod.
- Runtime container: containerd è l'unico runtime container disponibile per il tuo cluster.
Fai clic su Avanti per andare alla sezione Networking.

Networking

In questa sezione, specifica gli indirizzi IP per i nodi, i pod e i servizi del tuo cluster. Se utilizzi il bilanciamento del carico in bundle con MetalLB, devi configurarlo.

Nella sezione del nodo Control plane, inserisci l'indirizzo IPv4 di ciascun nodo del control plane. I nodi del piano di controllo eseguono il carico di lavoro del sistema. In genere, si tratta di una singola macchina se si utilizza un deployment minimo o di tre macchine se si utilizza un deployment ad alta disponibilità (HA). Specifica un numero dispari di nodi per avere un quorum di maggioranza per l'alta disponibilità. Questo campo può essere modificato ogni volta che aggiorni o esegui l'upgrade di un cluster.

Fai clic su + Aggiungi indirizzo IP in base alle esigenze per inserire altri indirizzi IP.
Nella sezione Bilanciatore del carico, seleziona il bilanciatore del carico dall'elenco Modalità da configurare per il cluster. Per maggiori informazioni, consulta la panoramica dei bilanciatori del carico.
Abbinato a MetalLB
Configura il bilanciamento del carico con il bilanciatore del carico MetalLB in bundle. Con questa opzione, Google Distributed Cloud esegue il deployment di bilanciatori del carico di livello 4 che vengono eseguiti su un pool dedicato di nodi worker o sugli stessi nodi del control plane.
1. Nella sezione Node pool del bilanciatore del carico, seleziona una delle seguenti opzioni:
  - Utilizza i nodi del control plane: scegli questa opzione per eseguire i bilanciatori del carico sugli stessi nodi del control plane.
  - Crea node pool del bilanciatore del carico: scegli questa opzione avanzata se devi eseguire i bilanciatori del carico su un pool dedicato di nodi worker. Tutti i nodi nel pool di nodi del bilanciatore del carico devono trovarsi nella stessa subnet di livello 2 degli IP virtuali (VIP) del bilanciatore del carico che configuri nella sezione Pool di indirizzi del bilanciatore del carico.
    
    Nel campo IP del pool di nodi del bilanciatore del carico 1, inserisci un indirizzo IPv4 per un nodo nelpool di nodil del bilanciatore del carico.
    
    Fai clic su + Aggiungi indirizzo IP, se necessario, per inserire altri indirizzi IP.
2. Nella sezione Pool di indirizzi del bilanciatore del carico, aggiungi uno o più pool di indirizzi tra cui il controller MetalLB può scegliere e assegnare ai servizi di tipo LoadBalancer. Il VIP in entrata, che specifichi nella sezione IP virtuali, deve trovarsi in uno di questi pool.
  1. Inserisci un nome per il pool di indirizzi.
  2. Inserisci un intervallo di indirizzi IP nella notazione CIDR (ad esempio: 192.0.2.0/26) o nella notazione di intervallo (ad esempio: 192.0.2.64-192.0.2.72). Per specificare un singolo indirizzo IP in un pool, utilizza /32 nella notazione CIDR (ad esempio: 192.0.2.1/32).
  3. Se l'IP virtuale Ingress non rientra nell'intervallo di indirizzi, seleziona + Aggiungi intervallo di indirizzi IP e inserisci un altro intervallo di indirizzi che includa l'IP virtuale Ingress.
    
    Gli indirizzi IP in ogni pool non possono sovrapporsi e devono trovarsi nella stessa subnet dei nodi del cluster.
  4. Nella sezione Assegnazione di indirizzi IP, seleziona una delle seguenti opzioni:
    
    Automatico: scegli questa opzione se vuoi che il controller MetalLB assegni automaticamente gli indirizzi IP dal pool di indirizzi ai servizi di tipo LoadBalancer.
    
    Manuale: scegli questa opzione se intendi utilizzare gli indirizzi del pool per specificare manualmente gli indirizzi per i servizi di tipo LoadBalancer.
  5. Fai clic su Evita indirizzi IP che presentano bug se vuoi che il controller MetalLB non utilizzi indirizzi del pool che terminano con .0 o .255. In questo modo si evita il problema dei dispositivi di consumo con bug che eliminano per errore il traffico inviato a questi indirizzi IP speciali.
  6. Al termine, fai clic su Fine.
  7. Se necessario, fai clic su Aggiungi pool di indirizzi.
Bilanciatore del carico manuale
Con il bilanciamento del carico manuale, configuri le tue soluzioni di bilanciamento del carico per il traffico del control plane e del data plane. Devi configurare il VIP del control plane sul bilanciatore del carico esterno prima di creare un cluster. Il bilanciatore del carico del control plane esterno può essere utilizzato anche per il traffico del data plane oppure puoi configurare un bilanciatore del carico separato per il data plane. Per saperne di più, consulta Configurare il bilanciamento del carico manuale.
Nella sezione IP virtuali, inserisci quanto segue:
- VIP del control plane: l'indirizzo IP di destinazione da utilizzare per il traffico inviato al server API Kubernetes del cluster utente. Il VIP del control plane deve trovarsi nella stessa subnet dei nodi del bilanciatore del carico e non deve trovarsi in nessuno degli intervalli di indirizzi utilizzati per i pool di indirizzi del bilanciatore del carico.
- Porta: la porta di destinazione utilizzata per il traffico inviato al server API Kubernetes. Il valore predefinito è 443.
- VIP Ingress: l'indirizzo IP da configurare sul bilanciatore del carico per il proxy in entrata. Inserisci un indirizzo da uno dei pool di indirizzi del bilanciatore del carico.
Nella sezione CIDR servizi e pod, specifica gli intervalli di indirizzi IP dei pod e dei servizi Kubernetes nella notazione CIDR. Non devono sovrapporsi tra loro né con indirizzi esterni al cluster che vuoi raggiungere dall'interno del cluster. Ti consigliamo di utilizzare gli intervalli di indirizzi IP privati definiti da RFC 1918. La console fornisce i seguenti intervalli di indirizzi predefiniti, ma puoi modificarli:
- CIDR servizio: 10.96.0.0/20 se non accetti il valore predefinito, inserisci un intervallo CIDR compreso tra /24 e /12, dove /12 fornisce il maggior numero di indirizzi IP.
- CIDR pod: 192.168.0.0/16 se non accetti il valore predefinito, inserisci un intervallo CIDR compreso tra /18 e /8, dove /8 fornisce il maggior numero di indirizzi IP.
Nella sezione degli attributi Attributi avanzati, specifica facoltativamente quanto segue:
- URL del proxy: l'indirizzo HTTP del server proxy. Includi il numero di porta anche se è lo stesso della porta predefinita dello schema, ad esempio: http://my-proxy.example.local:80
- URL: un elenco separato da virgole di indirizzi IP, intervalli di indirizzi IP, nomi host e nomi di dominio che non devono passare attraverso il server proxy. Quando Google Distributed Cloud invia una richiesta a uno di questi indirizzi, host o domini, la richiesta viene inviata direttamente.
Fai clic su Avanti.

Archiviazione

Google Distributed Cloud solo software fornisce interfacce di archiviazione a blocchi e di file. Hanno opzioni predefinite, ma puoi personalizzare le configurazioni. Per saperne di più, consulta Configurare l'archiviazione locale.

(Facoltativo) Puoi configurare quanto segue:
- Nodi montati dal provisioner del volume locale: specifica la configurazione per i PersistentVolumes locali supportati da dischi montati. Devi formattare e montare questi dischi. Puoi farlo prima o dopo la creazione del cluster.
- Condivisione provisioner volume locale: specifica la configurazione per i volumi permanenti locali PersistentVolumes supportati da sottodirectory in un file system condiviso. Queste sottodirectory vengono generate automaticamente durante la creazione del cluster.
Fai clic su Avanti.

Funzionalità

Per aiutarti a monitorare, risolvere i problemi e gestire il cluster, le seguenti funzionalità sono abilitate automaticamente e non possono essere disattivate:

Cloud Logging dei servizi di sistema
Cloud Monitoring dei servizi di sistema
Il log di controllo delle attività di amministrazione

Creare un pool di nodi nella console

Il cluster deve avere almeno un pool di nodi per i nodi worker. Un pool di nodi è un modello per i gruppi di nodi worker creati in questo cluster.

Nella console, configura almeno un pool di nodi (o accetta i valori predefiniti) e poi crea il cluster. Puoi aggiungere altri pool di nodi dopo la creazione del cluster. Con gcloud CLI, crei prima il cluster e poi aggiungi uno o più node pool al cluster appena creato.

Fai clic su Pool predefinito nella barra di navigazione a sinistra.
Nella sezione Valori predefiniti del pool di nodi, inserisci il Nome del pool di nodi o accetta "default-pool" come nome.
Nella sezione Nodi worker, inserisci gli indirizzi IP delle macchine su cui eseguire il cluster.
Nella sezione Metadati del node pool (facoltativo), se vuoi aggiungere etichette e taint di Kubernetes, fai quanto segue:
1. Fai clic su + Aggiungi etichette Kubernetes. Inserisci la Chiave e il Valore per l'etichetta. Ripeti queste operazioni in base alle necessità.
2. Fai clic su + Aggiungi taint. Inserisci Chiave, Valore ed Effetto per la taint. Ripeti queste operazioni in base alle necessità.
Fai clic su Verifica e completa per creare il cluster di utenti. La creazione del cluster utente richiede 15 minuti o più. La console mostra i messaggi di stato mentre verifica le impostazioni e crea il cluster nel data center.

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

Interfaccia a riga di comando gcloud

Utilizza il seguente comando per creare un cluster utente:

gcloud container bare-metal clusters create

Dopo aver creato il cluster, devi creare almeno un pool di nodi utilizzando il seguente comando:

gcloud container bare-metal node-pools create

La maggior parte dei flag per la creazione del cluster e del pool di nodi corrispondono ai campi del file di configurazione del cluster utente. Per aiutarti a iniziare, puoi testare il comando completo nella sezione Esempi. Per informazioni sui flag, consulta le sezioni successive agli esempi o la documentazione di riferimento di gcloud CLI.

Prima di iniziare

La versione selezionata durante la creazione di un cluster utente deve essere una versione supportata dal cluster di amministrazione. Inoltre, le versioni secondarie o patch più recenti non sono disponibili nell'API GKE On-Prem fino a 7-14 giorni dopo il rilascio. Puoi eseguire un comando gcloud per ottenere un elenco delle versioni del cluster supportate che puoi installare.

Assicurati di aggiornare i componenti:
```
gcloud components update
```
Recupera il nome e la posizione di appartenenza al parco risorse del cluster di amministrazione:
```
gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID
```
Sostituisci FLEET_HOST_PROJECT_ID con l'ID del progetto a cui è registrato il cluster di amministrazione.

L'output è simile al seguente:
```
NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
```
La località specifica dove vengono eseguiti i servizi Fleet e Connect. I cluster di amministrazione creati prima della versione 1.28 sono gestiti dai servizi globali Fleet e Connect. Nella versione 1.28 e successive, puoi specificare global o una regione Google Cloud quando crei il cluster di amministrazione. Specifichi la regione nel flag --admin-cluster-membership-location nei comandi di esempio che seguono.
Recupera un elenco delle versioni disponibili da installare sul cluster utente:
```
gcloud container bare-metal clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione.
- FLEET_HOST_PROJECT_ID: l'ID del progetto a cui è registrato il cluster di amministrazione.
- ADMIN_CLUSTER_REGION: la regione di appartenenza del parco del cluster di amministrazione. Può essere globale o una Google Cloud regione. Utilizza la posizione del cluster di amministrazione dall'output di gcloud container fleet memberships list.
- REGION: la Google Cloud regione che utilizzerai quando crei il cluster. Questa è la regione in cui vengono eseguiti l'API GKE On-Prem e i servizi Fleet e Connect. Specifica us-west1 o un'altra regione supportata.
L'output del comando è simile al seguente:
```
versions:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5
```

Ti consigliamo di utilizzare la versione più recente supportata per ottenere le correzioni e i miglioramenti più recenti.

Esempi

Questa sezione fornisce un esempio di comando che crea un cluster utilizzando il bilanciatore del carico MetalLB e un esempio che utilizza un bilanciatore del carico manuale. Le informazioni che specifichi variano a seconda del tipo di bilanciatore del carico che utilizzerai. Per ulteriori informazioni, consulta la Panoramica dei bilanciatori del carico.

Gli esempi creano il cluster senza node pool. Dopo l'avvio del cluster, devi aggiungere un pool di nodi prima di eseguire il deployment dei carichi di lavoro.

MetalLB

Questo esempio mostra come creare un cluster utente con il bilanciatore del carico MetalLB in bundle.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --metal-lb-address-pools='pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --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

Sostituisci quanto segue:

USER_CLUSTER_NAME: un nome a tua scelta per il cluster utente. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve:
- Deve contenere al massimo 40 caratteri.
- contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziare con un carattere alfabetico
- terminare con un carattere alfanumerico
FLEET_HOST_PROJECT_ID: l'ID del progetto in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto a cui è registrato il cluster di amministrazione. Dopo la creazione del cluster utente, questo viene registrato automaticamente nel parco risorse del progetto selezionato. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.
ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. Nel flag --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha il seguente formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
In alternativa, puoi impostare --admin-cluster-membership sul nome del cluster di amministrazione, come nel comando di esempio. Se utilizzi solo il nome del cluster di amministrazione, imposta l'ID progetto del cluster di amministrazione con --admin-cluster-membership-project e la località con --admin-cluster-membership-location. La posizione del cluster di amministrazione è global o una regione Google Cloud . Se devi trovare la regione, esegui gcloud container fleet memberships list.
REGION: la Google Cloud regione in cui vengono eseguiti l'API GKE On-Prem (gkeonprem.googleapis.com), il servizio Fleet (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com). 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 vengono archiviati:
- I metadati del cluster utente necessari all'API GKE 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 amministrativo creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.

Importante: se prevedi di installare Cloud Service Mesh, devi installare la versione 1.19.3 o successive. Questo è necessario perché i servizi Fleet e Connect vengono eseguiti in una regione.
VERSION: la versione di Google Distributed Cloud per il tuo cluster utente.
YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: Se non includi il flag --admin-users, in qualità di creatore del cluster, per impostazione predefinita ti vengono concessi i privilegi di amministratore del cluster. Tuttavia, se includi --admin-users per designare un altro utente come amministratore, esegui l'override del valore predefinito e devi includere sia il tuo indirizzo email sia l'indirizzo email dell'altro amministratore. Ad esempio, per aggiungere due amministratori:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Quando viene creato il cluster, l'API GKE On-Prem applica i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes al cluster per concedere a te e ad altri utenti amministratori il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

Nota:oltre ai criteri RBAC di Kubernetes, devi concedere alcuni ruoli Identity and Access Management (IAM) agli utenti che non sono proprietari del progetto. Per informazioni dettagliate sulla concessione dei ruoli IAM, consulta Concedere i ruoli richiesti.

Pool di indirizzi MetalLB

--metal-lb-address-pools: specifica la configurazione per i pool di indirizzi da utilizzare con il bilanciatore del carico MetalLB. Il valore del flag ha il seguente formato:

'pool=NAME,avoid-buggy-ips=True|False,manual-assign=True|False,addresses=IP_ADDRESS_RANGE_1;IP_ADDRESS_RANGE_2;...' \

Il valore ha segmenti che iniziano con le parole chiave pool, avoid-buggy-ip, manual-assign e addresses. Separa ogni segmento con una virgola.

pool: un nome a tua scelta per il pool.
avoid-buggy-ips: se imposti questo valore su True, il controller MetalLB non assegna indirizzi IP che terminano con .0 o .255 ai servizi. In questo modo si evita il problema dei dispositivi di consumo con bug che eliminano per errore il traffico inviato a questi indirizzi IP speciali. Se non specificato, il valore predefinito è False.
manual-assign: se non vuoi che il controller MetalLB assegni automaticamente gli indirizzi IP da questo pool ai servizi, imposta questo valore su True. Poi uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi del pool. Se non specificato, manual-assign è impostato su False.
Nell'elenco di addresses: ogni indirizzo deve essere un intervallo in formato CIDR o con trattino. Per specificare un singolo indirizzo IP in un pool (ad esempio per il VIP Ingress), utilizza /32 nella notazione CIDR (ad es. 192.0.2.1/32).

Tieni presente le seguenti regole di sintassi:

Racchiudi l'intero valore tra virgolette singole.
Gli spazi vuoti non sono consentiti.
Separa ogni intervallo di indirizzi IP con un punto e virgola.

Puoi specificare più di un'istanza del flag, come mostrato nell'esempio seguente:

--metal-lb-address-pools='pool=pool1,avoid-buggy-ips=False,manual-assign=True,addresses=192.0.2.0/26;192.0.2.64-192.0.2.72'
--metal-lb-address-pools='pool=pool2,avoid-buggy-ips=True,manual-assign=True,addresses=10.251.133.0/24;10.251.134.80/32'

Nodi MetalLB

(Facoltativo) --metal-lb-load-balancer-node-configs: Per impostazione predefinita, il bilanciatore del carico viene eseguito sugli stessi nodi del control plane. Se devi eseguire il bilanciatore del carico su un pool dedicato di nodi worker, specifica questo flag per ogni nodo. Tutti i nodi nel pool di nodi del bilanciatore del carico devono trovarsi nella stessa subnet di livello 2 degli IP virtuali (VIP) del bilanciatore del carico.

Importante: se crei il cluster senza un pool di nodi del bilanciatore del carico dedicato, non puoi aggiungerlo in un secondo momento. Per i cluster configurati con almeno un nodo del bilanciatore del carico, puoi aggiornare il cluster per aggiungere altri nodi al pool di nodi del bilanciatore del carico.

Il valore del flag ha il seguente formato:
```
'node-ip=LB_IP_ADDRESS_1,labels=LB_KEY_1.1=LB_VALUE_1.1;LB_KEY_1.2=LB_VALUE_1.2;...' \
```
Il valore ha 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 nel node pool del bilanciatore del carico. Puoi specificare un solo node-ip per flag. Se devi specificare più di un nodo, includi di nuovo il flag per ogni nodo.
- labels: una o più coppie chiave=valore associate al nodo.
Tieni presente le seguenti regole di sintassi:
- Racchiudi l'intero valore tra virgolette singole.
- Gli spazi vuoti non sono consentiti.
- Separa ogni coppia chiave=valore nel segmento labels con un punto e virgola.
Se specifichi --metal-lb-load-balancer-node-configs, puoi includere facoltativamente i seguenti flag:
- --metal-lb-load-balancer-node-labels: utilizza questo flag per aggiungere etichette a tutti i nodi nel pool di nodi del bilanciatore del carico. Separa l'elenco di coppie chiave=valore con una virgola.
```
--metal-lb-load-balancer-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
```
- --metal-lb-load-balancer-node-taints: utilizza questo flag per aggiungere incompatibilità a tutti i nodi nel pool di nodi del bilanciatore del carico. Ogni taint è una coppia chiave-valore associata a un effetto, che deve essere uno dei seguenti: PreferNoSchedule, NoSchedule o NoExecute.
```
--metal-lb-load-balancer-node-taints=KEY_1=VALUE_1:EFFECT_1,KEY_2=VALUE_2:EFFECT_2
```
L'esempio seguente aggiunge tre nodi al pool di nodi del bilanciatore del carico. Tutti i nodi sono etichettati con lb-pool-key=lb-pool-value e hanno la taint dedicated=experimental:PreferNoSchedule,
```
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.2,labels=key2.1=value2.1' \
--metal-lb-load-balancer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
--metal-lb-load-balancer-node-labels=lb-pool-key=lb-pool-value \
--metal-lb-load-balancer-node-taints=dedicated=experimental:PreferNoSchedule \
```

Nodi del control plane

--control-plane-node-configs: L'indirizzo IPv4 di un nodo del control plane. I nodi del control plane eseguono il carico di lavoro del sistema. Specifica questo flag per ogni nodo del control plane. 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 di un 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 ha 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 control plane. Puoi specificare un solo node-ip per flag. Se devi specificare più di un nodo, includi di nuovo il flag per ogni nodo.
labels: una o più coppie chiave=valore associate al nodo.
Tieni presente le seguenti regole di sintassi:
- Racchiudi l'intero valore tra virgolette singole.
- Gli spazi vuoti non sono consentiti.
- Separa ogni coppia chiave=valore nel segmento labels con un punto e virgola.
Se vuoi, includi i seguenti flag:
--control-plane-node-labels: utilizza questo flag per aggiungere etichette a tutti i nodi del control plane. Separa l'elenco di coppie chiave=valore con una virgola.
```
  --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
```
--control-plane-node-taints: utilizza questo flag per aggiungere incompatibilità a tutti i nodi del control plane. Ogni taint è una coppia chiave-valore associata a un effetto, che deve essere uno dei seguenti: PreferNoSchedule, NoSchedule o NoExecute.
L'esempio seguente aggiunge tre nodi ai nodi del control plane. Tutti i nodi sono etichettati con cp-node-pool-key=cp-node-pool-value e hanno il taint dedicated=experimental:PreferNoSchedule.
```
  --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-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \
```

IP virtuali

CONTROL_PLANE_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.
Esempio: --control-plane-vip=203.0.113.3
CONTROL_PLANE_LB_PORT: la porta su cui il bilanciatore del carico gestisce il server API Kubernetes.
Esempio: -control-plane-load-balancer-port=443
INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.
Esempio: --ingress-vip=10.251.134.80

L'indirizzo IP per il VIP in entrata deve trovarsi in uno dei pool di indirizzi MetalLB.

CIDR servizi e pod

SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i servizi nel cluster. L'intervallo CIDR deve essere compreso tra /24 e /12, dove /12 fornisce il maggior numero di indirizzi IP.
Esempio: --island-mode-service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i pod nel cluster. L'intervallo CIDR deve essere compreso tra /18 e /8, dove /8 fornisce il maggior numero di indirizzi IP.
Esempio: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Archiviazione

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

Per saperne di più sullo spazio di archiviazione, vedi Configurare l'archiviazione locale.

Manuale

Con il bilanciamento del carico manuale, configuri le tue soluzioni di bilanciamento del carico per il traffico del control plane e del data plane. Devi configurare il VIP del control plane sul bilanciatore del carico esterno prima di creare un cluster. Il bilanciatore del carico del control plane esterno può essere utilizzato anche per il traffico del data plane oppure puoi configurare un bilanciatore del carico separato per il data plane. Per saperne di più, consulta Configurare il bilanciamento del carico manuale.

Se necessario, scorri per compilare il segnaposto ADMIN_CLUSTER_NAME per il flag --admin-cluster-membership.

gcloud container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION \
  --version=VERSION \
  --admin-users=YOUR_EMAIL_ADDRESS \
  --admin-users=ANOTHER_EMAIL_ADDRESS \
  --enable-manual-lb \
  --control-plane-node-configs='node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
  --control-plane-vip=CONTROL_PLANE_VIP \
  --control-plane-load-balancer-port=CONTROL_PLANE_LB_PORT \
  --ingress-vip=INGRESS_VIP \
  --island-mode-service-address-cidr-blocks=SERVICE_CIDR_BLOCK \
  --island-mode-pod-address-cidr-blocks=POD_CIDR_BLOCK \
  --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

Sostituisci quanto segue:

USER_CLUSTER_NAME: un nome a tua scelta per il cluster utente. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve:
- Deve contenere al massimo 40 caratteri.
- contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziare con un carattere alfabetico
- terminare con un carattere alfanumerico
FLEET_HOST_PROJECT_ID: l'ID del progetto in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto a cui è registrato il cluster di amministrazione. Dopo la creazione del cluster utente, questo viene registrato automaticamente nel parco risorse del progetto selezionato. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.
ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. Nel flag --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha il seguente formato:
```
    projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME
```
In alternativa, puoi impostare --admin-cluster-membership sul nome del cluster di amministrazione, come nel comando di esempio. Se utilizzi solo il nome del cluster di amministrazione, imposta l'ID progetto del cluster di amministrazione con --admin-cluster-membership-project e la località con --admin-cluster-membership-location. La posizione del cluster di amministrazione è global o una regione Google Cloud . Se devi trovare la regione, esegui gcloud container fleet memberships list.
REGION: la Google Cloud regione in cui vengono eseguiti l'API GKE On-Prem (gkeonprem.googleapis.com), il servizio Fleet (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com). 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 vengono archiviati:
- I metadati del cluster utente necessari all'API GKE 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 amministrativo creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.

Importante: se prevedi di installare Cloud Service Mesh, devi installare la versione 1.19.3 o successive. Questo è necessario perché i servizi Fleet e Connect vengono eseguiti in una regione.
VERSION: la versione di Google Distributed Cloud per il tuo cluster utente.
YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: Se non includi il flag --admin-users, in qualità di creatore del cluster, per impostazione predefinita ti vengono concessi i privilegi di amministratore del cluster. Tuttavia, se includi --admin-users per designare un altro utente come amministratore, esegui l'override del valore predefinito e devi includere sia il tuo indirizzo email sia l'indirizzo email dell'altro amministratore. Ad esempio, per aggiungere due amministratori:
```
    --admin-users=sara@example.com \
    --admin-users=amal@example.com
```
Quando viene creato il cluster, l'API GKE On-Prem applica i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes al cluster per concedere a te e ad altri utenti amministratori il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi.

Nota:oltre ai criteri RBAC di Kubernetes, devi concedere alcuni ruoli Identity and Access Management (IAM) agli utenti che non sono proprietari del progetto. Per informazioni dettagliate sulla concessione dei ruoli IAM, consulta Concedere i ruoli richiesti.

Nodi del control plane

--control-plane-node-configs: L'indirizzo IPv4 di un nodo del control plane. I nodi del control plane eseguono il carico di lavoro del sistema. Specifica questo flag per ogni nodo del control plane. 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 di un 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 ha 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 control plane. Puoi specificare un solo node-ip per flag. Se devi specificare più di un nodo, includi di nuovo il flag per ogni nodo.
labels: una o più coppie chiave=valore associate al nodo.
Tieni presente le seguenti regole di sintassi:
- Racchiudi l'intero valore tra virgolette singole.
- Gli spazi vuoti non sono consentiti.
- Separa ogni coppia chiave=valore nel segmento labels con un punto e virgola.
Se vuoi, includi i seguenti flag:
--control-plane-node-labels: utilizza questo flag per aggiungere etichette a tutti i nodi del control plane. Separa l'elenco di coppie chiave=valore con una virgola.
```
  --control-plane-node-labels=KEY_1=VALUE_1,KEY_2=VALUE_2
```
--control-plane-node-taints: utilizza questo flag per aggiungere incompatibilità a tutti i nodi del control plane. Ogni taint è una coppia chiave-valore associata a un effetto, che deve essere uno dei seguenti: PreferNoSchedule, NoSchedule o NoExecute.
L'esempio seguente aggiunge tre nodi ai nodi del control plane. Tutti i nodi sono etichettati con cp-node-pool-key=cp-node-pool-value e hanno il taint dedicated=experimental:PreferNoSchedule.
```
  --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-planer-node-configs='node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \
  --control-plane-node-labels=cp-node-pool-key=cp-node-pool-value \
  --control-plane-node-taints=dedicated=experimental:PreferNoSchedule \
```

IP virtuali

CONTROL_PLANE_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.
Esempio: --control-plane-vip=203.0.113.3
CONTROL_PLANE_LB_PORT: la porta su cui il bilanciatore del carico gestisce il server API Kubernetes.
Esempio: -control-plane-load-balancer-port=443
INGRESS_VIP: l'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.
Esempio: --ingress-vip=10.251.134.80

L'indirizzo IP per il VIP in entrata deve trovarsi in uno dei pool di indirizzi MetalLB.

CIDR servizi e pod

SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i servizi nel cluster. L'intervallo CIDR deve essere compreso tra /24 e /12, dove /12 fornisce il maggior numero di indirizzi IP.
Esempio: --island-mode-service-address-cidr-blocks=10.96.0.0/20
POD_CIDR_BLOCK: un intervallo di indirizzi IP, in formato CIDR, da utilizzare per i pod nel cluster. L'intervallo CIDR deve essere compreso tra /18 e /8, dove /8 fornisce il maggior numero di indirizzi IP.
Esempio: --island-mode-pod-address-cidr-blocks=192.168.0.0/16

Archiviazione

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

Per saperne di più sullo spazio di archiviazione, vedi Configurare l'archiviazione locale.

Prima di eseguire il comando gcloud per creare il cluster, ti consigliamo di includere --validate-only per convalidare la configurazione specificata nei flag del comando gcloud. Quando è tutto pronto per creare il cluster, rimuovi questo flag ed esegui il comando.

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 OPERATION_ID dell'operazione a lunga esecuzione. Puoi scoprire lo stato dell'operazione con il seguente comando:

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

La creazione del cluster utente richiede almeno 15 minuti. Puoi visualizzare il cluster nella console Google Cloud nella pagina Cluster GKE.

Per un elenco completo dei flag e delle relative descrizioni, consulta la documentazione di riferimento di gcloud CLI.

Crea un node pool

Dopo aver creato il cluster, devi creare almeno un pool di nodi prima di eseguire il deployment dei carichi di lavoro. Un pool di nodi è un modello per i gruppi di nodi worker creati in questo cluster. Con gcloud CLI, crei prima il cluster e poi aggiungi uno o più node pool al cluster appena creato.

gcloud container bare-metal node-pools create NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --location=REGION \
  --node-configs='node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...'

Sostituisci quanto segue:

NODE_POOL_NAME: Un nome a tua scelta per il node pool. Il nome deve:
- Deve contenere al massimo 40 caratteri.
- contenere solo caratteri alfanumerici minuscoli o un trattino (-)
- iniziare con un carattere alfabetico
- terminare con un carattere alfanumerico
USER_CLUSTER_NAME: il nome del cluster utente appena creato.
FLEET_HOST_PROJECT_ID: l'ID del progetto a cui è registrato il cluster.
REGION: La Google Cloud regione che hai specificato durante la creazione del cluster.
--node-configs: L'indirizzo IPv4 di una macchina del nodo di lavoro. Specifica questo flag per ogni nodo. Il valore del flag ha il seguente formato:
```
'node-ip=NP_IP_ADDRESS_1,labels=NP_KEY_1.1=NP_VALUE_1.1;NP_KEY_1.2=NP_VALUE_1.2;...' \
```
Il valore ha 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 worker. Puoi specificare un solo node-ip per flag. Aggiungi di nuovo questo flag per ogni nodo nel pool di nodil.
- labels: una o più coppie chiave=valore associate al nodo.
Tieni presente le seguenti regole di sintassi:
- Racchiudi l'intero valore tra virgolette singole.
- Gli spazi vuoti non sono consentiti.
- Separa ogni coppia chiave=valore nel segmento labels con un punto e virgola.
In via facoltativa, puoi specificare quanto segue:
- --node-labels=KEY=VALUE,...: un elenco separato da virgole di etichette Kubernetes (coppie chiave-valore) applicate a ogni nodo del pool.
- --node-taints=KEY=VALUE:EFFECT,... Un elenco separato da virgole di taint Kubernetes applicati a ogni nodo del pool. Le incompatibilità sono coppie chiave-valore associate a un effetto. Le incompatibilità vengono utilizzate con le tolleranze per la pianificazione dei pod. Specifica uno dei seguenti valori per EFFECT: NoSchedule, PreferNoSchedule, NoExecute.

L'esempio seguente crea un pool di nodi denominato default-pool su user-cluster- e aggiunge due nodi alpool di nodil. Entrambi i nodi sono etichettati con node-pool-key=node-pool-value e hanno il taint dedicated=experimental:PreferNoSchedule.

gcloud container bare-metal node-pools create default-pool \
  --cluster=user-cluster-1  \
  --project=example-project-12345 \
  --location=us-west1 \
  --node-configs='node-ip=10.200.0.10' \
  --node-configs='node-ip=10.200.0.11,labels=key2.1=value2.1' \
  --node-labels=node-pool-key=node-pool-value \
  --node-taints=dedicated=experimental:PreferNoSchedule

Per saperne di più, consulta il riferimento di gcloud CLI.

Terraform

Prima di iniziare

La versione di Google Distributed Cloud (solo software) su bare metal che selezioni durante la creazione di un cluster utente deve essere una versione supportata dal cluster di amministrazione. Inoltre, le versioni secondarie o patch più recenti non sono disponibili nell'API GKE On-Prem fino a 7-14 giorni dopo il rilascio. Puoi eseguire un comando gcloud per ottenere un elenco delle versioni supportate che puoi utilizzare per installare il cluster utente.

Assicurati di aggiornare i componenti:
```
gcloud components update
```
Recupera il nome e la posizione di appartenenza al parco risorse del cluster di amministrazione:
```
gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID
```
Sostituisci FLEET_HOST_PROJECT_ID con l'ID del progetto a cui è registrato il cluster di amministrazione.

L'output è simile al seguente:
```
NAME             EXTERNAL_ID                           LOCATION
admin-cluster-1  bb7803b4-8438-4b22-859f-4559b4b29072  global
admin-cluster-2  ee16ee2b-6ec0-49fc-9413-3c89cbc70854  global
admin-cluster-3  fc2b7ef5-39ff-4b63-b919-04c5adc67be4  us-west1
```
La località specifica dove vengono eseguiti i servizi Fleet e Connect. I cluster di amministrazione creati prima della versione 1.28 sono gestiti dai servizi globali Fleet e Connect. Nella versione 1.28 e successive, puoi specificare global o una regione Google Cloud quando crei il cluster di amministrazione. Specifichi la regione nel flag --admin-cluster-membership-location nei comandi di esempio che seguono.
Recupera un elenco delle versioni disponibili da installare sul cluster utente:
```
gcloud container bare-metal clusters query-version-config \
  --admin-cluster-membership=ADMIN_CLUSTER_NAME \
  --admin-cluster-membership-project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership-location=ADMIN_CLUSTER_REGION \
  --location=REGION
```
Sostituisci quanto segue:
- ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione.
- FLEET_HOST_PROJECT_ID: l'ID del progetto a cui è registrato il cluster di amministrazione.
- ADMIN_CLUSTER_REGION: la regione di appartenenza del parco del cluster di amministrazione. Può essere globale o una Google Cloud regione. Utilizza la posizione del cluster di amministrazione dall'output di gcloud container fleet memberships list.
- REGION: la Google Cloud regione che utilizzerai quando crei il cluster. Questa è la regione in cui vengono eseguiti l'API GKE On-Prem e i servizi Fleet e Connect. Specifica us-west1 o un'altra regione supportata.
L'output del comando è simile al seguente:
```
versions:
- version: 1.16.2
- version: 1.16.1
- version: 1.16.0
- version: 1.15.7
- version: 1.15.6
- version: 1.15.5
```

Ti consigliamo di utilizzare la versione più recente supportata per ottenere le correzioni e i miglioramenti più recenti.

Esempio

Puoi utilizzare il seguente esempio di configurazione di base per creare un cluster utente con il bilanciatore del carico MetalLB in bundle. Per saperne di più, consulta la documentazione di riferimento di google_gkeonprem_bare_metal_cluster.

Imposta le variabili in `terraform.tfvars`

L'esempio fornisce un file di variabili di esempio da passare a main.tf, che mostra come configurare il bilanciatore del carico MetalLB in bundle.

Clona il repository anthos-samples e passa alla directory in cui si trova l'esempio Terraform:
```
git clone https://github.com/GoogleCloudPlatform/anthos-samples
cd anthos-samples/anthos-onprem-terraform/abm_user_cluster_metallb
```
Il campione fornisce un file di variabili di esempio da passare a main.tf.

Crea una copia del file terraform.tfvars.sample:

cp terraform.tfvars.sample terraform.tfvars

Modifica i valori dei parametri in terraform.tfvars e salva il file.
```
project_id          = "PROJECT_ID"
region              = "ON_PREM_API_REGION"
admin_cluster_name  = "ADMIN_CLUSTER_NAME"
bare_metal_version  = "VERSION"
admin_user_emails   = ["YOUR_EMAIL_ADDRESS", "ADMIN_2_EMAIL_ADDRESS"]
cluster_name        = "abm-user-cluster-metallb"
control_plane_ips   = ["10.200.0.4"]
worker_node_ips     = ["10.200.0.5", "10.200.0.6"]
control_plane_vip   = "10.200.0.50"
ingress_vip         = "10.200.0.51"
lb_address_pools    = [
    { name = "lbpool_1", addresses = ["10.200.0.51-10.200.0.70"] }
]
```
Il seguente elenco descrive le variabili:
- project_id: l'ID del progetto in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Dopo la creazione del cluster utente, questo viene registrato automaticamente nel parco risorse del progetto selezionato. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.
- region: la Google Cloud regione in cui vengono eseguiti l'API GKE On-Prem (gkeonprem.googleapis.com), il servizio Fleet (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com). Specifica us-west1 o un'altra regione supportata.
Importante: se prevedi di installare Cloud Service Mesh, devi installare la versione 1.19.3 o successive. Questo è necessario perché i servizi Fleet e Connect vengono eseguiti in una regione.
- admin_cluster_name: il nome del cluster di amministrazione che gestisce il cluster utente. L'esempio presuppone che il cluster di amministrazione utilizzi global come regione. Se hai un cluster di amministrazione regionale:
  1. Apri main.tf in un editor di testo.
  2. Cerca admin_cluster_membership, che ha il seguente aspetto:
```
admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"
```
  3. Modifica global con la regione utilizzata dal cluster di amministrazione e salva il file.
- bare_metal_version: la versione di Google Distributed Cloud per il cluster utente. Specifica la stessa versione del cluster di amministrazione o una versione non inferiore di più di una versione secondaria rispetto al cluster di amministrazione.
- admin_user_emails: un elenco di indirizzi email degli utenti a cui concedere privilegi amministrativi sul cluster. Assicurati di aggiungere il tuo indirizzo email se intendi amministrare il cluster.
  
  Quando viene creato il cluster, l'API GKE On-Prem applica i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes al cluster per concedere agli utenti amministratori il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi. In questo modo, gli utenti possono accedere alla console utilizzando la propria identità Google.
- cluster_name: un nome a tua scelta per il cluster utente. Il nome non può essere modificato dopo la creazione del cluster. Il nome deve:
  - Deve contenere al massimo 40 caratteri.
  - contenere solo caratteri alfanumerici minuscoli o un trattino (-)
  - iniziare con un carattere alfabetico
  - terminare con un carattere alfanumerico
- control_plane_ips: un elenco di uno o più indirizzi IPv4 per i nodi del control plane. I nodi del piano di controllo eseguono il carico di lavoro del sistema. 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 di un cluster.
- worker_node_ips: un elenco di uno o più indirizzi IPv4 per le macchine dei nodi worker.
- control_plane_vip: l'indirizzo IP virtuale (VIP) che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente.
- ingress_vip: L'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il proxy in entrata.
- lb_address_pools: un elenco di mappe che definiscono i pool di indirizzi da utilizzare dal bilanciatore del carico MetalLB. Il VIP in entrata deve trovarsi in uno di questi pool.
Salva le modifiche in terraform.tfvars.
Inizializza e crea il piano Terraform:
```
terraform init
```
Terraform installa tutte le librerie necessarie, ad esempio il provider Google Cloud .
Esamina la configurazione e apporta modifiche, se necessario:
```
terraform plan
```
Applica il piano Terraform per creare il cluster utente:
```
terraform apply
```
La creazione del cluster utente richiede almeno 15 minuti. Puoi visualizzare il cluster nella console Google Cloud nella pagina Cluster GKE.

Connettiti al cluster utente

Quando crei un cluster utente nella console, il cluster viene configurato con i criteri di controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes in modo da poter accedere al cluster utilizzando la tua identità Google Cloud . Quando crei un cluster utente con gcloud CLI, per impostazione predefinita ti vengono concessi questi criteri RBAC se non includi il flag --admin-users. Se includi --admin-users per designare un altro utente come amministratore, esegui l'override del valore predefinito e devi includere sia il tuo indirizzo email sia quello dell'altro amministratore. Per saperne di più sulle norme IAM e RBAC richieste, consulta Configurare l'autenticazione dell'identità Google.

Tutti i cluster hanno un endpoint canonico. L'endpoint espone il server API Kubernetes che kubectl e altri servizi utilizzano per comunicare con il control plane del cluster tramite la porta TCP 443. Questo endpoint non è accessibile su internet pubblico. Se hai accesso all'endpoint privato del cluster tramite il VPC, puoi connetterti direttamente all'endpoint privato e generare direttamente un file kubeconfig. In caso contrario, puoi utilizzare connect gateway.

Per accedere al cluster utente dalla riga di comando, è necessario un file kubeconfig. Esistono due modi per ottenere un file kubeconfig:

Utilizza il gateway di connessione per accedere al cluster da un computer su cui è installata Google Cloud CLI. In questo caso, kubectl utilizza kubeconfig del gateway Connect, che inoltra in modo sicuro il traffico all'endpoint privato per tuo conto.
Per l'accesso diretto agli endpoint privati, crea un file kubeconfig sulla workstation di amministrazione e gestisci il cluster dalla workstation di amministrazione.

Assicurati di attendere finché la console Google Cloud non indica che lo stato del cluster utente è integro.

Connettere il gateway

Inizializza gcloud CLI per l'utilizzo con il progetto host del parco risorse oppure esegui i seguenti comandi per accedere con il tuo Account Google, impostare il progetto host del parco risorse come predefinito e aggiornare i componenti:
```
gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update
```
Recupera le credenziali del cluster utilizzate per interagire con Connect Gateway. Nel comando seguente, sostituisciMEMBERSHIP_NAME con il nome del tuo cluster. Per Google Distributed Cloud (solo software) su bare metal, il nome dell'appartenenza è uguale al nome del cluster.
```
gcloud container fleet memberships get-credentials MEMBERSHIP_NAME
```
Questo comando restituisce un gateway di connessione specifico kubeconfig che ti consente di connetterti al cluster tramite il gateway.

Una volta ottenute le credenziali necessarie, puoi eseguire i comandi utilizzando kubectl come faresti normalmente per qualsiasi cluster Kubernetes e non devi specificare il nome del file kubeconfig, ad esempio:

kubectl get namespaces

Workstation di amministrazione

Utilizza il comando bmctl get credentials per recuperare un file kubeconfig per il cluster utente appena creato.

bmctl get credentials --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG_PATH

Sostituisci quanto segue:

CLUSTER_NAME: il nome del cluster utenti di destinazione.
ADMIN_KUBECONFIG_PATH: il percorso del file kubeconfig del cluster di amministrazione.

Un kubeconfig con le credenziali del cluster utente viene scritto in un file, bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. Il TIMESTAMP nel nome file indica la data e l'ora di creazione del file.

Poiché questo file contiene le credenziali di autenticazione per il tuo cluster, devi archiviarlo in una posizione sicura con accesso limitato.

Creare un cluster utente utilizzando i client dell'API GKE On-Prem Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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

Prima di iniziare

Concedi autorizzazioni IAM

API di Google obbligatorie

Prerequisiti del cluster di amministrazione

Prerequisiti delle macchine dei nodi del cluster

Accesso da riga di comando

Creazione di un cluster utente

Console

Impostazioni di base del cluster

Networking

Abbinato a MetalLB

Bilanciatore del carico manuale

Archiviazione

Funzionalità

Creare un pool di nodi nella console

Interfaccia a riga di comando gcloud

Prima di iniziare

Esempi

MetalLB

Pool di indirizzi MetalLB

Nodi MetalLB

Nodi del control plane

IP virtuali

CIDR servizi e pod

Archiviazione

Manuale

Nodi del control plane

IP virtuali

CIDR servizi e pod

Archiviazione

Crea un node pool

Terraform

Prima di iniziare

Esempio

Imposta le variabili in terraform.tfvars

Connettiti al cluster utente

Connettere il gateway

Workstation di amministrazione

Passaggi successivi

Creare un cluster utente utilizzando i client dell'API GKE On-Prem

Imposta le variabili in `terraform.tfvars`