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

In questa pagina viene descritto 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 da Google Cloud che consente di gestire del ciclo di vita dei cluster on-premise utilizzando Terraform e le applicazioni Google Cloud. L'API GKE On-Prem viene eseguita dell'infrastruttura. Terraform, la console gcloud CLI sono client dell'API che la utilizzano per creare nel tuo data center.

Per gestire il ciclo di vita dei tuoi cluster, l'API GKE On-Prem deve archiviare i metadati sullo stato del cluster in Google Cloud, utilizzando Regione Google Cloud specificata durante la creazione del cluster. Questo metadati consentono all'API di gestire il ciclo di vita del cluster includono dati specifici dei carichi di lavoro.

Quando crei un cluster utilizzando un client API GKE On-Prem, specifichi progetto Google Cloud. Una volta creato, il cluster viene automaticamente sono registrati nello spazio dei nomi di progetto flotta. 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 creandone uno. di configurazione del deployment 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 Configura un cluster utente che dovrà essere gestito dall'API GKE On-Prem.

Prima di iniziare

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

Concedi autorizzazioni IAM

Se non sei un proprietario del progetto, devi avere ricevuto l'autorizzazione roles/gkeonprem.admin.

Se vuoi accedere alle pagine di GKE Enterprise e Google Kubernetes Engine in devi disporre anche dei seguenti ruoli:

Dopo la creazione del cluster, se non sei un proprietario del progetto e vuoi usa il gateway Connect connetterti al cluster utente tramite la riga di comando sono necessari i seguenti ruoli:

  • roles/gkehub.gatewayAdmin: Questo ruolo ti consente di accedere all'API Connect gateway. Se hai bisogno solo della modalità di sola lettura per accedere al cluster, 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 obbligatorie

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

Se utilizzerai gcloud CLI per creare il cluster, abilitare l'API GKE On-Prem. Se utilizzi la console per creare il cluster, abilita automaticamente l'API GKE 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. La il cluster di amministrazione deve:

  • Avere accesso al server API Kubernetes sul cluster utente dopo che è è stato creato.

  • Avere la connettività di rete a tutti i nodi nel cluster utente una volta è stato creato.

  • Deve essere registrato a un parco risorse. La dell'ID progetto configurato gkeConnect.projectID, campo di quel cluster di amministrazione, che prende il nome di progetto host del parco risorse, deve essere lo stesso progetto in cui creerai il cluster utente.

Prerequisiti delle macchine dei nodi del cluster

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

Accesso da riga di comando

Dopo la creazione del cluster, se vuoi utilizzare il gateway Connect per eseguire kubectl rispetto al cluster utente su computer diversi dalla workstation di amministrazione, installa la seguente riga di comando sul computer che intendi utilizzare.

  • L'ultima versione di gcloud CLI.
  • kubectl per l'esecuzione di comandi sui cluster Kubernetes. Se hai bisogno per installare kubectl, segui queste instructions.

Creazione di un cluster utente

Puoi usare Terraform, la console Google Cloud o Google Cloud CLI (gcloud CLI) per creare un cluster gestito dal l'API GKE On-Prem. Se è la prima volta che installi Google Distributed Cloud, nella console potresti trovare strumento più semplice da usare.

Una volta acquisita familiarità con le informazioni che devi fornire, creare cluster, potresti trovare Terraform o pratico, in particolare se creerai più di un cluster. Terraform è un lo strumento Infrastructure as Code, standard del settore. Se la tua organizzazione ha già utilizza Terraform, ti consigliamo di utilizzarlo per creare cluster per gestire il ciclo di vita del cluster.

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

Console

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

  1. Nella console, vai al menu Crea un Pagina del cluster distribuito Cloud.

    Vai a Creare un cluster Distributed Cloud

  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 nello stesso progetto in cui è registrato il cluster di amministrazione. Dopo che l'utente il cluster viene creato, viene automaticamente registrato nell'istanza nel parco risorse del progetto.

  3. Fai clic su Avanti per iniziare a configurare il cluster.

