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

In questa pagina viene descritto come creare un cluster di amministrazione utilizzando la console Google Cloud oppure Google Cloud CLI (gcloud CLI). Entrambi questi client Google Cloud standard utilizzano l'API GKE On-Prem per creare il cluster.

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 cluster, l'API GKE On-Prem deve archiviare i metadati relativi allo stato del cluster in Google Cloud, utilizzando la 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 dell'API GKE On-Prem, specifichi un 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 di amministrazione creando un file di configurazione del cluster di amministrazione e utilizzando bmctl, come descritto in Creare un cluster di amministrazione.

Se vuoi utilizzare la console o gcloud CLI per gestire il ciclo di vita dei cluster creati utilizzando bmctl, consulta Configura i cluster che devono essere gestiti dall'API GKE On-Prem.

Autorizzazioni IAM

Se non sei un proprietario del progetto Google Cloud, devi disporre dei seguenti ruoli assegnati da un proprietario del progetto:

Se vuoi accedere alle pagine GKE Enterprise e GKE del devi avere a disposizione anche roles/container.viewer.

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

Accesso da riga di comando

Dopo la creazione del cluster, se vuoi utilizzare Connetti il gateway per l'esecuzione kubectl sul cluster su computer diversi dall'amministratore installa i seguenti strumenti a riga di comando sul computer che intendi utilizzare.

Scegli il client per creare il cluster di amministrazione

Puoi utilizzare la console o la CLI gcloud per creare un cluster di amministrazione gestito dall'API GKE On-Prem. Se è la prima volta che installi Google Distributed Cloud, potresti trovare la console più facile da usare rispetto all'interfaccia a riga di comando gcloud.

Una volta acquisita familiarità con le informazioni da fornire per la creazione di cluster, potresti trovare la CLI gcloud più comoda perché puoi salvare il comando con i relativi argomenti in un file di testo. Se utilizzando uno strumento CI/CD come Cloud Build, puoi utilizzare i comandi gcloud per creare un cluster e specificare --impersonate-service-account per automatizzare la creazione.

Prerequisiti

Console

  1. Nella console, vai al menu Crea un Pagina Cluster distribuito distribuito.

    Vai a Crea 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.

La pagina Prerequisiti mostra i requisiti per la workstation di amministrazione e le macchine dei nodi del cluster. Lo Strumento di pianificazione degli indirizzi IP nel Requisiti di rete ti consente di pianificare gli indirizzi IP necessari per un'installazione minima di un cluster di amministrazione e un cluster utente.

Prerequisiti della workstation di amministrazione

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

Prerequisiti delle macchine dei nodi del cluster

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

Requisiti di rete

Questa sezione ti aiuta a pianificare gli indirizzi IP necessari per una gestione completamente gestito di Google Cloud. Facoltativamente, nella sezione IP del nodo e indirizzi IP virtuali, puoi fornire un indirizzo IP del nodo iniziale e un indirizzo IP virtuale (VIP), e la console visualizza una tabella degli indirizzi IP necessari. Questi indirizzi IP non vengono applicati alla configurazione del cluster di amministrazione. Loro sono da intendersi come una guida per aiutarti a pianificare gli indirizzi IP di cui hai bisogno dell'installazione. Puoi scaricare la tabella in un file CSV e importarla in un foglio di lavoro o uno strumento di pianificazione degli indirizzi IP da utilizzare come punto di partenza per monitorare gli indirizzi IP necessari per i tuoi cluster.

Esamina le risorse di Google Cloud:

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

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

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

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

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

Interfaccia a riga di comando gcloud

Prerequisiti hardware, di rete e del sistema operativo

Per creare un cluster di amministrazione utilizzando un client API GKE On-Prem è necessario lo stesso prerequisiti hardware, di rete e del sistema operativo per la creazione del cluster utilizzando bmctl. Per maggiori dettagli, consulta i Prerequisiti di installazione.

API Google richieste

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

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

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

Account di servizio e autorizzazioni richiesti

