Creazione di un cluster utente

Questa pagina mostra come creare un cluster utente.

Generazione di un file di configurazione

Per creare un cluster utente, devi avere un file di configurazione del cluster utente. Se hai utilizzato gkeadm per creare la tua workstation di amministrazione, gkeadm ha generato un modello per il tuo file di configurazione e completato alcuni dei campi.

Se non hai utilizzato gkeadm per creare la workstation di amministrazione, puoi generare un modello eseguendo questo comando:

gkectl create-config cluster --config [OUTPUT_PATH]

dove [OUTPUT_PATH] è un percorso a tua scelta per il modello generato. Se non includi il flag --config, gkectl assegna al file il nome user-cluster.yaml e lo inserisce nella directory corrente.

Compilazione del file di configurazione

name

Imposta il campo name su un nome a tua scelta per il cluster utente.

gkeOnPremVersion

Imposta il campo gkeOnPremVersion.

vCenter

I valori impostati nella sezione vCenter del file di configurazione del cluster di amministrazione sono globali. In altri termini, vengono applicati al cluster di amministrazione e ai cluster utente.

Per ogni cluster utente creato, hai la possibilità di eseguire l'override di alcuni valori vCenter globali.

Se vuoi eseguire l'override di uno qualsiasi dei valori vCenter globali, compila i campi pertinenti nella sezione vCenter del file di configurazione del cluster utente.

network

Imposta network.ipMode.type sullo stesso valore che hai impostato nel file di configurazione del cluster di amministrazione: "dhcp" o "static".

Se imposti ipMode.type su "static", crea un file di configurazione host che fornisca gli indirizzi IP statici per i nodi nel cluster utente. Quindi imposta network.ipBlockFilePath sul percorso del file di configurazione dell'host.

Fornisci i valori per i campi rimanenti nella sezione network.

loadBalancer

Metti da parte un VIP per il server API di Kubernetes del tuo cluster utente. Metti da parte un altro VIP per il servizio in entrata del tuo cluster utente. Fornisci i tuoi VIP come valori per loadBalancer.controlPlaneVIP e loadBalancer.ingressVIP.

Imposta loadBalancer.kind sullo stesso valore che hai impostato nel file di configurazione del cluster di amministrazione: "ManualLB", "F5BigIP" o "Seesaw". Dopodiché compila la sezione corrispondente: manualLB, f5BigIP o seesaw.

proxy

Se la rete che contiene i nodi del cluster utente è protetta da un server proxy, compila la sezione proxy.

masterNode

Compila la sezione masterNode.

nodePools

Compila la sezione nodePools.

authentication

Se vuoi utilizzare OpenID Connect (OIDC) per autenticare gli utenti, compila la sezione authentication.oidc.

Se vuoi fornire un certificato di pubblicazione aggiuntivo per il server vCenter del tuo cluster utente, compila la sezione authentication.sni.

stackdriver

Compila la sezione stackdriver.

gkeConnect

Compila la sezione gkeConnect.

cloudRun

Imposta cloudRun.enabled su true o false.

Convalida del file di configurazione

Dopo aver compilato il file di configurazione del cluster utente, esegui gkectl check-config per verificare che il file sia valido:

gkectl check-config --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [CONFIG_PATH]

dove:

  • [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig per il cluster di amministrazione.

  • [CONFIG_PATH] è il percorso del file di configurazione del tuo cluster utente.

Se il comando restituisce messaggi di errore, correggi i problemi e convalida di nuovo il file.

Se vuoi ignorare le convalide più lunghe, supera il flag --fast. Per ignorare le singole convalide, utilizza i flag --skip-validation-xxx. Per ulteriori informazioni sul comando check-config, consulta Esecuzione di controlli preflight.

Creazione del cluster utente

Crea il cluster utente:

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

dove

  • [CONFIG_PATH] è il percorso del file di configurazione del tuo cluster utente.

  • [ADMIN_CLUSTER_KUBECONFIG] è il percorso del file kubeconfig per il cluster di amministrazione.

Il comando gkectl create cluster crea un file kubeconfig denominato [USER_CLUSTER_NAME]-kubeconfig nella directory corrente. Questo file kubeconfig ti servirà in un secondo momento per interagire con il cluster utente.

Non utilizzare il flag --skip-validation-all se non hai convalidato il file di configurazione in precedenza.

Verifica che il cluster utente sia in esecuzione

Verifica che il cluster utente sia in esecuzione:

kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]

dove [USER_CLUSTER_KUBECONFIG] è il percorso del tuo file kubeconfig.

L'output mostra i nodi del cluster utente.

Risolvere i problemi

Diagnostica dei problemi del cluster con gkectl

Utilizza i comandi gkectl diagnoseper identificare i problemi del cluster e condividerli con Google. Consulta 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 direttamente al file logs/gkectl-$(date).log nella directory locale in cui viene eseguito gkectl.
    • Per gkeadm, il file di log predefinito è logs/gkeadm-$(date).log nella directory locale in cui esegui gkeadm.
  • Tutte le voci di log vengono salvate nel file di log, anche se non sono 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.

Se hai bisogno di aiuto, ti consigliamo di inviare il file di log al team di assistenza.

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 direttamente alla directory locale.

Per specificare una posizione non predefinita per il file di log gkeadm, utilizza il flag --log_file.

Localizzazione dei log dell'API Cluster nel cluster di amministrazione

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

  1. Trova il nome del pod dei controller API del 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. Se preferisci, utilizza grep o uno strumento simile per cercare errori:

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

Debug dei problemi BIG-IP di F5 utilizzando il kubeconfig del nodo 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. Il file kubeconfig è identico al kubeconfig del cluster di amministrazione, con la differenza 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é le partizioni BIG-IP di F5 non possono essere trovate, anche se esistono.

Potenziali cause

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

Risoluzione

Riprova a eseguire gkectl check-config.

gkectl prepare --validate-attestations non riuscito: impossibile convalidare l'attestazione di 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 e a eseguire nuovamente il deployment dell'OVA della workstation di amministrazione, come indicato nella sezione 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. Dopo un'installazione riuscita, GKE On-Prem elimina il cluster di bootstrap, lasciandoti il cluster di amministrazione e il cluster utente. In genere, non dovresti avere motivo di interagire con questo cluster.

Se si verifica un problema durante l'installazione e hai passato --cleanup-external-cluster=false a gkectl create cluster, potrebbe essere utile eseguire il debug utilizzando i log del cluster di bootstrap. Puoi trovare il pod e quindi 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]

Per ulteriori informazioni, consulta la sezione Risoluzione dei problemi.