Le sezioni seguenti illustrano la configurazione del 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 Google Cloud, seleziona la località di Google Cloud regione dall'elenco. Questa impostazione specifica la regione in cui le API e i servizi seguenti vengono eseguiti:

    • API GKE On-Prem (gkeonprem.googleapis.com)
    • Servizio parco risorse (gkehub.googleapis.com)
    • Connetti servizio (gkeconnect.googleapis.com)

    Questa impostazione controlla anche la regione in cui sono archiviati i seguenti elementi:

    • 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 Admin creato da Cloud Audit Logs

    Il nome del cluster, il progetto e la località identificano in modo univoco in un cluster Google Cloud.

  4. Seleziona la versione di Google Distributed Cloud per il tuo cluster utente. I cluster utente devono avere la stessa versione secondaria del cluster di amministrazione oppure una versione secondaria inferiore rispetto al cluster di amministrazione.

  5. In qualità di creatore del cluster, ti vengono concessi i privilegi di amministratore del cluster in un cluster Kubernetes. (Facoltativo) Inserisci l'indirizzo email di un altro utente che eseguirà amministrare il cluster nel campo Utente amministratore.

    Alla creazione del cluster, l'API GKE On-Prem applica lo standard Kubernetes i criteri di controllo dell'accesso basato sui ruoli (RBAC) al cluster per concedere a te agli 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.

  6. Nella sezione Configurazione nodo, specifica quanto segue:

    • Numero massimo di pod per nodo: inserisci il numero massimo di pod che è possibile vengono eseguite 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 corrisponde al numero massimo di pod per nodo. Per ulteriori informazioni sull'impostazione del numero massimo di pod per nodo, Networking dei pod:

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

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

Networking

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

  1. Nella sezione del nodo Piano di controllo, inserisci l'indirizzo IPv4 di ogni dal nodo del piano di controllo. 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 se utilizzi un deployment ad alta disponibilità (HA). Specifica un valore un numero dispari di nodi per avere un quorum di maggioranza per l'alta disponibilità. Questo campo può essere ogni volta che aggiorni o esegui l'upgrade di un cluster.

    Fai clic su + Aggiungi indirizzo IP se necessario per inserire altri indirizzi IP.

  2. Nella sezione Bilanciatore del carico, seleziona il bilanciatore del carico dalla Modalità da configurare per il cluster. Consulta Panoramica dei bilanciatori del carico per ulteriori informazioni.

    Abbinato a MetalLB

    Configurare 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 in esecuzione su un pool dedicato di nodi worker o sullo stesso nodi come piano di controllo.

    1. Nella sezione Pool di nodi del bilanciatore del carico, seleziona uno dei seguenti:

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

      • Crea un pool di nodi del bilanciatore del carico: scegli questa opzione avanzata per eseguire i bilanciatori del carico su un pool dedicato nodi worker. Tutti i nodi nel pool di nodi del bilanciatore del carico devono essere nella stessa subnet di livello 2 degli IP virtuali del bilanciatore del carico (VIP) configurati nei pool di indirizzi del bilanciatore del carico .

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

        2. Fai clic su + Aggiungi indirizzo IP se necessario per inserire altri indirizzi e gli indirizzi IP esterni.

    2. Nella sezione Pool di indirizzi del bilanciatore del carico, aggiungi uno o più pool di indirizzi da cui il controller MetalLB può scegliere e assegnare ai servizi di tipo LoadBalancer. Il VIP in entrata, che hai specificare nella sezione IP virtuali, deve trovarsi in uno di questi piscine.

      1. Inserisci un nome per il pool di indirizzi.

      2. Inserisci un intervallo di indirizzi IP in una notazione CIDR (ad esempio 192.0.2.0/26) o notazione dell'intervallo (ad esempio: 192.0.2.64-192.0.2.72). per specificare un singolo IP in un pool, utilizza /32 nella notazione CIDR (ad esempio: 192.0.2.1/32).

      3. Se il VIP in entrata non è compreso nell'intervallo di indirizzi, seleziona + Aggiungi intervallo di indirizzi IP e inserisci un altro intervallo di indirizzi che include il VIP in entrata.

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

      4. In Assegnazione degli indirizzi IP, seleziona uno dei seguenti:

        • Automatico: scegli questa opzione se vuoi che il valore MetalLB per assegnare automaticamente gli indirizzi IP pool di indirizzi ai servizi di tipo LoadBalancer.
        • Manuale: scegli questa opzione se intendi utilizzare questa opzione. indirizzi IP del pool per specificare manualmente gli indirizzi Servizi di tipo LoadBalancer.

      5. Fai clic su Evita errori di indirizzi IP se vuoi che il controller MetalLB per non utilizzare indirizzi del pool che terminano con .0 o .255. Ciò evita il problema dei bug nei dispositivi dei consumatori che inviano erroneamente traffico 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 del carico manuale, puoi configurare il tuo bilanciamento del carico di Google Cloud per il traffico dal piano di controllo e dal piano dati. Devi configurare il VIP del piano di controllo sul bilanciatore del carico esterno prima di creare in un cluster Kubernetes. 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 piano dati. Per ulteriori informazioni, vedi Configurare il bilanciamento del carico manuale.

  3. Nella sezione IP virtuali, inserisci quanto segue:

    • VIP piano di controllo: l'indirizzo IP di destinazione da utilizzare per il traffico. inviate al server API Kubernetes del cluster utente. Il VIP del piano di controllo devono trovarsi nella stessa subnet dei nodi del bilanciatore del carico essere in uno qualsiasi degli intervalli di indirizzi utilizzati per il bilanciatore del carico pool di indirizzi.

    • Porta: la porta di destinazione utilizzata per il traffico inviato a Kubernetes. API di Google Cloud. Il valore predefinito è 443.

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

  4. Nella sezione CIDR di servizi e pod, specifica il servizio Kubernetes e Intervalli di indirizzi IP dei pod in notazione CIDR. Non devono sovrapporsi a uno di questi né con indirizzi esterni al cluster da cui vuoi raggiungere all'interno del cluster. Ti consigliamo di utilizzare gli intervalli di indirizzi IP privati definita da RFC 1918. La fornisce i seguenti intervalli di indirizzi predefiniti, ma puoi modificale:

    • 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 fornisce il maggior numero di indirizzi IP esterni.

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

  5. Nella sezione Attributi avanzati, specifica facoltativamente seguenti:

    • URL del proxy: l'indirizzo HTTP del server proxy. Includi il parametro anche se è uguale alla 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, host nomi di dominio 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.

  6. Fai clic su Avanti.

