Crea un cluster utente utilizzando i client API Anthos On-Prem

Questa pagina descrive come creare un cluster utente utilizzando la console Google Cloud, l'interfaccia a riga di comando gcloud (gcloud CLI) di Google Cloud o Terraform.

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 utente creando un file di configurazione del cluster utente e utilizzando bmctl, come descritto nella sezione Creazione di un cluster utente.

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

Prima di iniziare

Questa sezione descrive i requisiti per creare un cluster utente utilizzando i client API Anthos On-Prem.

Concedi le autorizzazioni IAM

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

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

Dopo la creazione del cluster, se non sei un proprietario del progetto e vuoi utilizzare il gateway Connect per connettersi al cluster utente dalla riga di comando, sono richiesti i ruoli seguenti:

  • roles/gkehub.gatewayAdmin: questo ruolo ti consente di accedere all'API Connect gateway. Se hai bisogno dell'accesso di sola lettura al cluster, il valore roles/gkehub.gatewayReader è sufficiente.

  • roles/gkehub.viewer: questo ruolo 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 richieste

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

Se utilizzerai l'interfaccia alla gcloud CLI per creare il cluster, devi abilitare l'API Anthos On-Prem. Se utilizzi la console per creare il cluster, abilita automaticamente l'API Anthos On-Prem.

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 di amministrazione deve:

  • Hanno accesso al server API Kubernetes nel cluster utente dopo la sua creazione.

  • Dispongono della connettività di rete per tutti i nodi nel cluster utente dopo la creazione.

  • Deve essere registrata in un flotta. L'ID progetto configurato nel campo gkeConnect.projectID del cluster di amministrazione, denominato progetto host del parco risorse, deve essere lo stesso in cui creerai il cluster utente.

Prerequisiti delle macchine dei nodi del cluster

Esamina i prerequisiti della macchina del nodo 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 Connect per eseguire kubectl sul cluster utente su computer diversi dalla workstation di amministrazione, installa i seguenti strumenti a riga di comando sul computer che prevedi di utilizzare.

Creazione di un cluster utente

Puoi utilizzare Terraform, la console Google Cloud o l'interfaccia a riga di comando gcloud CLI) Google Cloud per creare un cluster gestito dall'API Anthos On-Prem. Se è la prima volta che installi Anthos clusters on bare metal, potresti trovare la console lo strumento più semplice da utilizzare.

Dopo aver acquisito familiarità con le informazioni che devi fornire per creare i cluster, potresti trovare più facilmente Terraform o lgcloud CLI, in particolare se creerai più di un cluster. Terraform è uno strumento di Infrastructure as Code standard di settore. Se la tua organizzazione utilizza già Terraform, probabilmente lo utilizzerai per la creazione dei cluster e la gestione del ciclo di vita dei cluster.

Con l'interfaccia a riga di comando gcloud, puoi salvare il comando con i suoi 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 usare 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.

  1. Nella console Google Cloud, vai alla pagina Cluster Anthos.

    Vai a Cluster Anthos di Anthos

  2. Seleziona il progetto Google Cloud in cui vuoi creare il cluster. Il progetto selezionato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Una volta creato, il cluster utente viene registrato automaticamente nel parco risorse del progetto selezionato.

  3. Fai clic su Crea cluster.

  4. Nella finestra di dialogo, fai clic su On-premise.

  5. Accanto a Bare metal, fai clic su Configure (Configura).

  6. Esamina i prerequisiti e l'architettura di esempio. Al termine, fai clic su Avanti per iniziare a configurare il cluster.

Le seguenti sezioni illustrano come configurare il cluster utente.

Impostazioni di base del cluster

