Një sidecar VPN kërkon një rregull nisjeje dhe një rregull dështimi

Një pod nis kontejnerin e tunelit para aplikacionit dhe kërkesat e para kanë sukses, dhe pikërisht ky është rasti që fsheh problemin. Rendi rregullon një garë dhe nuk thotë asgjë për trafikun që aplikacioni nis katër orë më vonë, pasi tuneli ka dështuar. Këto janë dy vendime të ndara. Zakonisht projektohet vetëm njëri prej tyre.

Rendi bllokon vetëm kërkesën e parë

Kubernetes mbështet një cikël jetësor sidecar të ndërtuar nga kontejnerë init të rinisur. Në atë model, një provë nisjeje mund të mbajë hapin e ardhshëm të inicializimit derisa tuneli të raportojë gatishmëri. Ky është një përmirësim i vërtetë, dhe ia vlen të përdoret me qëllim në vend të shtimit të një sleep në skriptin e pikës hyrëse. Porta është vetëm aq e mirë sa kushti që teston.

Jashtë atij modeli, semantika e rendit i takon atij runtime ose sistemi varësie që përdorni, dhe nuk duhet të përputhen. Një vendosje e kopjuar nga një platformë tjetër mund të duket se pret tunelin sepse aplikacioni fillon ngadalë rastësisht. Nuk është e njëjta garanci, dhe dështon nën ngarkesë.

Thoni çfarë vëzhgon porta: ekziston një proces, ekziston një ndërfaqe, një handshake përfundoi. Secila prej tyre është një pohim më i dobët sesa «rruga e të dhënave drejt destinacioneve që i nevojiten këtij pod funksionon».

Zbatoni rrugën e të dhënave në vend që ta supozoni

Një provë është një kontroll në një moment dhe një firewall është një veti që vlen midis momenteve. Nëse kërkesa është që trafiku i aplikacionit të mos dalë kurrë jashtë tunelit, ajo duhet të shprehet në hapësirën e emrave të rrjetit të përbashkët si një rregull prano-ose-hidh. Rendi i nisjes së kontejnerëve nuk mund ta mbajë atë kërkesë. Vetëm një rregull mundet.

Kontejnerët në një pod ndajnë atë hapësirë emrash, kështu që pika e zbatimit është vetë hapësira e emrave. Çfarëdo që të shkruani, duhet të lërë të disponueshme lidhjen e jashtme të vetë tunelit, sepse bllokimi i saj për të mbrojtur aplikacionin pret rrugën që i nevojitet aplikacionit.

Vendosni politikën e dështimit në mënyrë eksplicite: a duhet të ndalet plotësisht trafiku i aplikacionit kur tuneli nuk është i shëndetshëm, apo të vazhdojë dhe të shënohet si i pambrojtur? Të dyja janë të mbrojtshme, dhe asnjëra nuk është ajo që merrni duke nisur kontejnerët në një rend të caktuar.

Testoni trafikun që nuk e përmendët

Merrni një kërkesë të re gjatë një dështimi të kontrolluar të tunelit dhe shihni nëse del jashtë. Pastaj përsëritni kontrollin për rrugët që një test i adresës së daljes nuk i prek kurrë: zgjidhja e DNS brenda klasterit, destinacionet IPv6 dhe shërbimet e arritura përmes adresave të brendshme të klasterit në vend të internetit publik. Këto janë rrugët që vazhdojnë të punojnë në heshtje pasi tuneli vdes.

Një faqe adrese daljeje provon se një kërkesë shkoi atje ku prisnit në atë moment. Nuk mund të inventarizojë rrugët e tjera, dhe hendeku midis asaj që testuat dhe asaj që pod mund të arrijë është vendi ku jetojnë dështimet interesante.

Përsëritni testin pas një rinisjeje të sidecar-it dhe jo vetëm pas një nisjeje të pastër. Një kontejner tuneli i rinisur mund ta lërë hapësirën e emrave me rrugë dhe politikë në një gjendje të ndërmjetme.

Shkruani rekordin e vendosjes

Tre fakte i përkasin shënimeve të vendosjes: testi i gatishmërisë dhe çfarë vëzhgon, veprimi i rikuperimit kur ai test dështon, dhe rregulli i zbatimit që qeveris daljen. Dokumentacioni i kontejnerëve sidecar mbulon mekanikën e ciklit jetësor dhe e lë atë vendim politikë tek ju. Kjo ndarje është e saktë, dhe është gjithashtu arsyeja pse politika zakonisht mungon.

Një kontroll shëndetësor i ngatërruar me mbrojtje është lloji më i kushtueshëm i treguesit të gjelbër, sepse i ndalon njerëzit të bëjnë pyetje. Emërtimi i saktë në dokumentacion kushton një fjali dhe e parandalon këtë.

Së fundi, testoni rrugën e rikuperimit një herë me aplikacionin në punë. Një dizajn që kërkon rikrijimin e pod për të rivendosur daljen është një vendim, dhe duhet të jetë ai që keni marrë ju, jo ai që keni zbuluar.