Archiviazione

Google Distributed Cloud fornisce interfacce per l'archiviazione a blocchi e di file. Hanno opzioni predefinite, ma puoi personalizzare le configurazioni. Per ulteriori informazioni, consulta Configurazione dell'archiviazione locale.

  1. Facoltativamente, puoi configurare quanto segue:

    • Montaggi dei nodi del provisioner del volume locale: specifica la configurazione per PersistentVolumes (PV) locali supportati da dischi montati. Devi formattare e montare questi dischi, cosa che puoi fare prima o dopo la creazione del cluster.

    • Condivisione provisioner del volume locale: specifica la configurazione per PersistentVolumes supportato da sottodirectory in un file system condiviso. Questi vengono create automaticamente durante la creazione del cluster.

  2. Fai clic su Avanti.

Funzionalità

Per aiutarti a monitorare, risolvere i problemi e gestire il cluster, di seguito sono riportate alcune è attivata automaticamente e non può essere disattivata:

Crea un pool di nodi

Il cluster deve avere almeno un pool di nodi per i nodi worker. R 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) e quindi creare il cluster. Puoi aggiungere ulteriori nodi dopo la creazione del cluster. Con gcloud CLI, puoi creare prima nel cluster, quindi aggiungi uno o più pool di nodi in un cluster Kubernetes.

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

  2. Nella sezione Valori predefiniti del pool di nodi, inserisci il valore Nome del pool di nodi oppure accetta "default-pool" come nome.

  3. Nella sezione Nodi worker, inserisci gli indirizzi IP delle macchine per il su cui eseguire.

  4. Nella sezione Metadati del pool di nodi (facoltativo), se vuoi aggiungere Kubernetes etichette e incompatibilità procedi nel seguente modo:

    1. Fai clic su + Aggiungi etichette Kubernetes. Inserisci la Chiave e Valore dell'etichetta. Ripeti queste operazioni in base alle necessità.
    2. Fai clic su + Aggiungi incompatibilità. Inserisci la Chiave, il Valore e Effetto sull'incompatibilità. Ripeti queste operazioni in base alle necessità.

  5. Fai clic su Verifica e completa per creare il cluster utente. Ci vogliono 15 minuti o più per creare il cluster utente. Nella console viene visualizzato lo stato messaggi durante la verifica delle impostazioni e la creazione del cluster nei dati Google Cloud.

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

Interfaccia a riga di comando gcloud

Utilizza il comando seguente 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 della file di configurazione del cluster utente. Per aiutarti a iniziare, puoi testare il comando completo nella Sezione Esempi. Per informazioni sui flag, consulta sezioni che seguono gli esempi o fare riferimento alle Riferimento dell'interfaccia a riga di comando gcloud.

Prima di iniziare