Inserisci le informazioni di base sul cluster.

  1. Inserisci un nome per il cluster utente.

  2. In Cluster di amministrazione, seleziona il cluster di amministrazione dall'elenco.

  3. Nel campo Posizione API di Google Cloud, seleziona la regione 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 metadati del cluster utente necessari per l'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.

  4. Seleziona la versione di Anthos clusters on bare metal per il tuo cluster utente. I cluster utente devono avere la stessa versione secondaria del cluster di amministrazione o una versione secondaria inferiore rispetto al cluster di amministrazione.

  5. In qualità di creatore del cluster, ti vengono concessi i privilegi amministrativi del cluster. Facoltativamente, inserisci l'indirizzo email di un altro utente che amministrerà il cluster nel campo Utente amministratore.

    Quando viene creato il cluster, l'API Anthos On-Prem applica i criteri di controllo dell'accesso basati sui ruoli (RBAC) di Kubernetes al cluster per concedere a te e agli altri utenti amministratori il ruolo Kubernetes clusterrole/cluster-admin, che fornisce l'accesso completo a ogni risorsa nel cluster in tutti gli spazi dei nomi.

  6. 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 ciascun 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 saperne di più sull'impostazione del numero massimo di pod per nodo, networking dei pod.

    • Runtime container: containerd è l'unico runtime del container disponibile per il cluster.

  7. Fai clic su Avanti per andare alla sezione Networking.

Networking

In questa sezione specifichi gli indirizzi IP dei nodi, dei pod e dei servizi del tuo cluster. Se utilizzi il bilanciamento del carico in bundle con MetalLB, configura anche questo.

  1. Nella sezione Nodo del piano di controllo, inserisci l'indirizzo IPv4 di ogni nodo del piano di controllo. I nodi del piano di controllo eseguono il carico di lavoro del sistema. In genere, può trattarsi di una singola macchina se utilizzi un deployment minimo o di tre macchine se utilizzi un deployment ad alta disponibilità. 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 come necessario per inserire altri indirizzi IP.

  2. Nella sezione Bilanciatore del carico, seleziona il bilanciatore del carico dall'elenco Modalità da configurare per il cluster. Per ulteriori 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, Anthos clusters on bare metal 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 piano di controllo.

    1. Nella sezione Pool di nodi del bilanciatore del carico, seleziona una delle seguenti opzioni:

      • Utilizza i nodi del piano di controllo: scegli questa opzione per eseguire i bilanciatori del carico sugli stessi nodi del piano di controllo.

      • Crea pool di nodi 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 hai configurato nella sezione Pool di indirizzi del bilanciatore del carico.

        1. Nel campo IP di pool di nodi del bilanciatore del carico 1, inserisci un indirizzo IPv4 per un nodo nel pool di nodi del bilanciatore del carico.

        2. Fai clic su + Aggiungi indirizzo IP secondo necessità per inserire indirizzi IP aggiuntivi.

    2. Nella sezione Pool di indirizzi del bilanciatore del carico, aggiungi uno o più pool di indirizzi per il controller MetalLB tra cui scegliere e assegnali ai servizi di tipo LoadBalancer. Il VIP Ingress, specificato 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 in notazione CIDR (ad esempio 192.0.2.0/26) o 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 il VIP Ingress non è compreso nell'intervallo, seleziona + Aggiungi intervallo di indirizzi IP e inserisci un altro intervallo che includa il VIP Ingress.

        Gli indirizzi IP in ogni pool non possono sovrapporsi e devono trovarsi nella stessa subnet dei nodi del cluster.

      4. In Assegnazione di indirizzi IP, seleziona una delle seguenti opzioni:

        • Automatica: 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 errori relativi a indirizzi IP se vuoi che il controller MetalLB non utilizzi indirizzi del pool che terminano con .0 o .255. Questo evita il problema di dispositivi consumer buggy che fanno cadere erroneamente il traffico inviato a quegli 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 manuale del carico, configuri le tue soluzioni di bilanciamento del carico per il traffico del piano di controllo e del piano dati. Prima di creare un cluster, devi configurare il VIP del piano di controllo sul bilanciatore del carico esterno. Il bilanciatore del carico del piano di controllo esterno può essere utilizzato anche per il traffico del piano dati, oppure puoi configurare un bilanciatore del carico separato per il piano dati. Per maggiori informazioni, consulta la pagina Configurare il bilanciamento del carico manuale.

  3. Nella sezione IP virtuali, inserisci quanto segue:

    • VIP del piano di controllo: l'indirizzo IP di destinazione da utilizzare per il traffico inviato al server API Kubernetes del cluster utente. Il VIP del piano di controllo deve trovarsi nella stessa subnet dei nodi del bilanciatore del carico e non deve rientrare in nessun intervallo di indirizzi utilizzato 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.

    • In entrata VIP: l'indirizzo IP da configurare nel bilanciatore del carico per il proxy in entrata. Inserisci un indirizzo da uno dei pool di indirizzi del bilanciatore del carico.

  4. Nella sezione Service e CIDR CIDR, 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 del servizio: 10.96.0.0/20 se non accetti il valore predefinito, inserisci un intervallo CIDR compreso tra /24 e /12, dove /12 fornirà 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 fornirà il maggior numero di indirizzi IP.

  5. Nella sezione Attributi avanzati, specifica facoltativamente quanto segue:

    • URL del proxy: l'indirizzo HTTP del server proxy. Includi il numero della porta anche se è la stessa 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 Anthos clusters on bare metal invia una richiesta a uno di questi indirizzi, host o domini, la richiesta viene inviata direttamente.

  6. Tocca Next (Avanti).

