VPN bawat Pod sa Kubernetes laban sa egress gateway: kanino ang tunnel?

Nag-deploy ka ng Pod na pinangalanang vpn-gateway, itinutok ang test client sa address nito at pinapanood ang mga packet na nawawala. Wala namang mali sa manifest at walang reklamo ang kubelet. Ang dahilan ay istruktural at hindi configuration: binibigyan ng Kubernetes ang bawat Pod ng sarili nitong namespace ng network, kaya ang pangalan, label o pinagsasaluhang API namespace ay walang binabago sa kung saan napupunta ang mga packet. Kaya ang desisyon kung paano lumalabas ang trapik ng VPN sa cluster ay nagsisimula sa tanong tungkol sa pagmamay-ari, hindi sa mga imahe ng container.

Dalawang mekanismo ang sumasaklaw sa karamihan ng tunay na deployment, at hindi sila mapagpapalit. Inilalagay ng isa ang tunnel sa loob ng sariling namespace ng network ng workload. Hinihiling ng isa pa sa CNI na patnubayan ang piling trapik sa isang itinalagang node ng gateway. Iba ang paraan ng pagpalya nila, iba ang paraan ng pag-scale at iba’t ibang team ang pinaglilingkuran, kaya ang tanong sa container ay karaniwang gumagawa ng mga debate na hindi natatapos.

Ang hangganan ng Pod ay namespace, hindi jump host

Ang namespace ng network ng Linux ay nagmamay-ari ng mga interface, address, ruta at tuntunin ng firewall nito, at bawat Pod ay tumatanggap ng isa. Sumasama ang mga container sa loob ng Pod na iyon, at iyon ang eksaktong dahilan kung bakit kayang isulat muli ng isang helper container ang mga rutang sinusundan ng aplikasyon. Ang katabing Pod ay may stack na kamukha ngunit ganap na hiwalay. Walang pinagsasaluhang talahanayan na mamamana ng gateway Pod, at walang palihim na paglipat ng trapik mula sa isang namespace patungo sa isa pa.

Iyon din ang dahilan kung bakit gumagana lamang ang pattern na gateway-Pod kapag may isang bagay sa upstream na talagang nagpapadala ng packet dito: isang Service, isang static na ruta sa node o patakaran sa paggabay sa CNI. Ang address lamang ay walang naaakit.

Ano ang binibili ng tunnel bawat Pod, at magkano ito

Ang tunnel na tumatakbo sa namespace ng workload ay nagbibigay sa workload na iyon ng sarili nitong pagkakakilanlan ng kliyente, na hinihiling ng maraming serbisyo ng remote access bago pahintulutan o bilangin ang isang session. Nananatiling lokal din ang saklaw ng pinsala: ang sirang tunnel ay nagpapatumba ng isang Deployment sa halip na ang pinagsasaluhang landas na ginagamit ng lahat. Nakasalalay sa implementasyon kung paano ito tumatakbo, at dito nagkakamali ang mga tao.

Ang setup na kailangan lamang ng kernel state ay maaaring matapos sa isang init container at lumabas. Ang userspace daemon na kailangang manatiling buhay sa buong buhay ng Pod ay nangangailangan ng restartable init container form na ipinakilala bilang native sidecar sa Kubernetes 1.29, at ang pagkakaibang iyon ay nagmumula sa implementasyon ng tunnel hindi sa panlasa. Ang halaga ng modelong ito ay duplikasyon: bawat replica ay nagpapatunay, tumatanggap ng sariling address ng tunnel at gumagamit ng isang puwang ng remote session, kaya ang kaganapan ng autoscaling ay nagiging kaganapan ng kapasidad sa kabilang dulo ng link. Ang pagkopya ng isang kredensyal sa lahat ng replica ay hindi nag-aalis ng halagang iyon, inaalis nito ang bakas ng audit. Ang mga kakayahan ay karapat-dapat sa parehong pagsusuri, dahil ang tunnel na gustong magkaroon ng NET_ADMIN sa sariling namespace ay walang dahilan para mamanahin ang awtoridad sa buong host mula sa halimbawang may privileged: true.

