Поставете безбедни граници за самообновување
ЗавршеноАвтоматизирајте познати дејства за обновување со изречни овластувања, проверка и услови за запирање. Одвојте го обновувањето при работа од менувањето софтвер.
Објавува TaigaКако пишуваме
Проверете го разбирањетоКонтролерот рестартирал извршувач двапати. Редицата продолжува да расте, а базата е недостапна. Што треба да наложи политиката?Направете ја вежбата
Што ќе научите
- Разликувајте самообновување од трајна софтверска поправка.
- Одредете ограничена политика за обновување и независни проверки за успех.
- Препознајте кога автоматизацијата мора да запре и да ескалира.
Обновете позната состојба
Самообновувањето автоматски открива определен неуспех и се обидува да изврши овластено дејство за обновување. Примери може да бидат рестартирање неуспешен процес или замена на неисправна инстанца. Дејството мора да одговара на неуспехот и на моделот на состојба на услугата.
Kubernetes може да замени неуспешни инстанци што извршуваат работа и да ја усогласи состојбата со декларираната. Тоа не поправа погрешна апликациска логика или секој неуспех на складирањето. За обновување на инфраструктурата и за исправноста на софтверот се потребни различни проверки. Самообновување во Kubernetes.
Одредете ја целта пред механизмот. Обновување на извозот значи дека работата што ги исполнува условите завршува правилно. Контејнер што работи е само еден предуслов.
Одвојте три вида промени
| Промена | Пример | Потребна одлука |
|---|---|---|
| Обновување при работа | Заменете еден неуспешен извршувач без состојба | Однапред одобрена политика за обновување може да го овласти ова |
| Софтверска поправка | Поправете го истекувањето меморија што го запира извршувачот | Преглед, тестови, контроли за издавање и проверка во продукција |
| Промена на политика | Зголемете ја дозволената стапка на рестартирање или опфатот на пристап | Изречно одобрение од одговорниот за политиката |
Агент може да предложи поправка по обновувањето. Тој предлог е нова софтверска промена. Не смее да наследи неограничени овластувања од контролерот за обновување.
Контролерот исто така не смее да ги менува сопствените критериуми за успех кога проверка не успева. Во спротивно, системот може да пријави подобрување без да ја подобри услугата.
Напишете ја политиката за обновување пред да ја овозможите
Следната политика е измислена. Нејзините бројки илустрираат дизајнерски избори; не се препорачани стандардни вредности.
| Поле на политиката | Измислено правило за извршувач за извоз |
|---|---|
| Повод | Нема сигнал за активност од извршувачот 90 секунди и постои работа во редицата |
| Предуслови | Друг извршувач е исправен; проверките на зависностите се успешни; нема сомнение за безбедносен упад или проблем со интегритетот |
| Дозволено дејство | Заменете еден извршувач со тековно одобрениот артефакт |
| Заштита на состојбата | Задачите користат трајно складирање и проверен клуч за идемпотентност |
| Ограничување | Најмногу две замени во 15 минути; никогаш повеќе од една истовремено |
| Пауза | Почекајте пет минути по замената пред друг обид |
| Успех | Синтетичка задача завршува правилно и засегнатата редица почнува да се празни |
| Запрете и ескалирајте | Кој било предуслов не е исполнет, ограничувањето е достигнато или успехот не може да се провери |
Користете идентитет со најмали потребни привилегии. Запишете ги верзијата на политиката, доказите за поводот, дејството, ресурсот и резултатот. Обезбедете независен начин за исклучување на контролерот. Одредете го човечкиот одговорен што ја прима ескалацијата.
Тестирајте неуспеси, како и успешно обновување
Повторен обид може да повтори страничен ефект. Извршувач може да зачува датотека и да запре пред да ја потврди задачата. Проверете ја идемпотентноста пред да дозволите друго извршување. Видете го примерот за неуспех во cloud native дизајн.
Повторените обиди може и да го зголемат оптоварувањето на веќе преоптоварена зависност. Користете ограничен број обиди, временски ограничувања и соодветно зголемување на паузата меѓу обидите. Избегнувајте синхронизирани повторни обиди низ сите инстанци. AWS објаснува зошто постепеното зголемување и случајното варирање на паузите го намалуваат ова засилување. Насоки за повторни обиди.
Тестирајте ја измислената политика во три случаи. Еден запрен извршувач треба да се обнови. Прекин на базата треба да спречи повторувана замена. Неизвесен проблем со интегритетот треба да ја запре автоматизацијата и да побара одлука за одговор.
Проверете и телеметрија што недостига. Отсуство на сигнал за активност може да значи неуспешен извршувач или неуспешна патека за собирање. На контролерот му требаат доволни докази за неговото дејство, а не доверба во објаснување од AI.
Мерете дали политиката помага
Бележете проверени обновувања, неуспешни обиди, ескалации, дуплирана работа и времето со влијание врз корисниците. Споредете ги со претходниот начин на работење во слични услови.
Задржете го основниот дефект како инженерска задача. Повторувано рестартирање процес од кој истекува меморија може да го намали непосредното влијание додека истекувањето продолжува. Продолжете со самоподобрување за да го поврзете набљудувањето со трајна поправка.
Направете ја вежбата
Осмислете политика за обновување на измислениот извршувач за извоз од оваа лекција. Одредете ги поводот, исклучувањата, дозволеното дејство, ограничувањето на обиди, паузата, проверката за успех и одговорниот за ескалација. Тестирајте ја при прекин на базата и непознат проблем со интегритетот на податоците.
Преземи работен лист (Markdown)Поништување на овој избор го брише целиот напредок зачуван во овој прелистувач.
Напредокот останува во овој прелистувач. Без сметка и следење.
Извори и дополнително читање
- Kubernetes: Self-Healing ↗
- AWS Builders’ Library: Timeouts, retries, and backoff with jitter ↗
- Google SRE: Automation at Google ↗