Archiviazione

Anthos clusters on bare metal offre 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.

  1. Facoltativamente, puoi configurare quanto segue:

    • Montaggi del nodo del provisioner del volume locale: specifica la configurazione per i PersistentVolumes (PV) locali supportati da dischi montati. Devi formattare e montare questi dischi. Puoi farlo prima o dopo la creazione del cluster.

    • Condivisione del provisioner del volume locale: specifica la configurazione per PersistentVolumes locale supportata dalle sottodirectory in un file system condiviso. Queste sottodirectory vengono generate automaticamente durante la creazione del cluster.

  2. Tocca Next (Avanti).

Funzionalità

Per aiutarti a monitorare, risolvere i problemi e gestire il cluster, vengono abilitati automaticamente e non possono essere disabilitati:

Crea un pool di nodi

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, configuri almeno un pool di nodi (o accetti i valori predefiniti), quindi crei il cluster. Puoi aggiungere altri pool di nodi dopo la creazione del cluster. Con gcloud CLI, devi prima creare il cluster, quindi aggiungere uno o più pool di nodi al cluster appena creato.

  1. Fai clic su pool predefinito nella barra di navigazione a sinistra.

  2. Nella sezione Valori predefiniti pool di nodi, inserisci il Nome pool di nodi o accetta come "default-pool"

  3. Nella sezione Nodi worker, inserisci gli indirizzi IP delle macchine su cui deve essere eseguito il cluster.

  4. Nella sezione Metadati del pool di nodi (facoltativo), se vuoi aggiungere etichette e incompatibilità Kubernetes, segui questi passaggi:

    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 incompatibilità. Inserisci la chiave, il valore e l'effetto dell'incompatibilità. Ripeti queste operazioni in base alle necessità.

  5. Fai clic su Verifica e completa per creare il cluster utente. La creazione del cluster utente richiede almeno 15 minuti. La console visualizza 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 deve essere abbastanza chiaro da consentirti di risolvere il problema di configurazione e riprova a creare il cluster.

Interfaccia a riga di comando gcloud

Per creare un cluster utente, utilizza il comando seguente:

gcloud beta container bare-metal clusters create

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

gcloud beta container bare-metal node-pools create

La maggior parte dei flag per la creazione del cluster e del pool di nodi corrisponde ai campi nel file di configurazione del cluster utente. Per iniziare, puoi testare il comando completo nella sezione Esempi. Per informazioni sui flag, consulta le sezioni che seguono gli esempi o consulta il riferimento per l'interfaccia a riga di comando gcloud.

