Risoluzione dei problemi relativi al cluster del carico di lavoro

Questa sezione include suggerimenti che consentono di risolvere i problemi dei cluster del carico di lavoro.

Per informazioni sulla risoluzione dei problemi relativi alle distribuzioni dei cluster di gestione autonomi, vedere Risoluzione dei problemi dei cluster di gestione. Ulteriori soluzioni per i problemi noti di questa versione sono disponibili nelle Note di rilascio o negli articoli della Knowledge Base di VMware.

Attività comuni

Eliminazione di utenti, contesti e cluster con kubectl

Per pulire lo stato di kubectl eliminando alcuni o tutti i relativi utenti, contesti e cluster:

1. Aprire il file ~/.kube/config.

2. Per gli oggetti user che si desidera eliminare, eseguire:

   kubectl config unset users.USER-NAME
   

   In cui USER-NAME è la proprietà name di ciascun oggetto user di livello superiore, come indicato nei file config.

3. Per gli oggetti context che si desidera eliminare, eseguire:

   kubectl config unset contexts.CONTEXT-NAME
   

   In cui CONTEXT-NAME è la proprietà name di ciascun oggetto context di livello superiore, come indicato nei file config, in genere nel formato contexts.mycontext-admin@mycontext.

4. Per gli oggetti cluster che si desidera eliminare, eseguire:

   kubectl config unset clusters.CLUSTER-NAME
   

   In cui CLUSTER-NAME è la proprietà name di ciascun oggetto cluster di livello superiore, come indicato nei file config.

5. Se nei file config il contesto corrente è indicato come cluster eliminato, annullare l'impostazione del contesto:

   kubectl config unset current-context
   

Pacchetti

Segreto non creato durante l'installazione di Grafana dal file YAML predefinito

Problema

Se si tenta di installare Grafana generando un file di configurazione di Grafana predefinito, l'installazione non riesce e viene visualizzato il messaggio di errore error: Secret in version "v1" cannot be handled as a Secret: illegal base64 data at input byte 4 (reason: BadRequest).

Soluzione

Creare il segreto manualmente e utilizzare lo stesso file YAML senza il tag del segreto per installare Grafana.

1. Eseguire i passaggi di Distribuzione di Grafana nel cluster del carico di lavoro per creare il file di configurazione per la configurazione di Grafana.
2. Rimuovere le voci grafana.secret.* dal file di configurazione generato.

3. Creare un segreto manualmente.

   kubectl create secret generic grafana -n tanzu-system-dashboards  --from-literal=admin=admin
   

4. Distribuire il pacchetto.

   tanzu package install grafana \
   --package grafana.tanzu.vmware.com \
   --version AVAILABLE-PACKAGE-VERSION \
   --values-file grafana-data-values.yaml \
   --namespace TARGET-NAMESPACE
   

5. Eseguire i passaggi rimanenti di Distribuzione di Grafana nel cluster del carico di lavoro.

Errore durante l'esecuzione di tanzu package repository

Problema

Il comando tanzu package repository non riesce e si verifica un errore.

Soluzione

Eseguire kubectl get pkgr REPOSITORY-NAME -n NAMESPACE -o yaml​ per visualizzare i dettagli dell'errore.

In cui:

• REPOSITORY-NAME è il nome del repository dei pacchetti.
• NAMESPACE è lo spazio dei nomi di destinazione del repository del pacchetto.

È possibile che il comando tanzu package repository non riesca con un errore simile al seguente:

Errore	Descrizione	Soluzione
NOT_FOUND	Il percorso dell'URL del repository non è valido.	Assicurarsi che l'URL del repository dei pacchetti sia raggiungibile dal cluster.
UNKNOWN o UNAUTHORIZED	Questo errore può verificarsi quando si tenta di connettersi al repository.
Ownership	Un repository con lo stesso URL del repository dei pacchetti è già installato nel cluster.	Eseguire una delle operazioni seguenti: Eseguire tanzu package available list -n NAMESPACE per verificare se il pacchetto che si desidera installare è già disponibile per l'installazione. Per ripristinare il tentativo di aggiunta del repository non riuscito, eseguire tanzu package repository delete REPOSITORY-NAME -n NAMESPACE. Eseguire tanzu package repository list -A per recuperare un repository dei pacchetti esistente con lo stesso URL. Se si recupera il repository dei pacchetti, è possibile procedere con l'eliminazione a proprio rischio.

