Context:
Am întâlnit recent o problemă în care un pod kubernetes (exportator cutie neagră) va primi un răspuns gol ori de câte ori încearcă să apeleze o adresă URL de intrare a unui pod care se află în același nod ca el însuși. Acest lucru s-a reflectat ca o sondă care eșuează intermitent pe tabloul de bord.
Controlerul de intrare utilizat este ingress-nginx și se află în spatele unui AWS NLB.
Exemplu:
nodul 1: 192.168.20.2
nodul 2: 192.168.20.3
nodul 3: 192.166.20.4
blackbox-exporter (implementat în node1, cu clusterIP 10.244.2.21)
foo-pod (implementat în nodul 1, cu clusterIP 10.244.2.22)
foo-pod (implementat în nodul 2, cu clusterIP 10.244.2.23)
foo-pod (implementat în node3, cu clusterIP 10.244.2.24)
Jurnalele controlerului de intrare:
192.168.20.3 - - [21/Iun/2021:15:15:07 +0000] „GET /metrics HTTP/1.1” 200 29973 „-” „curl/7.47.0” 90 0.005 [foo-pod] [] 10.32 .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
192.168.20.4 - - [21/Iun/2021:15:16:00 +0000] „GET /metrics HTTP/1.1” 200 29973 „-” „curl/7.47.0” 90 0,005 [foo-pod] [] 10.32 .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
192.168.20.3 - - [21/Iun/2021:15:16:30 +0000] „GET /metrics HTTP/1.1” 200 29973 „-” „curl/7.47.0” 90 0.005 [foo-pod] [] 10.32 .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
Urmărirea jurnalelor controlerului de intrare a arătat că „răspunsul gol” (timeout după 5 secunde) apare numai atunci când podul care efectuează apelul URL de intrare este implementat în același nod cu podul țintă care ar trebui să răspundă la apelul respectiv.
Concluzia a fost făcută pe baza faptului că ori de câte ori a fost primit „răspunsul gol”, nu există niciodată un jurnal cu IP de origine care să se potrivească cu IP-ul nodului în care se află exportatorul cutie neagră, în acest caz ar trebui să fie nodul 1 192.168.20.2.
Bănuind că are legătură cu IP-ul sursă „incorectă” și, ca urmare, podul țintă nu știe cum să returneze un răspuns, am trecut la utilizarea AWS Classic L7 LB și problema a fost rezolvată.
Acum jurnalele au arătat că IP-ul sursă a fost înlocuit cu IP-ul actual al podului ClusterIP și toate apelurile de sondare de la exportatorul cutie neagră au succes.
10.244.2.21 - - [21/Iun/2021:15:15:07 +0000] „GET /metrics HTTP/1.1” 200 29973 „-” „curl/7.47.0” 90 0,005 [foo-pod] [] 10. .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
10.244.2.21 - - [21/Iun/2021:15:16:00 +0000] „GET /metrics HTTP/1.1” 200 29973 „-” „curl/7.47.0” 90 0,005 [foo-pod] [] 10. .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
10.244.2.21 - - [21/Iun/2021:15:16:30 +0000] „GET /metrics HTTP/1.1” 200 29973 „-” „curl/7.47.0” 90 0,005 [foo-pod] [] 10. .0.2:3000 30015 0,004 200 e39022b47e857cc48eb6a127a7b8ce24
Mai multe informatii:
Versiunea cluster: AWS EKS v1.19
Întrebare:
Rețelele Linux/kubernetes nu sunt puterea mea, așa că ceea ce aș dori să întreb este, ce se întâmplă exact aici?
De ce trecerea la utilizarea AWS Classic L7 load balancer rezolvă problema?
ar putea alte componente (kubernetes SAU linux) să afecteze și acest lucru?