Kapag ang CNI ang nagmamay-ari ng labasan

Kung sinusuportahan ito ng CNI, pinipili ng egress gateway ang trapik ayon sa workload at saklaw ng destinasyon, pagkatapos ay ipinapadala ito sa mga piling node sa ilalim ng isang mahuhulaang address ng pinagmulan. Ang bersyon ng Cilium ang karaniwang sanggunian, at malinaw sa dokumentasyon nito na ang tampok ay nangangailangan ng partikular na configuration ng Cilium bukod sa mga node ng gateway na may tamang interface at address. Binabanggit din nito ang panimulang panahon pagkatapos malikha ang Pod kung kailan hindi pa ipinatutupad ang paggabay, at ito ay input ng disenyo hindi isang talababa.

Basahin ang pagkaantala na iyon laban sa sarili mong pangako. Kung ang tuntunin ay walang trapik na maaaring lumabas sa ibang landas, ang bagong Pod na nagpapadala sa pagitan ay nilabag na ito, kaya kailangan ng startup sequence ang sarili nitong sagot: pigilan ang aplikasyon hanggang maipatupad ang patakaran, o tanggapin ang window at idokumento ito.

Panatilihing makitid ang pag-aangkin. Pinipili at isinasalin ng egress gateway ang isang landas. Hindi nito tinatapos ang isang VPN, at hindi nito ginagawang kliyente ng iyong remote network ang cluster nang walang sinusuportahang koneksyon sa likod nito.

Tahimik na binabago ng salin ang nakikita ng malayong panig

Sa sandaling isulat muli ng gateway ang pinagmulan, wala na ang mga address bawat Pod, kaya ang allowlist na nakabatay sa pagkakakilanlan ay nagiging listahang nakabatay sa isang pinagsasaluhang address. Ito ay palitan at hindi depekto: mas kaunting tuntunin na dapat alagaan, mas magaspang na pag-attribute kapag may mali ang kilos.

Ang authentication sa antas ng aplikasyon at request logging ay dapat magdala ng hindi na iniuulat ng network. Ituring ang kapasidad at pagpapalit ng gateway bilang pinagsasaluhang imprastruktura, dahil ang pag-restart ng isang node ay naghahati na ngayon sa bawat workload sa likod nito, at suriin ang pabalik na landas nang maaga: kailangang malaman ng malayong dulo kung paano maabot ang isinaling address, karaniwang sa pamamagitan ng ruta o NAT na dapat pagmamay-arian ng tao, hindi ng manifest. Kasama rin dito ang pagpaplano ng address, dahil ang magkakapatong na saklaw ng cluster at malayo ay sumisira sa alinman sa mga modelo at ang pag-ampon ng IPv6 ay hindi excuse para sa magkasalungat na plano.

Magpasya ayon sa pagmamay-ari, pagkatapos ay subukan ang ipinangakong pagpalya

Piliin ang tunnel bawat Pod kapag ang malayong serbisyo ay nagpapatunay ng indibidwal na workload, kapag kakaunting Deployment lamang ang nangangailangan ng link, at kapag ang pagpalya ay dapat manatiling lokal. Piliin ang gateway kapag pagmamay-ari na ng isang network team ang landas, kapag maraming workload ang nagbabahagi ng isang destinasyon, at kapag ang stable na address ng pinagmulan ang buong layunin ng pagsasanay.

Anuman ang piliin, i-verify ang property na ibinenta mo at hindi ang steady state. Gumawa ng Pod, hayaang magpadala agad at panoorin ang mga unang segundo kung ang pangako ay walang tumatakas sa tunnel. I-scale sa limang replica at bilangin ang mga session na iniuulat ng malayong dulo kung ang pangako ay pagkakakilanlan bawat workload. Ang dalawang pagsusuring iyon ay naglalantad ng mga limitasyon ng mekanismo nang mas mabilis kaysa sa pagsusuri ng manifest, at sinasabi nila kung aling team ang may-ari ng susunod na insidente.