Bakit hindi maabot ng mga pod ng GKE ang mga lokal na host sa pamamagitan ng VPN

Gumagana ang ping mula sa node at nabigo mula sa pod, at walang dumarating sa lokal na panig. Maayos ang tunnel at ruta; hindi maayos ang source address sa kable. Ang pagkakaiba ng dalawang kaso ay kung ano ang ipinapahayag ng packet na siya kapag umaalis sa cluster, at may opinyon ang GKE tungkol dito. Ang mekanismo ay isang listahan ng masquerade exception, at isang utos lang ang kailangan para basahin ito.

Basahin ang umiiral na listahan bago magbago ng kahit ano

Nagbibigay ang GKE ng agent na nagpapasya, bawat saklaw ng destinasyon, kung ang trapik ng pod ay muling isusulat sa address ng node sa paglabas. Pinangalanan ng ipinagkaloob na configuration nito ang tatlong bloke ng RFC1918, 10.0.0.0/8, 172.16.0.0/12 at 192.168.0.0/16, bilang mga destinasyong hindi kasama. Kaya ang anumang ipadala mo mula sa pod patungo sa lokal na host na 10.x ay lumalabas sa node na nakakabit pa rin ang sariling address ng pod. Ang trapik ng node mismo ay hindi muling isinusulat, at iyon mismo ang dahilan kung bakit gumagana ang ping nito.

Basahin ang nilalayong configuration at ang mga naka-install na patakaran, dahil maaaring hindi sila magkasundo. Ipinapakita ng kubectl -n kube-system get configmap ip-masq-agent -o yaml ang sinabi sa agent, at ipinapakita ng kubectl -n kube-system get pods -l k8s-app=ip-masq-agent kung may tumatakbo para ipatupad ito. Sa isang node, ipinapakita ng iptables-save | grep -i masq ang mga patakarang talagang umiiral sa kernel. Kapag ang ConfigMap ay nagsabi ng isa at ang mga patakaran ng iba, ang pinaghihinalaan ay ang agent, hindi ang network.

Kumpirmahin ang source address sa pamamagitan ng paghuli

Gumawa ng paghuli bago ka magpalit ng listahan. Ang filter sa nag-iisang destinasyon ay nagpapanatili ng output na nababasa: tcpdump -ni any host 10.20.30.40.

Ihambing iyon sa iniuulat ng kabilang panig. Ang paghuli sa lokal na panig na nagpapakita ng address ng pod at walang sagot ay nagsasara ng bilog: ipinapaliwanag ng listahan ng exception ang kawalan ng simetriya nang walang anumang sira ng tunnel. Sapat na ang dalawang obserbasyon ng isang source address para tigilan ang hula tungkol sa CNI.

Paliitin ang exception hanggang sa CIDR ng pod

Ang sinusuportahang pag-aayos ay nagpapaliit ng exception sa halip na alisin ito: panatilihing exempted ang CIDR ng pod at bitawan ang natitirang bahagi ng espasyong 10.x. Ang listahang iyon ay nasa ConfigMap ng agent sa ilalim ng nonMasqueradeCIDRs, at ang pagbabago nito ay isang edit na sinusundan ng rollout. Palitan ang malawak na entry ng tunay na saklaw ng pod ng cluster, panatilihin ang iba pang pribadong bloke kung kailangan pa ito ng trapik sa loob ng cluster, at iwanan ang resyncInterval maliban kung may dahilan ka. Ipatupad ito, kumpirmahin na nag-restart ang mga pod ng agent, at kumpirmahin na nagbago ang mga patakaran ng kernel.

Ito ay pagbabago sa buong cluster na may tunay na saklaw ng epekto. Kapag naipatupad na, ang trapik na dating nagpapanatili ng source ng pod ay dumarating na ngayong muling isinulat sa node, kaya ang lahat ng umaasa sa mga address ng pod na iyon ay nakakakita ng ibang nagpadala. Ang mga biktima ay ang mga log, allowlist at lokal na patakaran ng firewall na nagbabanggit ng mga address ng pod, at tahimik silang nabibigo. Ipaalam ang pagbabago bilang pagbabago ng pag-uugali, hindi bilang pag-aayos.

Sa isang cluster na may maraming pool ng node, tingnan kung naka-iskedyul ang agent sa mga node kung saan talagang tumatakbo ang mga apektadong pod. Ang pool na walang DaemonSet ay nagpapanatili ng lumang patakaran nito, at walang makikita sa ConfigMap na magpapakita nito.

Ang alternatibo at ang halaga nito

Pinapanatili ng kabilang opsyon na buo ang mga address ng pod at tinuturuan ang ruta tungkol sa mga ito. Pumapasok ang CIDR ng pod sa mga tagapili ng trapik ng Cloud VPN, at kailangan ng lokal na panig ng rutang pabalik para dito upang malaman ng mga sagot kung saan pupunta. Pinapanatili nito ang pagkakakilanlan ng pod, na gusto ng ilang modelo ng seguridad, at pinalalawak nito ang saklaw ng routing at ang saklaw ng firewall na dapat tanggapin ng kabilang panig.

Ang kalakal ay nababasang kalinawan laban sa saklaw. Ginagawa ng pagsasalin na makita ng lokal na panig ang isang address bawat node, na madaling ilagay sa allowlist at itinatago kung aling pod ang nagpadala ng ano. Kung walang pagsasalin, nananatili ang address ng pod mula simula hanggang dulo, na mas mabuti para sa attribution at mas masama para sa bawat device sa ruta na kailangang matuto ng bagong saklaw. Wala sa mga opsyon ang depekto ng Docker o CNI; pareho silang desisyon sa routing na may operational na bill. Piliin ang kaya ng iyong team na bayaran, at isulat kung bakit.

I-verify at i-rollback

Patakbuhin muli ang parehong paghuli. Kung ang paghuli sa antas ng node ay nagpi-print pa rin ng address ng pod pagkatapos ng iyong edit, nangangahulugan itong hindi kailanman nagbago ang mga patakaran, anuman ang sabihin ng ConfigMap. Ang kable ang katotohanan; ang lahat ng iba ay hinuha.

Pagkatapos, tingnan ang kabaligtarang direksyon, dahil kalahati ng mga pagbabagong ito ay nabe-verify lamang pabalik. Kumpirmahin na umaabot ang sagot sa node o pod na nagpadala ng kahilingan, at kumpirmahin na natapos ang application sa halip na tumanggap lang ng SYN. Ang paghuling nagpapakita ng kahilingan na walang sagot ay problema sa routing sa kabilang panig, hindi problema sa masquerade sa panig na ito.

Ang rollback ay ang dating ConfigMap, ipinatupad sa parehong paraan, kasama ang parehong kumpirmasyon na nag-restart ang agent at nagbago ang mga patakaran. Itago ang source address bago at pagkatapos para sa isang kilalang kahilingan sa rekord ng pagbabago, dahil ang nag-iisang linyang iyon ang nagpapatunay na ginawa ng pagbabago ang sinabi mo. Idinodokumento ng gabay ng GKE sa IP masquerade agent ang mga default at ang mga field ng ConfigMap. Kung hindi nagbago ang source address pagkatapos ng rollout, hindi tumatakbo ang agent sa node na iyon at wala ring YAML edit ang makakapag-ayos nito.