Prima di creare il cluster, esegui il comando bmctl register bootstrap alla workstation di amministrazione, come descritto Prepara l'ambiente di bootstrap. Questo comando può creare gli account di servizio richiesti con le autorizzazioni IAM minime necessarie per creare il cluster amministrativo. Se preferisci, Configurare gli account di servizio manualmente.

Pianificare gli indirizzi IP

Prima di creare il cluster di amministrazione, devi pianificare gli indirizzi IP per cluster. Vedi Pianificare gli indirizzi IP per un esempio di come allocare indirizzi IP per un'alta disponibilità e due cluster utente ad alta disponibilità. Anche se utilizzerai l'interfaccia a riga di comando gcloud per creare il cluster amministrativo, ti consigliamo di seguire i passaggi della console in questa sezione per utilizzare lo strumento di pianificazione degli indirizzi IP.

prepara l'ambiente di bootstrap

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

Console

  1. Inserisci un nome per il cluster amministrativo. Tieni presente che il nome del cluster di bootstrap viene ricavato anteponendo bootstrap- al nome del cluster di amministrazione.

  2. Seleziona la versione Google Distributed Cloud per il tuo cluster di amministrazione.

  3. Nel campo Posizione API Google Cloud, seleziona la regione Google Cloud 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 per il parco risorse (gkehub.googleapis.com)
    • Connetti servizio (gkeconnect.googleapis.com)

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

    • I metadati del cluster di cui l'API GKE On-Prem ha bisogno per gestire il ciclo di vita del cluster
    • I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
    • L'audit log amministrativo creato da Cloud Audit Logs

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

  4. Nella console vengono visualizzati i comandi che devi eseguire. sulla workstation di amministrazione. Lo strumento a riga di comando bmctl deve corrispondere la versione del cluster che stai creando. Se hai già la versione applicabile di bmctl scaricata sulla workstation di amministrazione; non dovrai scaricarlo di nuovo.

Interfaccia a riga di comando gcloud

  1. Assicurati di aggiornare i componenti:

    gcloud components update

  2. Esegui questo comando per accedere con il tuo Account Google:

    gcloud auth login

  3. Elenca le versioni di Google Distributed Cloud disponibili che puoi installare. La versione di bmctl scaricata per creare l'ambiente di bootstrap deve corrispondere a quella che installerai sul cluster di amministrazione.

    gcloud container bare-metal admin-clusters query-version-config \
  --location=REGION

    Sostituisci REGION con la regione Google Cloud che utilizzerai durante la creazione del cluster. Si tratta della regione in cui vengono eseguiti l'API GKE On-Prem e i servizi Fleet e Connect. Specifica us-west1 o altro regione supportata.

Crea il cluster di bootstrap

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

  1. Imposta le tue credenziali utente come Credenziali predefinite dell'applicazione (ADC):

    gcloud auth application-default login

    Segui le istruzioni per selezionare il tuo Account Google per l'ADC.

  2. Se necessario, scarica lo strumento a riga di comando bmctl nell'attuale versione .

    gcloud storage cp gs://anthos-baremetal-release/bmctl/VERSION/linux-amd64/bmctl .
chmod a+x ./bmctl

    Sostituisci VERSION con la versione di Google Distributed Cloud che vuoi installare. Se hai copiato il comando dalla console, la versione è già nel comando.

  3. Crea il cluster di bootstrap. Puoi consentire a bmctl di creare gli account di servizio (SA) richiesti o puoi creare gli account di servizio e i file chiave autonomamente e passarli alla bmctl register bootstrap .

bmctl crea le SA

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

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

Sostituisci quanto segue:

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

  • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione.

  • FLEET_HOST_PROJECT_ID: il progetto a cui l'amministratore verrà registrato automaticamente dopo la creazione del cluster.

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

