Cluster classici: Perché la conservazione dell'IP sorgente fallisce quando si usano nodi contaminati?

Infrastrutture classiche

La conservazione dell'IP di origine fallisce quando si utilizzano nodi contaminati in cluster classici, impedendo al traffico di raggiungere l'applicazione.

In un cluster classico, hai abilitato la conservazione dell'IP di origine per un servizio del programma di bilanciamento del carico 1.0 modificando externalTrafficPolicy impostandolo su Local nel file di configurazione del servizio. Tuttavia, il traffico non raggiunge il servizio di back-end per la tua applicazione.

Quando abiliti la conservazione dell'IP di origine per i servizi del programma di bilanciamento del carico, l'indirizzo IP di origine della richiesta del client viene conservato.

Il servizio inoltra il traffico ai pod dell'applicazione solo sullo stesso nodo di lavoro per garantire che l'indirizzo IP del pacchetto di richiesta non venga modificato. In genere, i pod del servizio del programma di bilanciamento del carico vengono distribuiti negli stessi nodi di lavoro in cui sono distribuiti i pod dell'applicazione. Tuttavia, ci sono alcune situazioni in cui i pod del servizio e i pod dell'applicazione potrebbero non essere pianificati sullo stesso nodo di lavoro. Se si usano i taint di Kubernetes sui nodi worker, ai pod che non hanno una tolleranza di taint viene impedita l'esecuzione sui nodi worker contaminati. La conservazione dell'IP di origine potrebbe non funzionare in base al tipo di taint che hai utilizzato:

Contaminazioni del nodo edge: hai aggiunto l'etichetta dedicated=edge a due o più nodi di lavoro su ogni VLAN pubblica nel tuo cluster per garantire che i pod del programma di bilanciamento del carico vengano distribuiti solo a quei nodi di lavoro. Quindi, hai anche applicato un taint a tali nodi edge per impedire che altri carichi di lavoro vengano eseguiti su nodi edge. Tuttavia, non hai aggiunto una regola di affinità del nodo edge e una tolleranza alla tua distribuzione dell'applicazione. I tuoi pod dell'applicazione non possono essere pianificati sugli stessi nodi con taint dei pod del servizio e il traffico non raggiunge il servizio di back-end per la tua applicazione.
Taint personalizzati: hai utilizzato taint personalizzati su diversi nodi in modo che solo i pod dell'applicazione con tolleranza a questi taint possano essere distribuiti su tali nodi. Hai aggiunto regole di affinità e tolleranze alle distribuzioni dell'applicazione e del servizio del programma di bilanciamento del carico in modo che i loro pod vengano distribuiti solo su quei nodi. Tuttavia, i pod ibm-cloud-provider-ip keepalived che vengono creati automaticamente nello spazio dei nomi ibm-system garantiscono che i pod del programma di bilanciamento del carico e dell'applicazione siano sempre pianificati sullo stesso nodo di lavoro. Questi pod keepalived non hanno le tolleranze per i taint personalizzati che hai utilizzato. Non possono essere pianificati sugli stessi nodi con taint su cui sono in esecuzione i tuoi pod dell'applicazione e il traffico non raggiunge il servizio di back-end per la tua applicazione.

Risolvi il problema scegliendo una delle seguenti opzioni:

Taint del nodo edge: per garantire che i tuoi pod del programma di bilanciamento del carico e dell'applicazione vengano distribuiti sui nodi edge a cui è stato applicato un taint, aggiungi regole di affinità e tolleranze del nodo edge alla tua distribuzione dell'applicazione. I pod del programma di bilanciamento del carico hanno queste regole di affinità e tolleranze per impostazione predefinita.

Taint personalizzati: rimuovi i taint personalizzati per le quali i pod keepalived non hanno tolleranze. Puoi invece etichettare i nodi di lavoro come edge e quindi applicare un taint a tali nodi edge.

Se si completa una delle opzioni precedenti ma i pod keepalived non sono ancora stati pianificati, è possibile ottenere ulteriori informazioni sui pod keepalived:

Ottieni i pod keepalived.
```
oc get pods -n ibm-system
```

Nell'output, cerca i pod ibm-cloud-provider-ip che hanno lo Status uguale a Pending. Esempio:

ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t     0/1       Pending   0          2m        <none>          <none>
ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-8ptvg     0/1       Pending   0          2m        <none>          <none>

Descrivi ogni pod keepalived e cerca la sezione Events. Risolvi eventuali messaggi di errore o di avvertenza elencati.
```
oc describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```
Dopo aver risolto il problema, verificare che il traffico raggiunga l'applicazione controllando gli endpoint del servizio di bilanciamento del carico.
```
oc get svc -o wide
```