Prima di iniziare

  1. Accedi con il tuo Account Google.

    gcloud auth login

  2. Assicurati di aggiornare i componenti:

    gcloud components update

Esempi

Questa sezione fornisce un esempio di comando che crea un cluster utilizzando il bilanciatore del carico MetalLB e un esempio di uso di un bilanciatore del carico manuale. Le informazioni specificate 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 pool di nodi. Dopo aver eseguito il cluster, devi aggiungere un pool di nodi prima di eseguire il deployment dei carichi di lavoro.

MetalLB

Assicurati di scorrere se necessario per compilare il segnaposto ADMIN_CLUSTER_NAME per il flag --admin-cluster-membership.

gcloud beta container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --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:
    • contengono al massimo 40 caratteri
    • contengono solo caratteri alfanumerici minuscoli o un trattino (-)
    • inizia con un carattere alfabetico
    • terminano 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 in cui è registrato il cluster di amministrazione. Una volta creato, il cluster utente 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. Il nome del cluster di amministrazione è l'ultimo segmento del nome del cluster completamente specificato che identifica in modo univoco il cluster in Google Cloud: projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
  • 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 utente necessari per l'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 per il tuo cluster utente.
  • YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se non includi il flag --admin-users, come creatore del cluster ti vengono concessi i privilegi amministrativi del cluster. Tuttavia, se includi --admin-users per designare un altro utente come amministratore, devi sostituire l'impostazione predefinita e 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 Anthos On-Prem applica i criteri di controllo dell'accesso dell'accesso basato sui ruoli (RBAC) di Kubernetes al cluster per concedere a te e agli altri utenti amministrativi il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a ogni risorsa nel cluster in tutti gli spazi dei nomi.

Pool di indirizzi MetalLB

  • --metal-lb-address-pools: specifica la configurazione per i pool di indirizzi che devono essere utilizzati dal 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 contiene 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 la piscina.

  • avoid-buggy-ips: se lo imposti su True, il controller MetalLB non assegnerà agli indirizzi IP che terminano con .0 o .255. In questo modo, è possibile evitare il problema di dispositivi consumer buggy che eliminano erroneamente il traffico inviato a quegli 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, impostalo su True. 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 addresses: ogni indirizzo deve essere un intervallo in formato CIDR o con intervallo con trattini. 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.
  • Non sono consentiti spazi vuoti.
  • Separa ogni intervallo di indirizzi IP con un punto e virgola.

Puoi specificare più istanze 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 piano di controllo. Se devi eseguire il bilanciatore del carico su un pool dedicato di nodi worker, specifica questo flag per ciascun 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.

    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 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 nel tuo pool di nodi 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 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.

    Se specifichi --metal-lb-load-balancer-node-configs, puoi facoltativamente includere 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 delle 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 incompatibilità è una coppia chiave-valore associata a un effetto, che deve essere una delle 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 l'incompatibilità 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 piano di controllo

  • --control-plane-node-configs: 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 sola 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 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ù di un nodo, 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.

    Facoltativamente, includi i seguenti flag:

  • --control-plane-node-labels: utilizza questo flag per aggiungere etichette a tutti i nodi del piano di controllo. Separa l'elenco delle 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 piano di controllo. Ogni incompatibilità è una coppia chiave=valore associata a un effetto, che deve essere una delle seguenti: PreferNoSchedule, NoSchedule o NoExecute.

    L'esempio seguente aggiunge tre nodi ai nodi del piano di controllo. Tutti i nodi sono etichettati con cp-node-pool-key=cp-node-pool-value e hanno l'incompatibilità 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 di Kubernetes del cluster utente.

    Esempio: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: la porta sulla quale 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 del VIP Ingress 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

  1. --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.
  2. --lvp-share-storage-class: questo è l'oggetto StorageClass da utilizzare per creare volumi permanenti. Il valore StorageClass viene creato durante la creazione del cluster.
  3. --lvp-node-mounts-config-path: questo è il percorso della macchina host in cui è possibile rilevare i dischi montati. Per ogni montaggio viene creato un oggetto PersistentVolume (PV) locale.
  4. --lvp-node-mounts-config-storage: la classe di archiviazione con cui vengono creati i volumi permanenti durante la creazione del cluster.

