Lo stato del cluster di container Antrea è inattivo

Se lo stato del cluster di container 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 di container 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

Se il cluster Kubernetes è stato eliminato, cancellare i dati di registrazione e inventario rimasti in NSX. Vedere Eliminazione di un cluster di container Antrea dall'inventario di NSX-T tramite la riga di comando.
Recuperare kubectl e l'accesso kubeconfig per il cluster di container. 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.
```
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 di container Antrea dall'inventario di NSX-T tramite la riga di comando.

Per istruzioni sulla registrazione di un cluster di container Antrea in NSX, vedere Registrazione di un cluster di container Antrea in NSX-T Data Center.
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.
Se la Adattatore piano di gestione è attivoa, utilizzare la funzionalità del bundle di supporto in NSX per raccogliere i file di registro per il cluster di container.

Per ulteriori informazioni, vedere Raccolta di bundle di supporto per un cluster di container Antrea.