La versione di Google Distributed Cloud che selezioni durante la creazione di un cluster utente deve essere una versione supportata dal cluster di amministrazione. Inoltre, l'ultima versione le versioni secondarie o patch non sono disponibili nell'API GKE On-Prem fino alle 7-10 giorni dopo il lancio. Puoi eseguire un comando gcloud per ottenere un elenco versioni supportate che puoi installare nel cluster utente.

  1. Assicurati di aggiornare i componenti:

    gcloud components update

  2. Ottieni il nome e la località di appartenenza del parco risorse del tuo cluster di amministrazione:

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

    Sostituisci FLEET_HOST_PROJECT_ID con l'ID del progetto in 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. Amministratore i cluster creati prima alla 1.28 sono gestiti dal parco risorse globale Connetti i servizi. Nella versione 1.28 e successive, puoi specificare global o in una regione Google Cloud quando crei il cluster di amministrazione. Devi specificare regione nel flag --admin-cluster-membership-location nell'esempio che seguono.

  3. Ottieni un elenco delle versioni disponibili per l'installazione nel 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 che in cui è registrato il cluster di amministrazione.

    • ADMIN_CLUSTER_REGION: lo stato del cluster di amministrazione regione di abbonamento del parco risorse. È globale o è un servizio Google Cloud regione. Utilizza la posizione per il cluster di amministrazione dall'output di gcloud container fleet memberships list.

    • REGION: la regione Google Cloud che che utilizzerai durante la creazione del cluster. Questa è la regione in cui vengono eseguiti l'API GKE On-Prem e i servizi Fleet and Connect. Specifica us-west1 o altro 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

Per avere la versione più recente, ti consigliamo di utilizzare la versione più recente supportata correzioni e miglioramenti.

Esempi

Questa sezione fornisce un esempio di comando che crea un cluster utilizzando il bilanciatore del carico MetalLB e un esempio con un bilanciatore del carico manuale. Le informazioni specificate variano in base al tipo di bilanciatore del carico che utilizzerai. Consulta Panoramica dei bilanciatori del carico per ulteriori informazioni informazioni.

Gli esempi creano il cluster senza pool di nodi. Dopo che il cluster viene in esecuzione, devi aggiungere un pool di nodi prima del deployment dei carichi di lavoro.

MetalLB

Questo esempio mostra come creare un cluster utente con il bundle MetalLB con il bilanciatore del carico di rete passthrough esterno regionale.

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 scelto da te per l'utente in un cluster Kubernetes. Non è possibile modificare il nome dopo la creazione del cluster. Il nome deve:
    • Deve contenere al massimo 40 caratteri
    • Contenere solo caratteri alfanumerici minuscoli o un trattino (-)
    • iniziano con un carattere alfabetico
    • terminare con un carattere alfanumerico
  • FLEET_HOST_PROJECT_ID: l'ID del progetto che in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto del cluster di amministrazione registrato. Una volta creato, il cluster utente viene automaticamente registrato nel parco risorse del progetto selezionato. Il progetto host del parco risorse e non possono essere modificate dopo la creazione del cluster.
  • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. In --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha seguente formato: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    In alternativa, puoi impostare --admin-cluster-membership sul del cluster di amministrazione, come nel comando di esempio. Quando 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. Il cluster di amministrazione la località è global o una regione Google Cloud. Se per trovare la regione, esegui gcloud container fleet memberships list.

  • REGION: la regione Google Cloud in cui API GKE On-Prem (gkeonprem.googleapis.com), servizio parco risorse (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com) esegui. Specifica us-west1 o un altro 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 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 Admin creato da Cloud Audit Logs

    Il nome del cluster, il progetto e la località identificano in modo univoco in un cluster Google Cloud.

  • VERSION: la versione di Google Distributed Cloud per il tuo nel cluster utente.
  • YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: Se non includi il flag --admin-users, in quanto creatore del cluster, per impostazione predefinita ti vengono concessi i privilegi amministrativi del cluster. Ma se includi --admin-users per designare un altro utente come amministratore, sostituisce il valore predefinito e devi includere sia il tuo indirizzo email che all'indirizzo email dell'altro amministratore. Ad esempio, per aggiungere due Amministratori: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Alla creazione del cluster, l'API GKE On-Prem applica lo standard Kubernetes i criteri di controllo dell'accesso basato sui ruoli (RBAC) al cluster per concedere a te agli 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.

Pool di indirizzi MetalLB

  • --metal-lb-address-pools: specifica la configurazione per pool di indirizzi che devono essere usati dal bilanciatore del carico MetalLB. Il valore del parametro 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 imposti True, il controller MetalLB non assegneranno indirizzi IP che terminano con .0 o .255 ai servizi. Questo evita il problema dei bug nei dispositivi dei consumatori che cadono erroneamente traffico inviato a questi indirizzi IP speciali. Se non specificato, il valore predefinito è False.

  • manual-assign: se non vuoi che il controller MetalLB assegnare automaticamente gli indirizzi IP da questo pool ai servizi, impostare a True. Quindi uno sviluppatore può creare un servizio di tipo LoadBalancer e specificare manualmente uno degli indirizzi nel piscina. Se non specificato, il criterio manual-assign è impostato su False.

  • Nell'elenco di addresses: ogni indirizzo deve essere un intervallo in CIDR o formato dell'intervallo con trattino. Per specificare un singolo indirizzo IP in un pool. (ad esempio per il VIP in entrata), 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.
  • Lo spazio vuoto non è consentito.
  • Separa ogni intervallo di indirizzi IP con un punto e virgola.

