Installazione tramite DHCP

Questa pagina spiega come installare GKE On-Prem in un ambiente VMware vSphere 6.5 o 6.7 Update 3 utilizzando un server Dynamic Host Configuration Protocol (DHCP) esistente per assegnare indirizzi IP ai nodi del cluster. Puoi anche installarlo utilizzando IP statici.

Panoramica

Questa pagina mostra come creare un cluster di amministrazione e un cluster di utenti con tre nodi. Ogni nodo viene eseguito su una macchina virtuale (VM) in un cluster vSphere e a ogni nodo è assegnato un indirizzo IP da un server DHCP nel tuo ambiente.

Dopo aver creato i cluster, puoi crearne altri e aggiungerli o rimuoverli in un cluster utente.

Prima di iniziare

  1. Configura l'ambiente on-premise come descritto nei Requisiti di sistema.

  2. Completa le procedure descritte in Preparare l'installazione.

  3. Crea una workstation di amministrazione in vSphere.

  4. Accedi a SSH nella workstation di amministrazione:

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

  5. Se utilizzi un proxy, tutti i comandi gkectl utilizzano automaticamente lo stesso proxy impostato nella config.yaml per le richieste Internet dalla workstation di amministrazione. Questo è l'ambiente consigliato, in cui la workstation di amministrazione e tutti i cluster utilizzano lo stesso proxy. In questo caso d'uso non è necessario impostare le variabili di ambiente proxy.

    Opzioni proxy manuali: se la workstation di amministrazione non si trova dietro lo stesso proxy, devi configurare manualmente l'ambiente per assicurarti che abbia accesso a Internet. Puoi impostare la variabile di ambiente HTTPS_PROXY per eseguire il proxy di tutte le richieste HTTPS, inclusi i comandi gkectl, ma devi anche configurare la variabile di ambiente NO_PROXY per tutte le richieste che vuoi escludere dal proxy.

    Se devi eseguire anche i comandi gcloud e gsutil singolarmente, puoi configurare Google Cloud CLI in modo che utilizzi sempre un proxy specifico. Per le istruzioni, vedi Configurazione dell'interfaccia a riga di comando gcloud da utilizzare dietro un proxy/firewall.

    Utilizza le seguenti opzioni per impostare manualmente un proxy per i comandi gkectl:

    • Tutti i gkectl comandi:

      Puoi utilizzare le variabili di ambiente HTTPS_PROXY e NO_PROXY per impostare manualmente il proxy di tutti i comandi gkectl:

      • Imposta un proxy diverso per i comandi gkectl. Esempio: 
        HTTPS_PROXY="http://my.other.proxy"
NO_PROXY="10.0.1.0/24,private-registry.example,10.0.2.1"
      • Escludi il tuo proxy gkectl dal proxy. Esempio: HTTPS_PROXY=""
      export HTTP_PROXY="http://[PROXY_ADDRESS]"
export HTTPS_PROXY="http://[PROXY_ADDRESS]"
export NO_PROXY="[NO_PROXY_ADDRESSES]"

      dove

      • [PROXY_ADDRESS] può essere vuoto (""), un indirizzo IP del proxy o il nome host del proxy.
      • [NO_PROXY_ADDRESSES] può essere un elenco separato da virgole di URL, indirizzi IP o nomi host che vuoi escludere dal proxy, ma non possono contenere spazi o schede.

    • Singoli comandi gkectl:

      Puoi anche anteporre il singolo comando gkectl alla variabile di ambiente per utilizzare un proxy specificato solo per la chiamata.

      Esempi:

      Per eseguire il proxy dei comandi gkectl attraverso un proxy diverso da quanto specificato nel file di configurazione (config.yaml), utilizza la variabile di ambiente HTTPS_PROXY:

      • Per utilizzare il proxy http://my.other.proxy: 
        • HTTPS_PROXY="http://my.other.proxy" gkectl create cluster --config config.yaml
        • HTTPS_PROXY="http://my.other.proxy" gkectl prepare --config config.yaml
      • Utilizza un valore vuoto per escludere un proxy: 
        • HTTPS_PROXY="" gkectl create cluster --config config.yaml
        • HTTPS_PROXY="" gkectl check-config --config config.yaml

  6. Accedi a Google Cloud utilizzando le credenziali del tuo account utente Google Cloud. L'account utente deve avere almeno il ruolo IAM Visualizzatore:

    gcloud auth login

  7. Se utilizzi un proxy, devi configurare Google Cloud CLI in modo che i comandi gcloud e gsutil lo utilizzino. Per le istruzioni, consulta la pagina sulla configurazione dell'interfaccia a riga di comando gcloud da utilizzare dietro un proxy/firewall.

  8. Imposta un progetto predefinito. L'impostazione di un'istanza di Google Cloud predefinita fa sì che tutti i comandi dell'interfaccia a riga di comando gcloud vengano eseguiti sul progetto, quindi non è necessario specificare il progetto per ogni comando:

    gcloud config set project [PROJECT_ID]

    Sostituisci [PROJECT_ID] con il tuo ID progetto. (Puoi trovare il tuo ID progetto in Google Cloud Console o eseguendo gcloud config get-value project).

Utilizzo delle prenotazioni DHCP per i nodi del cluster

In Kubernetes è importante che gli indirizzi IP dei nodi non cambino mai. Se un indirizzo IP del nodo cambia o diventa non disponibile, può interrompere il cluster. Per evitare ciò, valuta la possibilità di utilizzare le prenotazioni DHCP per assegnare nodi di indirizzi permanenti nei cluster di amministrazione e utente. L'utilizzo delle prenotazioni DHCP garantisce che a ogni nodo vengano assegnati gli stessi indirizzi IP dopo il riavvio o il lease del rinnovo.

Indirizzi IP necessari per i cluster di amministrazione e di utenti

Il server DHCP deve essere in grado di fornire un numero di indirizzi IP sufficiente per l'amministrazione e i nodi del cluster utente.

Indirizzi IP necessari per il cluster di amministrazione

