VPN sidecar batek abiarazte-araua eta hutsegite-araua behar ditu

Pod batek tunelaren edukiontzia abiarazten du aplikazioaren aurretik eta lehen eskaerek arrakasta dute, eta horixe da arazoa ezkutatzen duen kasua. Ordenamenduak lasterketa bat konpontzen du eta ez du ezer esaten aplikazioak lau ordu geroago hasten duen trafikoaz, tunelak huts egin ondoren. Bi erabaki bereizi dira. Normalean horietako bat baino ez da diseinatzen.

Ordenamenduak lehen eskaera bakarrik kontrolatzen du

Kubernetesek berrabiaraz daitezkeen init edukiontziekin eraikitako sidecar bizi-zikloa onartzen du. Eredu horretan, abiarazte-proba batek hurrengo hasieratze-pausoa atxiki dezake tunelak prest dagoela jakinarazi arte. Benetako hobekuntza da, eta nahita erabili behar da, sarrera-puntuko script bati sleep gehitzen zaionaren ordez. Atea probatzen duen baldintza bezain ona da soilik.

Eredu horretatik kanpo, ordenamenduaren semantika erabiltzen ari zaren runtime edo mendekotasun-sistemari dagokio, eta ez dute zertan bat etorri. Beste plataforma batetik kopiatutako inplementazio bat tunelaren zain egongo balitz bezala ager daiteke, aplikazioa kasualitatez motel abiarazten delako. Ez da berme bera, eta kargapean huts egiten du.

Esan zer behatzen duen ateak: prozesu bat dago, interfaze bat dago, handshake bat osatu da. Horietako bakoitza “pod honek behar dituen helmuguetarako datu-bideak funtzionatzen du” baino baieztapen ahulagoa da.

Behartu datu-bidea, ez suposatu

Proba une bateko egiaztapena da eta suebakia unteen artean balio duen propietatea da. Baldintza aplikazioaren trafikoak inoiz tunelatik kanpora irten ez dadila bada, sare-namespace partekatuan adierazi behar da onartu edo baztertu arau gisa. Eduiontzien abiarazte-ordena ezin da baldintza hori eraman. Arau batek bakarrik.

Pod bereko edukiontziek namespace hori partekatzen dute, beraz betearazte-puntua namespace bera da. Idazten duzuna idazten duzula, tunelaren beraren kanpoko konexioa erabilgarri utzi behar du, aplikazioa babesteko blokeatzeak aplikazioak behar duen bidea mozten baitu.

Erabaki hutsegite-politika espresuki: aplikazioaren trafikoak erabat gelditu behar du tunela osasuntsu ez dagoenean, edo jarraitu eta babesgabe gisa markatu? Biak defendagarriak dira, eta bat ere ez da edukiontziak ordena jakin batean abiaraziz lortzen duzuna.

Probatu aipatu ez duzun trafikoa

Egin eskaera berri bat tunelaren hutsegite kontrolatu batean eta ikusi irteten den. Gero errepikatu egiaztapena irteera-helbide probak inoiz ukitzen ez dituen bideetarako: DNS ebazpena klusterraren barruan, IPv6 helmugak eta klusterraren barneko helbideen bidez, internet publikoaren ordez, lortzen diren zerbitzuak. Horiek dira tunela hil ondoren isilean lanean jarraitzen duten bideak.

Irteera-helbidearen orrialde batek eskaera bat une hartan espero zenuen lekura joan zela frogatzen du. Ezin ditu beste bideak inbentariatu, eta probatu duzunaren eta podak har dezakeenaren arteko aldea da hutsegite interesgarriak bizi diren tokia.

Errepikatu proba sidecar bat berrabiarazi ondoren, eta ez soilik abiarazte garbi baten ondoren. Berrabiarazitako tunel-edukiontzi batek namespacea ibilbide eta politikarekin tarteko egoeran utz dezake.

Idatzi inplementazio-erregistroa

Hiru gertaera dagozkio inplementazio-oharrei: prestasun-proba eta haren behaketa, proba horrek huts egiten duenean berreskuratzeko ekintza, eta irteera gobernatzen duen betearazte-araua. Sidecar edukiontzien dokumentazioak bizi-zikloaren mekanika estaltzen du eta politika-erabaki hori zure esku uzten du. Zatiketa hori zuzena da, eta horregatik ere izaten da politika normalean falta.

Babespen intzidentzia duen osasun-egiaztapen bat berde adierazle motarik garestiena da, jendea galderak egitea eragozten duelako. Dokumentazioan zehazki izendatzeak esaldi bat kostatzen du eta hori saihesten du.

Azkenean, probatu berreskuratze-bidea behin aplikazioa martxan dagoela. Irteera berrezartzeko poda birsortzea eskatzen duen diseinua erabaki bat da, eta zuk hartutako erabakia izan behar luke, aurkitu duzuna izan beharrean.