VPN šalutiniam konteineriui reikia paleidimo taisyklės ir gedimo taisyklės

Podas paleidžia tunelio konteinerį prieš programą, ir pirmosios užklausos pavyksta, o būtent šis atvejis paslepia problemą. Tvarka ištaiso vienas lenktynes ir nieko nesako apie srautą, kurį programa pradeda po keturių valandų, kai tunelis jau sugedo. Tai du atskiri sprendimai. Paprastai suprojektuojamas tik vienas jų.

Tvarka blokuoja tik pirmąją užklausą

Kubernetes palaiko šalutinio konteinerio gyvavimo ciklą, sudarytą iš paleidžiamų iš naujo init konteinerių. Pagal tą modelį paleidimo zondas gali sulaikyti kitą inicijavimo žingsnį, kol tunelis praneš apie pasirengimą. Tai tikras patobulinimas, ir jį verta naudoti sąmoningai, o ne pridedant sleep į įėjimo taško scenarijų. Vartai yra tokie geri, kokia yra jų tikrinama sąlyga.

Už šio modelio ribų tvarkos semantika priklauso tai vykdymo aplinkai ar priklausomybių sistemai, kurią naudojate, ir jos neturi sutapti. Iš kitos platformos nukopijuotas diegimas gali atrodyti laukiantis tunelio, nes programa atsitiktinai paleidžiama lėtai. Tai ne ta pati garantija, ir ji žlunga esant apkrovai.

Pasakykite, ką stebi vartai: yra procesas, yra sąsaja, rankos paspaudimas baigtas. Kiekvienas iš jų yra silpnesnis teiginys nei „duomenų kelias į paskirties vietas, kurių reikia šiam podui, veikia“.

Priverskite duomenų kelią, o ne manykite jį

Zondas yra patikrinimas vienu momentu, o ugniasienė yra savybė, galiojanti tarp momentų. Jei reikalavimas yra, kad programos srautas niekada neišeitų už tunelio, jis turi būti išreikštas bendroje tinklo vardų erdvėje kaip priimti-arba-atmesti taisyklė. Konteinerių paleidimo tvarka negali nešti šio reikalavimo. Tik taisyklė gali.

Vieno podo konteineriai dalijasi ta vardų erdve, todėl vykdymo taškas yra pati vardų erdvė. Ką bebūtų rašote, tai turi palikti prieinamą paties tunelio išorinį ryšį, nes jo blokavimas programai apsaugoti nukerta kelią, kurio programai reikia.

Nuspręskite gedimo politiką aiškiai: ar programos srautas turi visiškai sustoti, kai tunelis nesveikas, ar tęstis ir būti pažymėtas kaip neapsaugotas? Abu yra pagrįsti, ir nė vienas nėra tai, ką gaunate paleisdami konteinerius tam tikra tvarka.

Išbandykite srautą, kurio nepaminėjote

Paimkite naują užklausą per kontroliuojamą tunelio gedimą ir pažiūrėkite, ar ji išeina. Tada pakartokite patikrinimą keliams, kurių išėjimo adreso testas niekada neliečia: DNS sprendimas klasterio viduje, IPv6 paskirties vietos ir paslaugos, pasiekiamos per vidinius klasterio adresus, o ne viešąjį internetą. Tai keliai, kurie po tunelio mirties tyliai veikia toliau.

Išėjimo adreso puslapis įrodo, kad viena užklausa tuo momentu nuėjo ten, kur tikėjotės. Jis negali inventorizuoti kitų kelių, o atotrūkis tarp to, ką išbandėte, ir to, ką podas gali pasiekti, yra vieta, kur gyvena įdomūs gedimai.

Pakartokite testą po šalutinio konteinerio paleidimo iš naujo, o ne tik po švaraus paleidimo. Iš naujo paleistas tunelio konteineris gali palikti vardų erdvę su maršrutais ir politika tarpinėje būsenoje.

Parašykite diegimo įrašą

Trys faktai priklauso diegimo pastaboms: pasirengimo testas ir ką jis stebi, atkūrimo veiksmas, kai šis testas žlunga, ir vykdymo taisyklė, kuri valdo išėjimą. Šalutinių konteinerių dokumentacija apima gyvavimo ciklo mechaniką ir palieka tą politikos sprendimą jums. Toks padalijimas yra teisingas, ir tai taip pat priežastis, kodėl politikos paprastai trūksta.

Sveikatos patikrinimas, sumaišytas su apsauga, yra brangiausia žalio indikatoriaus rūšis, nes jis sustabdo žmones nuo klausimų. Tikslus jo pavadinimas dokumentacijoje kainuoja vieną sakinį ir to išvengia.

Galiausiai vieną kartą išbandykite atkūrimo kelią, kai programa veikia. Dizainas, kuris reikalauja iš naujo sukurti podą, kad būtų atkurtas išėjimas, yra sprendimas, ir jis turėtų būti jūsų priimtas, o ne jūsų atrastas.