'n VPN-sywa het 'n beginreël en 'n mislukkingsreël nodig

'n Pod begin die tonnelhouer voor die toepassing, en die eerste versoeke slaag, wat juis die geval is wat die probleem verberg. Ordening los een wedloop op en sê niks oor die verkeer wat die toepassing vier uur later begin, nadat die tonnel misluk het nie. Dit is twee afsonderlike besluite. Gewoonlik word net een daarvan ontwerp.

Ordening hou net die eerste versoek terug

Kubernetes ondersteun 'n sywa-lewensiklus wat uit herbeginbare init-houers gebou is. Binne daardie model kan 'n opstartprobe die volgende inisialiseringsstap terughou totdat die tonnel gereed rapporteer. Dit is 'n werklike verbetering, en dit is die moeite werd om dit doelbewus te gebruik eerder as om 'n slaap by 'n intreepuntskrip te voeg. Die hek is net so goed soos die voorwaarde wat dit toets.

Buite daardie model behoort die ordeningsemantiek aan watter looptyd- of afhanklikheidstelsel jy ook al gebruik, en dit hoef nie te ooreen te stem nie. 'n Ontplooiing wat van 'n ander platform gekopieer is, kan lyk of dit vir die tonnel wag omdat die toepassing toevallig stadig begin. Dit is nie dieselfde waarborg nie, en dit faal onder las.

Sê wat die hek sien: 'n proses bestaan, 'n koppelvlak bestaan, 'n handdruk het voltooi. Elkeen daarvan is 'n swakker bewering as “die datapad na die bestemmings wat hierdie pod nodig het, werk”.

Dwing die datapad af in plaas daarvan om dit te aanvaar

'n Probe is 'n kontrole op een oomblik en 'n vuurmuur is 'n eienskap wat tussen oomblikke geld. As die vereiste is dat toepassingsverkeer nooit buite die tonnel vertrek nie, moet dit in die gedeelde netwerknaamruimte as 'n aanvaar-of-verwerp-reël uitgedruk word. Houerbeginorde kan nie daardie vereiste dra nie. Net 'n reël kan.

Houers in een pod deel daardie naamruimte, dus is die handhawingspunt die naamruimte self. Wat jy ook al skryf, moet die tonnel se eie buitenste verbinding beskikbaar laat, want om dit te blokkeer om die toepassing te beskerm, sny die pad wat die toepassing nodig het.

Besluit die mislukkingsbeleid eksplisiet: moet toepassingsverkeer heeltemal stop wanneer die tonnel ongesond is, of voortgaan en as onbeskermd gemerk word? Albei is verdedigbaar, en nie een is wat jy kry deur houers in 'n bepaalde orde te begin nie.

Toets die verkeer wat jy nie genoem het nie

Neem 'n nuwe versoek tydens 'n beheerde tonnelmislukking en kyk of dit uitgaan. Herhaal dan die kontrole vir die paaie wat 'n uitgangsadres-toets nooit raak nie: DNS-resolusie binne die cluster, IPv6-bestemmings, en dienste wat deur cluster-interne adresse eerder as die publieke internet bereik word. Dit is die paaie wat stilweg aanhou werk nadat die tonnel sterf.

'n Uitgangsadres-bladsy bewys dat een versoek daardie oomblik gegaan het waar jy verwag het. Dit kan nie die ander paaie inventariseer nie, en die gaping tussen wat jy getoets het en wat die pod kan bereik, is waar die interessante mislukkings woon.

Herhaal die toets ná 'n sywa-herbegin eerder as net ná 'n skoon begin. 'n Herbeginnde tonnelhouer kan die naamruimte met roetes en beleid in 'n tussenstaat laat.

Skryf die ontplooiingsrekord

Drie feite hoort in die ontplooiingsnotas: die gereedheidstoets en wat dit sien, die herstelaksie wanneer daardie toets misluk, en die handhawingsreël wat uitgang beheer. Die dokumentasie vir sywa-houers dek die lewensiklusmeganika en laat daardie beleidsbesluit aan jou oor. Daardie verdeling is korrek, en dit is ook hoekom die beleid gewoonlik ontbreek.

'n Gesondheidskontrole wat vir beskerming aangesien word, is die duurste soort groen aanwyser, want dit stop mense om vrae te vra. Om dit akkuraat in die dokumentasie te benoem, kos een sin en voorkom dit.

Ten slotte, toets die herstelpad een keer met die toepassing aan die gang. 'n Ontwerp wat vereis dat die pod herskep word om uitgang te herstel, is 'n besluit, en dit moet een wees wat jy geneem het eerder as een wat jy ontdek het.