Per maggiori informazioni sullo spazio di archiviazione, vedi Configurare lo spazio di archiviazione locale.

Manuale

Con il bilanciamento manuale del carico, configuri le tue soluzioni di bilanciamento del carico per il traffico del piano di controllo e del piano dati. Prima di creare un cluster, devi configurare il VIP del piano di controllo sul bilanciatore del carico esterno. Il bilanciatore del carico del piano di controllo esterno può essere utilizzato anche per il traffico del piano dati, oppure puoi configurare un bilanciatore del carico separato per il piano dati. Per maggiori informazioni, consulta la pagina Configurare il bilanciamento del carico manuale.

Assicurati di scorrere se necessario per compilare il segnaposto ADMIN_CLUSTER_NAME per il flag --admin-cluster-membership.

gcloud beta container bare-metal clusters create USER_CLUSTER_NAME \
  --project=FLEET_HOST_PROJECT_ID \
  --admin-cluster-membership=projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME \
  --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:
    • contengono al massimo 40 caratteri
    • contengono solo caratteri alfanumerici minuscoli o un trattino (-)
    • inizia con un carattere alfabetico
    • terminano 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 in cui è registrato il cluster di amministrazione. Una volta creato, il cluster utente 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. Il nome del cluster di amministrazione è l'ultimo segmento del nome del cluster completamente specificato che identifica in modo univoco il cluster in Google Cloud: projects/FLEET_HOST_PROJECT_ID/locations/global/memberships/ADMIN_CLUSTER_NAME
  • 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 utente necessari per l'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 per il tuo cluster utente.
  • YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: se non includi il flag --admin-users, come creatore del cluster ti vengono concessi i privilegi amministrativi del cluster. Tuttavia, se includi --admin-users per designare un altro utente come amministratore, devi sostituire l'impostazione predefinita e 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 Anthos On-Prem applica i criteri di controllo dell'accesso dell'accesso basato sui ruoli (RBAC) di Kubernetes al cluster per concedere a te e agli altri utenti amministrativi il ruolo clusterrole/cluster-admin di Kubernetes, che fornisce l'accesso completo a ogni risorsa nel cluster in tutti gli spazi dei nomi.

Nodi del piano di controllo

  • --control-plane-node-configs: 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 sola 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 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ù di un nodo, 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.

    Facoltativamente, includi i seguenti flag:

  • --control-plane-node-labels: utilizza questo flag per aggiungere etichette a tutti i nodi del piano di controllo. Separa l'elenco delle 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 piano di controllo. Ogni incompatibilità è una coppia chiave=valore associata a un effetto, che deve essere una delle seguenti: PreferNoSchedule, NoSchedule o NoExecute.

    L'esempio seguente aggiunge tre nodi ai nodi del piano di controllo. Tutti i nodi sono etichettati con cp-node-pool-key=cp-node-pool-value e hanno l'incompatibilità 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 di Kubernetes del cluster utente.

    Esempio: --control-plane-vip=203.0.113.3

  • CONTROL_PLANE_LB_PORT: la porta sulla quale 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 del VIP Ingress 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

  1. --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.
  2. --lvp-share-storage-class: questo è l'oggetto StorageClass da utilizzare per creare volumi permanenti. Il valore StorageClass viene creato durante la creazione del cluster.
  3. --lvp-node-mounts-config-path: questo è il percorso della macchina host in cui è possibile rilevare i dischi montati. Per ogni montaggio viene creato un oggetto PersistentVolume (PV) locale.
  4. --lvp-node-mounts-config-storage: la classe di archiviazione con cui vengono creati i volumi permanenti durante la creazione del cluster.

