IP ya mteja wa VPN ndani ya Kubernetes: kuihifadhi au kufanya SNAT?

Mahali fulani kati ya handaki na backend, anwani ya mteja ama inaendelea kuishi au inabadilishwa, na matokeo yote mawili yanaweza kuteteleka. Uchaguzi ni wa mmiliki wa huduma inayopokea, si wa aliyeweka CNI. Wakati idhini kwa kila mteja, kwota au rekodi za ukaguzi ni muhimu, anwani lazima idumu kila hatua. Wakati ugawaji wa pamoja unakubalika, NAT ya chanzo huondoa tatizo la uelekezaji ambalo vinginevyo ungedumisha milele.

Anwani ya mteja inapotea wapi kwa kweli

Pakiti ya mteja wa mbali hufika kwenye pod ya VPN ikiwa na chanzo cha ndani ndani ya wigo wa handaki, tuseme 10.90.0.42. Wakati pod inapeleka pakiti hiyo kuelekea ClusterIP au IP ya pod, mifumo mitatu tofauti inaweza kuandika upya chanzo. Kanuni ya masquerade ya CNI kwenye nodi inashughulikia trafiki ambayo pod inatuma nje ya CIDR ya kundi. Ingizo la conntrack la kube-proxy kwenye nodi lengwa linashughulikia hatua yenyewe ya Service. Proksi inayomaliza muunganisho haipeleki pakiti kabisa, kwa hivyo chanzo unachokiona mwishoni ni cha proksi.

Kila kimoja kinaishi katika tabaka tofauti, ndiyo sababu sehemu moja ya Service karibu kamwe haitengenezi njia nzima.

externalTrafficPolicy kwenye Service ya umma ya VPN huamua tu kinachotokea kwa muunganisho wa nje: Local huweka anwani ya mbali kwenye nodi iliyoipokea, wakati Cluster huruhusu kube-proxy kukabidhi pakiti kwa nodi nyingine na kufanya masquerade huko. Mpangilio huo unasimamia listener ambayo wateja wako wanaunganisha nayo. Haisemi chochote kuhusu pakiti iliyofumbuliwa ambayo mchakato wako wa VPN unaelekeza kwenye kundi baadaye.

Masharti matatu yanayomaliza mjadala

Ninauza maswali yale yale matatu kwa mpangilio ule ule kila mara jambo hili linapotokea, kwa sababu la kwanza kwa kawaida humaliza majadiliano. Jibu kwa ajili ya mzigo wa kazi mahususi na si kwa kundi zima. Makundi mawili ndani ya kampuni moja yanaweza kufikia majibu tofauti na yote mawili kuwa sahihi.

Ikiwa backend inajibu ndiyo kwa swali la kwanza na hapana kwa la pili, una kazi ya mtandao ya kufanya badala ya manifest ya kuhariri. Ikiwa mstari wa tatu unasema proksi, anwani haingekuwa imeendelea kuishi, na kujifanya vinginevyo hugharimu wiki moja ya kunasa pakiti.

Preserve mode inahitaji nini kutoka kwa mtandao

Kuhifadhi chanzo kunamaanisha nodi lengwa lazima irudishe trafiki kwenye 10.90.0.42 kupitia lango la VPN linalofanya kazi. Bwawa la VPN si CIDR ya kundi, kwa hivyo hakuna CNI inayoelekeza kwa ajili yako kwa chaguo-msingi. Unaongeza njia wewe mwenyewe, kisha unahakikisha kwamba kituo cha mwisho cha lango inachoelekea kinastahimili upangaji upya.

ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2

Hatua inayofuata ni anwani ya pod, na anwani za pod huhamahama. Elekeza njia kwenye VIP ya Service au anwani ya nodi inayobaki mahali pake, au kubali kwamba utafukuza lango baada ya kila kufukuzwa. Uchujaji wa njia ya kurudi ni mtego mwingine: hali kali hutupa pakiti ambazo njia yake ya kurudi hailingani na kiolesura zilikotokea, na hiyo ndiyo sura kamili ya mtiririko wa VPN uliohifadhiwa.

Uthibitishaji legevu mara nyingi ni tofauti kati ya njia ya kurudi inayofanya kazi na majibu yanayotoweka baada ya kuondoka backend. Kanuni za masquerade kwenye nodi ya VPN pia lazima ziondoe wigo wa handaki, vinginevyo pakiti iliyopelekwa inatoka na anwani ya pod, bila kujali njia uliyojenga. Ni bora kueleza uondoaji huo katika usanidi wa CNI yenyewe badala ya kuhariri iptables kwa mkono, kwa sababu wakala huandika upya minyororo yake anapowasha upya na kanuni yako iliyoandikwa kwa mkono hudumu hadi sasisho linalofuata.

NetworkPolicy ni udhibiti wa ufikiaji, si uelekezaji. Kukaza sera hakutarejesha anwani ambayo masquerade tayari imeibadilisha.

SNAT inagharimu nini, na jinsi ya kuiandika

NAT ya chanzo kuelekea kundini ni muundo wa bei nafuu, na si kosa. Backend inaona anwani ya pod au nodi ya VPN, kumbukumbu zinapatana, na hakuna njia ya kurudi inayohitajika kuwepo. Unachopoteza ni uwezo wa kutofautisha wateja wawili katika tabaka la mtandao, kwa hivyo kwota, marufuku na alama za ukaguzi lazima zitoke mahali pengine.

Kwa kawaida mahali pengine hapo ni programu: tokeni ya kikao, kichwa kilichosainiwa, au mstari wa itifaki ya PROXY ulioandikwa na proksi unayodhibiti. Hizi humpa mpokeaji utambulisho ambao anaweza kuutumaini tu wakati proksi iko kwenye njia na kichwa hakiwezi kuwekwa kutoka upande wa mteja. Kuwa wazi katika runbook kuhusu ipi inatumika, kwa sababu mhandisi anayefuata atadhani anwani iliyo kwenye kumbukumbu ni mteja. Si hivyo, na tukio moja linatosha kufanya dhana hiyo iwe ghali.

Kubadilishana kunabaki kuwa mwaminifu mradi tu kumeandikwa.

Ukaguzi unaotenganisha njia inayofanya kazi na iliyo na bahati

Jaribu kwa muunganisho mpya badala ya uliohifadhiwa kwenye akiba, na jaribu pande zote mbili. Hitilafu kadhaa zinaonekana kuwa za vipindi kwa sababu tu mitiririko mipya inachukua njia iliyoandikwa upya.

Nasa tuple katika maeneo matatu wakati wa ombi moja lililoidhinishwa: mara moja baada ya kufumbua, kwenye kiolesura cha kutoka cha pod ya VPN, na kwenye backend. Ikiwa chanzo kinabadilika kati ya kunasa kwa pili na kwa tatu, sababu iko chini ya pod. Ikiwa kinabadilika kabla ya la pili, pod yenyewe inatafsiri.

Kisha futa pod ya VPN na urudie jaribio wakati inapangwa upya. Njia iliyohifadhiwa inayovunjika wakati wa kufukuzwa haijakamilika, na vilevile kanuni ya NAT iliyobandikwa kwenye anwani ambayo haipo tena. Mwisho, tuma ombi moja kutoka chanzo unachotarajia kukataliwa na uthibitishe kwamba kukataliwa kunatoka kwenye sera na si kwenye njia inayokosekana.