VPN-flanka kontenero bezonas startregulon kaj fiaskregulon

Podo startas la tunelan konteneron antaŭ la aplikaĵo kaj la unuaj petoj sukcesas, kio estas ĝuste la kazo, kiu kaŝas la problemon. Ordigado solvas unu konkurson kaj diras nenion pri la trafiko, kiun la aplikaĵo komencas kvar horojn poste, post kiam la tunelo fiaskis. Tiuj estas du apartaj decidoj. Kutime nur unu el ili estas dizajnita.

Ordigado nur baras la unuan peton

Kubernetes subtenas flankan konteneran vivciklon konstruita el restarteblaj init-konteneroj. En tiu modelo starta provo povas reteni la sekvan inicialigan paŝon ĝis la tunelo raportas pretecon. Tio estas vera plibonigo, kaj indas uzi ĝin intence anstataŭ aldoni sleep al enirpunkta skripto. La pordego estas nur tiom bona, kiom la kondiĉo, kiun ĝi testas.

Ekster tiu modelo, la ordiga semantiko apartenas al kiu ajn rulmedio aŭ dependeca sistemo, kiun vi uzas, kaj ili ne devas kongrui. Disigado kopiita de alia platformo povas ŝajni atendi la tunelon, ĉar la aplikaĵo hazarde malrapide startas. Tio ne estas la sama garantio, kaj ĝi fiaskas sub ŝarĝo.

Diru, kion la pordego observas: proceso ekzistas, interfaco ekzistas, handshake kompletiĝis. Ĉiu el tiuj estas pli malforta aserto ol “la datenvojo al la celoj, kiujn ĉi tiu podo bezonas, funkcias”.

Devigu la datenvojon anstataŭ supozi ĝin

Provo estas kontrolo en unu momento, kaj fajroŝirmilo estas eco, kiu validas inter momentoj. Se la postulo estas, ke aplikaĵa trafiko neniam eliru ekster la tunelon, ĝi devas esti esprimita en la komuna reta nomspaco kiel akceptu-aŭ-forĵetu regulo. Kontenera startordo ne povas porti tiun postulon. Nur regulo povas.

Konteneroj en unu podo kunhavas tiun nomspacon, do la devigpunkto estas la nomspaco mem. Kion ajn vi skribas, ĝi devas lasi la propran eksteran konekton de la tunelo disponebla, ĉar bloki ĝin por protekti la aplikaĵon tranĉas la vojon, kiun la aplikaĵo bezonas.

Decidu la fiaskpolitikon eksplicite: ĉu aplikaĵa trafiko tute haltu kiam la tunelo ne estas sana, aŭ daŭru kaj esti markita kiel neprotektita? Ambaŭ estas defendeblaj, kaj neniu estas tio, kion vi ricevas startigante kontenerojn en aparta ordo.

Testu la trafikon, kiun vi ne menciis

Prenu novan peton dum kontrolita tunela fiasko kaj vidu, ĉu ĝi eliras. Poste ripetu la kontrolon por la vojoj, kiujn elirajresa testo neniam tuŝas: DNS-rezolucio ene de la klastro, IPv6-celoj, kaj servoj atingataj per klasteraj internaj adresoj anstataŭ la publika interreto. Tiuj estas la vojoj, kiuj silente daŭre funkcias post kiam la tunelo mortas.

Elirajresa paĝo pruvas, ke unu peto iris tien, kie vi atendis tiun momenton. Ĝi ne povas inventari la aliajn vojojn, kaj la breĉo inter tio, kion vi testis, kaj tio, kion la podo povas atingi, estas kie loĝas la interesaj fiaskoj.

Ripetu la teston post flanka kontenera restarto, ne nur post pura starto. Restartita tunela kontenero povas lasi la nomspacon kun itineroj kaj politiko en meza stato.

Skribu la disigan rikordon

Tri faktoj apartenas al la disigaj notoj: la preteca testo kaj kion ĝi observas, la reaga ago kiam tiu testo fiaskas, kaj la deviga regulo, kiu regas eliron. La dokumentaro pri flankaj konteneroj kovras la vivciklan mekanikon kaj lasas tiun politikan decidon al vi. Tiu divido estas ĝusta, kaj ĝi ankaŭ estas kial la politiko kutime mankas.

Sana kontrolo konfuzita kun protekto estas la plej multekosta speco de verda indikilo, ĉar ĝi haltigas homojn demandi. Nomumi ĝin precize en la dokumentaro kostas unu frazon kaj malhelpas tion.

Fine, testu la reakvan vojon unufoje kun la aplikaĵo kuranta. Dizajno, kiu postulas rekreadon de la podo por restarigi eliron, estas decido, kaj ĝi devus esti tiu, kiun vi faris, ne tiu, kiun vi malkovris.