Pod, node o cluster: ano ba talaga ang irinaruta muli ng isang sidecar na VPN

Ang isang sidecar na VPN sa loob ng Pod sa Kubernetes ay mukhang VPN sa antas ng host na may mas magandang asal, at nagtatapos ang pagkakatulad sa hangganan ng namespace. Ang mga container sa isang Pod ay nagbabahagi ng network namespace, kasama ang espasyo ng address at port, kaya ang sidecar na naglalagay ng ruta at patakaran ay talagang nagbabago kung saan napupunta ang mga packet ng aplikasyon. Wala itong binabago para sa ibang Pod sa node, at hindi nito ginagalaw ang sariling stack ng node maliban kung i-configure mo ito nang ganoon. Ang tamang pag-unawa sa hanggang na ito ang nagtatakda kung ano ang maaari mong i-deploy at kung ano ang dapat mong subukan. Sinusundan ng mga seksyon sa ibaba iyon mula sa namespace pakanlabas.

Ibinahaging namespace, ibinahaging kahihinatnan

Dalawang container sa isang Pod ay nag-uusap sa loopback at nakikita ang parehong mga interface, at iyon ang dahilan kung bakit gumagana ang sidecar pattern: hindi kailangang malaman ng aplikasyon na may tunnel, dahil ang rutang nireresolba nito ay na-install sa namespace na ginagamit nito. Ang parehong katangian ay nangangahulugan na ang mga pagkakamali ng sidecar ay mga pagkakamali ng aplikasyon. Ang rutang sumasalo ng sobra, o ang pagbabago ng DNS na tumuturo sa resolver sa loob ng tunnel, ay nalalapat agad sa bawat proseso sa Pod na iyon. Sa ibinahaging namespace walang routing kada container, kaya hindi maaaring limitahan ang sidecar sa isang proseso.

Ito ang mekanismong dapat tandaan sa pagsusuri: ang saklaw ng epekto ay ang Pod, hindi ang node at hindi ang cluster.

Saan hindi umaabot ang sidecar

Pinapanatili ng ibang Pod ang kanilang sariling namespace at sariling routing, kaya ang workload na nangangailangan ng parehong labasan ay nangangailangan ng parehong sidecar o, sa halip, disenyo sa antas ng node. Ang trapiko ng node ay nasa labas din ng namespace ng Pod, at ang mga Pod na may host network ay sadyang umaayaw nang buo sa paghihiwalay na ito. Kung patakbuhin mo ang sidecar gamit ang host network para maabot ang isang bagay na maginhawa, pinalawak mo ang saklaw mula sa isang Pod hanggang sa buong node at dapat mong sabihin iyon nang malakas.

Ang trapiko papunta sa mga serbisyo ng cluster ang isa pang karaniwang sorpresa. Ang malawak na default na ruta sa loob ng Pod ay maaaring sumalo ng mga kahilingang para sa API server o sa isang serbisyong ClusterIP, at pagkatapos ay nabibigo ang mga ito sa paraang mukhang sira ang tunnel.

Plano ng ruta: hanay ng Pod, serbisyo, node at VPN

Isulat ang apat na hanay at tingnan ang pag-overlap bago mag-deploy ng kahit ano: CIDR ng Pod, CIDR ng serbisyo, mga address ng node at ang mga destinasyon sa likod ng VPN. Hindi bihira ang pag-overlap ng mga pribadong hanay ng VPN at ng sariling espasyo ng cluster, at mali ang default na ruta para doon. Ang plano ng ruta ay kabilang sa parehong repository ng manifest, dahil maaaring magbigay ang susunod na cluster ng ganap na ibang hanay ng Pod at serbisyo.

Ang DNS ay bahagi ng plano at hindi hiwalay na alalahanin. Ang sidecar na nagsusulat muli ng configuration ng resolver ay maaaring makasira ng pagtuklas ng serbisyo sa loob ng cluster habang perpektong gumagana ang panlabas na paghahanap.

Ang pagsisimula at pagpalya ay tahasang estado

Ang tumatakbong proseso ng sidecar ay hindi patakaran sa labasan. Magpasya kung anong trapiko ang maaaring dumaloy bago maging handa ang tunnel at ano ang mangyayari kung mamatay ito pagkatapos, pagkatapos ay ipatupad ang pasyang iyon: isang probe na humaharang sa container ng aplikasyon, isang patakaran sa network na tumatanggi bilang default, o pareho. Kung wala ang isa sa mga ito, nagsisimula ang aplikasyon, nagreresolba at nagpapadala ng trapiko sa labas ng normal na landas ng node habang kumokonekta pa lang ang tunnel.

Ang puwang na iyon ay maikli sa malusog na cluster at permanente sa sira, at iyon ang eksaktong katangiang pinipili ng umaatake o ng aksidenteng pagtagas ng data.

Ipares ang pagkakasunod-sunod sa isang pagsubok ng pagpalya. Patayin ang sidecar at tiyakin na nawawala ng aplikasyon ang inilaan nitong labasan sa halip na tahimik na umurong.

Mga kakayahan, patakaran at pagsubok mula sa container ng app

Ang pagbibigay ng mga kakayahang kailangan para gumawa ng mga interface at baguhin ang ruta ay desisyon sa pribilehiyo, at ang pribilehiyong angkop sa isang nakahiwalay na Pod ay hindi awtomatikong angkop sa stack ng node. Gamitin ang mga mekanismong suportado ng cluster para sa patakaran ng network at seguridad, at huwag ipagpalagay na ang bawat pagpapatupad ng CNI o patakaran ay pantay na tinatrato ang interface ng VPN; lumilitaw ang mga pagkakaiba sa mismong mga kaso ng pagpalya na mahalaga sa iyo.

Subukan mula sa tunay na container ng aplikasyon, na may mga bagong kahilingan sa pribadong destinasyon, serbisyo ng cluster at pampublikong internet. Pinatutunayan ng pagsubok mula sa sidecar na gumagana ang tunnel, hindi na naaabot ng aplikasyon ang kailangan nito.

Idokumento ang mga palagay sa network ng cluster sa tabi ng configuration ng VPN. Ang paglipat ng workload sa ibang cluster ay magiging pagsasanay sa pagsuri ng plano ng ruta sa halip na pagbabago ng image na tahimik na humihinto sa paggana.