Puoi specificare più di un'istanza del flag, come mostrato in 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 controllo aereo. Se devi eseguire il bilanciatore del carico su un pool dedicato di nodi worker, specifica questo flag per ciascun nodo. Tutti i nodi nel carico Il pool di nodi del bilanciatore deve trovarsi nella stessa subnet di livello 2 del carico IP virtuali (VIP) del bilanciatore.

    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 nodo del bilanciatore del carico piscina. Puoi specificare un solo node-ip per flag. Se hai bisogno specificare più nodi, includi di nuovo il flag 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.
    • Lo spazio vuoto non è consentito.
    • Separa ogni coppia chiave=valore nel segmento labels con una e virgola.

    Se specifichi --metal-lb-load-balancer-node-configs, puoi facoltativamente includere i seguenti flag:

    • --metal-lb-load-balancer-node-labels: usa 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: usa questo flag per aggiungere incompatibilità a tutti i nodi nel pool di nodi del bilanciatore del carico. Ogni incompatibilità è un coppia chiave=valore associata a un effetto, che deve essere uno dei seguente: 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 nodo del bilanciatore del carico piscina. 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 control plane

  • --control-plane-node-configs: L'indirizzo IPv4 di un nodo del piano di controllo. I nodi del piano di controllo eseguono carico di lavoro di sistema. Specifica questo flag per ciascun nodo del piano di controllo. In genere, hai una sola macchina se utilizzi un deployment minimo oppure tre macchine se utilizzi un deployment ad alta disponibilità. Specifica un valore 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 elemento includi il flag di nuovo 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.
    • Lo spazio vuoto non è consentito.
    • Separa ogni coppia chiave=valore nel segmento labels con un punto e virgola.

    Facoltativamente, includi i seguenti flag:

  • --control-plane-node-labels: usa 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: usa questo flag per aggiungere incompatibilità a tutti i nodi del piano di controllo. Ogni incompatibilità è una coppia chiave-valore associata con un effetto, che deve essere uno dei 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 presentano 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 a tua disposizione 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 viene caricato di Google Cloud gestisce il server API Kubernetes.

    Esempio: -control-plane-load-balancer-port=443

  • INGRESS_VIP: l'indirizzo IP che hai scelto di usare e la configurazione sul bilanciatore del carico per il proxy in entrata.

    Esempio: --ingress-vip=10.251.134.80

    L'indirizzo IP del VIP in entrata deve essere in uno dei bucket MetalLB pool di indirizzi.

CIDR servizi e pod

  • SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP in 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 CIDR da utilizzare per i pod nel tuo cluster. L'intervallo CIDR deve essere 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 le sottodirectory possono possono essere create. Viene creato un PersistentVolume (PV) locale per ogni sottodirectory.
  2. --lvp-share-storage-class: oggetto StorageClass da utilizzare per creare come volumi permanenti. L'oggetto StorageClass viene creato durante la creazione del cluster.
  3. --lvp-node-mounts-config-path: questo è il percorso della macchina host in cui è montato il rilevamento dei dischi. Per ogni montaggio viene creato un PersistentVolume (PV) locale.
  4. --lvp-node-mounts-config-storage: la classe di archiviazione in cui vengono creati i volumi permanenti durante la creazione del cluster.

Per ulteriori informazioni sullo spazio di archiviazione, vedi Configura l'archiviazione locale.

Manuale

Con il bilanciamento del carico manuale, puoi configurare il tuo bilanciamento del carico di Google Cloud per il traffico dal piano di controllo e dal piano dati. Devi configurare il VIP del piano di controllo sul bilanciatore del carico esterno prima di creare in un cluster Kubernetes. 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 piano dati. Per ulteriori informazioni, vedi Configurare il bilanciamento del carico manuale.

