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

Infrastrutture classiche

Il servizio conservazione dell'IP sorgente abilitata per un ALB di ingresso viene modificato da externalTrafficPolicy a 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 ALB Ingress, 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 di servizio Ingress ALB sono distribuiti sugli stessi nodi worker dei pod delle applicazioni. Tuttavia, in alcune situazioni, i pod dei servizi e i pod delle applicazioni potrebbero non essere pianificati sullo stesso nodo worker. 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, a seconda del tipo di taint 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 Ingress 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 Ingress 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 ALB e i pod 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:

Tazze dei nodi edge: Per garantire che i pod ALB e le applicazioni siano distribuiti su nodi edge contaminati, aggiungere regole di affinità dei nodi edge e tolleranze alla distribuzione delle applicazioni. I pod ALB Ingress 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 danneggiare quei nodi edge.

Se sono stati completati i passaggi precedenti, ma i pod keepalived non sono ancora stati pianificati, raccogliere ulteriori informazioni sui pod keepalived:

Ottieni i pod keepalived.
```
kubectl 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>

Descrivete ogni pod keepalived e rivedete la sezione Eventi. Risolvere tutti i messaggi di errore o di avvertimento elencati.
```
kubectl describe pod ibm-cloud-provider-ip-169-61-XX-XX-55967b5b8c-7zv9t -n ibm-system
```