Questa pagina descrive come creare un cluster di amministrazione utilizzando la console Google Cloud o 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 su Google Cloudche ti consente di gestire il ciclo di vita dei tuoi cluster on-premise utilizzando Terraform e applicazioniGoogle Cloud standard. L'API GKE On-Prem viene eseguita nell'infrastruttura di Google Cloud. Terraform, la console e la gcloud CLId sono client dell'API e la utilizzano per creare cluster nel tuo data center.
Per gestire il ciclo di vita dei cluster, l'API GKE On-Prem deve archiviare i metadati sullo stato del cluster in Google Cloud, utilizzando la regioneGoogle Cloud che specifichi durante la creazione del cluster. Questi metadati consentono all'API di gestire il ciclo di vita del cluster e non includono dati specifici del carico di lavoro.
Quando crei un cluster utilizzando un client API GKE On-Prem, specifichi un progettoGoogle Cloud . Dopo la creazione, il cluster viene registrato automaticamente nel parco risorse del progetto specificato. Questo progetto è denominato progetto host del parco risorse. Il progetto host del parco risorse non può essere modificato dopo la creazione del cluster.
Se preferisci, puoi creare un cluster di amministrazione creando un file di configurazione del cluster di amministrazione e utilizzando bmctl
, come descritto in Creazione di un cluster di amministrazione.
Se vuoi utilizzare la console o gcloud CLI per gestire
il ciclo di vita dei cluster creati utilizzando bmctl
, consulta
Configurare i cluster da gestire tramite l'API GKE On-Prem.
Autorizzazioni IAM
Se non sei il proprietario del progetto, devi chiedere a un proprietario del progetto di concederti i seguenti ruoli: Google Cloud
Se vuoi accedere alle pagine GKE Enterprise e GKE nella console, devi disporre anche del ruolo roles/container.viewer.
Per informazioni sulla concessione dei ruoli, consulta Gestire l'accesso a progetti, cartelle e organizzazioni.
Accesso da riga di comando
Dopo aver creato il cluster, se vuoi utilizzare il
gateway di connessione per eseguire
i comandi kubectl
sul cluster su computer diversi dalla workstation
amministrativa, installa i seguenti strumenti a riga di comando sul computer che
intendi utilizzare.
L'ultima versione della gcloud CLI.
kubectl
per l'esecuzione di comandi sui cluster Kubernetes. Se devi installarekubectl
, segui queste istruzioni.
Scegliere il cliente per creare il cluster di amministrazione
Puoi utilizzare la console o gcloud CLI per creare un cluster di amministrazione gestito dall'API GKE On-Prem. Se è la prima volta che installi Google Distributed Cloud (solo software) su bare metal, potresti trovare la console più facile da usare rispetto a gcloud CLI.
Dopo aver acquisito familiarità con le informazioni che devi fornire per
creare cluster, potresti trovare gcloud CLI più comodo
perché puoi salvare il comando con i relativi argomenti in un file di testo. Se utilizzi uno strumento CI/CD, come Cloud Build, puoi utilizzare i comandi gcloud
per creare un cluster e specificare il flag --impersonate-service-account
per automatizzare la creazione.
Prerequisiti
Console
Nella console, vai alla pagina Crea un cluster bare metal.
Seleziona il Google Cloud progetto in cui vuoi creare il cluster. Il progetto selezionato viene utilizzato anche come progetto host del parco risorse.
La pagina Prerequisiti mostra i requisiti per la workstation amministrativa e le macchine dei nodi del cluster. Il pianificatore di indirizzi IP nella sezione Requisiti di rete ti aiuta a 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 un ambiente minimo. Se vuoi, nella sezione Indirizzi IP del nodo e IP virtuali, puoi fornire un indirizzo IP del nodo iniziale e un indirizzo IP virtuale (VIP) e la console mostra una tabella degli indirizzi IP necessari. Questi indirizzi IP non vengono applicati alla configurazione del cluster di amministrazione. Sono pensati come guida per aiutarti a pianificare gli indirizzi IP necessari per l'installazione. Puoi scaricare la tabella in un file CSV e importarla in un foglio di lavoro o in uno strumento di pianificazione degli indirizzi IP da utilizzare come punto di partenza per monitorare gli indirizzi IP necessari per i tuoi cluster.
Rivedi le risorse Google Cloud:
Assicurati che tutte le API di Google richieste siano abilitate nel progetto host del parco risorse. 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 veicoli.
Prima di creare il cluster, esegui il comando bmctl register bootstrap
sulla workstation di amministrazione come descritto in Preparare l'ambiente di bootstrap. Questo comando
può creare i service account richiesti con le autorizzazioni IAM minime
necessarie per creare il cluster di amministrazione.
Se preferisci, puoi configurare manualmente i service account.
Quando è tutto pronto per iniziare, fai clic su Installa ambiente bootstrap nella barra di navigazione a sinistra.
Interfaccia a riga di comando gcloud
Prerequisiti hardware, di rete e del sistema operativo
La creazione di un cluster di amministrazione utilizzando un client API GKE On-Prem richiede gli stessi prerequisiti di hardware, networking e sistema operativo della creazione del cluster utilizzando bmctl
. Per maggiori dettagli,
vedi Prerequisiti per l'installazione.
API Google richieste
Assicurati che tutte le API di Google richieste siano abilitate nel progetto host del parco risorse. 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 veicoli.
Service account e autorizzazioni richiesti
Prima di creare il cluster, esegui il comando bmctl register bootstrap
sulla workstation di amministrazione come descritto in Prepara l'ambiente di bootstrap. Questo comando
può creare i service account richiesti con le autorizzazioni IAM minime
necessarie per creare il cluster di amministrazione.
Se preferisci, puoi configurare manualmente i service account.
Pianificare gli indirizzi IP
Prima di creare il cluster di amministrazione, devi pianificare gli indirizzi IP per i tuoi cluster. Consulta la sezione Pianifica gli indirizzi IP per un esempio di come allocare indirizzi IP per un cluster di amministrazione ad alta disponibilità (HA) e due cluster utente HA. Anche se utilizzerai gcloud CLId per creare il cluster di amministrazione, ti consigliamo di seguire i passaggi della console in questa sezione per utilizzare lo strumento di pianificazione degli indirizzi IP.
Prepara l'ambiente di bootstrap
Prima di creare il cluster di amministrazione, devi eseguire il comando
bmctl register bootstrap
sulla workstation di amministrazione. Questo comando
esegue il deployment di un cluster Kubernetes in Docker
(kind) sulla workstation di amministrazione. Questo cluster bootstrap ospita i controller Kubernetes necessari per creare il cluster di amministrazione. Quando crei il cluster di amministrazione, i controller del cluster di bootstrap eseguono il provisioning dei nodi, eseguono controlli preflight e registrano il cluster di amministrazione nel parco risorse. Il cluster di bootstrap viene eliminato automaticamente dopo la creazione del cluster.
Console
Inserisci un nome per il cluster amministrativo. Tieni presente che il nome del cluster di bootstrap viene derivato anteponendo bootstrap- al nome del cluster di amministrazione.
Seleziona la versione per il cluster di amministrazione.
Nel campo Posizione API Google Cloud, seleziona la regione Google Cloud dall'elenco. Questa impostazione specifica la regione in cui vengono eseguiti i seguenti servizi e API:
- API GKE On-Prem (
gkeonprem.googleapis.com
) - Servizio flotta (
gkehub.googleapis.com
) - Servizio Connect (
gkeconnect.googleapis.com
)
Questa impostazione controlla anche la regione in cui vengono archiviati:
- I metadati del cluster necessari all'API GKE On-Prem per gestire il ciclo di vita del cluster
- I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
- Il log di controllo amministrativo creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.
- API GKE On-Prem (
La console mostra i comandi che devi eseguire sulla workstation di amministrazione. Lo strumento a riga di comando
bmctl
deve corrispondere alla versione del cluster che stai creando. Se hai già scaricato la versione applicabile dibmctl
nella workstation amministrativa, non è necessario scaricarla di nuovo.
Interfaccia a riga di comando gcloud
Assicurati di aggiornare i componenti:
gcloud components update
Esegui questo comando per accedere con il tuo Account Google:
gcloud auth login
Elenca le versioni del cluster Bare Metal disponibili che puoi installare:
La versione di
bmctl
che scarichi 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 quando crei il cluster. Questa è la regione in cui vengono eseguiti l'API GKE On-Prem e i servizi Fleet e Connect. Specificaus-west1
o un'altra regione supportata.
Crea il cluster di bootstrap
Esegui i passaggi riportati di seguito sulla workstation di amministrazione. Questi comandi vengono visualizzati nella console.
Imposta le credenziali utente come Credenziali predefinite dell'applicazione (ADC):
gcloud auth application-default login
Segui le istruzioni per selezionare il tuo Account Google per ADC.
Se necessario, scarica lo strumento a riga di comando
bmctl
nella directory di lavoro attuale.gcloud storage cp gs://anthos-baremetal-release/bmctl/VERSION/linux-amd64/bmctl . chmod a+x ./bmctl
Sostituisci
VERSION
con la versione del cluster bare metal che vuoi installare. Se hai copiato il comando dalla console, la versione è già inclusa.Crea il cluster di bootstrap. Puoi consentire a
bmctl
di creare i service account (SA) richiesti oppure puoi creare i service account e i file delle chiavi autonomamente e passarli al comandobmctl register bootstrap
.
bmctl
crea SA
Utilizza il seguente comando se vuoi che bmctl
crei i service account richiesti con le autorizzazioni minime necessarie per creare il cluster di amministrazione. Questo comando presuppone che bmctl
si trovi nella directory di lavoro corrente.
./bmctl register bootstrap \ --ssh-key=YOUR_PRIVATE_KEY \ --target-cluster-name=ADMIN_CLUSTER_NAME \ --project-id=FLEET_HOST_PROJECT_ID
Sostituisci quanto segue:
YOUR_PRIVATE_KEY
: Il percorso della tua chiave SSH privata. Hai creato la chiave SSH quando hai configurato l'accesso SSH root ai nodi.
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 in cui verrà registrato automaticamente il cluster di amministrazione dopo la creazione del cluster.
Il comando bmctl register bootstrap
crea i seguenti service account.
Le chiavi del account di servizio sono memorizzate nella directory
bmctl-workspace/.sa-keys
.
Service account | Finalità | Ruoli IAM |
---|---|---|
anthos-baremetal-gcr | Google Distributed Cloud utilizza questo account di servizio per scaricare immagini container da Artifact Registry. | Nessuno |
anthos-baremetal-connect | L'agente Connect utilizza questo account di servizio per mantenere una connessione tra il cluster e Google Cloud. | roles/gkehub.connect |
anthos-baremetal-register | L'agente Connect utilizza questo account di servizio per registrare i cluster nel Google Cloud fleet. | 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. |
roles/logging.logWriter roles/monitoring.metricWriter roles/stackdriver.resourceMetadata.writer roles/opsconfigmonitoring.resourceMetadata.writer roles/monitoring.dashboardEditor roles/monitoring.viewer roles/serviceusage.serviceUsageViewer roles/kubernetesmetadata.publisher |
Specifica i file delle chiavi SA
Se preferisci, puoi passare bmctl
i file delle chiavi del account di servizio
che hai creato. Il seguente comando utilizza i nomi dei file delle chiavi in
Configura 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 della tua chiave SSH privata. Hai creato la chiave SSH quando hai configurato l'accesso SSH root ai nodi.ADMIN_CLUSTER_NAME
: il nome del cluster di amministrazione.FLEET_HOST_PROJECT_ID
: Il progetto in cui verrà registrato automaticamente il cluster di amministrazione dopo la creazione del cluster.
I seguenti flag specificano il percorso dei file delle chiavi:
-gcr-service-account-key
: il percorso del file della chiave per l'account di servizio che estrae le immagini container (anthos-baremetal-gcr
).--gke-agent-service-account-key
: il percorso del file della chiave per l'account di servizio dell'agente Connect (anthos-baremetal-connect
).--gke-register-service-account-key
: il percorso del file della chiave per il account di servizio dell'agente Connect che registra il cluster nel fleet (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, viene visualizzato un output simile al seguente:
[2023-03-22 17:35:24+0000] Waiting for the temporary cluster to be registered... OK [2023-03-22 17:35:37+0000] Please go to https://console.cloud.google.com/home/dashboard?project=example-project-12345 to create the cluster [2023-03-22 17:35:37+0000] Waiting for preflight checks and cluster to run..
Crea il cluster di amministrazione
Console
Nella pagina Installa ambiente bootstrap, fai clic su Controlla connessione.
Se l'operazione riesce, la console visualizza
Connessione stabilita.Prima di continuare, devi stabilire la connessione al cluster di bootstrap. Se la connessione non viene stabilita, controlla gli argomenti che hai specificato per il comando
bmctl register bootstrap
:Assicurati che il valore di
--target-cluster-name
corrisponda al nome del cluster di amministrazione visualizzato nella 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 dabmctl register bootstrap
e riesegui il comando.Fai clic su Avanti per iniziare a configurare il cluster di amministrazione. La maggior parte delle impostazioni nella console corrisponde ai campi del file di configurazione del cluster.
In Configurazione nodo, inserisci un valore compreso tra 64 e 250 in Numero massimo di pod per nodo o accetta il valore predefinito, 110. Dopo aver creato il cluster, non puoi aggiornare questo valore.
Il numero massimo di pod per nodo (denominato densità del pod) è limitato anche dalle risorse IP disponibili del cluster. Per maggiori dettagli, vedi Networking dei pod.
Fai clic su Avanti.
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, tieni il puntatore sopra il
accanto a ogni campo.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 con la configurazione, la console visualizza un messaggio di errore che dovrebbe essere abbastanza chiaro da consentirti di risolvere il problema e riprovare a creare il cluster.
Interfaccia a riga di comando gcloud
Prima di creare il cluster di amministrazione, verifica che il cluster di bootstrap sia stato registrato come membro del parco risorse:
gcloud container fleet memberships list \ --project=FLEET_HOST_PROJECT_ID
Se il cluster di bootstrap non è elencato, controlla il nome del cluster di bootstrap e
l'ID progetto che hai specificato per bmctl register bootstrap
. Se devi
modificare il nome del cluster di bootstrap o l'ID progetto, inserisci Ctrl-C
per uscire
da bmctl register bootstrap
e riesegui il comando.
Utilizza il seguente comando per creare un cluster di amministrazione:
gcloud container bare-metal admin-clusters create
La maggior parte dei flag specificati per il 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
comando.
Sostituisci quanto segue:
ADMIN_CLUSTER_NAME
: il nome del cluster di amministrazione. Il nome non può essere modificato dopo la creazione del cluster.FLEET_HOST_PROJECT_ID
: Il progetto in cui verrà registrato automaticamente il cluster di amministrazione 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 eseguita l'API GKE On-Prem. Specificaus-west1
o un'altra regione supportata. La regione non può essere modificata dopo la creazione del cluster. Questa impostazione specifica la regione in cui vengono archiviati:- I metadati del cluster necessari all'API GKE On-Prem per gestire il ciclo di vita del cluster
- I dati di Cloud Logging e Cloud Monitoring dei componenti di sistema
- Il log di controllo amministrativo creato da Cloud Audit Logs
Il nome, il progetto e la località del cluster identificano in modo univoco il cluster in Google Cloud.
VERSION
: La versione del cluster bare metal. La versione deve corrispondere alla versione dibmctl
che hai utilizzato per eseguirebmctl register bootstrap
. Puoi controllare la versione dibmctl
eseguendobmctl version
sulla workstation di amministrazione.MAX_PODS_PER_NODE
: per i cluster di amministrazione, i valori consentiti sono 32-250 e 64-250 per i cluster non HA. Il valore predefinito se--max-pods-per-node
non è incluso nel comando è 110. Dopo la creazione del cluster, questo valore non può essere aggiornato.Il numero massimo di pod per nodo (denominato densità del pod) è limitato anche dalle risorse IP disponibili del cluster. Per maggiori dettagli, vedi Networking dei pod.
CONTROL_PLANE_VIP
: l'IP virtuale (VIP) sul bilanciatore del carico del server API Kubernetes del cluster. Includi il VIP del control plane 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. Anche se puoi configurare un altro valore, la porta443
è la porta standard utilizzata per le connessioni HTTPS.CONTROL_PLANE_NODE_CONFIG
: L'indirizzo IPv4 di un nodo del piano di controllo. I nodi del piano di controllo eseguono il carico di lavoro del sistema. Specifica questo flag per ogni nodo del control plane. In genere, hai una singola macchina se utilizzi un deployment minimo o tre macchine se utilizzi un deployment ad alta disponibilità. Specifica un numero dispari di nodi per avere un quorum di maggioranza per l'alta disponibilità. Puoi modificare questi indirizzi ogni volta che aggiorni o esegui l'upgrade del cluster.Il valore del flag ha il seguente formato:
'node-ip=CP_IP_ADDRESS_1,labels=CP_KEY_1.1=CP_VALUE_1.1;CP_KEY_1.2=CP_VALUE_1.2;...' \
Il valore ha segmenti che iniziano con le parole chiave
node-ip
elabels
. Separa ogni segmento con una virgola.node-ip
: l'indirizzo IP di un nodo del control plane. Puoi specificare un solonode-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 di indirizzi IP per le reti internet private, definito nella RFC 1918, ad esempio10.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 compreso tra /18 e /8, dove /8 fornisce il maggior numero di indirizzi IP. Ti consigliamo di utilizzare un intervallo nello spazio di indirizzi IP per le reti internet private, definito nella RFC 1918, ad esempio192.168.0.0/16
.
Devi specificare i seguenti flag di archiviazione. Il comando di esempio include valori tipici. Per saperne di più, consulta Configurare l'archiviazione locale.
--lvp-share-path
: questo è il percorso della macchina host in cui è possibile creare sottodirectory. Viene creato un PersistentVolume (PV) locale per ogni sottodirectory.--lvp-share-storage-class
: questo è l'oggetto StorageClass da utilizzare per creare volumi permanenti. StorageClass viene creato durante la creazione del cluster.--lvp-node-mounts-config-path
: il percorso della macchina host in cui è possibile rilevare i dischi montati. Viene creato un PersistentVolume (PV) locale per ogni montaggio.--lvp-node-mounts-config-storage
: la classe di archiviazione con cui vengono creati i PV durante la creazione del cluster.
Per un elenco completo dei flag e delle relative descrizioni, consulta la documentazione di riferimento di gcloud CLI.
L'output del comando è simile al seguente:
Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
Nell'output di esempio, la stringa operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179
è il OPERATION_ID
dell'operazione a lunga esecuzione. Puoi
scoprire lo stato dell'operazione con il seguente comando:
gcloud container bare-metal operations describe OPERATION_ID \ --project=FLEET_HOST_PROJECT_ID \ --location=REGION
Per ulteriori informazioni, consulta gcloud container bare-metal operations.
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
viene chiuso 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é non è stato possibile raggiungere il nodo del piano di controllo. Nella workstation di amministrazione vedrai un risultato 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
Sulla workstation di amministrazione, assicurati che il processo
bmctl register bootstrap
sia ancora in esecuzione. In caso contrario, esegui di nuovo il comando con gli stessi argomenti e aggiungi il flag--reuse-bootstrap-cluster=true
.Esegui
gcloud ... update
per correggere l'indirizzo IP non valido:gcloud 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, consulta gcloud container bare-metal admin-clusters update.
I dettagli sul processo di creazione del cluster vengono visualizzati sulla workstation di amministrazione. Se i controlli preflight vengono superati, viene visualizzato un risultato simile al seguente:
[2023-03-22 23:12:47+0000] Waiting for cluster kubeconfig to become ready OK [2023-03-22 23:15:47+0000] Writing kubeconfig file [2023-03-22 23:15:47+0000] kubeconfig of cluster being created is present at bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig [2023-03-22 23:15:47+0000] Please restrict access to this file as it contains authentication credentials of your cluster. [2023-03-22 23:15:47+0000] Waiting for cluster to become ready OK [2023-03-22 23:20:17+0000] Please run [2023-03-22 23:20:17+0000] kubectl --kubeconfig bmctl-workspace/abm-cluster-1/abm-cluster-1-kubeconfig get nodes [2023-03-22 23:20:17+0000] to get cluster nodes status. [2023-03-22 23:20:17+0000] Waiting for node pools to become ready OK [2023-03-22 23:20:37+0000] Waiting for metrics to become ready in GCP OK [2023-03-22 23:25:38+0000] Waiting for cluster API provider to install in the created admin cluster OK [2023-03-22 23:25:48+0000] Moving admin cluster resources to the created admin cluster [2023-03-22 23:25:51+0000] Waiting for node update jobs to finish OK [2023-03-22 23:27:41+0000] Flushing logs... OK [2023-03-22 23:27:41+0000] Deleting membership... OK [2023-03-22 23:27:42+0000] Deleting bootstrap cluster.
Connettiti al cluster di amministrazione
Il comando bmctl register bootstrap
crea un file kubeconfig
per il cluster di amministrazione sulla workstation di amministrazione. La directory in cui si trova kubeconfig
e il nome del file si basano sul nome del cluster di amministrazione come segue:
bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig
Devi limitare l'accesso a questo kubeconfig
perché contiene
le credenziali di autenticazione per il cluster.
Se vuoi utilizzare la tua identità Google per accedere al cluster, puoi configurare il gateway di connessione nel seguente modo:
Sulla workstation amministrativa, imposta la variabile di ambiente
KUBECONFIG
:export KUBECONFIG=$HOME/bmctl-workspace/ADMIN_CLUSTER_NAME/ADMIN_CLUSTER_NAME-kubeconfig
Imposta il contesto corrente in una variabile di ambiente:
export CONTEXT="$(kubectl config current-context)"
Esegui questo comando
gcloud
. Questo comando esegue le seguenti operazioni:- Concede al tuo account utente il ruolo Kubernetes
clusterrole/view
sul cluster. - Configura il cluster in modo da poter eseguire comandi
kubectl
di sola lettura sul computer locale senza dover utilizzare SSH per connettersi alla workstation di amministrazione.
Sostituisci
GOOGLE_ACCOUNT_EMAIL
con l'indirizzo email associato al tuo account Google Cloud . Ad esempio:--users=alex@example.com
.gcloud container fleet memberships generate-gateway-rbac \ --membership=ADMIN_CLUSTER_NAME \ --role=clusterrole/view \ --users=GOOGLE_ACCOUNT_EMAIL \ --project=FLEET_HOST_PROJECT_ID \ --kubeconfig=$KUBECONFIG \ --context=$CONTEXT\ --apply
L'output di questo comando è simile al seguente, che è troncato per facilitare la lettura:
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.
- Concede al tuo account utente il ruolo Kubernetes
Con queste norme RBAC in vigore, puoi accedere al cluster dalla console utilizzando la tua identità Google. Inoltre, puoi eseguire
comandi kubectl
di sola lettura su computer diversi dalla workstation amministrativa utilizzando
un kubeconfig
speciale che instrada le richieste tramite il
gateway di connessione.
Esegui il seguente comando su un computer diverso dalla workstation di amministrazione per ottenere 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.
Ora puoi eseguire i comandi
kubectl
tramite il gateway di connessione:kubectl get pods -A
Passaggi successivi
- Eliminare un cluster di amministrazione
- Annullare la registrazione di un cluster non disponibile
- Aggiungere un cluster utente
- Gestire i cluster dalla console Google Cloud