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 Pulizia dei dati di Antrea da NSX.
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 Pulizia dei dati di Antrea da NSX.

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.