Service account Finalità Ruoli IAM
anthos-baremetal-gcr Google Distributed Cloud utilizza questo account di servizio per scaricare immagini container da Google Container Registry. Nessuno
anthos-baremetal-connect L'agente Connect utilizza questo account di servizio per mantenere una connessione tra il cluster e Google Cloud. ruoli/gkehub.connect
anthos-baremetal-register L'agente Connect utilizza questo account di servizio per registrare i cluster nel fleet Google Cloud. roles/gkehub.admin
anthos-baremetal-cloud-ops L'agente Stackdriver utilizza questo account di servizio per esportare log e metriche dai cluster a Cloud Logging e Cloud Monitoring. ruoli/logging.logWriter
roles/monitoring.metricWriter
ruoli/stackdriver.resourceMetadata.writer
roles/opsconfigmonitoring.resourceMetadata.writer
roles/monitoring.dashboardEditor

Specifica i file di chiavi SA

Se preferisci, puoi passare a bmctl i file delle chiavi dell'account di servizio che hai creato. Il seguente comando utilizza i nomi dei file delle chiavi in Configurare manualmente gli account di servizio e presuppone che bmctl e i file delle chiavi si trovino nella directory di lavoro corrente.

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

Sostituisci quanto segue:

  • YOUR_PRIVATE_KEY: il percorso alla posizione chiave SSH. Hai creato la chiave SSH quando hai configurato l'accesso SSH come utente root ai nodi.

  • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione.

  • FLEET_HOST_PROJECT_ID: il progetto a cui verrà registrato automaticamente il cluster di amministrazione dopo la creazione.

I seguenti flag specificano il percorso dei file chiave:

  • -gcr-service-account-key: il percorso del file della chiave per l'account servizio che estrae le immagini dei contenitori (anthos-baremetal-gcr).

  • --gke-agent-service-account-key: il percorso del file della chiave per l'account di servizio Connect Agent (anthos-baremetal-connect).

  • --gke-register-service-account-key: il percorso del file della chiave per l'account di servizio dell'agente Connect che registra il cluster parco risorse (anthos-baremetal-register).

  • --cloud-operation-service-account-key: il percorso del file della chiave per l'account di servizio per controllare i log e monitorare i progetti (anthos-baremetal-cloud-ops).

Dopo che bmctl ha creato correttamente il cluster di bootstrap, vedrai l'output simile al seguente:

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

Crea il cluster di amministrazione

Console

  1. Nella pagina Installa ambiente di bootstrap, fai clic su Controlla la connessione.

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

    La connessione al cluster di bootstrap deve essere stabilita prima di continuare. Se la connessione non viene stabilita, controlla gli argomenti che specificato per il comando bmctl register bootstrap:

    • Assicurati che il valore di --target-cluster-name corrisponda a Nome del cluster di amministrazione visualizzato in Sezione Nozioni di base sull'ambiente di bootstrap.

    • Assicurati che il valore di --project-id corrisponda all'ID del progetto che hai selezionato nella console.

    Se devi modificare il nome del cluster di bootstrap o l'ID progetto, inserisci Ctrl-C per uscire da bmctl register bootstrap e esegui di nuovo il comando.

  2. Fai clic su Avanti per iniziare a configurare il cluster di amministrazione. La maggior parte delle impostazioni nella console corrisponde ai campi del file di configurazione del cluster.

  3. In Configurazione del nodo, inserisci un valore compreso tra 64 e 250 in Numero massimo di pod per nodo oppure accetta il valore predefinito 110. Una volta creato il cluster, non puoi aggiornare questo valore.

    Il numero massimo di pod per nodo (chiamato densità del pod) è limitato anche dalle risorse IP disponibili del cluster. Per maggiori dettagli, consulta Networking dei pod.

  4. Fai clic su Avanti.

  5. Nella pagina Networking, definisci il modo in cui i nodi e i componenti del cluster comunicano tra loro e con il control plane Kubernetes.

    Per informazioni dettagliate, posiziona il cursore sopra il accanto a ciascun campo.

  6. Fai clic su Verifica e crea.

    La console mostra i messaggi di stato durante la verifica delle impostazioni e la creazione del cluster nel data center.

    Se si verifica un problema di configurazione, la console mostra un messaggio di errore che dovrebbe essere sufficientemente chiaro per consentirti di risolvere il problema di configurazione e riprovare a creare il cluster.

Interfaccia a riga di comando gcloud

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

gcloud container fleet memberships list \
  --project=FLEET_HOST_PROJECT_ID

