Se non è possibile eseguire il provisioning di un cluster TKGS, esaminare questo elenco di errori comuni per risolvere i problemi.

Controllo dei registri dell'API del cluster

Se non è possibile creare un cluster TKG, verificare che CAPW/V funzioni.

Il controller CAPW/V è l'implementazione specifica dell'infrastruttura dell'API del cluster. CAPW/V viene abilitato tramite Supervisore. CAPW/V è un componente di TKG ed è responsabile della gestione del ciclo di vita dei cluster TKG.

CAPW/V è responsabile della creazione e dell'aggiornamento della VirtualNetwork. Solo se la VirtualNetwork è pronta, è possibile procedere con la creazione dei nodi del cluster. Il workflow di creazione del cluster ha superato questa fase?

CAPW/V è responsabile della creazione e dell'aggiornamento di VirtualMachineService. Creazione del VirtualMachineService completata? È stato ottenuto l'IP esterno? Il workflow di creazione del cluster ha superato questa fase?

Per rispondere a queste domande, controllare il registro dell'API del cluster come indicato di seguito: 
kubectl config use-context tkg-cluster-ns
kubectl get pods -n vmware-system-capw  | grep capv-controller
kubectl logs -n vmware-system-capw -c manager capv-controller-manager-...

Errore di convalida della specifica del cluster

In base alla specifica YAML, è possibile utilizzare il carattere spazio nel nome di una chiave. Si tratta di una stringa scalare contenente uno spazio e non richiede virgolette.

Tuttavia, la convalida di TKGS non consente l'uso del carattere spazio nei nomi delle chiavi. In TKGS, un nome di chiave valido può essere composto solo da caratteri alfanumerici, un trattino (ad esempio key-name), un carattere di sottolineatura (ad esempio KEY_NAME) o un punto (ad esempio key.name).

Se si utilizza il carattere spazio in un nome di chiave nella specifica del cluster, il cluster TKGS non viene distribuito. Nel registro vmware-system-tkg-controller-manager viene visualizzato il messaggio di errore seguente:

Invalid value: \"Key Name\": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name', or 'KEY_NAME', or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')"

Per correggere l'errore, rimuovere completamente il carattere spazio o sostituirlo con un carattere supportato.

Errori durante l'applicazione del codice YAML del cluster TKG

Se si ricevono errori durante l'applicazione del codice YAML del cluster TKG, risolvere i problemi come indicato di seguito.
La rete del cluster non si trova nello stato corretto
Comprendere il workflow di provisioning del cluster TKG:
  • CAPV crea un oggetto ReteVirtuale per ogni rete del cluster TKG.
  • Se Supervisore è configurato con Networking con NSX, NCP controlla gli oggetti VirtualNetwork e crea un router di livello 1 NSX e un segmento NSX per ogni VirtualNetwork.
  • CAPV verifica lo stato della VirtualNetwork e, quando è pronto, procede al passaggio successivo nel workflow.

Il controller del servizio macchina virtuale controlla gli oggetti personalizzati creati da CAPV e utilizza tali specifiche per creare e configurare le macchine virtuali che costituiscono il cluster TKG.

NSX Container Plugin (NCP) è un controller che gestisce le risorse di rete aggiunte a etcd tramite l'API di Kubernetes e orchestra la creazione di oggetti corrispondenti in NSX.

Ciascuno di questi controller viene eseguito come pod Kubernetes nel piano di controllo Supervisore. Per risolvere i problemi di rete, controllare il registro del controller CAPV, il registro del servizio macchina virtuale e il registro NCP.

Controllare i registri del container, dove name-XXXX è il nome univoco del pod quando si esegue 
kubectl get pods -A
kubectl logs pod/name-XXXXX -c pod-name -n namesapce
Numero di nodi del piano di controllo non valido

Il cluster TKG in Supervisore supporta 1 o 3 nodi del piano di controllo. Se si immette un numero diverso di repliche, il provisioning del cluster non riesce.

Classe di storage non valida per il piano di controllo/worker della macchina virtuale
Eseguire il comando seguente: 
kubectl describe ns <tkg-clsuter-namesapce>

Assicurarsi che sia stata assegnata una classe di storage allo spazio dei nomi in cui si sta tentando di creare il cluster TKG. Deve essere presente una QuotaRisorse in Spazio dei nomi vSphere che fa riferimento a tale classe di storage e la classe di storage deve esistere in Supervisore.

Assicurarsi che il nome corrisponda alla classe di storage presente in Supervisore. Eseguire kubectl get storageclasses Supervisore come amministratore vSphere. WCP può trasformare il nome quando si applica il profilo di storage a Supervisore (ad esempio, i trattini diventano caratteri di sottolineatura).

Classe macchina virtuale non valida