Scorri oltre se necessario per compilare Segnaposto ADMIN_CLUSTER_NAME per 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 scelto da te per l'utente in un cluster Kubernetes. Non è possibile modificare il nome dopo la creazione del cluster. Il nome deve:
    • Deve contenere al massimo 40 caratteri
    • Contenere solo caratteri alfanumerici minuscoli o un trattino (-)
    • iniziano con un carattere alfabetico
    • terminare con un carattere alfanumerico
  • FLEET_HOST_PROJECT_ID: l'ID del progetto che in cui vuoi creare il cluster. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Deve essere lo stesso progetto del cluster di amministrazione registrato. Una volta creato, il cluster utente viene automaticamente registrato nel parco risorse del progetto selezionato. Il progetto host del parco risorse e non possono essere modificate dopo la creazione del cluster.
  • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione che gestisce il cluster utente. In --admin-cluster-membership puoi utilizzare il nome del cluster completamente specificato, che ha seguente formato: 
        projects/FLEET_HOST_PROJECT_ID/locations/ADMIN_CLUSTER_REGION/memberships/ADMIN_CLUSTER_NAME

    In alternativa, puoi impostare --admin-cluster-membership sul del cluster di amministrazione, come nel comando di esempio. Quando 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. Il cluster di amministrazione la località è global o una regione Google Cloud. Se per trovare la regione, esegui gcloud container fleet memberships list.

  • REGION: la regione Google Cloud in cui API GKE On-Prem (gkeonprem.googleapis.com), servizio parco risorse (gkehub.googleapis.com) e il servizio Connect (gkeconnect.googleapis.com) esegui. Specifica us-west1 o un altro 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 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 Admin creato da Cloud Audit Logs

    Il nome del cluster, il progetto e la località identificano in modo univoco in un cluster Google Cloud.

  • VERSION: la versione di Google Distributed Cloud per il tuo nel cluster utente.
  • YOUR_EMAIL_ADDRESS e ANOTHER_EMAIL_ADDRESS: Se non includi il flag --admin-users, in quanto creatore del cluster, per impostazione predefinita ti vengono concessi i privilegi amministrativi del cluster. Ma se includi --admin-users per designare un altro utente come amministratore, sostituisce il valore predefinito e devi includere sia il tuo indirizzo email che all'indirizzo email dell'altro amministratore. Ad esempio, per aggiungere due Amministratori: 
        --admin-users=sara@example.com \
    --admin-users=amal@example.com

    Alla creazione del cluster, l'API GKE On-Prem applica lo standard Kubernetes i criteri di controllo dell'accesso basato sui ruoli (RBAC) al cluster per concedere a te agli 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.

Nodi del control plane

  • --control-plane-node-configs: L'indirizzo IPv4 di un nodo del piano di controllo. I nodi del piano di controllo eseguono carico di lavoro di sistema. Specifica questo flag per ciascun nodo del piano di controllo. In genere, hai una sola macchina se utilizzi un deployment minimo oppure tre macchine se utilizzi un deployment ad alta disponibilità. Specifica un valore 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 elemento includi il flag di nuovo 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.
    • Lo spazio vuoto non è consentito.
    • Separa ogni coppia chiave=valore nel segmento labels con un punto e virgola.

    Facoltativamente, includi i seguenti flag:

  • --control-plane-node-labels: usa 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: usa questo flag per aggiungere incompatibilità a tutti i nodi del piano di controllo. Ogni incompatibilità è una coppia chiave-valore associata con un effetto, che deve essere uno dei 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 presentano 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 a tua disposizione 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 viene caricato di Google Cloud gestisce il server API Kubernetes.

    Esempio: -control-plane-load-balancer-port=443

  • INGRESS_VIP: l'indirizzo IP che hai scelto di usare e la configurazione sul bilanciatore del carico per il proxy in entrata.

    Esempio: --ingress-vip=10.251.134.80

    L'indirizzo IP del VIP in entrata deve essere in uno dei bucket MetalLB pool di indirizzi.

CIDR servizi e pod

  • SERVICE_CIDR_BLOCK: un intervallo di indirizzi IP in 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 CIDR da utilizzare per i pod nel tuo cluster. L'intervallo CIDR deve essere 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 le sottodirectory possono possono essere create. Viene creato un PersistentVolume (PV) locale per ogni sottodirectory.
  2. --lvp-share-storage-class: oggetto StorageClass da utilizzare per creare come volumi permanenti. L'oggetto StorageClass viene creato durante la creazione del cluster.
  3. --lvp-node-mounts-config-path: questo è il percorso della macchina host in cui è montato il rilevamento dei dischi. Per ogni montaggio viene creato un PersistentVolume (PV) locale.
  4. --lvp-node-mounts-config-storage: la classe di archiviazione in cui vengono creati i volumi permanenti durante la creazione del cluster.

Per ulteriori informazioni sullo spazio di archiviazione, vedi Configura l'archiviazione locale.

Prima di eseguire il comando gcloud per creare il cluster, è consigliabile includi --validate-only per convalidare la configurazione che hai specificato i flag al comando gcloud. Quando è tutto pronto per creare il cluster, rimuovi il 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. Tu puoi verificare lo stato dell'operazione con il seguente comando:

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

Per creare il cluster utente sono necessari almeno 15 minuti. Puoi visualizzare nel cluster nella console Google Cloud Cluster GKE .