Se il cluster di bootstrap non è presente nell'elenco, controlla il nome del cluster di bootstrap e l'ID progetto specificato in bmctl register bootstrap. Per modifica il nome del cluster di bootstrap o l'ID progetto, inserisci Ctrl-C per uscire su bmctl register bootstrap ed esegui nuovamente il comando.

Utilizza il seguente comando per creare un cluster amministrativo:

gcloud container bare-metal admin-clusters create

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

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

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

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

Sostituisci quanto segue:

  • ADMIN_CLUSTER_NAME: il nome del cluster di amministrazione. Non è possibile modificare il nome dopo la creazione del cluster.

  • FLEET_HOST_PROJECT_ID: il progetto a cui l'amministratore verrà registrato automaticamente dopo la creazione del cluster. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.

  • REGION: la regione Google Cloud in cui Viene eseguito l'API GKE On-Prem. 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 vengono archiviati i seguenti elementi:

    • I metadati del cluster di cui l'API GKE On-Prem ha bisogno per gestire il ciclo di vita del cluster
    • I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
    • L'audit log amministrativo 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 Google Distributed Cloud. La versione deve corrispondere alla versione di bmctl utilizzata per eseguire bmctl register bootstrap. Puoi controllare la versione di bmctl eseguendo bmctl version sulla workstation di amministrazione.

  • MAX_PODS_PER_NODE : valori consentiti per i cluster di amministrazione sono 32-250 e 64-250 per i cluster non ad alta disponibilità. Il valore predefinito se--max-pods-per-node non è incluso nel comando è 110. Dopo aver creato il cluster, questo valore non può essere aggiornato.

    Il numero massimo di pod per nodo (chiamato densità del pod) è limitato anche dalle risorse IP disponibili del cluster. Per maggiori dettagli, consulta Networking dei pod.

  • CONTROL_PLANE_VIP: l'IP virtuale (VIP) sul carico per il server API Kubernetes del cluster. Includi il piano di controllo il VIP nella stessa subnet dei nodi del bilanciatore del carico. Non includere il VIP del control plane nei pool di indirizzi del bilanciatore del carico.

  • CONTROL_PLANE_LOAD_BALANCER_PORT: la porta su cui il bilanciatore del carico gestisce il control plane. Sebbene sia possibile configurarne un altro, , la porta 443 è la porta standard utilizzata per le connessioni HTTPS.

  • CONTROL_PLANE_NODE_CONFIG: l'indirizzo IPv4 di un nodo del control plane. I nodi del piano di controllo eseguono il carico di lavoro del sistema. Specifica questo flag per ogni nodo del piano di controllo. In genere, hai una singola macchina se utilizzi un deployment minimo o tre macchine se utilizzi un deployment ad alta disponibilità (HA). Specifica un numero dispari di nodi per avere un quorum di maggioranza per l'alta disponibilità. Puoi modificare questi indirizzi ogni volta che esegui l'aggiornamento o eseguire l'upgrade del cluster.

    Il valore del flag ha il seguente formato:

    'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \

    Il valore contiene segmenti che iniziano con le parole chiave node-ip e labels. Separa ogni segmento con una virgola.

    • node-ip: l'indirizzo IP di un nodo del control plane. Puoi specificare un solo node-ip per flag. Se devi specificare più di un nodo, includi di nuovo il flag per ogni nodo.

    • labels: una o più coppie chiave=valore associate al nodo.

    Tieni presente le seguenti regole di sintassi:

    • Racchiudi l'intero valore tra virgolette singole.
    • Gli spazi vuoti non sono consentiti.
    • Separa ogni coppia chiave=valore nel segmento labels con un punto e virgola.

    Ad esempio:

    --control-plane-node-configs 'node-ip=192.0.2.1' \