Assicurarsi che il valore fornito nel cluster YAML corrisponda a una delle classi di macchine virtuali restituite da kubectl get virtualmachineclass. Solo le classi associate possono essere utilizzate da un cluster TKG. Una classe di macchine virtuali viene associata quando viene aggiunta a Spazio dei nomi vSphere.

Il comando kubectl get virtualmachineclasses restituisce tutte le classi di macchine virtuali in Supervisore, ma solo quelle associate possono essere utilizzate.

Impossibile trovare le distribuzioni TKR
Se viene visualizzato un errore simile al seguente: 
“Error from server (unable to find Kubernetes distributions): 
admission webhook “version.mutating.tanzukubernetescluster.run.tanzu.vmware.com” 
denied the request: unable to find Kubernetes distributions”

Ciò è probabilmente dovuto a un problema della libreria di contenuti. Per elencare i dati disponibili, utilizzare il comando kubectl get virtualmachineimages -A. Il risultato è ciò che è disponibile e sincronizzato o caricato nella libreria di contenuti.

Per TKG su Supervisore sono presenti nuovi nomi TKR compatibili con la nuova API TKR. È necessario accertarsi di denominare correttamente ogni TKR nella libreria di contenuti.

Nome nella libreria di contenuti: photon-3-amd64-vmi-k8s-v1.23.8---vmware.2-tkg.1-zshippable

Nome corrispondente nella specifica del cluster TKG: version: v1.23.8+vmware.2-tkg.1-zshippable

Viene applicato il codice YAML TKG ma non vengono create macchine virtuali

Se il codice YAML del cluster TKG 2.0 è valido e applicato ma le macchine virtuali del nodo non sono state create, risolvere i problemi come indicato di seguito.
Controllare le risorse CAPI/CAPV

Controllare se TKG ha creato le risorse a livello di CAPI/CAPV.

  • Controllare se CAPV ha creato le risorse VirtualMachine.
  • Controllare i registri dell'operatore della macchina virtuale per verificare il motivo per cui la macchina virtuale non è stata creata. Ad esempio, è possibile che la distribuzione di OVF non sia riuscita a causa di risorse insufficienti nell'host ESX.
  • Controllare i registri CAPV e dell'operatore macchina virtuale.
  • Controllare i registri NCP. NCP è responsabile della creazione di VirtualNetwork, VirtualNetworkInterface e LoadBalancer per il piano di controllo. Se si tratta di un errore relativo a tali risorse, può essere un problema.
Errore di servizi della macchina virtuale
Errore di servizi della macchina virtuale
  • Eseguire kubectl get virtualmachineservices nello spazio dei nomi
  • È stato creato un servizio Macchina Virtuale?
  • Eseguire kubectl describe virtualmachineservices nello spazio dei nomi
  • Sono presenti errori segnalati nel servizio Macchina Virtuale?
Errore di rete virtuale

Eseguire kubectl get virtualnetwork nello spazio dei nomi.

È stata creata la Rete Virtuale per questo cluster?

Eseguire kubectl describe virtual network nello spazio dei nomi.

L'interfaccia della Rete Virtuale è stata creata per la macchina virtuale?

Il piano di controllo del cluster TKG non è in esecuzione

Se il piano di controllo TKG non è in esecuzione, verificare che le risorse fossero pronte quando si è verificato l'errore. Si tratta di un piano di controllo Nodo join non attivo o di un Nodo Init? Verificare inoltre che l'ID provider non sia impostato nell'oggetto del nodo.
Verificare che le risorse fossero pronte quando si è verificato l'errore

Oltre che cercare i registri, controllare lo stato degli oggetti correlati ControlPlaneLoadBalancer ti aiuterà a capire se le risorse erano pronte quando si è verificato l'errore. Vedere risoluzione dei problemi di rete.

Si tratta di un piano di controllo Nodo join non attivo o di un Nodo Init?

I nodi join a volte non funzionano correttamente. Esaminare i registri del nodo per la macchina virtuale specifica. È possibile che nel cluster manchino i nodi di lavoro e del piano di controllo se il nodo init non viene visualizzato correttamente.

L'ID del provider non è impostato nell'oggetto nodo

Se viene creata una macchina virtuale, verificare se include IP, esaminare i registri di cloud-init (i comandi kubeadm vengono eseguiti correttamente)

Controllare i registri del controller CAPI per verificare se si è verificato un problema. È possibile procedere al controllo utilizzando kubectl get nodes nel cluster TKG e quindi verificare che l'ID provider sia presente nell'oggetto nodo.

I nodi di lavoro TKG non vengono creati

Se vengono create macchine virtuali del cluster TKG e del piano di controllo, ma non vengono creati worker o nessun altro oggetto di macchina virtuale, provare a eseguire le operazioni seguenti: 
kubectl describe cluster CLUSTER-NAME

Controllare le risorse delle macchine virtuali nello spazio dei nomi. Ne sono state create altre?

In caso contrario, controllare i registri CAPV per capire perché gli altri dati di bootstrap degli oggetti macchina virtuale non sono disponibili.

