Questa pagina mostra come creare un cluster di amministrazione per i cluster Anthos su VMware (GKE on-prem).
Le istruzioni riportate qui sono complete. Per un'introduzione più breve alla creazione di un cluster di amministrazione, consulta la sezione Creare un cluster di amministrazione (guida rapida).
Prima di iniziare
Crea una workstation di amministrazione.
Ottenere una connessione SSH alla workstation di amministrazione
Crea una connessione SSH alla workstation di amministrazione.
Ricordiamo che gkeadm
ha attivato il tuo
account di servizio di accesso ai componenti sulla workstation di amministrazione.
Esegui tutti i passaggi rimanenti di questo argomento sulla tua workstation di amministrazione nella directory home.
File di configurazione delle credenziali
Quando hai utilizzato gkeadm
per creare la workstation di amministrazione, hai compilato un file di configurazione delle credenziali denominato credential.yaml
. Questo file contiene il nome utente e la password del tuo server vCenter.
File di configurazione del cluster di amministrazione
Quando gkeadm
ha creato la tua workstation di amministrazione, ha generato un file di configurazione denominato admin-cluster.yaml
. Questo file di configurazione consente di creare il cluster di amministrazione.
Compilazione del file di configurazione
bundlePath
Questo campo è già compilato.
vCenter
La maggior parte dei campi in questo campo contiene già i valori inseriti al momento della creazione della workstation di amministrazione. L'eccezione è il
campo dataDisk
,
che devi compilare ora.
network
Decidi come vuoi che i nodi del cluster ricevano i rispettivi indirizzi IP. Le opzioni sono:
Da un server DHCP. Imposta
network.ipMode.type
su"dhcp"
.Da un elenco di indirizzi IP statici da te forniti. Imposta
network.ipMode.type
su"static"
e crea un file di blocco IP che fornisce gli indirizzi IP statici.
Fornisci i valori per i campi rimanenti nella sezione
network
.
Indipendentemente dal fatto che ti affidi a un server DHCP o specifichi un elenco di indirizzi IP statici, sono necessari indirizzi IP sufficienti per soddisfare le seguenti esigenze:
Tre nodi nel cluster di amministrazione per eseguire il piano di controllo e i componenti aggiuntivi del cluster di amministrazione.
Un nodo aggiuntivo nel cluster di amministrazione da utilizzare temporaneamente durante gli upgrade.
Per ogni cluster utente che intendi creare, uno o tre nodi nel cluster di amministrazione per eseguire i componenti del piano di controllo per il cluster utente. Se vuoi che il piano di controllo per un cluster utente sia ad alta disponibilità, devi avere tre nodi nel cluster di amministrazione per il piano di controllo del cluster utente. In caso contrario, sarà necessario un solo nodo nel cluster di amministrazione per il piano di controllo del cluster utente.
Ad esempio, supponiamo che tu voglia creare due cluster utente: uno con un piano di controllo ad alta disponibilità e uno con un piano di controllo non ad alta disponibilità. Quindi, sono necessari otto indirizzi IP per i seguenti nodi nel cluster di amministrazione:
- Tre nodi per il piano di controllo e i componenti aggiuntivi del cluster di amministrazione
- Un nodo temporaneo
- Tre nodi per il piano di controllo del cluster utente ad alta disponibilità
- Un nodo per il piano di controllo del cluster utente non ad alta disponibilità
Come accennato in precedenza, se vuoi utilizzare indirizzi IP statici, devi fornire un file del blocco IP. Ecco un esempio di file di blocco IP con otto host:
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 - ip: 172.16.20.17 hostname: admin-host8
loadBalancer
Metti da parte un VIP per il server API Kubernetes del cluster di amministrazione. Metti da parte
un altro VIP per il server dei componenti aggiuntivi. Fornisci i tuoi VIP come valori per loadBalancer.vips.controlPlaneVIP
e loadBalancer.vips.addonsVIP
.
Decidi quale tipo di bilanciamento del carico utilizzare. Le opzioni sono:
Visualizza il bilanciamento del carico in bundle. Imposta
loadBalancer.kind
su"Seesaw"
e compila la sezioneloadBalancer.seesaw
.Bilanciamento del carico integrato con F5 BIG-IP. Imposta
loadBalancer.kind
su"F5BigIP"
e compila la sezionef5BigIP
.Bilanciamento del carico manuale. Imposta
loadBalancer.kind
su"ManualLB"
e compila la sezionemanualLB
.
antiAffinityGroups
Imposta antiAffinityGroups.enabled
su true
o false
in base alle tue preferenze.
proxy
Se la rete che contiene i nodi del cluster di amministrazione si trova dietro un server proxy, compila la sezione proxy
.
privateRegistry
Decidi dove vuoi mantenere le immagini container per i cluster Anthos sui componenti VMware. Le opzioni sono:
gcr.io Non compilare la sezione
privateRegistry
.Il tuo registro Docker privato. Compila la sezione
privateRegistry
.
gcrKeyPath
Imposta gcrKeyPath
sul percorso del file della chiave JSON per l'account del servizio di accesso ai componenti.
stackdriver
Compila la sezione
stackdriver
.
cloudAuditLogging
Se vuoi che gli audit log di Kubernetes siano integrati con gli audit log di Cloud, compila la sezione cloudAuditLogging
.
autoRepair
Se vuoi attivare la riparazione automatica dei nodi,
imposta autoRepair.enabled
su true
. In caso contrario, impostala su false
.
adminMaster
Se vuoi configurare manualmente le CPU e la memoria per il nodo del piano di controllo dell'amministratore, compila la sezione adminMaster
.
Convalida del file di configurazione
Dopo aver compilato il file di configurazione del cluster di amministrazione, esegui gkectl check-config
per verificare che il file sia valido:
gkectl check-config --config [CONFIG_PATH]
dove [CONFIG_PATH] è il percorso del file di configurazione del cluster di amministrazione.
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.
Esecuzione del gkectl prepare
Esegui gkectl prepare
per inizializzare il tuo ambiente vSphere:
gkectl prepare --config [CONFIG_PATH]
Il comando gkectl prepare
esegue le seguenti attività preparatorie:
importa le immagini del sistema operativo in vSphere e le contrassegna come modelli VM.
Se utilizzi un registro Docker privato, questo comando esegue il push delle immagini container Docker al tuo registro.
Questo comando convalida le immagini container, quindi attesta le build, verificando quindi che le immagini siano state create e firmate da Google e siano pronte per il deployment.
Creazione di un bilanciatore del carico di Seesaw per il cluster di amministrazione
Se hai scelto di utilizzare il bilanciatore del carico di Seesaw in bundle, esegui il passaggio in questa sezione. Altrimenti, puoi saltare questa sezione.
Crea e configura le VM per il tuo bilanciatore del carico di Seesaw:
gkectl create loadbalancer --config [CONFIG_PATH]
Creazione del cluster di amministrazione
Crea il cluster di amministrazione:
gkectl create admin --config [CONFIG_PATH]
dove [CONFIG_PATH] è il percorso del file di configurazione del cluster di amministrazione.
Il comando gkectl create admin
crea un file kubeconfig denominato
kubeconfig
nella directory corrente. Questo file kubeconfig ti servirà in un secondo momento per interagire con il cluster di amministrazione.
Verifica che il cluster di amministrazione sia in esecuzione
Verifica che il cluster di amministrazione sia in esecuzione:
kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
dove [ADMIN_CLUSTER_KUBECONFIG] è il percorso del tuo file kubeconfig.
L'output mostra i nodi del cluster di amministrazione.
Risolvere i problemi
Diagnostica dei problemi del cluster con gkectl
Utilizza i comandi gkectl diagnose
per 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 filelogs/gkectl-$(date).log
nella directory locale in cui viene eseguitogkectl
. -
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 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:
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
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, Cluster Anthos su VMware 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, i cluster Anthos su VMware creano un cluster di bootstrap temporaneo. Al termine dell'installazione, i cluster Anthos su VMware eliminano il cluster di bootstrap, lasciando 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.
Passaggi successivi
Creazione di un cluster utente