Per un elenco completo delle segnalazioni e delle relative descrizioni, consulta la Riferimento dell'interfaccia a riga di comando gcloud.

Crea un pool di nodi

Dopo la creazione del cluster, devi creare almeno un pool di nodi prima 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, puoi creare prima nel cluster, quindi aggiungi uno o più pool di nodi in un cluster Kubernetes.

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 nodo piscina. Il nome deve:

    • Deve contenere al massimo 40 caratteri
    • Contenere solo caratteri alfanumerici minuscoli o un trattino (-)
    • iniziano con un carattere alfabetico
    • terminare con un carattere alfanumerico

  • USER_CLUSTER_NAME: il nome della persona nel cluster utente.

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

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

  • --node-configs: L'indirizzo IPv4 di una macchina con nodo worker. 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 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 ogni nodo in del 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.
    • Lo spazio vuoto non è consentito.
    • Separa ogni coppia chiave=valore nel segmento labels con una e virgola.

    Facoltativamente, puoi specificare quanto segue:

    • --node-labels=KEY=VALUE,...: A 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à di Kubernetes applicati a ciascun nodo nel pool. Le incompatibilità sono coppie chiave=valore associate un effetto. Le incompatibilità vengono utilizzate con le tolleranze per la pianificazione dei pod. Specificane uno dei seguenti 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 di nodi. Tutti entrambi i nodi sono etichettati con node-pool-key=node-pool-value presentano l'incompatibilità 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 ulteriori informazioni, consulta Riferimento dell'interfaccia a riga di comando gcloud.

Terraform

Prima di iniziare

La versione di Google Distributed Cloud che selezioni durante la creazione di un cluster utente deve essere una versione supportata dal cluster di amministrazione. Inoltre, l'ultima versione le versioni secondarie o patch non sono disponibili nell'API GKE On-Prem fino alle 7-10 giorni dopo il lancio. Puoi eseguire un comando gcloud per ottenere un elenco versioni supportate che puoi installare nel cluster utente.

  1. Assicurati di aggiornare i componenti:

    gcloud components update

  2. Ottieni il nome e la località di appartenenza del parco risorse del tuo cluster di amministrazione:

    gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

    Sostituisci FLEET_HOST_PROJECT_ID con l'ID del progetto in 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. Amministratore i cluster creati prima alla 1.28 sono gestiti dal parco risorse globale Connetti i servizi. Nella versione 1.28 e successive, puoi specificare global o in una regione Google Cloud quando crei il cluster di amministrazione. Devi specificare regione nel flag --admin-cluster-membership-location nell'esempio che seguono.

  3. Ottieni un elenco delle versioni disponibili per l'installazione nel 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 che in cui è registrato il cluster di amministrazione.

    • ADMIN_CLUSTER_REGION: lo stato del cluster di amministrazione regione di abbonamento del parco risorse. È globale o è un servizio Google Cloud regione. Utilizza la posizione per il cluster di amministrazione dall'output di gcloud container fleet memberships list.

    • REGION: la regione Google Cloud che che utilizzerai durante la creazione del cluster. Questa è la regione in cui vengono eseguiti l'API GKE On-Prem e i servizi Fleet and Connect. Specifica us-west1 o altro 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

Per avere la versione più recente, ti consigliamo di utilizzare la versione più recente supportata correzioni e miglioramenti.