Se CAPI non è in grado di comunicare con il piano di controllo del cluster TKG tramite il bilanciamento del carico, NSX con IP della macchina virtuale del nodo o VDS con bilanciamento del carico esterno, recuperare il kubeconfig del cluster TKG utilizzando il segreto nello spazio dei nomi:

Recuperare il kubeconfig del cluster TKG utilizzando il segreto nello spazio dei nomi: 
kubectl get secret -n <namespace> <tkg-cluster-name>-kubeconfig -o jsonpath='{.data.value}' | base64 -d 
> tkg-cluster-kubeconfig; kubectl --kubeconfig tkg-cluster-kubeconfig get pods -A

Se l'operazione non riesce e viene rifiutata la connessione, è possibile che il piano di controllo non venga inizializzato correttamente. Se si verifica un timeout di I/O, verificare la connettività all'indirizzo IP in kubeconfig.

NSX con bilanciamento del carico incorporato:

  • Verificare che il bilanciamento del carico del piano di controllo sia attivo e raggiungibile.
  • Se LB non dispone di IP, controllare i registri NCP e controllare l'interfaccia utente NSX-T per verificare se gli stati dei componenti correlati sono corretti. (NSX-T LB, VirtualServer, ServerPool devono essere tutti nello stato integro).
  • Se LB include un IP ma non è raggiungibile (curl -k https://<LB- VIP>:6443/healthz dovrebbe restituire un errore non autorizzato).

    Lo stato del tipo LoadBalancer dell'IP esterno del servizio è stato "sospeso", verificare che il cluster TKG possa comunicare con l'API del supervisore Kubernetes tramite il VIP LB del supervisore. Assicurarsi che non vi siano indirizzi IP sovrapposti.

Controllare se i nodi del piano di controllo TKG sono integri:
  • Controllare se il piano di controllo del cluster TKG segnala eventuali errori (ad esempio, non è possibile creare un nodo con ID provider).
  • Il provider di cloud del cluster TKG non contrassegna il nodo con l'ID provider corretto; pertanto, CAPI non può confrontare l'ID provider nel nodo del cluster guest e la risorsa macchina nel cluster supervisore per verificarlo.
Accedere tramite SSH alla macchina virtuale del piano di controllo o utilizzare il kubeconfig del cluster TKG per verificare che il Cloud Provider Pod di TKG sia in esecuzione/registrato. Vedere Connessione ai cluster Servizio TKG come amministratore di Kubernetes e utente di sistema. 
kubectl get po -n vmware-system-cloud-provider
kubectl logs -n vmware-system-cloud-provider <pod name>

Se il VMOP non ha riconciliato correttamente VirtualMachineService, controllare il registro di Operatore macchina virtuale.

Se in NCP si sono verificati problemi durante la creazione delle risorse di NSX-T, controllare il registro NCP.

Se il piano di controllo non viene inizializzato correttamente, determinare l'IP della macchina virtuale. Lo stato deve contenere l'IP della macchina virtuale. 
kubectl get virtualmachine -n <namespace> <TKC-name>-control-plane-0 -o yaml
ssh vmware-system-user@<vm-ip> -i tkc-cluster-ssh
Verificare se kubeadm ha registrato eventuali errori. 
cat /var/log/cloud-init-output.log | less

Cluster TKG con provisioning bloccato nella fase "Creazione"

Eseguire i comandi seguenti per controllare lo stato del cluster.

kubectl get tkc -n <namespace>
kubectl get cluster -n <namespace> 
kubectl get machines -n <namespace>
KubeadmConfig era presente, ma CAPI non è stato in grado di trovarlo. Controllare se il token in vmware-system-capv disponeva delle autorizzazioni appropriate per eseguire una query in kubeadmconfig. 
$kubectl --token=__TOKEN__ auth can-i get kubeadmconfig 
yes
È possibile che la cache controller-runtime non sia stata aggiornata. È possibile che le cache di controllo di CAPI siano obsolete e non prelevano i nuovi oggetti. Se necessario, riavviare il capi-controller-manager per risolvere il problema. 
kubectl rollout restart deployment capi-controller-manager -n vmware-system-capv

Spazio dei nomi vSphere bloccate nella fase "Cessazione"

Verificare che TKR, Supervisore e vCenter siano sincronizzati dal punto di vista della compatibilità della versione.

Gli spazi dei nomi possono essere eliminati solo quando tutte le risorse sotto gli spazi dei nomi vengono eliminate. 
kubectl describe namespace NAME

È stato rilevato il seguente errore: "Errore dal server (impossibile trovare le distribuzioni Kubernetes): il webhook di accettazione "version.mutating.tanzukubernetescluster.run.tanzu.vmware.com” ha negato la richiesta: impossibile trovare le distribuzioni Kubernetes"

Controllare le immagini delle macchine virtuali in vCenter. 
kubectl get virtualmachineimages -A