Per maggiori informazioni sullo spazio di archiviazione, vedi Configurare lo spazio di archiviazione locale.

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

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

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

Crea un pool di nodi

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, devi prima creare il cluster, quindi aggiungere uno o più pool di nodi al cluster appena creato.

gcloud beta 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 pool di nodi. Il nome deve:

    • contengono al massimo 40 caratteri
    • contengono solo caratteri alfanumerici minuscoli o un trattino (-)
    • inizia con un carattere alfabetico
    • terminano con un carattere alfanumerico

  • USER_CLUSTER_NAME: il nome del cluster utente appena creato.

  • FLEET_HOST_PROJECT_ID: l'ID del progetto in cui è registrato il cluster.

  • REGION: la regione Google Cloud che hai specificato al momento della creazione del cluster.

  • --node-configs: L'indirizzo IPv4 di una macchina nodo worker. Specifica questo flag per ciascun 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 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 worker. Puoi specificare un solo node-ip per flag. Aggiungi di nuovo questo flag per ciascun nodo nel pool di nodi.

    • 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.

    Facoltativamente, puoi specificare quanto segue:

    • --node-labels=KEY=VALUE,...: un elenco separato da virgole di etichette Kubernetes (coppie chiave=valore) applicate a ciascun nodo nel pool.

    • --node-taints=KEY=VALUE:EFFECT,... Un elenco separato da virgole di incompatibilità Kubernetes applicate a ciascun nodo nel pool. le incompatibilità sono coppie chiave=valore associate a un effetto. Le incompatibilità vengono utilizzate con le tolleranze per la pianificazione dei pod. Specifica una delle seguenti opzioni per EFFECT: NoSchedule, PreferNoSchedule, NoExecute.

L'esempio seguente crea un pool di nodi denominato default-pool su user-cluster- e aggiunge due nodi al pool. Tutti i nodi sono etichettati con node-pool-key=node-pool-value e hanno l'incompatibilità dedicated=experimental:PreferNoSchedule,

gcloud beta 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 ulteriori informazioni, consulta il riferimento per l'interfaccia a riga di comando gcloud.

Terraform

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

  1. Clona il repository anthos-samples e passa alla directory in cui si trova l'esempio di Terraform:

    git clone https://github.com/GoogleCloudPlatform/anthos-samples
cd anthos-samples/anthos-onprem-terraform/abm_user_cluster_metallb

    Nell'esempio è fornito un file di variabili di esempio da trasmettere a main.tf.

  2. Crea una copia del file terraform.tfvars.sample:

    cp terraform.tfvars.sample terraform.tfvars
    anthos-onprem-terraform/abm_user_cluster_metallb/terraform.tfvars.sample 
    
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"] }
]

  3. Modifica i valori dei parametri in terraform.tfvars e salva il file.

    Nell'elenco che segue vengono descritte 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. Una volta creato, il cluster utente 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 regione di Google Cloud in cui viene eseguita l'API Anthos On-Prem. Specifica us-west1 o un'altra regione supportata.

    • admin_cluster_name: il nome del cluster di amministrazione che gestisce il cluster utente.

    • bare_metal_version: la versione di Anthos clusters on bare metal per il tuo cluster utente. Specifica la stessa versione del cluster di amministrazione o una versione che non sia più di una versione secondaria inferiore al cluster di amministrazione.

    • 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:

      • contengono al massimo 40 caratteri
      • contengono solo caratteri alfanumerici minuscoli o un trattino (-)
      • inizia con un carattere alfabetico
      • terminano con un carattere alfanumerico

    • control_plane_ips: un elenco di uno o più indirizzi IPv4 per i nodi del piano di controllo. I nodi del piano di controllo eseguono il carico di lavoro del sistema. In genere, hai una sola 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 con 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 che devono essere utilizzati dal bilanciatore del carico MetalLB. Il VIP Ingress deve essere in uno di questi pool.

    • admin_user_emails: un elenco di indirizzi email degli utenti a cui concedere i privilegi amministrativi sul cluster. Assicurati di aggiungere il tuo indirizzo email se intendi amministrare il cluster.

    Quando viene creato il cluster, l'API Anthos On-Prem applica i criteri di controllo dell'accesso basati 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 ogni risorsa nel cluster in tutti gli spazi dei nomi. In questo modo gli utenti possono anche accedere alla console utilizzando la propria identità Google.

  4. Salva le modifiche in terraform.tfvars.

  5. Inizializza e crea il piano Terraform:

    terraform init

    Terraform installa le librerie necessarie, ad esempio il provider Google Cloud.

  6. Rivedi la configurazione e apporta modifiche, se necessario:

    terraform plan

  7. 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 Anthos.

