Se lo stato del cluster Kubernetes Antrea è inattivo, eseguire i passaggi descritti in questa documentazione per determinare la causa di questo problema e risolverlo oppure raccogliere il bundle di supporto.

Problema

Il nodo del piano di controllo del cluster è inattivo. Il cluster Kubernetes Antrea è disconnesso dal piano di controllo centrale (CCP).

Causa

Nell'interfaccia utente di NSX Manager passare a Sistema > Infrastruttura > Nodi > Cluster di container > Antrea. Se necessario, filtrare l'elenco di cluster nella pagina Antrea con il campo ID esterno.

Fare clic sulla colonna Stato del cluster in cui si è verificato il problema. Se tutti i componenti sono inattivi, le possibili cause sono:
  • Il cluster Kubernetes è stato eliminato.
  • Si è verificato un problema di connettività di rete relativo a CCP.
  • Si è verificato un arresto anomalo delle schede o le schede sono state eliminate per qualche motivo.
  • Il certificato client delle schede non è corretto.
  • La versione delle schede non è compatibile con CCP.

Se solo la Adattatore piano di controllo centrale è inattiva, è possibile che si sia verificato un arresto anomalo della scheda di CCP.

Soluzione

  1. Se il cluster Kubernetes è stato eliminato, cancellare i dati di registrazione e inventario rimasti in NSX. Vedere Eliminazione di un cluster Kubernetes Antrea dall'inventario di NSX tramite la riga di comando.
  2. Recuperare kubectl e l'accesso kubeconfig per il cluster Kubernetes. Utilizzare kubectl per recuperare il nome del nodo in cui è in esecuzione il pod interworking. Avviare una sessione SSH nel nodo e utilizzare il comando curl o nc per connettersi a ogni IP di NSX Manager nelle porte 1234 e 1235. Se non è possibile stabilire la connessione, la causa è un problema di connettività di rete relativo a CCP.
    Esempio del comando curl:

    Assicurarsi di sostituire NSX-Manager-IP con l'indirizzo IP di NSX Manager nell'ambiente in uso.

    curl -v NSX-Manager-IP:1235
    
    Trying NSX-Manager-IP... 
    Connected to NSX-Manager-IP (NSX-Manager-IP) port 1235 (#0) 
    ... 
    Empty reply from server 
    Connection #0 to host NSX-Manager-IP left intact 
    curl: (52) Empty reply from server

    Esempio del comando nc:

    nc -v NSX-Manager-IP 1235 < /dev/null
    
    Ncat: Version 7.50 (https://nmap.org/ncat)
    Ncat: Connected to NSX-Manager-IP:1235.
    Ncat: 0 bytes sent, 0 bytes received in 0.37 seconds.
  3. Utilizzare kubectl per verificare se tutti i container del pod interworking nello spazio dei nomi vmware-system-antrea sono attivi.
    Se un container è inattivo, utilizzare kubectl per recuperare i registri dei container in cui si è verificato l'arresto anomalo e controllare il messaggio di errore. Questo passaggio consente di identificare l'errore causato da uno dei motivi seguenti:
    • Si è verificato un arresto anomalo delle schede o le schede sono state eliminate per qualche motivo.
    • Arresto anomalo della scheda CCP.
    Esempio del comando kubectl per recuperare il pod interworking:
    kubectl get pod -o wide -l app=antrea-interworking -n vmware-system-antrea

    Prendere nota del nome del pod interworking.

    Esempio del comando kubectl per recuperare lo stato dettagliato del pod interworking:

    Assicurarsi di sostituire pod-name con il nome effettivo del pod.

    kubectl get pod -o yaml pod-name -n vmware-system-antrea

    Esempio del comando kubectl per recuperare i registri dei container:

    Assicurarsi di sostituire pod-name con il nome effettivo del pod.

    kubectl logs pod-name -c mp-adapter -n vmware-system-antrea > mp-adapter.log
    kubectl logs pod-name -c ccp-adapter -n vmware-system-antrea > ccp-adapter.log
    kubectl logs pod-name -c tn-proxy -n vmware-system-antrea > tn-proxy.log
    kubectl logs pod-name -c election-runner -n vmware-system-antrea > election-runner.log

    Se manca lo spazio dei nomi vmware-system-antrea o il pod interworking, è possibile che le schede siano state eliminate dal cluster Kubernetes senza eseguire i passaggi di annullamento della registrazione. È possibile cancellare dal sistema i dati di registrazione e inventario rimasti e quindi registrare nuovamente il cluster Kubernetes. L'ID cluster sarà diverso dopo la nuova registrazione del cluster. Se al cluster è stato applicato un criterio di Antrea, è necessario applicarlo nuovamente dopo la nuova registrazione del cluster.

    Per istruzioni sulla cancellazione dei dati di registrazione rimasti, vedere Eliminazione di un cluster Kubernetes Antrea dall'inventario di NSX tramite la riga di comando.

    Per istruzioni sulla registrazione di un cluster Kubernetes Antrea in NSX, vedere Registrazione di un cluster Kubernetes Antrea in NSX.

  4. Utilizzare kubectl per recuperare i registri dei container nsx-proxy dal pod interworking e controllare i messaggi di errore.
    Questo passaggio consente di identificare l'errore causato da uno dei motivi seguenti:
    • Il certificato client delle schede non è corretto.
    • La versione delle schede non è compatibile con CCP.

    Per esempi di comandi, vedere il passaggio 3.

  5. Se la Adattatore piano di gestione è attiva, utilizzare la funzionalità del bundle di supporto in NSX per raccogliere i file di registro per il cluster Kubernetes Antrea.