--control-plane-node-configs 'node-ip=192.0.2.2,labels=key2.1=value2.1' \
--control-plane-node-configs 'node-ip=192.0.2.3,labels=key3.1=value3.1;key3.2=value3.2' \

  • SERVICE_ADDR_CIDR: un intervallo di indirizzi IPv4 in formato CIDR per i servizi nel cluster. L'intervallo CIDR deve essere compreso tra /24 e /12, dove /12 fornisce il maggior numero di indirizzi IP. Ti consigliamo di utilizzare un intervallo nello spazio degli indirizzi IP per le reti private, definito in RFC 1918, ad esempio 10.96.0.0/20.

  • POD_ADDR_CIDR: un intervallo di indirizzi IPv4 in formato CIDR da utilizzare per i pod nel cluster utente. L'intervallo CIDR deve essere tra /18 e /8, dove /8 fornisce il maggior numero di indirizzi IP. I nostri suggerimenti di utilizzare un intervallo nello spazio di indirizzi IP per le connessioni internet private, definiti in RFC 1918, ad esempio 192.168.0.0/16.

Devi specificare i seguenti flag di archiviazione. Il comando di esempio include valori tipici. Per ulteriori informazioni, vedi Configura l'archiviazione locale.

  • --lvp-share-path: il percorso della macchina host in cui possono essere create le sottodirectory. Per ogni sottodirectory viene creato un volume permanente (PV) locale.

  • --lvp-share-storage-class: questo è lo StorageClass da utilizzare per creare volumi permanenti. StorageClass viene creato durante la creazione del cluster.

  • --lvp-node-mounts-config-path: questo è il percorso della macchina host in cui è montato il rilevamento dei dischi. Per ogni montaggio viene creato un volume permanente locale (PV).

  • --lvp-node-mounts-config-storage: la classe di archiviazione con cui vengono creati i PV durante la creazione del cluster.

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

L'output del comando è simile al seguente:

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

Nell'output di esempio, la stringa operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 è il OPERATION_ID dell'operazione a lungo termine. 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 ulteriori informazioni, vedi Operazioni di gcloud container bare-metal.

Correggere gli errori preflight

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

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

Ad esempio, supponiamo che un controllo preflight non sia riuscito perché il piano di controllo impossibile raggiungere il nodo. Nella workstation di amministrazione, vedrai un messaggio simile al seguente:

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

  1. Sulla workstation di amministrazione, assicurati che bmctl register bootstrap è ancora in esecuzione. In caso contrario, esegui di nuovo il comando con gli stessi argomenti e aggiungi il flag --reuse-bootstrap-cluster=true.

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

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

    Per ulteriori informazioni, vedi gcloud container bare-metal admin-clusters update.

I dettagli sulla procedura di creazione del cluster vengono visualizzati sulla workstation di amministrazione. Se i controlli preflight vengono superati, vedrai qualcosa di simile seguenti:

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

Connettiti al cluster di amministrazione

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

bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig

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

Se vuoi utilizzare la tua identità Google per accedere al cluster, puoi configura il gateway di connessione come segue:

  1. Nella workstation di amministrazione, imposta la variabile di ambiente KUBECONFIG:

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

  2. Imposta il contesto corrente in una variabile di ambiente:

    export CONTEXT="$(kubectl config current-context)"

  3. Esegui questo comando gcloud. Questo comando esegue le seguenti operazioni:

    • Concede al tuo account utente l'clusterrole/view di Kubernetes nel cluster.
    • Configura il cluster in modo da poter eseguire comandi kubectl di sola lettura su sul tuo computer locale senza doverti connettere alla workstation di amministrazione tramite SSH.

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

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

    L'output di questo comando è simile al seguente, che è abbreviato per leggibilità:

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

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

Con questi criteri RBAC, puoi accedere al cluster dal utilizzando la tua identità Google. Inoltre, puoi eseguire comandi kubectl di sola lettura su computer diversi dalla workstation di amministrazione che utilizzano un kubeconfig speciale che instrada le richieste attraverso connetti il gateway.

  1. Esegui il seguente comando su un computer diverso dalla workstation di amministrazione per recuperare la voce kubeconfig che può accedere al cluster tramite il gateway di connessione.

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

    L'output è simile al seguente:

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

  2. Ora puoi eseguire i comandi kubectl tramite il gateway di connessione:

    kubectl get pods -A

Passaggi successivi