Errore durante l'esecuzione di tanzu package installed

Problema

Il comando tanzu package installed non riesce e si verifica un errore.

Soluzione

Eseguire kubectl get pkgi INSTALLED-PACKAGE-NAME -n NAMESPACE -o yaml​ per visualizzare i dettagli dell'errore.

In cui:

• INSTALLED-PACKAGE-NAME è il nome del pacchetto installato.
• NAMESPACE è lo spazio dei nomi del pacchetto installato.

È possibile che il comando tanzu package installed non riesca con un errore simile al seguente:

Errore	Descrizione	Soluzione
Ownership	Un pacchetto con lo stesso nome è già installato nel cluster.	Eseguire tanzu package installed list -A per verificare se il pacchetto che si desidera installare è già installato. In tal caso, è consigliabile utilizzare il pacchetto già installato, aggiornarne la versione o eliminare il pacchetto per poter procedere con l'installazione.
Evaluating starlark template	Questo errore può verificarsi quando il valore di configurazione indicato non è presente.	Eseguire tanzu package available get AVAILABLE-PACKAGE-NAME/VERSION -n NAMESPACE –values-schema per visualizzare tutti i valori di configurazione disponibili e specificare i valori di configurazione richiesti per il comando tanzu package install.
Failed to find a package with name PACKAGE-NAME in namespace NAMESPACE	Il pacchetto specificato e i metadati del pacchetto non sono disponibili nello spazio dei nomi di destinazione.	Assicurarsi che il pacchetto specificato sia presente nell'output di tanzu package available list AVAILABLE-PACKAGE-NAME -n NAMESPACE​. Se non lo è, aggiungere il repository dei pacchetti che contiene il pacchetto nello spazio dei nomi di destinazione.
Namespace NAMESPACE not found	Lo spazio dei nomi in cui si desidera installare il pacchetto non esiste.	In TKG v2.1 o versioni successive i comandi tanzu package si basano su kctrl e non supportano più il flag —create-namespace. Prima di installare un pacchetto o un repository del pacchetto, lo spazio dei nomi di destinazione deve già esistere.
Provided service account SERVICE-ACCOUNT-NAME is already used by another package in namespace NAMESPACE​	L'account del servizio specificato con il flag service-account-name è già utilizzato da un altro pacchetto installato.	Consentire al plug-in del pacchetto di creare l'account del servizio o scegliere il nome di un altro account di servizio.

Pod

I pod sono bloccati in sospeso nel cluster a causa della connettività di vCenter

Problema

Quando si esegue kubectl get pods -A nel cluster creato, alcuni pod restano nello stato in sospeso.

Eseguire kubectl describe pod -n pod-namespace pod-name in un pod interessato. Viene visualizzato l'evento seguente:

n node(s) had taint {node.cloudprovider.kubernetes.io/uninitialized: true}, that the pod didn't tolerate

Soluzione

Verificare che siano presenti regole di connettività e firewall per garantire la comunicazione tra il cluster e vCenter. Per i requisiti delle porte e dei protocolli del firewall, vedere gli elenchi di vSphere 8 in VMware Ports and Protocols.

Storage

La modifica dell'oggetto StorageClass predefinito causa un errore di riconciliazione nei cluster del carico di lavoro

Problema

La modifica delle proprietà di un oggetto StorageClass predefinito incluso in TKG causa un errore di riconciliazione dei pacchetti nei cluster del carico di lavoro che utilizzano la classe di storage.

Soluzione:

per personalizzare una classe di storage, creare una nuova definizione di StorageClass con un name diverso anziché modificare la definizione dell'oggetto predefinita e riconfigurare il cluster in modo che utilizzi la nuova classe di storage.

Cluster del carico di lavoro

Si verifica il timeout della distribuzione di un cluster, ma il cluster viene creato

Problema

