În prezent rulez Kubernetes cu Calico v3.20.2 ca CNI. Am un caz foarte unic în care trebuie să trimit trafic UDP de la un anumit DaemonSet Pod către un server extern care va citi combinația sourceIP:sourcePort a antetelor IP și va trimite răspunsul prin setarea celor două ca câmpuri destIP:destPort. Deoarece diferite sesiuni UDP vor alege aleatoriu diferite porturi sursă randomizate (interval 1024-65535), iar răspunsul trebuie să fie echilibrat de încărcare prin MetalLB, ar trebui să configurez un ascultător UDP pe fiecare pod al DaemonSet, ascultând fiecare cerere de ieșire. portul sursă, precum și reconfigurați LB-ul astfel încât să asculte pe acel port și să distribuie traficul.Acest lucru este evident nescalabil și, de asemenea, nu este performant, având în vedere latența unor astfel de configurații care durează mai mult decât trebuie returnat răspunsul, precum și potențialele nepotriviri ale reconfigărilor LB paralele.
Prin urmare, aș deschide mai degrabă un singur ascultător per Pod pe un anumit port (de exemplu, 20000) și SNAT tot traficul de ieșire de la fiecare Pod, astfel încât portul sursă odată ce fiecare datagramă UDP părăsește nodul să fie 20000. Serverul extern ar trimite răspunsul la acest port de destinație și răspunsul ar ajunge în cele din urmă la unul dintre ascultătorii UDP de pe unul dintre podurile DaemonSet. Am încercat asta prin implementare
sudo iptables -t nat -I POSTROUTING 1 -d <EXT-SERVER-IP>/32 -p udp --dport <EXT-SERVER-PORT> -j SNAT --to-source <WORKER-NODE-IP>:20000
Când încerc să implementez acest lucru în IPtables, Calico rescrie întotdeauna modificările pe care le fac și își impune propria configurație, ceea ce duce la porturile sursei aleatorii să părăsească din nou nodul. Pe de altă parte, când setez indicatorul natOutgoing la false și încerc să-mi stabilesc propriile reguli, doar o singură datagramă UDP părăsește nodul cu modificarea corectă a SNAT înainte ca toate celelalte datagrame să fie blocate și nu las niciodată nodul lucrător la all (după cum este demonstrat de serverul extern, precum și de tcpdump pe nodul lucrător)
Remedierea oricăreia dintre aceste cazuri ar rezolva problema generală și orice sugestie este apreciată!