Esempio

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 documentazione di riferimento di google_gkeonprem_bare_metal_cluster.

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

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

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

    L'esempio fornisce un file di variabili di esempio da passare a main.tf.

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

    cp terraform.tfvars.sample terraform.tfvars

  3. 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"] }
]

    Le variabili sono descritte nel seguente elenco:

    • project_id: l'ID del progetto in cui vuoi creare il cluster in. Il progetto specificato viene utilizzato anche come progetto host del parco risorse. Questo deve essere lo stesso progetto in cui è registrato il cluster di amministrazione. Dopo il giorno il cluster utente viene creato, viene registrato automaticamente nel parco risorse del progetto selezionato. Il progetto host del parco risorse non può essere modificato dopo viene creato il cluster.

    • region: la regione Google Cloud in cui l'API GKE On-Prem (gkeonprem.googleapis.com), servizio parco risorse (gkehub.googleapis.com), e il servizio Connect (gkeconnect.googleapis.com). Specifica us-west1 o altro regione supportata.

    • admin_cluster_name: il nome del cluster di amministrazione che gestisce l'utente in un cluster Kubernetes. L'esempio presuppone che il cluster di amministrazione utilizzi global come regione. Se hai un cluster di amministrazione a livello di regione:

      1. Apri main.tf in un editor di testo.

      2. Cerca admin_cluster_membership, che assomiglia a seguenti:

        admin_cluster_membership = "projects/${var.project_id}/locations/global/memberships/${var.admin_cluster_name}"

      3. Modifica global nella regione utilizzata dal cluster di amministrazione e salva del file.

    • bare_metal_version: la versione di Google Distributed Cloud per il tuo utente in un cluster Kubernetes. Specifica la stessa versione del cluster di amministrazione o una versione che non è più di una versione secondaria inferiore a quella dell'amministratore in un cluster Kubernetes.

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

      Alla creazione del cluster, l'API GKE On-Prem applica lo standard Kubernetes i criteri di controllo dell'accesso basato sui ruoli (RBAC) al cluster per concedere agli utenti amministratore il ruolo Kubernetes clusterrole/cluster-admin, fornisce l'accesso completo a tutte le risorse del cluster in tutti gli spazi dei nomi. Ciò consente inoltre agli utenti di accedere alla console utilizzando il proprio Identità Google.

    • cluster_name: un nome a tua scelta per il cluster utente. Il nome e non possono essere modificate dopo la creazione del cluster. Il nome deve:

      • Deve contenere al massimo 40 caratteri
      • Contenere solo caratteri alfanumerici minuscoli o un trattino (-)
      • iniziano con un carattere alfabetico
      • terminare con un carattere alfanumerico

    • control_plane_ips: un elenco di uno o più indirizzi IPv4 per il controllo nodi del piano. I nodi del piano di controllo eseguono il carico di lavoro del sistema. Di solito, avere una sola macchina se si utilizza un deployment minimo, oppure tre macchine se un deployment ad alta disponibilità. Specifica un numero dispari di nodi avere un quorum di maggioranza per l'alta disponibilità. Puoi modificare questi indirizzi in qualsiasi momento per aggiornare o eseguire l'upgrade di un cluster.

    • worker_node_ips: un elenco di uno o più indirizzi IPv4 per il worker di macchine nodo.

    • control_plane_vip: l'indirizzo IP virtuale (VIP) che hai scelto di configura sul bilanciatore del carico il server API Kubernetes dell'utente in un cluster Kubernetes.

    • ingress_vip: l'indirizzo IP che hai scelto di configurare nella bilanciatore del carico per il proxy in entrata.

    • lb_address_pools: un elenco di mappe che definiscono i pool di indirizzi da utilizzare usato dal bilanciatore del carico MetalLB. Il VIP in entrata deve trovarsi in uno di questi piscine.

  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 le modifiche necessarie:

    terraform plan

  7. Applica il piano Terraform per creare il cluster utente:

    terraform apply

    Per creare il cluster utente sono necessari almeno 15 minuti. Puoi visualizzare nel cluster nella console Google Cloud Cluster GKE .

Connettiti al cluster utente

Quando crei un cluster utente nella console, questo viene configurato con i criteri di controllo dell'accesso basato su ruoli (RBAC, Role-Based Access Control) di Kubernetes per consentirti di 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 l'impostazione predefinita ed è necessario includere sia l'indirizzo email che all'indirizzo email dell'altro amministratore. Per ulteriori informazioni sui i criteri IAM e RBAC richiesti, consulta Configura l'autenticazione dell'identità Google.

Tutti i cluster hanno un endpoint canonico. L'endpoint espone l'API Kubernetes server che kubectl e altri servizi utilizzano per comunicare con il tuo cluster dalla porta TCP 443. Questo endpoint non è accessibile al pubblico internet. Se hai accesso all'endpoint privato del cluster tramite VPC, puoi connetterti direttamente all'endpoint privato e generare kubeconfig file direttamente. Altrimenti, puoi utilizzare Connetti il gateway.

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

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

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

Assicurati di attendere che la console Google Cloud indichi che il cluster utente che lo stato sia integro.

Connetti gateway

  1. Inizializza il file gcloud CLI per l'utilizzo con il progetto host del parco risorse oppure esegui seguenti comandi per accedere con il tuo Account Google, imposta il tuo parco risorse progetto host come predefinito e aggiornare 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 il comando seguente, sostituisci MEMBERSHIP_NAME con il nome del cluster. In Google Distributed Cloud, il nome dell'appartenenza corrisponde al nome del cluster.

    gcloud container fleet memberships get-credentials MEMBERSHIP_NAME

    Questo comando restituisce uno speciale Connect gateway-specific kubeconfig che ti consente di connetterti 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 ti servono per specificare il nome del file kubeconfig, ad esempio:

kubectl get namespaces

Workstation di amministrazione

Usa il comando bmctl get credentials per recuperare un file kubeconfig per 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 cluster di amministrazione kubeconfig .

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

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

Passaggi successivi