Nustatykite saugias self-healing ribas

Atkurkite žinomą būseną

Self-healing automatiškai aptinka apibrėžtą gedimą ir bando atlikti leistiną atkūrimo veiksmą. Pavyzdžiai gali būti sugedusio proceso paleidimas iš naujo ar neveiksnaus egzemplioriaus pakeitimas. Veiksmas turi atitikti gedimą ir paslaugos būsenos modelį.

Kubernetes gali pakeisti sugedusius darbo krūvio egzempliorius ir palaikyti deklaruotą būseną. Tai netaiso klaidingos programos logikos ar kiekvieno saugyklos gedimo. Infrastruktūros atkūrimui ir programinės įrangos teisingumui reikia skirtingų patikrinimų. Kubernetes self-healing.

Apibrėžkite tikslą prieš mechanizmą. Atkurti eksportą reiškia, kad tinkamas darbas teisingai užbaigiamas. Veikiantis konteineris yra tik viena išankstinė sąlyga.

Atskirkite tris pakeitimų rūšis

Agentas po atkūrimo gali pasiūlyti pataisą. Toks pasiūlymas yra naujas programinės įrangos pakeitimas. Jis neturi paveldėti neribotų įgaliojimų iš atkūrimo valdiklio.

Valdiklis taip pat neturi keisti savo sėkmės kriterijų, kai patikrinimas nepavyksta. Antraip sistema gali pranešti apie pagerėjimą nepagerindama paslaugos.

Užrašykite atkūrimo taisykles prieš jas įjungdami

Toliau pateiktos taisyklės yra išgalvotos. Jų skaičiai iliustruoja projektavimo pasirinkimus; tai nėra rekomenduojamos numatytosios reikšmės.

Naudokite mažiausias būtinas teises turinčią tapatybę. Registruokite taisyklių versiją, paleidimo įrodymus, veiksmą, išteklių ir rezultatą. Suteikite nepriklausomą būdą išjungti valdiklį. Įvardykite atsakingą žmogų, kuris gauna eskalavimą.

Testuokite nesėkmės kelius ir sėkmingą atkūrimą

Pakartotinis bandymas gali pakartoti šalutinį poveikį. Vykdymo procesas gali išsaugoti failą ir sustoti prieš patvirtindamas užduotį. Prieš leisdami kitą vykdymą, patikrinkite idempotentiškumą. Žr. cloud native sutrikimo pavyzdį.

Pakartotiniai bandymai taip pat gali dar labiau apkrauti perkrautą priklausomybę. Naudokite ribotą bandymų skaičių, laukimo terminus ir tinkamai didinamą delsą. Venkite sinchroniškų pakartotinių bandymų visuose egzemplioriuose. AWS paaiškina, kodėl didėjanti delsa ir atsitiktinis jos kitimas padeda sumažinti šį sustiprinimą. Pakartotinių bandymų gairės.

Išbandykite išgalvotas taisykles trimis atvejais. Vienas sustojęs vykdymo procesas turėtų būti atkurtas. Duomenų bazės neveikimas turėtų neleisti kartotinių pakeitimų. Neaiški vientisumo klaida turėtų sustabdyti automatizavimą ir pareikalauti reagavimo sprendimo.

Taip pat patikrinkite trūkstamą telemetriją. Gyvybingumo signalo nebuvimas gali reikšti sugedusį vykdymo procesą arba sugedusį rinkimo kelią. Valdikliui reikia jo veiksmui pakankamų įrodymų, o ne pasitikėjimo DI paaiškinimu.

Matuokite, ar taisyklės padeda

Registruokite patikrintus atkūrimus, nesėkmingus bandymus, eskalavimus, dubliuotą darbą ir laiką, kai naudotojai patiria poveikį. Palyginkite su ankstesniu eksploatavimo būdu panašiomis sąlygomis.

Pagrindinę klaidą palikite kaip inžinerinį darbą. Pakartotinai paleidžiant atmintį prarandantį procesą galima sumažinti tiesioginį poveikį, nors nuotėkis tęsiasi. Toliau skaitykite apie self-improvement, kad susietumėte stebėjimą su ilgalaike pataisa.