Perché il mio nodo di lavoro mostra un errore di NetworkUnavailable ?

Risolvere i problemi relativi allo stato di integrità dei nodi di " Calico " e i problemi di rete.

Virtual Private Cloud Infrastruttura classica Satellite

Quando aggiorni il tuo master o i tuoi nodi di lavoro, i tuoi nodi di lavoro entrano in uno stato Node network unavailable.

I tuoi nodi di lavoro potrebbero entrare in uno stato NetworkUnavailable o Node network unavailable ogni volta che il pod calico-node è stato arrestato. Questo potrebbe accadere durante un aggiornamento della patch Calico, ma non dovrebbe avere un impatto sulla disponibilità dell'applicazione.

Quando Calico viene aggiornato, il taint node.kubernetes.io/network-unavailable:NoSchedule viene aggiunto al tuo nodo di lavoro e la condizione Node network unavailable diventa True. Entrambe queste condizioni vengono eliminate quando si riavvia Calico, che generalmente impiega solo pochi secondi.

Mentre ciò accade, potrebbe essere visualizzato un messaggio di errore simile al seguente esempio.

[Kubernetes] Node network unavailable is Triggered on kubernetes.node.name = 10.184.XXX.XXX
[Kubernetes] Node network unavailable is Triggered on kubernetes.node.name = 10.184.XXX.XXX
[Kubernetes] Node network unavailable is Triggered on kubernetes.node.name = 10.184.XXX.XXX

A volte, il riavvio potrebbe richiedere più tempo. In quasi tutti i casi, il riavvio è abbastanza rapido da evitare problemi di rete del nodo di lavoro. Tuttavia, ci sono situazioni in cui un riavvio di Calico viene ritardato e, quindi, potrebbero verificarsi delle interruzioni di rete. Per questi casi, la condizione e il taint della rete del nodo non disponibili sono progettati per impedire la distribuzione di nuove app al nuovo nodo fino a quando Calico e il nodo non vengono corretti. Gli aggiornamenti Calico vengono sottoposti a rollout in modo molto controllato, in modo da ridurre al minimo l'impatto globale dell'applicazione in caso di problemi di nodo.

Monitorare lo stato di Node network unavailable con IBM Cloud Monitoring

Utilizzando i servizi per monitorare le applicazioni come IBM Cloud Monitoring, puoi configurare gli avvisi per quando un nodo di lavoro passa a uno stato Node network unavailable e contare ogni volta che ciò si verifica. Puoi inoltre configurare le soglie e ottimizzare i tuoi avvisi per consentire quando i nodi di lavoro si trovano in uno stato Node network unavailable durante le patch della routine Calico.

Quando configuri gli avvisi IBM Cloud Monitoring, tieni conto dei seguenti scenari.

• Un avviso Node network unavailable potrebbe diventare un problema quando un pod calico-node non riesce a raggiungere uno stato Running e il suo conteggio di riavvio del contenitore continua ad aumentare.
• Un nodo di lavoro rimane nello stato di Node network unavailable per un lungo periodo di tempo.

Dopo un aggiornamento o una sostituzione del nodo di lavoro, a volte il pod calico-node non inizia ancora sul cluster VPC Red Hat OpenShift. Il pod calico_node potrebbe rimanere bloccato in uno stato in cui non può essere avviato su un cluster VPC Red Hat OpenShift. Questo non è un problema sui cluster IKS o Classic. Ciò può verificarsi quando hai installato sysdig-admission-controller-webhook e provi a eseguire un aggiornamento o una sostituzione del nodo di lavoro. Ciò accade perché:

1. Il pod del client VPN viene spostato sul nuovo nodo di lavoro quando viene avviato.
2. calico-node sul nuovo nodo di lavoro viene avviato, ma si blocca perché effettua una chiamata apiserver e va in timeout dopo 2 secondi.
3. La chiamata apiserver tenta quindi di richiamare il webhook che non riesce perché il pod client VPN stava tentando di avviarsi sul nuovo nodo. Il nodo VPN non può eseguire correttamente questa operazione perché calico-node non è ancora stato avviato.

In sintesi, l'inizio del pod calico-node dipende dal funzionamento del webhook; il webhook dipende dal pod client VPN e il pod client VPN dipende dall'avvio di calico-node. Il sistema è bloccato in una dipendenza circolare. Se sei in grado di raccogliere i log da un pod calico-node distribuito correttamente, potresti visualizzare un errore come questo:

2022-09-08 07:13:19.719 [WARNING][9] startup/utils.go 228: Failed to set NetworkUnavailable; will retry error=Patch "https://172.21.0.1:443/api/v1/nodes/10.242.64.17/status?timeout=2s": net/http: request canceled (Client.Timeout exceeded while awaiting headers)