Questa pagina spiega come installare GKE On-Prem in un ambiente VMware vSphere 6.5 o 6.7 Update 3 utilizzando IP statici. Puoi anche installarlo utilizzando un server DHCP.
Panoramica
Le istruzioni riportate in questa pagina mostrano come creare un cluster di amministrazione e un cluster utente con tre nodi. Dopo aver creato i cluster, puoi crearne altri e aggiungerli o rimuoverli in un cluster utente.
Prima di iniziare
Configura l'ambiente come descritto in questi argomenti:
Crea una workstation di amministrazione in vSphere.
Scopri come abilitare il bilanciamento del carico manuale, se vuoi utilizzarlo.
Accedi a SSH nella workstation di amministrazione:
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
-
Se utilizzi un proxy, tutti i comandi
gkectl
utilizzano automaticamente lo stesso proxy impostato nellaconfig.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 richiesteHTTPS
, inclusi i comandigkectl
, ma devi anche configurare la variabile di ambienteNO_PROXY
per tutte le richieste che vuoi escludere dal proxy.Se devi eseguire anche i comandi
gcloud
egsutil
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
eNO_PROXY
per impostare manualmente il proxy di tutti i comandigkectl
:- 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.
- Imposta un proxy diverso per i comandi
- 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 ambienteHTTPS_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
- Per utilizzare il proxy
- Tutti i
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
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 eseguendogcloud config get-value project
).
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:
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.
Copia il file del certificato in
/etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt
. Devi assegnare un nome al fileca.crt
, anche se in origine aveva un nome diverso.Riavvia il servizio Docker:
sudo service docker restart
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.
Configurazione degli indirizzi IP statici
Se vuoi utilizzare indirizzi IP statici, devi creare due file di blocco IP: uno per il cluster di amministrazione e uno per il cluster utente. I file di blocco IP indicano a GKE On-Prem quali indirizzi IP e nomi host assegnare ai nodi del cluster.
Indirizzi IP statici 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. Nel file di blocco IP del cluster di amministrazione, devi specificare almeno questo numero di indirizzi IP:
4 + N + 3 x H
Ad esempio, supponi di voler creare un cluster di amministrazione e un cluster utente ad alta disponibilità. Dovresti quindi mettere da parte sette indirizzi IP per il cluster di amministrazione. Ecco un esempio di file di blocco IP che specifica sette indirizzi IP:
blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.10 hostname: admin-host1 - ip: 172.16.20.11 hostname: admin-host2 - ip: 172.16.20.12 hostname: admin-host3 - ip: 172.16.20.13 hostname: admin-host4 - ip: 172.16.20.14 hostname: admin-host5 - ip: 172.16.20.15 hostname: admin-host6 - ip: 172.16.20.16 hostname: admin-host7
Come puoi vedere nell'esempio precedente, un file di blocco IP contiene una struttura di dati YAML.
Il campo ips
è un array di indirizzi IP e nomi host. Questi sono gli indirizzi e i nomi host IP che GKE On-Prem assegnerà ai nodi del cluster di amministrazione.
Nel file di blocco IP, puoi specificare anche gli indirizzi dei server DNS, dei server degli orari e del gateway predefinito che saranno utilizzati dai nodi del cluster di amministrazione.
Indirizzi IP statici 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, dovrai mettere da parte sei indirizzi IP per il cluster utente. Ecco un esempio di file di blocco IP che specifica sei coppie IP/nome host.
blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.17 hostname: user-host1 - ip: 172.16.20.18 hostname: user-host2 - ip: 172.16.20.19 hostname: user-host3 - ip: 172.16.20.20 hostname: user-host4 - ip: 172.16.20.21 hostname: user-host5 - ip: 172.16.20.22 hostname: user-host6
Ogni hostname
viene interpretato come un nome host locale senza il relativo dominio. Se specifichi un nome di dominio completo, il dominio viene tagliato. Ad esempio, host1.enterprise.net
diventa host1
. Il valore di un campo hostname
deve essere minuscolo.
Crea account di servizio' chiavi private nella workstation di amministrazione
Se non hai ancora creato chiavi JSON per i tuoi account di servizio, creale subito.
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 ... EMAIL component-accesss-sa@my-gcp-project.iam.gserviceaccount.com connect-register-sa@my-gcp-project.iam.gserviceaccount.com connect-agent-sa@my-gcp-project.iam.gserviceaccount.com log-mon-sa@my-gcp-project.iam.gserviceaccount.com
Prendi nota dell'indirizzo email di ogni account. Per ciascuna delle seguenti sezioni, fornisci l'account email dell'account pertinente.
Account di servizio accesso ai componenti
gcloud iam service-accounts keys create component-access-key.json \ --iam-account [COMPONENT_ACCESS_SERVICE_ACCOUNT_EMAIL]
dove [COMPOONENT_ACCESS_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email del tuo account di servizio di accesso ai componenti.
Connetti-registra account di servizio
gcloud iam service-accounts keys create connect-register-key.json \ --iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]
dove [CONECT_REGISTER_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email del tuo account di servizio Connect-register.
Account di servizio Connect-Agent
gcloud iam service-accounts keys create connect-agent-key.json \ --iam-account [CONNECT_AGENT_SERVICE_ACCOUNT_EMAIL]
dove [CONNECT_AGENT_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email del tuo account di servizio connect-agent.
Account di servizio di monitoraggio del logging
gcloud iam service-accounts keys create logging-monitoring-key.json \ --iam-account [LOGGING_MONITORING_SERVICE_ACCOUNT_EMAIL]
dove [LOGGING_MONITORINGH_SERVICE_ACCOUNT_EMAIL] è l'indirizzo email del tuo account di servizio di monitoraggio del logging.
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.5.2-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
contiene le informazioni sulla tua istanza vCenter Server.
GKE On-Prem ha bisogno di queste informazioni per comunicare con il tuo server vCenter.
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 comandogovc
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"
proxy.url
è l'URL del proxy HTTPS.proxy.noproxy
include gli intervalli CIDR, gli indirizzi IP, i domini e i nomi host che non devono essere sottoposti al proxy. Ad esempio, le chiamate agli indirizzi IP dei nodi del cluster non devono essere inviate al proxy. Quindi, se hai una subnet che contiene solo nodi nodo, puoi elencare l'intervallo CIDR della subnet nel camponoproxy
. Tieni presente che seprivateregistryconfig
è specificato, l'indirizzo viene aggiunto automaticamente per evitare chiamate al registro privato.
Specifica del cluster di amministrazione
La specifica admincluster
contiene le informazioni necessarie a GKE On-Prem per 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
Poiché stai utilizzando indirizzi IP statici, devi avere un
file di blocco IP come descritto in
Configurazione di IP statici. Specifica il percorso del file di blocco IP nel campo admincluster.ipblockfilepath
. Ad esempio:
admincluster: ipblockfilepath: "/my-config-folder/my-admin-ipblock.yaml"
admincluster.manuallbspec (modalità di bilanciamento del carico manuale)
Il server API di Kubernetes nel cluster di amministrazione è implementato come servizio di
tipo NodePort
. Se utilizzi il bilanciamento del carico manuale, devi scegliere un valore nodePort
per il servizio. Specifica il valore nodePort
in
controlplanenodeport
. Ad esempio:
admincluster: ... manuallbspec: ... controlplanenodeport: 30968
Il server componenti aggiuntivi nel cluster di amministrazione è implementato come servizio di tipo NodePort
. Se utilizzi il bilanciamento del carico manuale, devi scegliere un valore nodePort
per il servizio. Specifica il valore nodePort
in
controlplanenodeport
. Ad esempio:
admincluster: manuallbspec: ... addonsnodeport: 30562
admincluster.bigip.credentials (modalità di bilanciamento del carico integrata)
Se non utilizzi la modalità di bilanciamento del carico integrata, lascia admincluster.bigip
commentato.
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. 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.partition (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
Indipendentemente dal fatto che tu stia utilizzando il bilanciamento del carico integrato o manuale per
il cluster di amministrazione, devi compilare il campo 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'autorizzazioneHost.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
Poiché utilizzi indirizzi IP statici, devi disporre di un file di blocco IP come descritto in Configurare gli indirizzi IP statici.
Specifica il percorso del file di blocco IP nel campo usercluster.ipblockfilepath
. Ad esempio:
usercluster: ipblockfilepath: "/my-config-folder/my-user-ipblock.yaml"
usercluster.manuallbspec
(modalità di bilanciamento del carico manuale)
Il controller Ingress nel cluster utente viene implementato come un servizio di tipo NodePort.
Il servizio dispone di un servizio ServicePort per HTTP e di un altro ServicePort per HTTPS. Se utilizzi la modalità di bilanciamento del carico manuale, devi scegliere i valori nodePort
per queste ServicePort.
Specifica i valori nodePort
in ingresshttpnodeport
e ingresshttpsnodeport
. Ad esempio:
usercluster: manuallbspec: ingresshttpnodeport: 30243 ingresshttpsnodeport: 30879
Il server API di Kubernetes nel cluster utente viene implementato come servizio di
tipo NodePort
. Se utilizzi il bilanciamento del carico manuale, devi scegliere un valore nodePort
per il servizio. Specifica il valore nodePort
in
controlplanenodeport
. Ad esempio:
usercluster: ... manuallbspec: ... controlplanenodeport: 30562
usercluster.bigip.credentials
(modalità di bilanciamento del carico integrata)
Se utilizzi il bilanciamento del carico integrato, 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)
Se utilizzi la 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
Indipendentemente dal fatto che tu stia utilizzando il bilanciamento del carico integrato o manuale per
il cluster utente, devi compilare il campo 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 usare 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
:
- Imposta questo campo su
1
per eseguire un piano di controllo utente. - Imposta questo campo su
3
se vuoi avere un piano di controllo dell'utente ad alta disponibilità (HA) composto da tre nodi del piano di controllo che eseguono ciascuno un piano di controllo dell'utente.
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
clusterutente.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 perclientsecret
:oidc: clientsecret: "secret"
clusterutente.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 o manuale. La scelta della modalità di bilanciamento del carico si applica al cluster di amministrazione e al cluster utente iniziale. Si applica anche a eventuali cluster utente aggiuntivi che creerai in futuro.
Specifica la scelta del bilanciamento del carico impostando il valore lbmode
su Integrated
o Manual
. 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-prem.
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.
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 che GKE On-Prem utilizza per eseguire il push delle immagini al 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 del servizio di accesso ai componenti.
Ad esempio:
gcrkeypath: "/my-key-folder/component-access-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 [PATH_TO_CONFIG] --fast
Se il comando restituisce un messaggio FAILURE
, risolvi i problemi e convalida di nuovo il file. Utilizza il flag --fast
per saltare i controlli che creano VM di test, che dipendono dall'immagine del sistema operativo del nodo caricata dalla workstation di amministrazione in vCenter entro il giorno gkectl prepare
.
Ignorare le convalide
I seguenti comandi gkectl
eseguono automaticamente le convalide per il tuo file di configurazione:
gkectl prepare
gkectl create cluster
gkectl upgrade
Per saltare le convalide di un comando, passa --skip-validation-all
. Ad esempio, per saltare tutte le convalide per gkectl prepare
:
gkectl prepare --config [PATH_TO_CONFIG] --skip-validation-all
Per visualizzare tutti i flag disponibili per saltare specifiche convalide:
gkectl check-config --help
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.
Se utilizzi un registro Docker privato, esegui il push di immagini GKE On-Prem al tuo registro.
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
.
Convalidare di nuovo il file di configurazione
Dopo aver caricato l'immagine del sistema operativo del nodo eseguendo gkectl prepare
, esegui gkectl check-config
senza il flag --fast
, in modo da eseguire i controlli aggiuntivi che creano VM di test.
gkectl check-config --config [PATH_TO_CONFIG]
Se il comando restituisce un messaggio FAILURE
, risolvi i problemi e convalida di nuovo il file.
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:
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
creakubeconfig
file denominato[CLUSTER_NAME]-kubeconfig
nella directory attuale dove [CLUSTER_NAME] è il nome che hai impostato percluster
. 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]
Verifica che il cluster sia creato e in esecuzione:
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.
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:
- Rimuovi la specifica
admincluster
dal file di configurazione. 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...
Quando compili le specifiche di
gkeconnect
, il cluster utente viene registrato automaticamente con Google Cloud Console. Puoi visualizzare un cluster GKE On-Prem registrato nel menu Cluster Kubernetes di Google Cloud Console. Da qui, puoi accedere al cluster per visualizzarne i carichi di lavoro.Se non vedi il cluster in Google Cloud Console entro un'ora dalla creazione, consulta la risoluzione dei problemi di connessione.
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:
- Crea un Secret che contenga il certificato e la chiave.
- 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 di GKE On-Prem
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 ulteriori informazioni, consulta la sezione Risoluzione dei problemi.
Diagnostica dei problemi del cluster utilizzando gkectl
Utilizza i comandi gkectl diagnose
per identificare i problemi del cluster e condividere le informazioni sul cluster con Google. Consulta la sezione Diagnosi dei problemi del cluster.
Comportamento di logging predefinito
Per gkectl
e gkeadm
è sufficiente utilizzare le impostazioni di logging predefinite:
-
Per impostazione predefinita, le voci di log vengono salvate come segue:
-
Per
gkectl
, il file di log predefinito è/home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log
e il file è collegato automaticamente al filelogs/gkectl-$(date).log
nella directory locale in cui eseguigkectl
. -
Per
gkeadm
, il file di log predefinito èlogs/gkeadm-$(date).log
nella directory locale in cui eseguigkeadm
.
-
Per
- Tutte le voci di log vengono salvate nel file di log, anche se non vengono stampate nel terminale (quando
--alsologtostderr
èfalse
). - Il livello di dettaglio
-v5
(predefinito) copre tutte le voci di log necessarie al team di assistenza. - Il file di log contiene anche il comando eseguito e il messaggio di errore.
Ti consigliamo di inviare il file del log al team di assistenza quando hai bisogno di aiuto.
Specificare una posizione non predefinita per il file di log
Per specificare una posizione non predefinita per il file di log gkectl
, utilizza il flag --log_file
. Il file di log specificato non verrà collegato alla directory locale.
Per specificare una posizione non predefinita per il file di log gkeadm
, utilizza il flag --log_file
.
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:
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
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
- Scopri come creare cluster utente aggiuntivi.
- Visualizza i tuoi cluster in Google Cloud Console.
- Accedi ai tuoi cluster.