VPN blakuskonteinerim nepieciešams palaišanas noteikums un kļūmes noteikums

Pod palaiž tuneļa konteineru pirms lietotnes, un pirmie pieprasījumi izdodas, un tieši šis gadījums slēpj problēmu. Kārtība izlabo vienas sacensības un neko nesaka par trafiku, ko lietotne sāk četras stundas vēlāk, pēc tam kad tunelis ir sabojājies. Tie ir divi atsevišķi lēmumi. Parasti tiek projektēts tikai viens no tiem.

Kārtība bloķē tikai pirmo pieprasījumu

Kubernetes atbalsta blakuskonteinera dzīves ciklu, kas veidots no restartējamiem init konteineriem. Šajā modelī palaišanas zonde var aizturēt nākamo inicializācijas soli, līdz tunelis ziņo par gatavību. Tas ir īsts uzlabojums, un to ir vērts izmantot apzināti, nevis pievienojot sleep ieejas punkta skriptam. Vārti ir tikai tik labi, cik labs ir to pārbaudītais nosacījums.

Ārpus šī modeļa kārtības semantika pieder tai izpildes videi vai atkarību sistēmai, ko lietojat, un tām nav jāsakrīt. No citas platformas kopēts izvietojums var izskatīties kā tuneļa gaidīšana, jo lietotne nejauši startē lēni. Tā nav tā pati garantija, un tā sabrūk slodzes laikā.

Pasakiet, ko vārti novēro: pastāv process, pastāv saskarne, handshake ir pabeigts. Katrs no tiem ir vājāks apgalvojums nekā „datu ceļš uz galamērķiem, kas šim podam nepieciešami, darbojas“.

Piespiediet datu ceļu, nevis pieņemiet to

Zonde ir pārbaude vienā mirklī, un ugunsmūris ir īpašība, kas ir spēkā starp mirklīšiem. Ja prasība ir, ka lietotnes trafiks nekad neiziet ārpus tuneļa, tā ir jāizsaka koplietotajā tīkla vārdu telpā kā pieņemt-vai-izmest noteikums. Konteineru palaišanas kārtība nevar iznest šo prasību. To var tikai noteikums.

Konteineri vienā podā koplieto šo vārdu telpu, tāpēc izpildes punkts ir pati vārdu telpa. Ko vien rakstāt, tam jāatstāj pieejams paša tuneļa ārējais savienojums, jo tā bloķēšana lietotnes aizsardzībai nogriež ceļu, kas lietotnei nepieciešams.

Izlemiet kļūmes politiku skaidri: vai lietotnes trafikam pilnībā jāapstājas, kad tunelis nav veselīgs, vai jāturpinās un jāatzīmē kā neaizsargāts? Abi ir pamatojami, un neviens nav tas, ko iegūstat, palaižot konteinerus noteiktā kārtībā.

Pārbaudiet trafiku, ko nepieminējāt

Paņemiet jaunu pieprasījumu kontrolētas tuneļa kļūmes laikā un skatiet, vai tas iziet. Pēc tam atkārtojiet pārbaudi ceļiem, kurus izejas adreses tests nekad neaizskar: DNS atrisināšana klastera iekšienē, IPv6 galamērķi un pakalpojumi, kas sasniedzami caur klastera iekšējām adresēm, nevis publisko internetu. Tie ir ceļi, kas pēc tuneļa nāves klusi turpina darboties.

Izejas adreses lapa pierāda, ka viens pieprasījums tajā mirklī devās tur, kur gaidījāt. Tā nevar uzskaitīt citus ceļus, un plaisa starp to, ko pārbaudījāt, un to, ko pod var sasniegt, ir vieta, kur dzīvo interesantās kļūmes.

Atkārtojiet testu pēc blakuskonteinera restartēšanas, nevis tikai pēc tīras palaišanas. Restartēts tuneļa konteiners var atstāt vārdu telpu ar maršrutiem un politiku starpstāvoklī.

Uzrakstiet izvietošanas ierakstu

Trīs fakti pieder izvietošanas piezīmēm: gatavības tests un tas, ko tas novēro, atkopšanas darbība, kad šis tests sabrūk, un izpildes noteikums, kas pārvalda izeju. Blakuskonteineru dokumentācija aptver dzīves cikla mehāniku un atstāj šo politikas lēmumu jums. Šis dalījums ir pareizs, un tas arī ir iemesls, kāpēc politika parasti trūkst.

Veselības pārbaude, kas sajaukta ar aizsardzību, ir visdārgākais zaļā indikatora veids, jo tā attur cilvēkus uzdot jautājumus. Precīza tās nosaukšana dokumentācijā maksā vienu teikumu un to novērš.

Visbeidzot, vienreiz pārbaudiet atkopšanas ceļu, kamēr lietotne darbojas. Dizains, kas prasa no jauna izveidot pod, lai atjaunotu izeju, ir lēmums, un tam jābūt jūsu pieņemtam, nevis jūsu atklātam.