In VPN-sidecar hat in startregel en in flaterregel nedich

In pod startet de tunnelcontainer foar de applikaasje en de earste oanfragen slagje, en dat is krekt it gefal dat it probleem ferberget. Oardering makket ien race klear en seit neat oer it ferkear dat de applikaasje fjouwer oeren letter begjint, neidat de tunnel mislearre is. Dat binne twa aparte besluten. Meastentiids wurdt mar ien fan beide ûntwurpen.

Oardering beheint allinnich de earste oanfraach

Kubernetes stipet in sidecar-libenssyklus boud út werstartbere init-containers. Yn dat model kin in startprobe de folgjende initialisaasjestap tsjinhâlde oant de tunnel klear rapportearret. Dat is in echte ferbettering, en it is de muoite wurdich om it bewust te brûken ynstee fan in sleep ta te foegjen oan in yngongspunt-skript. De poarte is mar sa goed as de betingst dy't er test.

Bûten dat model heart de oarderingssemantyk by hokker runtime of ôfhinklikenssysteem dan ek dat jo brûke, en dy hoegge net oerien te kommen. In útrulling kopiearre fan in oar platfoarm kin lykje te wachtsjen op de tunnel om't de applikaasje tafallich stadich start. Dat is net deselde garânsje, en it mislearret ûnder lading.

Sis wat de poarte waarnimt: in proses bestiet, in ynterface bestiet, in handshake is foltôge. Elk dêrfan is in swakker bewearing as “it datapad nei de bestimmingen dy't dizze pod nedich hat, wurket”.

Twang it datapad ynstee fan it oan te nimmen

In probe is in kontrôle op ien momint en in firewall is in eigenskip dy't tusken mominten jildt. As de eask is dat applikaasjeferkear nea bûten de tunnel giet, moat it yn 'e dielde netwurknammeromte as in akseptearje-of-ôfwize-regel útdrukt wurde. Containerstartoarder kin dy eask net drage. Allinnich in regel kin dat.

Containers yn ien pod diele dy nammeromte, dus it hanthaveningspunt is de nammeromte sels. Wat jo ek skriuwe, it moat de eigen bûtenferbining fan 'e tunnel beskikber litte, want it blokkearjen dêrfan om de applikaasje te beskermjen snijt it paad ôf dat de applikaasje nedich hat.

Beslis it flaterbelied eksplisyt: moat applikaasjeferkear hielendal stopje as de tunnel net sûn is, of trochgean en as ûnbeskerme markearre wurde? Beide binne ferdigenber, en gjinien is wat jo krije troch containers yn in bepaalde oarder te starten.

Test it ferkear dat jo net neamden

Nim in nije oanfraach by in kontrolearre tunnelstoaring en sjoch oft er nei bûten giet. Werhelje dan de kontrôle foar de paden dy't in útgongadres-test nea rekket: DNS-oplossing binnen it cluster, IPv6-bestimmingen, en tsjinsten berikt fia cluster-ynterne adressen ynstee fan it iepenbiere ynternet. Dat binne de paden dy't stil trochgeane nei't de tunnel dea is.

In útgongadres-side bewiist dat ien oanfraach op dat momint gie wêr't jo ferwachten. It kin de oare paden net ynventarisearje, en de kleau tusken wat jo teste en wat de pod berikke kin, is wêr't de nijsgjirrige flaters libje.

Werhelje de test nei in sidecar-herstart ynstee fan allinnich nei in skjinne start. In werstarte tunnelcontainer kin de nammeromte mei rûtes en belied yn in tuskenstân litte.

Skriuw it útrullingsrecord

Trije feiten hearre yn 'e útrullingsnotysjes: de geriedheidstest en wat er waarnimt, de hersteltiid by it mislearjen fan dy test, en de hanthaveningsregel dy't útgong regelet. De dokumintaasje oer sidecar-containers behannelet de libenssyklusmeganika en lit dat beliedsbeslút oan jo oer. Dy ferdieling is korrekt, en dat is ek wêrom't it belied meastentiids ûntbrekt.

In sûnenscheck oansjoen foar beskerming is de djoerste soarte griene yndikator, want it stopet minsken om fragen te stellen. It krekt beneamen yn 'e dokumintaasje kostet ien sin en foarkomt dat.

Uteinlik, test it herstelpaad ien kear mei de applikaasje oan 'e gong. In ûntwerp dat easket dat de pod op 'e nij makke wurdt om útgong te herstellen is in beslút, en it soe ien wêze moatte dy't jo naam hawwe ynstee fan ien dy't jo ûntdutsen hawwe.