Il cluster di amministrazione deve avere gli indirizzi per i nodi seguenti:

  • Un nodo per il piano di controllo del cluster di amministrazione
  • Due nodi per componenti aggiuntivi nel cluster di amministrazione
  • Un nodo temporaneo occasionale durante un upgrade del cluster di amministrazione
  • Per ogni cluster utente associato, uno o tre nodi

Per un cluster utente ad alta disponibilità, il cluster di amministrazione ha tre nodi che eseguono componenti del piano di controllo per il cluster utente. Per un cluster utente non ad alta disponibilità, il cluster di amministrazione ha un nodo che esegue componenti del piano di controllo per il cluster utente,

Supponiamo che N sia il numero di cluster utente non ad alta disponibilità che intendi creare e H sia il numero di cluster utente ad alta disponibilità che intendi creare. Il tuo server DHCP deve essere in grado di fornire almeno questo numero di indirizzi IP per i nodi del cluster di amministrazione:

4 + N + 3 x H

Ad esempio, supponi di voler creare un cluster di amministrazione e un cluster utente ad alta disponibilità. Quindi il server DHCP deve fornire sette indirizzi IP per il tuo cluster di amministrazione.

Indirizzi IP necessari per un cluster utente

Un cluster utente deve avere un indirizzo IP per ogni nodo e un indirizzo IP aggiuntivo da utilizzare per un nodo temporaneo durante un upgrade del cluster utente.

Supponi, ad esempio, che intendi creare un cluster utente con cinque nodi. Quindi il server DHCP deve fornire sei indirizzi IP per il tuo cluster utente.

Scegliere un registro di immagini container per l'installazione

Per eseguire l'installazione, GKE On-Prem deve sapere dove estrarre i componenti del cluster containerizzati. Sono disponibili due opzioni:

Container Registry

Per impostazione predefinita, GKE On-Prem utilizza un registro di immagini container esistente di proprietà di Google ospitato da Container Registry. Oltre a configurare il proxy per consentire il traffico da gcr.io, questa configurazione non richiede ulteriori configurazioni.

Registro Docker privato

Puoi scegliere di utilizzare un registro Docker privato per l'installazione. GKE On-Prem esegue il push dei componenti del cluster a tale registro Docker. Per specificare un registro Docker privato, imposta il campo privateregistryconfig.

Configurazione di un registro Docker privato per l'installazione (facoltativo)

Questa sezione spiega come configurare un registro Docker esistente per l'installazione di GKE On-Prem. Per scoprire come creare un registro Docker, vedi Eseguire un registro accessibile esternamente. Dopo aver configurato il Registro di sistema, compila il campo privateregistryconfig del file di configurazione GKE On-Prem.

Se vuoi utilizzare un registro Docker privato per l'installazione, la tua VM della workstation di amministrazione deve considerare attendibile la CA che ha firmato il certificato. GKE On-Prem non supporta i registri Docker non protetti. Quando avvii il tuo registro Docker, devi fornire un certificato e una chiave. Il certificato può essere firmato da un'autorità di certificazione pubblica (CA) o autofirmato.

Per stabilire questo trust, esegui i seguenti passaggi dalla VM della workstation di amministrazione:

  1. Crea una cartella in cui conservare il certificato:

    sudo mkdir -p /etc/docker/certs.d/[REGISTRY_SERVER]

    dove [REGISTRY_SERVER] è l'indirizzo IP o il nome host della VM che esegue il tuo registro Docker.

  2. Copia il file del certificato in /etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt. Devi assegnare un nome al file ca.crt, anche se in origine aveva un nome diverso.

  3. Riavvia il servizio Docker:

    sudo service docker restart

  4. Verifica di poter accedere a Docker:

    docker login -u [USERNAME] -p [PASSWORD] [REGISTRY_SERVER]

    dove [USERNAME] e [PASSWORD] sono le credenziali per l'accesso al registro Docker.

Quando esegui gkectl prepare durante l'installazione, viene eseguito il push delle immagini necessarie per l'installazione nel registro Docker.

Risoluzione dei problemi di configurazione del Registro di sistema

  • GET https://[REGISTRY_SERVER]/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers): Assicurati di avere l'indirizzo IP corretto per la VM che esegue il tuo registro Docker.

  • login attempt to https://[REGISTRY_SERVER]/v2/ failed with status: 401 Unauthorized: Assicurati che il tuo nome utente e la password siano corretti.

  • GET https://[REGISTRY_SERVER]/v1/users/: x509: certificate signed by unknown authority: la tua VM della workstation di amministrazione non considera attendibile il certificato.

Crea account di servizio' chiavi private nella workstation di amministrazione

In Preparazione all'installazione, hai creato quattro account di servizio. Ora devi creare un file di una chiave privata JSON per ciascuno di questi account di servizio. Dovrai fornire queste chiavi durante l'installazione.

Elenco account di servizio' indirizzi email

Innanzitutto, elenca gli account di servizio nel progetto Google Cloud:

gcloud iam service-accounts list

Per un progetto Google Cloud denominato my-gcp-project, l'output di questo comando ha il seguente aspetto:

gcloud iam service-accounts list
NAME                                    EMAIL
                                        allowlisted-service-account@my-gcp-project.iam.gserviceaccount.com
                                        connect-register-service-account@my-gcp-project.iam.gserviceaccount.com
                                        connect-agent-service-account@my-gcp-project.iam.gserviceaccount.com
                                        log-mon-service-account@my-gcp-project.iam.gserviceaccount.com

Prendi nota di ogni indirizzo email di ogni account. Per ciascuna delle seguenti sezioni, fornisci l'account email dell'account pertinente.

Account di servizio incluso nella lista consentita

gcloud iam service-accounts keys create-whitelisted-key.json \
--iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]

dove [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email dell'account di servizio incluso nella lista consentita.

Registra account di servizio

gcloud iam service-accounts keys create register-key.json \
--iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]

