Risoluzione dei problemi relativi al cluster di gestione

Questo argomento include suggerimenti che consentono di risolvere i problemi relativi alle distribuzioni del cluster di gestione autonomo.

Per informazioni sulla risoluzione dei problemi dei cluster del carico di lavoro, vedere Risoluzione dei problemi dei cluster del carico di lavoro. Ulteriori soluzioni per i problemi noti di questa versione sono disponibili nelle Note di rilascio o negli articoli della Knowledge Base di VMware.

Prerequisito

Alcune delle procedure seguenti utilizzano la CLI kind. Per installare kind, vedere Installazione nella documentazione di kind.

087bf3b4 (aggiornamenti RN per Ghost (#1178))

Attività comuni

Connessione ai nodi del cluster con SSH

È possibile utilizzare SSH per connettersi a singoli nodi di cluster di gestione autonomi o cluster del carico di lavoro. A tale scopo, la coppia di chiavi SSH creata durante la distribuzione del cluster di gestione deve essere disponibile nella macchina in cui si esegue il comando SSH. Di conseguenza, è necessario eseguire comandi ssh sulla macchina in cui vengono eseguiti i comandi tanzu.

Le chiavi SSH registrate nel cluster di gestione e utilizzate da tutti i cluster del carico di lavoro distribuiti dal cluster di gestione sono associate ai seguenti account utente:

• Cluster di gestione vSphere e nodi Tanzu Kubernetes in esecuzione su Photon OS e Ubuntu: capv
• Nodi bastion AWS: ubuntu
• Cluster di gestione AWS e nodi Tanzu Kubernetes in esecuzione su Ubuntu: ubuntu
• Cluster di gestione AWS e nodi Tanzu Kubernetes in esecuzione su Amazon Linux: ec2-user
• Cluster di gestione Azure e nodi Tanzu Kubernetes (sempre Ubuntu): capi

Per connettersi a un nodo utilizzando SSH, eseguire uno dei seguenti comandi dalla macchina utilizzata come macchina di bootstrap:

• Nodi vSphere: ssh capv@node-address
• Nodi bastion AWS, cluster di gestione e nodi del carico di lavoro in Ubuntu: ssh ubuntu@node-address
• Cluster di gestione AWS e nodi Tanzu Kubernetes in esecuzione su Amazon Linux: ssh ec2-user@node-address
• Nodi Azure: ssh capi@node-address

Poiché la chiave SSH è presente nel sistema in cui si esegue il comando ssh, non è necessaria alcuna password.

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-tkg/config.

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

   kubectl config unset users.USERNAME --kubeconfig ~/.kube-tkg/config
   

   In cui USERNAME è la proprietà name di ciascun oggetto user di livello superiore, come indicato nel file config.

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

   kubectl config unset contexts.CONTEXT-NAME --kubeconfig ~/.kube-tkg/config
   

   In cui CONTEXT-NAME è la proprietà name di ciascun oggetto context di livello superiore, come indicato nel 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 --kubeconfig ~/.kube-tkg/config
   

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

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

   kubectl config unset current-context --kubeconfig ~/.kube-tkg/config
   

6. Se si eliminano cluster di gestione monitorati dalla CLI di tanzu, eliminarli dallo stato della CLI di tanzu eseguendo tanzu context delete come descritto in Eliminazione dei cluster di gestione dalla configurazione della CLI di Tanzu.

Disattivazione di nfs-utils nei nodi Photon OS

Problema

In Tanzu Kubernetes Grid v1.1.2 e versioni successive, nfs-utils è abilitato per impostazione predefinita. Se nfs-utils non è necessario, è possibile rimuoverlo dalle macchine virtuali del nodo del cluster.

Soluzione

Per disattivare nfs-utils nei cluster distribuiti con Tanzu Kubernetes Grid versione 1.1.2 o successiva, utilizzare SSH per accedere alle macchine virtuali del nodo del cluster ed eseguire il comando seguente:

tdnf erase nfs-utils

Piattaforma di destinazione

Il problema di assegnazione dei tag delle risorse CAPA causa un errore di riconciliazione durante la distribuzione e l'aggiornamento del cluster di gestione AWS

Problema

A causa di un problema di assegnazione dei tag delle risorse in Cluster API Provider AWS (CAPA) upstream, le distribuzioni offline non possono accedere all'API ResourceTagging causando errori di riconciliazione durante la creazione o l'aggiornamento del cluster di gestione.

Soluzione

in un ambiente AWS offline, impostare EXP_EXTERNAL_RESOURCE_GC=false nell'ambiente locale o nel file di configurazione del cluster di gestione prima di eseguire tanzu mc create o tanzu mc upgrade.

Convalida non riuscita, errore di credenziali in AWS

Problema

L'esecuzione tanzu management-cluster create o tanzu mc create non riesce e viene visualizzato un errore simile al seguente:

Validating the pre-requisites...
Looking for AWS credentials in the default credentials provider chain

Error: : Tkg configuration validation failed: failed to get AWS client: NoCredentialProviders: no valid providers in chain
caused by: EnvAccessKeyNotFound: AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY not found in environment
SharedCredsLoad: failed to load shared credentials file
caused by: FailedRead: unable to open file
caused by: open /root/.aws/credentials: no such file or directory
EC2RoleRequestError: no EC2 instance role found
caused by: EC2MetadataError: failed to make EC2Metadata request

Soluzione

Tanzu Kubernetes Grid utilizza la catena di provider di credenziali AWS predefinita. Prima di creare un cluster di gestione o un cluster del carico di lavoro in AWS, è necessario configurare le credenziali dell'account AWS come descritto in Configurazione delle credenziali AWS.

Convalida non riuscita, errore di termini legali in Azure

Problema

Prima di creare un cluster di gestione autonomo o del carico di lavoro in Azure, è necessario accettare i termini legali che riguardano l'immagine della macchina virtuale utilizzata dai nodi del cluster. Se si esegue tanzu mc create o tanzu cluster create senza aver accettato la licenza, l'operazione non riesce e viene visualizzato un messaggio di errore simile al seguente:

User failed validation to purchase resources. Error message: 'You have not accepted the legal terms on this subscription: '*********' for this plan. Before the subscription can be used, you need to accept the legal terms of the image.

Soluzione

In questo caso, accettare i termini legali e riprovare:

• Cluster di gestione: Vedere Accettazione della licenza dell'immagine di base
• Cluster del carico di lavoro: Vedere le istruzioni Azure in Distribuzione di un cluster con una versione di Kubernetes non predefinita.

Cluster di gestione

Pulizia dopo la distribuzione non riuscita di un cluster di gestione

Problema

Un tentativo non riuscito di distribuire un cluster di gestione autonomo lascia oggetti orfani nell'infrastruttura cloud e nella macchina di bootstrap.

Soluzione

1. Monitorare l'output del comando tanzu mc create nel terminale o nell'interfaccia del programma di installazione di Tanzu Kubernetes Grid. Se il comando non riesce, viene visualizzato un messaggio della guida che include quanto segue: “Failure while deploying management cluster… To clean up the resources created by the management cluster: tkg delete mc….”
2. eseguire tanzu mc delete YOUR-CLUSTER-NAME. Questo comando rimuove gli oggetti creati nell'infrastruttura e localmente.

È inoltre possibile utilizzare i metodi alternativi descritti di seguito:

• Pulizia della macchina di bootstrap:

  • Per rimuovere un cluster kind, utilizzare la CLI kind. Ad esempio:

    kind get clusters
    kind delete cluster --name tkg-kind-example1234567abcdef
    

  • Per rimuovere gli oggetti Docker, utilizzare la CLI docker. Ad esempio, docker rm, docker rmi e docker system prune -a --volumes.

    Attenzione Se si eseguono processi Docker non correlati a Tanzu Kubernetes Grid nel sistema, rimuovere singolarmente gli oggetti Docker non richiesti.

• Pulizia della piattaforma di destinazione:

  • vSphere: Individuare, disattivare ed eliminare le macchine virtuali e le altre risorse create da Tanzu Kubernetes Grid.
  • AWS: Accedere al dashboard di Amazon EC2 ed eliminare le risorse manualmente o utilizzare una soluzione automatizzata.
  • Azure: In Gruppi di risorse (Resource Groups) aprire AZURE_RESOURCE_GROUP. Utilizzare le caselle di controllo per selezionare ed Eliminare (Delete) le risorse create da Tanzu Kubernetes Grid, che contengono data e ora nei nomi.

Non è possibile eliminare il cluster di gestione in AWS

Problema

Dopo aver eseguito tanzu mc delete in AWS, tanzu mc get e altri comandi della CLI di Tanzu non elencano più il cluster di gestione eliminato, ma:

• Il cluster non viene eliminato dall'infrastruttura di AWS e i relativi nodi vengono ancora visualizzati nel dashboard Amazon EC2
• I registri del cluster di gestione includono l'errore cluster infrastructure is still being provisioned: VpcReconciliationFailed.

Soluzione

Questo comportamento si verifica quando TKG utilizza credenziali dell'account AWS scadute o comunque non valide. Per impedire che si verifichi questa situazione o per eseguire il ripristino quando si verifica:

• Per impedirla: aggiornare le credenziali dell'account AWS come descritto in Configurazione delle credenziali dell'account AWS utilizzando i profili delle credenziali di AWS o le variabili di ambiente statiche locali.

  • Non è possibile utilizzare le credenziali del profilo dell'istanza di AWS per eliminare un cluster di gestione.

• Per eseguire il ripristino utilizzando il dashboard EC2: eliminare manualmente i nodi del cluster di gestione dal dashboard EC2

• Per eseguire il ripristino utilizzando la CLI:

  1. nel cluster kind che rimane nella macchina di bootstrap a causa della mancata eliminazione del cluster di gestione, correggere il segreto delle credenziali di AWS:

     kubectl get secret capa-manager-bootstrap-credentials -n capa-system -ojsonpath="{.data.credentials}"| base64 -d
     

  2. Modificare il segreto per includere le credenziali di AWS:

     [default]
     aws_access_key_id = <key id>
     aws_secret_access_key = <access_key>
     region = <region>
     

  3. Eseguire nuovamente tanzu mc delete.

Il cluster kind rimane dopo l'eliminazione del cluster di gestione

Problema

L'esecuzione di tanzu mc delete rimuove il cluster di gestione, ma non riesce a eliminare il cluster kind locale dalla macchina di bootstrap.

Soluzione

1. Elencare tutti i cluster kind in esecuzione e rimuovere quello simile a tkg-kind-unique_ID:

   kind delete cluster --name tkg-kind-unique_ID
   

2. Elencare tutti i cluster in esecuzione e identificare il cluster kind.

   docker ps -a
   

3. Copiare l'ID container del cluster kind e rimuoverlo.

   docker kill container-ID
   

Macchine bloccate dopo una distribuzione non riuscita del cluster di gestione

Problema

La distribuzione del cluster di gestione autonomo non riesce perché le macchine sono bloccate in attesa di correzione.

Soluzione

Per un cluster di gestione distribuito con il piano dev, che include un solo nodo del piano di controllo, è necessario ridistribuire il cluster di gestione. Per i cluster di gestione con più nodi del piano di controllo, è possibile identificare ed eliminare le macchine bloccate.

1. Recuperare lo stato del cluster di gestione. Ad esempio:

   kubectl -n tkg-system get cluster my-mgmt-cluster -o yaml
   

2. Individuare i nomi delle macchine bloccate nell'output del passaggio precedente. Una macchina bloccata viene contrassegnata come WaitingForRemediation. Ad esempio, il nome della macchina bloccata è my-mgmt-cluster-zpc7t nell'output seguente:

   status:
     conditions:
     - lastTransitionTime: "2021-08-25T15:44:23Z"
       message: KCP can't remediate if current replicas are less or equal then 1
       reason: WaitingForRemediation @ Machine/my-mgmt-cluster-zpc7t
       severity: Warning
       status: "False"
       type: Ready
   

3. Aumentare i valori di timeout del controllo dello stato della macchina per i nodi del piano di controllo a un valore maggiore del valore predefinito, 5m. Ad esempio:

   tanzu cluster machinehealthcheck control-plane set my-cluster --mhc-name my-control-plane-mhc --unhealthy-conditions "Ready:False:10m,Ready:Unknown:10m"
   

   Per ulteriori informazioni sull'aggiornamento di un oggetto MachineHealthCheck, vedere Creazione o aggiornamento di un oggetto MachineHealthCheck in Configurazione dei controlli dello stato delle macchine per i cluster del carico di lavoro.

4. Impostare il contesto di kubectl sul contesto del cluster di gestione. Ad esempio:

   kubectl config use-context mgmt-cluster-admin@mgmt-cluster
   

5. Eliminare le macchine bloccate.

   kubectl delete machine MACHINE-NAME
   

   Dove MACHINE-NAME è il nome della macchina individuata in un passaggio precedente.

6. Attendere che il controller KubeadmControlPlane distribuisca di nuovo la macchina.

Ripristinare la directory ~/.config/tanzu

Problema

La directory ~/.config/tanzu nella macchina di bootstrap è stata accidentalmente eliminata o danneggiata. La CLI di Tanzu crea e utilizza questa directory, e non può funzionare se è assente.

Soluzione

Per ripristinare il contenuto della directory ~/.config/tanzu:

1. Per identificare i cluster di gestione Tanzu Kubernetes Grid esistenti, eseguire:

   kubectl --kubeconfig ~/.kube-tkg/config config get-contexts
   

   L'output del comando elenca i nomi e i contesti di tutti i cluster di gestione creati o aggiunti dalla CLI di Tanzu.

2. Per ogni cluster di gestione elencato nell'output, ripristinarlo nella directory e nella CLI di ~/.config/tanzu eseguendo:

   tanzu context create --management-cluster --kubeconfig ~/.kube-tkg/config --context MGMT-CLUSTER-CONTEXT --name MGMT-CLUSTER
   

L'esecuzione di tanzu management-cluster create in macOS genera un errore di versione di kubectl

Problema

Se si esegue il comando tanzu management-cluster create o tanzu mc create su macOS con la versione stabile più recente di Docker Desktop, l'operazione non riesce e viene visualizzato il messaggio di errore simile al seguente:

Error: : kubectl prerequisites validation failed: kubectl client version v1.15.5 is less than minimum supported kubectl client version 1.26.8

Questo accade perché Docker Desktop inserisce nel percorso collegamenti simbolici a una versione precedente di kubectl.

Soluzione

Inserire una versione più recente supportata di kubectl nel percorso prima della versione di Docker.

Ripristino delle credenziali del cluster di gestione

Se si perdono le credenziali per un cluster di gestione autonomo, ad esempio eliminando inavvertitamente il file .kube-tkg/config nel sistema in cui si eseguono i comandi tanzu, è possibile ripristinare le credenziali dal nodo del piano di controllo del cluster di gestione.

1. Eseguire tanzu mc create per ricreare il file .kube-tkg/config.
2. Ottenere l'indirizzo IP pubblico del nodo del piano di controllo del cluster di gestione da vSphere, AWS o Azure.

3. Utilizzare SSH per accedere al nodo del piano di controllo del cluster di gestione.

   Vedere il precedente argomento Connessione ai nodi del cluster con SSH per informazioni sulle credenziali da utilizzare per ogni piattaforma di destinazione.

4. Accedere al file admin.conf per il cluster di gestione.

   sudo vi /etc/kubernetes/admin.conf
   

   Il file admin.conf contiene il nome del cluster, il nome utente del cluster, il contesto del cluster e i dati del certificato del client.

5. Copiare il nome del cluster, il nome utente del cluster, il contesto del cluster e i dati del certificato client nel file .kube-tkg/config nel sistema in cui vengono eseguiti i comandi tanzu.

Pinniped

L'aggiunta della gestione delle identità esterne a una distribuzione esistente può richiedere l'impostazione di un valore fittizio di VSPHERE_CONTROL_PLANE_ENDPOINT

Problema

L'integrazione di un provider di identità esterno con una distribuzione TKG esistente può richiedere l'impostazione di un valore fittizio di VSPHERE_CONTROL_PLANE_ENDPOINT nel file di configurazione del cluster di gestione utilizzato per creare il segreto del componente aggiuntivo, come descritto in Generazione del segreto del componente aggiuntivo Pinniped per il cluster di gestione

La disattivazione di Pinniped richiede l'eliminazione manuale di Secret nei cluster legacy

Problema

Quando si disattiva la gestione delle identità esterne in un cluster di gestione, l'oggetto Secret inutilizzato di Pinniped rimane presente nei cluster del carico di lavoro legacy.

Se un utente tenta quindi di accedere al cluster utilizzando un vecchio kubeconfig, verrà visualizzato un popup di accesso che non riesce.

Soluzione

eliminare manualmente il Secret di Pinniped del cluster legacy come descritto in Disattivazione della gestione delle identità.

Il processo post-distribuzione di Pinniped non riesce

Problema

L'aggiornamento a Tanzu Kubernetes Grid v2.3 restituisce un errore simile al seguente:

 Operation cannot be fulfilled on certificates.cert-manager.io "pinniped-cert": the object has been modified; please apply your changes to the latest version and try again

Soluzione

Questo errore può verificarsi se il processo post-distribuzione di Pinniped è in conflitto con il processo di aggiornamento di un componente. Eseguire i passaggi seguenti per eliminare e ridistribuire il processo.

1. Eliminare il processo post-distribuzione di Pinniped.

   kubectl delete jobs.batch -n pinniped-supervisor pinniped-post-deploy-job
   

2. Attendere circa 5 minuti affinché kapp-controller ridistribuisca il processo di post-distribuzione.

3. Verificare lo stato dell'app Pinniped.

   kubectl get app -n tkg-system pinniped
   NAME       DESCRIPTION           SINCE-DEPLOY   AGE
   pinniped   Reconcile succeeded   5s             49m
   

   Se in DESCRIPTION è visualizzato Reconciling, attendere alcuni minuti, quindi controllare di nuovo. Una volta visualizzato Reconcile succeeded continuare con il passaggio successivo.

4. Verificare lo stato del processo post-distribuzione di Pinniped.

   kubectl get jobs -n pinniped-supervisor
   NAME                             COMPLETIONS   DURATION   AGE
   pinniped-post-deploy-job-ver-1   1/1           9s         62s
   

Errore di autenticazione Pinniped nel cluster del carico di lavoro dopo l'aggiornamento del cluster di gestione

Problema

Il cluster di gestione è stato aggiornato di recente. Quando si tenta di eseguire l'autenticazione in un cluster del carico di lavoro associato a questo cluster di gestione, viene visualizzato un messaggio di errore simile al seguente:

Error: could not complete Pinniped login: could not perform OIDC discovery for "https://IP:PORT": Get "https://IP:PORT/.well-known/openid-configuration": x509: certificate signed by unknown authority

Soluzione

Ciò si verifica perché la copia del bundle CA supervisore Pinniped utilizzata dal cluster del carico di lavoro è obsoleta. Per aggiornare il bundle CA supervisore, eseguire i passaggi seguenti:

1. Impostare il contesto di kubectl sul cluster di gestione.

2. Ottenere il bundle CA con codifica base64 e l'endpoint issuer dalla ConfigMap pinniped-info:

   kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer_ca_bundle_data} > /tmp/ca-bundle && kubectl get configmap pinniped-info -n kube-public -o jsonpath={.data.issuer} > /tmp/supervisor-endpoint
   

3. Ottenere la sezione values.yaml dal segreto del componente aggiuntivo Pinniped per il cluster del carico di lavoro:

   kubectl get secret WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
   

   Questo segreto si trova nel cluster di gestione.

4. Nel file values.yaml creato in precedenza, aggiornare la chiave supervisor_ca_bundle_data in modo che corrisponda al bundle CA della ConfigMap pinniped-info. Assicurarsi inoltre che supervisor_svc_endpoint corrisponda all'endpoint issuer.

5. Applicare l'aggiornamento codificando in base64 il file values.yaml modificato e sostituendolo nel segreto del cluster del carico di lavoro. Questo comando varia in base al sistema operativo del proprio ambiente. Ad esempio:

   Linux:

   kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
   

   macOS:

   kubectl patch secret/WORKLOAD-CLUSTER-NAME-pinniped-addon -n WORKLOAD-CLUSTER-NAMESPACE -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
   

6. Nel cluster del carico di lavoro, verificare che l'app Pinniped abbia riconciliato correttamente le modifiche:

   kubectl get app pinniped -n tkg-system
   

7. Autenticarsi sul cluster. Ad esempio:

   kubectl get pods -A --kubeconfig my-cluster-credentials
   

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 in VMware Ports and Protocols.

CLI di Tanzu

La CLI di Tanzu non riesce a raggiungere il cluster di gestione

Problema

L'esecuzione dei comandi della CLI di tanzu restituisce un errore simile al seguente:

Failed to invoke API on cluster : the server has asked for the client to provide credentials, retrying

Soluzione

Vedere Aggiornamento del certificato del cluster di gestione nella configurazione della CLI di Tanzu e Non è possibile accedere ai cluster utilizzando i comandi della CLI di TKG/Tanzu in Tanzu Kubernetes Grid.

Prompt dei comandi di Windows: caratteri estranei nelle intestazioni delle colonne di output della CLI

Problema

Nel prompt dei comandi (CMD) di Windows, l'output del comando della CLI di Tanzu formattato in colonne include caratteri estranei nelle intestazioni delle colonne. Il problema non si verifica in Windows Terminal o PowerShell.

Soluzione

nelle macchine di bootstrap di Windows, eseguire la CLI di Tanzu da Windows Terminal.

La CLI segnala temporaneamente per errore lo stato dei nodi eliminati di recente quando i controlli MHC sono disattivati

Problema

Quando i controlli di integrità delle macchine (MHC) sono disattivati, i comandi della CLI di Tanzu come tanzu cluster status potrebbero non segnalare lo stato aggiornato del nodo durante la ricreazione dell'infrastruttura.

Soluzione

nessuna.

Interfaccia del programma di installazione Tanzu Kubernetes Grid

L'interfaccia utente di Tanzu Kubernetes Grid non viene visualizzata correttamente in Windows

Problema

Quando si esegue il comando tanzu management-cluster create --ui o tanzu mc create --ui in un sistema Windows, l'interfaccia utente viene aperta nel browser predefinito, ma la grafica e gli stili non vengono applicati. Ciò accade perché una voce del registro di sistema di Windows è impostata su application/x-css.

Soluzione

1. Nella ricerca Windows, immettere regedit per aprire l'utilità Editor del Registro di sistema.
2. Espandere HKEY_CLASSES_ROOT e selezionare .js.
3. Fare clic con il pulsante destro del mouse su Tipo di contenuto e scegliere Modifica.
4. Impostare il Valore su application/javascript e fare clic su OK.
5. Eseguire nuovamente il comando tanzu mc create --ui per riavviare l'interfaccia utente.

NSX Advanced Load Balancer

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 di gestione con lo stesso valore CLUSTER_NAME, anche da macchine di bootstrap diverse.

Le richieste del VIP NSX Advanced Load Balancer non riescono e viene visualizzato un messaggio che indica che non è disponibile il routing verso l'host

Problema

Se il numero totale di servizi di tipo LoadBalancer è elevato e tutti i motori di servizio sono distribuiti nella stessa rete L2, è possibile che le richieste al VIP NSX Advanced Load Balancer non riescano e che venga visualizzato il messaggio no route to host.

Ciò si verifica perché il limite di velocità di ARP predefinito nei motori di servizio è 100.

Soluzione

Impostare il limite di velocità di ARP su un numero maggiore. Questo parametro non è modificabile in NSX Advanced Load Balancer Essentials, ma è modificabile in NSX Advanced Load Balancer Enterprise Edition.

Errore di AKODeploymentConfig ignorabile durante la creazione del cluster di gestione

Problema

L'esecuzione di tanzu management-cluster create per creare un cluster di gestione con NSX ALB genera l'errore no matches for kind AKODeploymentConfig in version networking.tkg.tanzu.vmware.com/v1alpha1.

Soluzione

L'errore può essere ignorato. Per ulteriori informazioni, vedere questo articolo della Knowledge Base.

Multus CNI non riesce in pod medium e più piccoli con NSX Advanced Load Balancer

Problema

In vSphere, è possibile che i cluster del carico di lavoro con nodi worker medium o più piccoli che eseguono il pacchetto Multus CNI con NSX ALB non riescano e che venga visualizzato il messaggio di errore Insufficient CPU o altri.

Soluzione

per utilizzare Multus CNI con NSX ALB, distribuire i cluster del carico di lavoro con nodi worker di dimensioni large o extra-large.

Aggiornamento

L'aggiornamento dei cluster in Azure non riesce

Problema

In Azure, l'aggiornamento dei cluster di gestione e dei cluster del carico di lavoro non riesce e vengono visualizzati messaggi di errore come context deadline exceeded o unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane. Questo problema si verifica perché le operazioni in Azure impiegano a volte più tempo rispetto alle altre piattaforme.

Soluzione

eseguire nuovamente tanzu management-cluster upgrade o tanzu cluster upgrade specificando un timeout più lungo nel flag --timeout. Il Timeout predefinito è 30 m0s.

L'aggiornamento non riesce per i cluster di gestione autonomi originariamente creati in TKG v1.3 o versioni precedenti

Problema

In TKG v2.3, i componenti che trasformano un cluster generico in un cluster di gestione autonomo TKG sono inclusi in un pacchetto di Carvel tkg-pkg. Nei cluster di gestione autonomi originariamente creati in TKG v1.3 o versioni precedenti manca un segreto di configurazione richiesto dal processo di aggiornamento per installare tkg-pkg. L'aggiornamento non viene quindi eseguito correttamente.

Soluzione

eseguire i passaggi aggiuntivi elencati in Aggiornamento dei cluster di gestione autonomi per i cluster di gestione autonomi creati in TKG v1.3 o versioni precedenti.