L'esecuzione di tanzu cluster create non riesce e si verifica un errore di timeout simile al seguente:

I0317 11:11:16.658433 clusterclient.go:341] Waiting for resource my-cluster of type *v1beta1.Cluster to be up and running
E0317 11:26:16.932833 common.go:29]
Error: unable to wait for cluster and get the cluster kubeconfig: error waiting for cluster to be created (this may take a few minutes): cluster control plane is still being initialized
E0317 11:26:16.933251 common.go:33]

Soluzione

Utilizzare il flag --timeout per specificare il tempo di attesa del completamento della creazione del cluster. Il tempo di attesa predefinito è 30 minuti.

tanzu cluster create --timeout TIME

In cui TIME è l'intervallo di tempo, in minuti, di attesa del completamento della creazione del cluster. Ad esempio, 60m.

Il cluster del carico di lavoro è bloccato durante l'eliminazione

Problema

tanzu cluster delete non riesce a eliminare il cluster del carico di lavoro.

Per eliminare il cluster manualmente, vedere le due soluzioni seguenti.

Soluzione 1

1. Nel cluster di destinazione, eliminare l'oggetto StatefulSet per AKO, che viene eseguito nello spazio dei nomi avi-system:

   kubectl delete sts ako -n avi-system
   

Soluzione 2

1. Accedere al cluster ed eliminare le macchine worker:

   kubectl delete machine worker1 worker2
   

2. Da vCenter, spegnere ed eliminare le macchine virtuali del nodo worker.

3. Modificare le macchine del piano di controllo e rimuovere il collegamento del finalizzatore:

   finalizers:
    - machine.cluster.x-k8s.io
   

4. Eliminare le macchine del piano di controllo:

   kubectl delete machine controlplane1 controlplane2
   

5. Da vCenter, spegnere ed eliminare le macchine virtuali del piano di controllo

Nodi worker del cluster in stato NotReady a causa di MTU non corrispondenti

Problema

Impostazioni MTU (unità massima di trasmissione) diverse nei nodi worker in un cluster determinano il timeout dell'handshake TLS.

I registri di journalctl -u kubelet in un nodo mostrano un errore di comunicazione con il server API. L'esecuzione di nodi kubectl get nodes indica che i nodi worker sono stati spostati nello stato NotReady.

È possibile riconfermare il problema eseguendo le operazioni seguenti:

1. Nel nodo del piano di controllo e nelle macchine del nodo worker, eseguire ip link e confrontare i valori MTU dell'interfaccia eth0. Se non corrispondono, è presente questo problema.
2. Eseguire la diagnostica arresti anomali (Crashd) e rivedere i registri kubelet per determinare che si è verificato il timeout delle connessioni o che i nodi worker si trovano nello stato NotReady. Per ulteriori informazioni sull'esecuzione di Crashd, vedere Risoluzione dei problemi dei cluster del carico di lavoro con la diagnostica arresti anomali

3. Verificare che i seguenti comandi non vengano eseguiti correttamente quando vengono eseguiti su una macchina che si trova nello stato di nodo NotReady:

   • openssl s_client -connect IP:PORT

   • curl IP:PORT -k /healthz

   Dove IP e PORT sono indirizzo IP e numero di porta dell'endpoint del piano di controllo del server dell'API Kubernetes. Per impostazione predefinita, PORT è impostata su 6443.

Soluzione

1. Esaminare i daemonset privilegiati distribuiti nel cluster e tutti i daemonset di fornitori di terze parti che potrebbero modificare le configurazioni di rete del sistema operativo host. Potrebbe essere necessario consultare il fornitore del software per scoprirlo. I daemonset che possono modificare il sistema operativo host avranno .spec.template.spec.hostNetwork: true oppure avranno privileged: true o NET_ADMIN nel campo di funzionalità di qualsiasi contesto di sicurezza del container.

2. Se si desidera configurare impostazioni MTU di grandi dimensioni, eseguire il provisioning del cluster con il piano di controllo con un valore MTU più elevato.

3. Assicurarsi che la rete del cluster consenta il rilevamento dell'MTU del percorso o abbia il clamping TCP MSS attivo per consentire il corretto dimensionamento dell'MTU per i servizi esterni, ad esempio vCenter o i registri dei container.