Connettiti al cluster utente

Quando crei un cluster utente nella console, il cluster viene configurato con i criteri di controllo dell'accesso basati sui ruoli (RBAC) di Kubernetes, in modo da poter accedere al cluster utilizzando la tua identità Google Cloud. Quando crei un cluster utente con l'interfaccia alla gcloud CLI, per impostazione predefinita ti vengono mostrati i criteri RBAC se non includi il flag --admin-users. Se includi --admin-users per designare un altro utente come amministratore, devi sostituire l'impostazione predefinita e devi includere sia il tuo indirizzo email sia l'indirizzo email dell'altro amministratore. Per saperne di più sui criteri IAM e RBAC richiesti, 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 piano di controllo del cluster sulla porta TCP 443. Questo endpoint non è accessibile sulla rete Internet pubblica. Se hai accesso all'endpoint privato del cluster tramite il tuo VPC, puoi connetterti direttamente all'endpoint privato e generare un file kubeconfig direttamente. In caso contrario, puoi utilizzare Connetti gateway.

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

  • Utilizza il gateway Connect per accedere al cluster da un computer su cui è installato Google Cloud CLI. In questo caso, kubectl utilizza kubeconfig del gateway Gateway, che inoltra in modo sicuro il traffico all'endpoint privato per tuo conto.

  • Per l'accesso diretto agli endpoint privati, crea un file kubeconfig nella workstation di amministrazione e gestisci il cluster dalla workstation di amministrazione.

Assicurati che la console Google Cloud indichi che lo stato del cluster utente è in stato integro.

Connetti gateway

  1. Inizializza l'interfaccia alla gcloud CLI da utilizzare con il progetto host del parco risorse oppure esegui i comandi seguenti per accedere con il tuo Account Google, imposta il progetto host del parco risorse come predefinito e aggiorna i componenti:

    gcloud auth login
gcloud config set project PROJECT_ID
gcloud components update

  2. Recupera le credenziali del cluster utilizzate per interagire con Connect gateway. Nel comando seguente, sostituisci MEMBERSHIP_NAME con il nome del cluster. Nei Anthos clusters on bare metal, il nome dell'appartenenza è uguale al nome del cluster.

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

    Questo comando restituisce un comando speciale Connect gateway-specific kubeconfig che consente di connettersi al cluster tramite il gateway.

Dopo aver ottenuto le credenziali necessarie, puoi eseguire i comandi utilizzando kubectl come faresti normalmente per qualsiasi cluster Kubernetes e non è necessario 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 utente di destinazione.

  • ADMIN_KUBECONFIG_PATH: il percorso del file del cluster di amministrazione kubeconfig.

Un elemento kubeconfig con le credenziali del cluster utente viene scritto in un file, bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-TIMESTAMP-kubeconfig. TIMESTAMP nel nome del file indica la data e l'ora in cui è stato creato il file.

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

Passaggi successivi