Ang VPN sidecar ay kailangan ng panuntunan sa pagsisimula at panuntunan sa pagpalya
Ang pagsisimula ng tunnel bago ang app ay tumutugon sa isang karera. Magpasya nang hiwalay kung ano ang maaaring ipadala ng app bago ang kahandaan, habang may pagpalya ng tunnel at pagkatapos ng restart.
Nagsisimula ang isang pod ng tunnel container bago ang application at nagtatagumpay ang mga unang kahilingan, at ito mismo ang kaso na nagtatago ng problema. Ang pagkakasunod-sunod ay nag-aayos ng isang karera at walang sinasabi tungkol sa trapikong sinisimulan ng application apat na oras mamaya, pagkatapos pumalya ang tunnel. Dalawang hiwalay na desisyon ito. Karaniwang isa lamang ang dinidisenyo.
Ang pagkakasunod-sunod ay humaharang lamang sa unang kahilingan
Sinusuportahan ng Kubernetes ang lifecycle ng sidecar na binuo mula sa mga restartable init container. Sa modelong iyon, ang startup probe ay maaaring magpigil sa susunod na hakbang ng initialization hanggang mag-ulat ang tunnel na handa na. Tunay na pagpapabuti ito, at sulit gamitin nang sadya sa halip na magdagdag ng sleep sa entrypoint script. Ang gate ay kasintaas lamang ng kondisyong sinusuri nito.
Sa labas ng modelong iyon, ang semantika ng pagkakasunod-sunod ay pag-aari ng runtime o sistema ng dependency na ginagamit mo, at hindi kailangang magtugma. Ang deployment na kinopya mula sa ibang platform ay maaaring magmukhang naghihintay sa tunnel dahil nagkataong mabagal magsimula ang application. Hindi ito ang parehong garantiya, at pumapalya ito sa ilalim ng karga.
Sabihin kung ano ang inoobserbahan ng gate: may proseso, may interface, natapos ang isang handshake. Bawat isa sa mga ito ay mas mahinang pahayag kaysa sa “gumagana ang landas ng data patungo sa mga destinasyong kailangan ng pod na ito”.
Ipilit ang landas ng data sa halip na ipagpalagay ito
Ang probe ay pagsusuri sa isang sandali at ang firewall ay katangiang umiiral sa pagitan ng mga sandali. Kung ang pangangailangan ay hindi kailanman lalabas ang trapiko ng application sa labas ng tunnel, dapat itong ipahayag sa shared network namespace bilang panuntunang tanggapin-o-itapon. Hindi kayang dalhin ng pagkakasunod-sunod ng pagsisimula ng container ang pangangailangang iyon. Panuntunan lamang ang makakaya.
Ang mga container sa isang pod ay nagbabahagi ng namespace na iyon, kaya ang punto ng pagpapatupad ay ang namespace mismo. Anuman ang isulat mo, dapat nitong iwanang magagamit ang sariling panlabas na koneksyon ng tunnel, dahil ang pagharang dito upang protektahan ang application ay pumuputol sa landas na kailangan ng application.
Magpasya nang malinaw sa patakaran ng pagpalya: dapat bang ganap na huminto ang trapiko ng application kapag hindi malusog ang tunnel, o magpatuloy at markahan bilang hindi protektado? Pareho ay may katwiran, at wala sa kanila ang nakukuha sa pamamagitan ng pagsisimula ng mga container sa isang partikular na pagkakasunod-sunod.
Subukan ang trapikong hindi mo binanggit
Kumuha ng bagong kahilingan habang may kontroladong pagpalya ng tunnel at tingnan kung lumalabas ito. Pagkatapos ulitin ang pagsusuri para sa mga landas na hindi kailanman hinahawakan ng pagsubok sa exit address: paglutas ng DNS sa loob ng cluster, mga destinasyong IPv6, at mga serbisyong naaabot sa pamamagitan ng mga panloob na address ng cluster sa halip na pampublikong internet. Ito ang mga landas na tahimik na patuloy na gumagana pagkatapos mamatay ang tunnel.
Pinatutunayan ng pahina ng exit address na ang isang kahilingan ay pumunta kung saan mo inaasahan sa sandaling iyon. Hindi nito maaaring imbentaryuhin ang iba pang mga landas, at ang agwat sa pagitan ng iyong sinubukan at ng naaabot ng pod ay doon nakatira ang mga kawili-wiling pagpalya.
Ulitin ang pagsubok pagkatapos ng restart ng sidecar at hindi lamang pagkatapos ng malinis na pagsisimula. Ang na-restart na tunnel container ay maaaring mag-iwan sa namespace ng mga ruta at patakaran sa isang intermediate na kalagayan.
Isulat ang talaan ng deployment
Tatlong katotohanan ang nabibilang sa mga tala ng deployment: ang pagsubok sa kahandaan at kung ano ang inoobserbahan nito, ang aksyon sa pagbawi kapag pumalya ang pagsubok na iyon, at ang panuntunan ng pagpapatupad na namamahala sa egress. Ang dokumentasyon ng sidecar container ay sumasaklaw sa mekanika ng lifecycle at iniiwan sa iyo ang desisyong iyon sa patakaran. Tama ang paghahating iyon, at iyon din ang dahilan kung bakit karaniwang nawawala ang patakaran.
Ang health check na napagkamalang proteksyon ay ang pinakamahal na uri ng berdeng indicator, dahil pinipigilan nito ang mga tao na magtanong. Ang tumpak na pagpangalan dito sa dokumentasyon ay nagkakahalaga ng isang pangungusap at pumipigil doon.
Sa huli, subukan ang landas ng pagbawi nang isang beses habang tumatakbo ang application. Ang disenyong nangangailangan ng muling paglikha ng pod upang maibalik ang egress ay isang desisyon, at dapat itong isang desisyong ginawa mo, hindi isang natuklasan mo.