4. Assicurarsi di configurare le stesse impostazioni MTU per tutti i nodi di un cluster.

5. Le impostazioni del firewall di rete devono consentire l'uso di pacchetti delle dimensioni di MTU configurate.

Con NSX ALB, non è possibile creare cluster con nomi identici

Problema

Se si utilizza NSX Advanced Load Balancer per i carichi di lavoro (AVI_ENABLE) o il piano di controllo (AVI_CONTROL_PLANE_HA_PROVIDER), è possibile che il controller Avi non riesca a distinguere i cluster con nome identico.

Soluzione:

impostare un valore CLUSTER_NAME univoco per ogni cluster. non creare più cluster del carico di lavoro che hanno lo stesso CLUSTER_NAME e si trovano anche nello stesso spazio dei nomi del cluster di gestione, come specificato dal valore NAMESPACE.

L'eliminazione del volume vSphere CSI può non riuscire in AVS

Problema

In Azure vSphere Solution (AVS), è possibile che l'eliminazione dei volumi persistenti di vSphere CSI non riesca. L'eliminazione di un volume persistente richiede l'autorizzazione cns.searchable. L'account amministratore predefinito per AVS, <[email protected]>, non viene creato con questa autorizzazione. Per ulteriori informazioni, vedere Ruoli e privilegi di vSphere.

Soluzione

per eliminare un volume persistente di vSphere CSI in AVS, contattare l'assistenza di Azure.

L'eliminazione del cluster in AWS non riesce se il cluster utilizza risorse di rete non distribuite con Tanzu Kubernetes Grid

Problema

I comandi tanzu cluster delete e tanzu management-cluster delete possono bloccarsi nei cluster che utilizzano risorse di rete create da AWS Cloud Controller Manager indipendentemente dal processo di distribuzione di Tanzu Kubernetes Grid. Tali risorse possono includere bilanciamenti del carico e altri servizi di rete, come indicato in Controller del servizio nella documentazione del provider di cloud AWS Kubernetes.

Per ulteriori informazioni, vedere il problema di Cluster API Drain workload clusters of service Type=Loadbalancer on teardown.

Soluzione

utilizzare kubectl delete per eliminare i servizi di tipo LoadBalancer dal cluster. Se questa soluzione non funziona, utilizzare la console AWS per eliminare manualmente LoadBalancer e SecurityGroup creati per questo servizio da Cloud Controller Manager.

Attenzione

Non eliminare i bilanciamenti del carico o i gruppi di sicurezza gestiti da Tanzu in cui sono presenti i tag key: sigs.k8s.io/cluster-api-proider-aws/cluster/CLUSTER-NAME,value: owned.

L'eliminazione del cluster non riesce quando il volume di storage utilizza un account con endpoint privato

Problema

Con un cluster del carico di lavoro di Azure in un gruppo di risorse non gestito, quando il driver CSI di Azure crea un volume persistente che utilizza un account di storage con un endpoint privato, crea risorse privateEndpoint e vNet che non vengono eliminate quando il volume persistente viene eliminato. Di conseguenza, l'eliminazione del cluster non riesce e viene visualizzato un messaggio di errore simile a subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use.

Soluzione:

prima di eliminare il cluster di Azure, eliminare manualmente l'interfaccia di rete per l'endpoint privato dell'account di storage:

1. Da un browser accedere ad Azure Resource Explorer.
2. Fare clic su subscriptions a sinistra ed espandere la propria sottoscrizione.
3. Nella sottoscrizione, espandere resourceGroups a sinistra ed espandere il gruppo di risorse della distribuzione TKG.
4. Nel gruppo di risorse, espandere providers > Microsoft.Network > networkinterfaces.
5. In networkinterfaces, selezionare la risorsa NIC che non viene eliminata correttamente.
6. Fare clic sul pulsante Read/Write in alto, quindi sulla scheda Actions (POST, DELETE) subito sotto.
7. Fare clic su Elimina.
8. Dopo aver eliminato la scheda NIC, eliminare il cluster di Azure.