dove [REGISTER_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email dell'account di servizio di registrazione.

Connetti account di servizio

gcloud iam service-accounts keys create connect-key.json \
--iam-account [CONNECT_SERVICE_ACCOUNT_EMAIL]

dove [CONNECT_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email dell'account di servizio di connessione.

Account di servizio Cloud Monitoring

gcloud iam service-accounts keys create stackdriver-key.json \
--iam-account [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]

dove [STACKDRIVER_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email dell'account di servizio di Cloud Monitoring.

Generazione di un file di configurazione

Per avviare un'installazione, esegui gkectl create-config per generare un file di configurazione. Puoi modificare il file con le specifiche dell'ambiente e con le specifiche del cluster che preferisci.

Per generare il file, esegui questo comando, dove --config [PATH] è facoltativo e accetta un percorso e un nome per il file di configurazione. L'omissione di --config crea config.yaml nell'attuale directory di lavoro:

gkectl create-config [--config [PATH]]

Modificare il file di configurazione

Ora che hai generato il file di configurazione, devi modificarlo in modo che sia adatto al tuo ambiente e che soddisfi le tue aspettative per i tuoi cluster. Le sezioni seguenti spiegano ciascun campo, i valori previsti e dove puoi trovare le informazioni. Alcuni campi vengono commentati per impostazione predefinita. Se uno di questi campi è pertinente per l'installazione, rimuovi il commento e fornisci i valori.

Le istruzioni riportate in questa sezione mostrano come utilizzare un singolo comando che crea un cluster di amministrazione e un cluster utente. A partire dalla versione 1.2, puoi creare separatamente i cluster utente e amministratore.

bundlepath

Il file bundle di GKE On-Prem contiene tutti i componenti di una determinata release di GKE On-Prem. Quando crei una workstation di amministrazione, questa viene fornita con un pacchetto completo all'indirizzo /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz. La versione di questo bundle corrisponde alla versione dell'OVA che hai importato per creare la workstation di amministrazione.

Imposta il valore di bundlepath sul percorso del file del bundle della workstation di amministrazione. In altre parole, imposta bundlepath su:

/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz

dove [VERSION] è la versione di GKE On-Prem che stai installando. L'ultima versione è 1.4.3-gke.3.

Tieni presente che puoi liberare il file del bundle in una posizione diversa o assegnargli un nome diverso. Assicurati che nel file di configurazione il valore bundlepath corrisponda al percorso del file del bundle, a prescindere da quale sia il valore.

Specifica vCenter

La specifica vCenter Server, vcenter, contiene informazioni sulla tua istanza vCenter Server che GKE On-Prem deve installare nel tuo ambiente.

vcenter.credentials.address

Il campo vcenter.credentials.address contiene l'indirizzo IP o il nome host del server vCenter.

Prima di compilare la vsphere.credentials.address field, scarica e ispeziona il certificato di pubblicazione del server vCenter. Inserisci il comando seguente per scaricare il certificato e salvarlo in un file denominato vcenter.pem.

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

Apri il file del certificato per visualizzare il nome comune dell'oggetto e il nome alternativo dell'oggetto:

openssl x509 -in vcenter.pem -text -noout

L'output mostra il nome comune (CN) Subject. Potrebbe essere un indirizzo IP o un nome host. Ad esempio:

Subject: ... CN = 203.0.113.100
Subject: ... CN = my-host.my-domain.example

L'output potrebbe includere anche uno o più nomi DNS in Subject Alternative Name:

X509v3 Subject Alternative Name:
    DNS:vcenter.my-domain.example

Scegli il nome comune Subject o uno dei nomi DNS in Subject Alternative Name da utilizzare come valore di vcenter.credentials.address nel file di configurazione. Ad esempio:

vcenter:
  credentials:
    address: "203.0.113.1"
    ...

vcenter:
  credentials:
    address: "my-host.my-domain.example"
    ...

Devi scegliere un valore visualizzato nel certificato. Ad esempio, se l'indirizzo IP non compare nel certificato, non puoi utilizzarlo per vcenter.credentials.address.

vcenter.credentials

GKE On-Prem deve conoscere il nome utente e la password di vCenter Server. Per fornire queste informazioni, imposta i valori username e password in vcenter.credentials. Ad esempio:

vcenter:
  credentials:
    ...
    username: "my-name"
    password: "my-password"

vcenter.datacenter, .datastore, .cluster, .network

GKE On-Prem richiede alcune informazioni sulla struttura del tuo ambiente vSphere. Imposta i valori in vcenter per fornire queste informazioni. Ad esempio:

vcenter:
  ...
  datacenter: "MY-DATACENTER"
  datastore: "MY-DATASTORE"
  cluster: "MY-VSPHERE-CLUSTER"
  network: "MY-VIRTUAL-NETWORK"

vcenter.resourcepool

Un pool di risorse vSphere è un raggruppamento logico di VM vSphere nel cluster vSphere. Se utilizzi un pool di risorse diverso da quello predefinito, fornisci il nome a vcenter.resourcepool. Ad esempio:

vcenter:
  ...
  resourcepool: "my-pool"

Se vuoi che GKE On-Prem esegua il deployment dei suoi nodi nel pool di risorse predefinito del cluster vSphere, fornisci una stringa vuota a vcenter.resourcepool. Ad esempio:

vcenter:
  ...
  resourcepool: ""

vcenter.datadisk

GKE On-Prem crea un disco della macchina virtuale (VMDK) per conservare i dati dell'oggetto Kubernetes per il cluster di amministrazione. Il programma di installazione crea il VMDK per te, ma devi fornire un nome per il VMDK nel campo vcenter.datadisk. Ad esempio:

vcenter:
  ...
  datadisk: "my-disk.vmdk"
Datastore vSAN: creazione di una cartella per il VMDK

Se utilizzi un datastore vSAN, devi inserire il VMDK in una cartella. La cartella deve essere creata manualmente in anticipo. Per farlo, puoi utilizzare govc per creare una cartella:

govc datastore.mkdir -namespace=true my-gke-on-prem-folder

quindi imposta vcenter.datadisk sul percorso del VMDK, che include la cartella. Ad esempio:

vcenter:
...
datadisk: "my-gke-on-prem-folder/my-disk.vmdk"

Nella versione 1.1.1 e precedenti, un problema noto richiede che il percorso dell'identificatore univoco universale (UUID) della cartella, anziché il relativo percorso file, venga inviato a vcenter.datadisk. Copialo dall'output del comando govc riportato sopra.

Quindi, fornisci l'UUID della cartella nel campo vcenter.datadisk. Non inserire una barra davanti all'UUID. Ad esempio:

vcenter:
...
datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"

Questo problema è stato risolto nelle versioni 1.1.2 e successive.

vcenter.cacertpath

Quando un client, come GKE On-Prem, invia una richiesta a vCenter Server, il server deve dimostrare la propria identità al client presentando un certificato o un bundle di certificati. Per verificare il certificato o il bundle, GKE On-Prem deve avere il certificato radice nella catena di attendibilità.

Imposta vcenter.cacertpath sul percorso del certificato radice. Ad esempio:

vcenter:
  ...
  cacertpath: "/my-cert-folder/the-root.crt"

La tua installazione VMware ha un'autorità di certificazione (CA) che emette un certificato per il server vCenter. Il certificato radice nella catena di attendibilità è un certificato autofirmato creato da VMware.

Se non vuoi utilizzare VMWare CA, che è l'impostazione predefinita, puoi configurare VMware in modo che utilizzi un'autorità di certificazione diversa.

Se il server vCenter utilizza un certificato emesso dalla CA VMware predefinita, esistono diversi modi per ottenere il certificato radice:

  • curl -k "https://[SERVER_ADDRESS]/certs/download.zip" > download.zip

    dove [SERVER_ADDRESS] è l'indirizzo del server vCenter.

  • Inserisci l'indirizzo del server vCenter in un browser. Nella casella grigia a destra, fai clic su Scarica certificati CA radice attendibili.

  • Inserisci questo comando per ottenere il certificato di gestione:

    true | openssl s_client -connect [SERVER_ADDRESS]:443 -showcerts

    Nell'output, individua un URL simile al seguente: https://[SERVER_ADDRESS]/afd/vecs/ca. Inserisci l'URL in un browser. Viene scaricato il certificato radice.

Il file scaricato si chiama downloads.zip.

Decomprimi il file:

unzip downloads.zip

Se il comando decomprimi non funziona la prima volta, inseriscilo di nuovo.

Trova il file del certificato in certs/lin.

Specifica proxy

Se la rete è protetta da un server proxy, compila il campo proxy con il proxy HTTPS e gli indirizzi che devono essere esclusi dal proxy. Ad esempio:

proxy:
  url: "https://username:password@domain"
  noproxy: "10.0.1.0/24,private-registry.example,10.0.2.1"

Specifica del cluster di amministrazione

La specifica del cluster di amministrazione, admincluster, contiene le informazioni di cui GKE On-Prem deve creare il cluster di amministrazione.

admincluster.vcenter.network

In admincluster.vcenter.network, puoi specificare una rete vCenter per i nodi del cluster di amministrazione. Tieni presente che questa operazione sostituisce l'impostazione globale che hai fornito in vcenter. Ad esempio:

admincluster:
  vcenter:
    network: MY-ADMIN-CLUSTER-NETWORK

admincluster.ipblockfilepath

Questo campo viene utilizzato se utilizzi IP statici. Poiché utilizzi un server DHCP per allocare indirizzi IP, lascia vuoto il campo admincluster.ipblockfilepath.

admincluster.bigip.credentials (modalità di bilanciamento del carico integrata)

Se utilizzi la modalità di bilanciamento del carico integrata, GKE On-Prem deve conoscere l'indirizzo IP o il nome host, il nome utente e la password del tuo bilanciatore del carico BIG-IP F5. Imposta i valori in admincluster.bigip per fornire queste informazioni. Ad esempio:

admincluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.2"
      username: "my-admin-f5-name"
      password: "rJDlm^%7aOzw"

admincluster.bigip.credentials (modalità di bilanciamento del carico integrata)

Se utilizzi la modalità di bilanciamento del carico integrata, devi creare una partizione BIG-IP per il tuo cluster di amministrazione. Imposta admincluster.bigip.partition sul nome della partizione. Ad esempio:

admincluster:
  ...
  bigip:
    partition: "my-admin-f5-partition"

admincluster.vips

Imposta il valore di admincluster.vips.controlplanevip sull'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster di amministrazione. Imposta il valore di ingressvip sull'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il controller in entrata del cluster di amministrazione. Ad esempio:

admincluster:
  ...
  vips:
    controlplanevip: 203.0.113.3
    ingressvip: 203.0.113.4

admincluster.serviceiprange e admincluster.podiprange

Il cluster di amministrazione deve avere un intervallo di indirizzi IP da usare per i servizi e un intervallo di indirizzi IP da usare per i pod. Questi intervalli sono specificati dai campi admincluster.serviceiprange e admincluster.podiprange. Questi campi vengono completati quando esegui gkectl create-config. Se vuoi, puoi modificare i valori completati e utilizzare quelli che preferisci.

Gli intervalli di servizi e pod non devono sovrapporsi. Inoltre, gli intervalli di servizi e pod non devono sovrapporsi agli indirizzi IP utilizzati per i nodi in qualsiasi cluster.

Esempio:

admincluster:
  ...
  serviceiprange: 10.96.232.0/24
  podiprange: 192.168.0.0/16

Specifica del cluster utente

La specifica del cluster utente, usercluster, contiene le informazioni di cui GKE on-prem deve creare il cluster utente iniziale.

Disabilitazione delle regole anti-affinità DRS VMware (facoltativo)

GKE On-Prem crea automaticamente le regole anti-affinità di Distributed Resource Scheduler (DRS) di VMware per i nodi del cluster utente, in modo da distribuirle in almeno tre host fisici del data center.

Questa funzionalità richiede che il tuo ambiente vSphere soddisfi le seguenti condizioni:

  • VMware DRS è abilitato. VMware DRS richiede la versione di licenza vSphere Enterprise Plus. Per informazioni su come abilitare gli DRS, consulta Abilitare DRS VMware in un cluster.
  • L'account utente vSphere fornito nel campo vcenter dispone dell'autorizzazione Host.Inventory.EditCluster.
  • Sono disponibili almeno tre host fisici.

Ricorda che se hai una licenza vSpphere Standard, non puoi abilitare VMware DRS.

Se non hai abilitato DRS o se non hai almeno tre host in cui VM possono essere pianificate vSphere, aggiungi usercluster.antiaffinitygroups.enabled: false al file di configurazione. Ad esempio:

usercluster:
  ...
  antiaffinitygroups:
    enabled: false

Per ulteriori informazioni, consulta le note di rilascio per la versione 1.1.0-gke.6.

Per cluster che eseguono più di tre nodi
Se vSphere vMotion sposta un nodo in un host diverso, sarà necessario riavviare i carichi di lavoro del nodo prima che vengano distribuiti di nuovo tra gli host.

usercluster.vcenter.network

In usercluster.vcenter.network, puoi specificare una rete vCenter per i nodi del cluster utente. Tieni presente che questa operazione sostituisce l'impostazione globale che hai fornito in vcenter. Ad esempio:

usercluster:
  vcenter:
    network: MY-USER-CLUSTER-NETWORK

usercluster.ipblockfilepath

Questo campo viene utilizzato se utilizzi IP statici. Poiché utilizzi un server DHCP per allocare indirizzi IP, lascia vuoto il campo usercluster.ipblockfilepath.

usercluster.bigip.credentials (modalità di bilanciamento del carico integrata)

Se utilizzi la modalità di bilanciamento del carico integrata, GKE On-Prem deve conoscere l'indirizzo IP o il nome host, il nome utente e la password del bilanciatore del carico BIG-IP di F5 che intendi utilizzare per il cluster utente. Imposta i valori in usercluster.bigip per fornire queste informazioni. Ad esempio:

usercluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.5"
      username: "my-user-f5-name"
      password: "8%jfQATKO$#z"
  ...

usercluster.bigip.partition (modalità di bilanciamento del carico integrata)

Devi creare una partizione BIG-IP per il tuo cluster utente. Imposta usercluster.bigip.partition sul nome della partizione. Ad esempio:

usercluster:
  ...
  bigip:
    partition: "my-user-f5-partition"
  ...

usercluster.vips

Imposta il valore di usercluster.vips.controlplanevip sull'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il server API Kubernetes del cluster utente. Imposta il valore di ingressvip sull'indirizzo IP che hai scelto di configurare sul bilanciatore del carico per il controller in entrata del cluster utente. Ad esempio:

usercluster:
  ...
  vips:
    controlplanevip: 203.0.113.6
    ingressvip: 203.0.113.7

usercluster.serviceiprange e usercluster.podiprange

Il cluster utente deve avere un intervallo di indirizzi IP da utilizzare per i servizi e un intervallo di indirizzi IP da usare per i pod. Questi intervalli sono specificati dai campi usercluster.serviceiprange e usercluster.podiprange. Questi campi vengono completati quando esegui gkectl create-config. Se vuoi, puoi modificare i valori completati e utilizzare quelli che preferisci.

Gli intervalli di servizi e pod non devono sovrapporsi. Inoltre, gli intervalli di servizi e pod non devono sovrapporsi agli indirizzi IP utilizzati per i nodi in qualsiasi cluster.

Esempio:

usercluster:
  ...
  serviceiprange: 10.96.233.0/24
  podiprange: 172.16.0.0/12

usercluster.clustername

Imposta il valore di usercluster.clustername sul nome che preferisci. Scegli un nome di lunghezza non superiore a 40 caratteri. Ad esempio:

usercluster:
  ...
  clustername: "my-user-cluster-1"

usercluster.masternode.replicas

Il campo usercluster.masternode.replicas specifica il numero di nodi del piano di controllo che vuoi avere per il cluster utente. Un nodo del piano di controllo del cluster utente esegue il piano di controllo dell'utente, i componenti del piano di controllo Kubernetes. Questo valore deve essere 1 o 3:

usercluster.masternode.cpus e usercluster.masternode.memorymb

I campi usercluster.masternode.cpus e usercluster.masternode.memorymb specificano la quantità di CPU e quantità di memoria, in megabyte, assegnata a ogni nodo del piano di controllo del cluster utente. Ad esempio:

usercluster:
  ...
  masternode:
    cpus: 4
    memorymb: 8192

usercluster.workernode.replicas

Il campo usercluster.workernode.replicas specifica il numero di nodi worker che vuoi che il cluster utente abbia. I nodi worker eseguono i carichi di lavoro del cluster.

usercluster.workernode.cpus e usercluster.workernode.memorymb

I campi usercluster.masternode.cpus e usercluster.masternode.memorymb specificano la quantità di CPU e quantità di memoria, in megabyte, assegnata a ogni nodo worker del cluster utente. Ad esempio:

usercluster:
  ...
  workernode:
    cpus: 4
    memorymb: 8192
    replicas: 3

usercluster.oidc

Se vuoi che i client del cluster utente utilizzino l'autenticazione OIDC, imposta i valori per i campi sotto usercluster.oidc. La configurazione di OIDC è facoltativa.

Per informazioni su come configurare l'OIDC, consulta l'articolo sull'autenticazione con OIDC.

Informazioni sull'installazione della versione 1.0.2-gke.3

La versione 1.0.2-gke.3 introduce i seguenti campi OIDC (usercluster.oidc). Questi campi consentono di accedere a un cluster da Google Cloud Console:

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

Nella versione 1.0.2-gke.3, se vuoi utilizzare OIDC, il campo clientsecret è obbligatorio anche se non vuoi accedere a un cluster da Google Cloud Console. In tal caso, puoi fornire un valore segnaposto per clientsecret:

oidc:
clientsecret: "secret"

usercluster.sni

SNI (Server Name Indication), un'estensione di TLS (Transport Layer Security), che consente ai server di presentare più certificati su un singolo indirizzo IP e una singola porta TCP, a seconda del nome host indicato dal client.

Se la tua CA è già distribuita come CA attendibile per i client al di fuori del cluster utente e vuoi fare affidamento su questa catena per identificare i cluster attendibili, puoi configurare il server API Kubernetes con un certificato aggiuntivo presentato ai client esterni dell'indirizzo IP del bilanciatore del carico.

Per utilizzare SNI con i tuoi cluster utente, devi avere una tua CA e una Public Key Infrastructure (PKI). Esegui il provisioning di un certificato di gestione separato per ogni cluster utente e GKE On-Prem aggiunge ogni certificato di pubblicazione aggiuntivo al rispettivo cluster utente.

Per configurare SNI per il server API Kubernetes del cluster utente, fornisci i valori per usercluster.sni.certpath (percorso del certificato esterno) e usercluster.sni.keypath (percorso del file della chiave privata del certificato esterno). Ad esempio:

usercluster:
  ...
  sni:
    certpath: "/my-cert-folder/example.com.crt"
    keypath: "/my-cert-folder/example.com.key"

lbmode

Puoi utilizzare il bilanciamento del carico integrato con DHCP. La modalità di bilanciamento del carico integrata si applica al cluster di amministrazione e al cluster utente iniziale. Si applica anche a eventuali cluster utente aggiuntivi che creerai in futuro. Integra la modalità di bilanciamento del carico utilizzando F5 BIG-IP come bilanciatore del carico.

Imposta il valore di lbmode su Integrated. Ad esempio:

lbmode: Integrated

gkeconnect

La specifica gkeconnect contiene le informazioni necessarie a GKE On-Prem per configurare la gestione dei tuoi cluster on-prem da Google Cloud Console.

Imposta gkeconnect.projectid sull'ID progetto del progetto Google Cloud in cui vuoi gestire i tuoi cluster on-prem.

Imposta il valore di gkeconnect.registerserviceaccountkeypath sul percorso del file della chiave JSON per il tuo account di servizio di registrazione. Imposta il valore di gkeconnect.agentserviceaccountkeypath sul percorso del file della chiave JSON per il tuo account di servizio di connessione.

Esempio:

gkeconnect:
  projectid: "my-project"
  registerserviceaccountkeypath: "/my-key-folder/register-key.json"
  agentserviceaccountkeypath: "/my-key-folder/connect-key.json"

stackdriver

La specifica stackdriver contiene le informazioni necessarie a GKE On-Prem per archiviare le voci di log generate dai cluster on-prem.

Imposta stackdriver.projectid sull'ID del progetto Google Cloud in cui vuoi visualizzare i log di Stackdriver relativi ai tuoi cluster on-prem.

Imposta stackdriver.clusterlocation su una regione di Google Cloud in cui vuoi archiviare i log di Stackdriver. È consigliabile scegliere un'area geografica vicina al data center on-premise.

Imposta stackdriver.enablevpc su true se la rete del cluster è controllata da un VPC. Ciò garantisce che tutta la telemetria passi attraverso gli indirizzi IP con restrizioni di Google.

Imposta stackdriver.serviceaccountkeypath sul percorso del file della chiave JSON per il tuo account di servizio Stackdriver Logging. Ad esempio:

stackdriver:
  projectid: "my-project"
  clusterlocation: "us-west1"
  enablevpc: false
  serviceaccountkeypath: "/my-key-folder/stackdriver-key.json"

privateregistryconfig

Se hai un registro Docker privato, il campo privateregistryconfig contiene le informazioni utilizzate da GKE On-Prem per eseguire il push delle immagini al tuo registro privato. Se non specifichi un registro privato, gkectl esegue il pull delle immagini container GKE on-prem dal suo repository Container Registry, gcr.io/gke-on-prem-release, durante l'installazione.

In privatedockerregistry.credentials, imposta address sull'indirizzo IP della macchina che esegue il registro Docker privato. Imposta username e password sul nome utente e sulla password del tuo registro Docker privato. Il valore impostato per address viene aggiunto automaticamente a proxy.noproxy.

Quando Docker estrae un'immagine dal tuo registro privato, deve dimostrare la propria identità presentando un certificato. Il certificato del registry è firmato da un'autorità di certificazione (CA). Docker utilizza il certificato CA's per convalidare il certificato del registro.

Imposta privateregistryconfig.cacertpath sul percorso del certificato del CA. Ad esempio:

privateregistryconfig
  ...
  cacertpath: /my-cert-folder/registry-ca.crt

gcrkeypath

Imposta il valore di gcrkeypath sul percorso del file della chiave JSON dell'account di servizio incluso nella lista consentita. Ad esempio:

gcrkeypath: "/my-key-folder/whitelisted-key.json"

cloudauditlogging

Se vuoi inviare i tuoi audit log di Kubernetes al tuo progetto Google Cloud, compila la specifica cloudauditlogging. Ad esempio:

cloudauditlogging:
  projectid: "my-project"
  # A Google Cloud region where you would like to store audit logs for this cluster.
  clusterlocation: "us-west1"
  # The absolute or relative path to the key file for a Google Cloud service account used to
  # send audit logs from the cluster
  serviceaccountkeypath: "/my-key-folder/audit-logging-key.json"

Scopri di più sull'utilizzo dell'audit logging.

Convalida del file di configurazione

Completa questo passaggio dalla workstation di amministrazione.

Dopo aver modificato il file di configurazione, esegui gkectl check-config per verificare che il file sia valido e che possa essere utilizzato per l'installazione:

gkectl check-config --config config.yaml

Se il comando restituisce un messaggio FAILURE, risolvi i problemi e convalida di nuovo il file.

Se vuoi saltare le convalide più lunghe, passa il flag --fast. Per saltare le singole convalide, utilizza i flag --skip-validation-xxx. Per ulteriori informazioni sul comando check-config, consulta la pagina Esecuzione dei controlli preliminari.

gkectl prepare in esecuzione

Prima dell'installazione, devi eseguire gkectl prepare sulla workstation di amministrazione per inizializzare l'ambiente vSphere. gkectl prepare esegue le seguenti attività:

  • Importa l'immagine del sistema operativo del nodo in vSphere e contrassegnala come modello.

  • Facoltativamente, convalida le immagini container' crea attestazioni, verificando così che le immagini siano state create e firmate da Google e siano pronte per il deployment.

Esegui gkectl prepare con il file di configurazione GKE On-Prem, dove --validate-attestations è facoltativo:

gkectl prepare --config [CONFIG_FILE] --validate-attestations

L'output positivo di --validate-attestations è Image [IMAGE_NAME] validated.

Installazione di GKE On-Prem

Hai creato un file di configurazione che specifica l'aspetto dell'ambiente e l'aspetto dei tuoi cluster. Hai convalidato il file. Hai eseguito gkectl prepare per inizializzare l'ambiente con il software GKE On-Prem. Ora è tutto pronto per avviare una nuova installazione di GKE On-Prem.

Per installare GKE On-Prem, devi creare i cluster di amministrazione e dell'utente. I passaggi seguenti creano sia il cluster di amministrazione che il cluster utente durante lo stesso processo. Se vuoi creare ciascun cluster separatamente, consulta Creazione di cluster di amministrazione e utente separatamente per i dettagli.

Per creare i cluster di amministrazione e di utenti:

  1. Crea il cluster di amministrazione e il cluster utente eseguendo il comando gkectl create cluster.

    gkectl create cluster --config [CONFIG_FILE]

    dove [CONFIG_FILE] è il file di configurazione creato in precedenza.

    Il comando gkectl create cluster crea kubeconfig file denominato [CLUSTER_NAME]-kubeconfig nella directory attuale dove [CLUSTER_NAME] è il nome che hai impostato per cluster. Esempio: MY-VSPHERE-CLUSTER-kubeconfig

    La documentazione di GKE On-Prem utilizza i seguenti segnaposto per fare riferimento a questi file kubeconfig:

    • Cluster di amministrazione: [ADMIN_CLUSTER_KUBECONFIG]
    • Cluster utente: [USER_CLUSTER_KUBECONFIG]

  2. Verifica che il cluster sia creato e in esecuzione:

    1. Per verificare il cluster di amministrazione, esegui il comando seguente:

      kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

      L'output mostra i nodi del cluster di amministrazione.

    2. Per verificare il cluster utente, esegui questo comando:

      kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]

      L'output mostra i nodi del cluster utente. Ad esempio:

      NAME                        STATUS   ROLES    AGE   VERSION
xxxxxx-1234-ipam-15008527   Ready    <none>   12m   v1.14.7-gke.24
xxxxxx-1234-ipam-1500852a   Ready    <none>   12m   v1.14.7-gke.24
xxxxxx-1234-ipam-15008536   Ready    <none>   12m   v1.14.7-gke.24

Scopri come riutilizzare il file di configurazione per creare cluster utente aggiuntivi.

Ripresa dell'installazione

Se l'installazione viene interrotta dopo la creazione del cluster di amministrazione, puoi riprendere l'installazione seguendo questi passaggi:

  1. Rimuovi la specifica admincluster dal file di configurazione.

  2. Esegui gkectl create cluster con entrambi i flag --kubeconfig e --skip-validation-all per superare il file kubeconfig del cluster di amministrazione e ignora i controlli preliminari:

    gkectl create cluster  \
--config [CONFIG_FILE] \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--skip-validation-all

    dove [ADMIN_CLUSTER_NAME] è il kubeconfig del cluster di amministrazione, che è stato creato nella directory di lavoro all'avvio dell'installazione.

Connessione dei cluster a Google in corso...

Attivazione del traffico in entrata

Quando il cluster utente è in esecuzione, devi abilitare il traffico in entrata creando un oggetto gateway. La prima parte del manifest del gateway è sempre questa:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system

Puoi personalizzare il resto del manifest in base alle tue esigenze. Ad esempio, questo manifest indica che i client possono inviare richieste sulla porta 80 utilizzando il protocollo HTTP/2 e qualsiasi nome host:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system
  servers:
  - port:
      number: 80
      protocol: HTTP2
      name: http
    hosts:
    - "*"

Se vuoi accettare richieste HTTPS, devi fornire uno o più certificati che il controller in entrata possa presentare ai client.

Per fornire un certificato:

  1. Crea un Secret che contenga il certificato e la chiave.
  2. Crea un oggetto gateway o modifica un oggetto gateway esistente che faccia riferimento al tuo secret. Il nome dell'oggetto Gateway deve essere istio-autogenerated-k8s-ingress.

Supponiamo, ad esempio, che tu abbia già creato un file del certificato, ingress-wildcard.crt e un file della chiave ingress-wildcard.key.

Crea un secret denominato ingressgateway-wildcard-certs:

kubectl create secret tls \
    --namespace gke-system \
    ingressgateway-wildcard-certs \
    --cert ./ingress-wildcard.crt \
    --key ./ingress-wildcard.key

Ecco un manifest per un gateway che fa riferimento al tuo secret. I client possono chiamare sulla porta 443 utilizzando il protocollo HTTPS e qualsiasi nome host corrispondente a *.example.com. Tieni presente che il nome host nel certificato deve corrispondere al nome host nel manifest, *.example.com in questo esempio:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system
  servers:
  - port:
      number: 80
      protocol: HTTP2
      name: http
    hosts:
    - "*"
  - hosts:
    - "*.example.com"
    port:
      name: https-demo-wildcard
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: ingressgateway-wildcard-certs

Puoi creare più certificati TLS per host diversi modificando il manifest del gateway.

Salva il manifest in un file denominato my-gateway.yaml e crea il gateway:

kubectl apply -f my-gateway.yaml

Ora puoi utilizzare gli oggetti Kubernetes Ingress nel modo standard.

Creazione di cluster utente e amministratore separatamente

A partire da GKE On-Prem versione 1.2, puoi creare i cluster di amministrazione e utente separatamente. Vale a dire che puoi iniziare creando solo un cluster di amministrazione. Quindi puoi creare uno o più cluster utente in base alle tue esigenze.

Prima della versione 1.2:

  • Il tuo primo cluster utente utilizzava sempre il datastore dei cluster di amministrazione. I cluster utente creati in un secondo momento potrebbero utilizzare un datastore separato dal datastore del cluster di amministrazione.

  • Se hai specificato un datastore separato per un cluster utente, i nodi worker del cluster utente e i volumi permanenti (PV) per i nodi worker hanno utilizzato il datastore separato. Tuttavia, le VM del piano di controllo dell'utente e i PV associati utilizzavano il datastore del cluster di amministrazione.

A partire dalla versione 1.2:

  • Qualsiasi cluster utente, anche il tuo primo cluster di utilizzo, può utilizzare un datastore separato dal datastore del cluster di amministrazione.

  • Se specifichi un datastore separato per un cluster utente, i nodi worker del cluster utente, i PV dei nodi worker del cluster utente, le VM del piano di controllo utente e i PV delle VM del piano di controllo utente usano tutti il datastore separato.

Per creare solo un cluster di amministrazione, rimuovi l'intera sezione usercluster dal file di configurazione del cluster. Quindi inserisci il comando gkectl create:

gkectl create --config [ADMIN_CONFIG_FILE]

dove [ADMIN_CONFIG_FILE] è il percorso del file di configurazione in cui la sezione usercluster è stata rimossa.

A questo punto, crea un file di configurazione in cui è stata rimossa l'intera sezione admincluster. In questo file puoi specificare un datastore vSphere diverso dal datastore del cluster di amministrazione. Per specificare un datastore, inserisci un valore per vcenter.credentials.datastore. Ad esempio:

vcenter:
  credentials:
    ...
  ...
  datastore: "my-user-cluster-datastore"

Per creare un cluster utente, inserisci questo comando:

gkectl create --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]

dove:

  • [ADMIN_CLUSTER_KUBECONFIG] è il file kubeconfig del cluster di amministrazione.
  • [USER_CLUSTER_CONFIG] è il file di configurazione per il cluster utente.

Limitazioni

Limitazione Descrizione
Limiti massimi e minimi per cluster e nodi

Vedi Quote e limiti. Le prestazioni del tuo ambiente potrebbero influire su questi limiti.
Univocità per i nomi dei cluster utente

Tutti i cluster utente registrati allo stesso progetto Google Cloud devono avere nomi univoci.
Impossibile eseguire il deployment in più di un data center vCenter e/o vSphere

Attualmente, puoi eseguire il deployment di un cluster di amministrazione e di un insieme di cluster utente associati in un singolo data center vCenter e/o vSphere. Non puoi eseguire il deployment degli stessi cluster di amministratore e utente in più di un data center vCenter e/o vSphere.
Impossibile modificare in modo dichiarativo le configurazioni dei cluster dopo la creazione Sebbene sia possibile creare cluster aggiuntivi e ridimensionare i cluster esistenti, non è possibile modificare un cluster esistente tramite il relativo file di configurazione.

Risolvere i problemi

Per saperne di più, consulta la sezione Risoluzione dei problemi.

Diagnostica dei problemi del cluster utilizzando gkectl

Utilizza i comandi gkectl diagnoseper identificare i problemi del cluster e condividere le informazioni sul cluster con Google. Consulta la sezione Diagnosi dei problemi del cluster.

Esecuzione di gkectl comandi in modo dettagliato

-v5

Registrazione di gkectl errori in stderr

--alsologtostderr

Individuare i log di gkectl nella workstation di amministrazione

Anche se non passi i flag di debug, puoi visualizzare i log gkectl nella seguente directory della workstation di amministrazione:

/home/ubuntu/.config/gke-on-prem/logs

Individuare i log dell'API del cluster nel cluster di amministrazione

Se l'avvio di una VM non va a buon fine dopo l'avvio del piano di controllo dell'amministratore, puoi tentare di eseguire il debug controllando i controller dell'API del cluster' log nel cluster di amministrazione:

  1. Trova il nome del pod dei controller dell'API Cluster nello spazio dei nomi kube-system, dove [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig del cluster di amministrazione:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

  2. Apri i log del pod, dove [POD_NAME] è il nome del pod. Facoltativamente, utilizza grep o uno strumento simile per cercare gli errori:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

Eseguire il debug dei problemi di BIG-IP di F5 utilizzando il nodo kubeconfig del piano di controllo del cluster di amministrazione

Dopo un'installazione, GKE On-Prem genera un file kubeconfig nella home directory della workstation di amministrazione denominata internal-cluster-kubeconfig-debug. Questo file kubeconfig è identico a kubeconfig del tuo cluster di amministrazione, tranne per il fatto che rimanda direttamente al nodo del piano di controllo del cluster di amministrazione, dove viene eseguito il piano di controllo dell'amministratore. Puoi utilizzare il file internal-cluster-kubeconfig-debug per eseguire il debug dei problemi di BIG-IP di F5.

La convalida di gkectl check-config non riesce: non riesce a trovare le partizioni BIG-IP di F5.

Sintomi

La convalida non riesce perché non è possibile trovare le partizioni BIG-IP di F5, anche se esistono.

Potenziali cause

Un problema con l'API F5 BIG-IP può causare la mancata convalida della convalida.

Risoluzione

Prova a eseguire di nuovo gkectl check-config.

gkectl prepare --validate-attestations non riuscito: impossibile convalidare l'attestazione build

Sintomi

L'esecuzione di gkectl prepare con il flag --validate-attestations facoltativo restituisce il seguente errore:

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
Potenziali cause

Potrebbe non esistere un'attestazione per le immagini interessate.

Risoluzione

Prova a scaricare ed eseguire nuovamente il deployment dell'OVA della workstation di amministrazione, come indicato in Creare una workstation di amministrazione. Se il problema persiste, contatta Google per ricevere assistenza.

Debug utilizzando i log del cluster di bootstrap

Durante l'installazione, GKE On-Prem crea un cluster di bootstrap temporaneo. Una volta completata l'installazione, GKE On-Prem elimina il cluster bootstrap, lasciando il cluster di amministrazione e il cluster utente. In genere, non dovrebbe esserci alcun motivo per interagire con questo cluster.

Se si verifica un problema durante un'installazione e hai superato il comando --cleanup-external-cluster=false per gkectl create cluster, potrebbe essere utile eseguire il debug utilizzando i log del cluster di bootstrap. Puoi trovare il pod e recuperare i relativi log:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

Passaggi successivi