🥇Сондите за живост во Кубернетес може да бидат опасни

Забелешка. превод.: Главниот инженер од Заландо, Хенинг Џејкобс, постојано забележал проблеми меѓу корисниците на Кубернетес во разбирањето на целта на сондите за живост (и подготвеност) и нивната правилна употреба. Затоа, тој ги собра своите размислувања во оваа обемна белешка, која на крајот ќе стане дел од документацијата на K8s.

Здравствени проверки, познати во Кубернетес како сонди за живост (т.е., буквално, „тестови за одржливост“ - приближно превод.), може да биде доста опасно. Препорачувам да ги избегнувате доколку е можно: единствените исклучоци се кога се навистина неопходни и сте целосно свесни за спецификите и последиците од нивната употреба. Оваа публикација ќе зборува за проверки на живост и подготвеност, а исто така ќе ви каже во кои случаи е и не треба да ги користите.

Мојот колега Шандор неодамна на Твитер ги сподели најчестите грешки со кои се среќава, вклучително и оние поврзани со употребата на сонди за подготвеност/живост:

Неправилно конфигуриран livenessProbe може да ги влоши ситуациите со големо оптоварување (исклучување на снежни топки + потенцијално долго време за стартување на контејнерот/апликацијата) и да доведе до други негативни последици како што се падовите на зависноста (исто така види мојата неодамнешна статија за ограничување на бројот на барања во комбинацијата K3s+ACME). Уште полошо е кога сондата за живост се комбинира со здравствена проверка, што е надворешна база на податоци: еден неуспех на DB ќе ги рестартира сите ваши контејнери!

Општа порака „Не користете сонди за живост“ во овој случај тоа не помага многу, па ајде да погледнеме за што служат проверките за подготвеност и живост.

Забелешка: Поголемиот дел од тестот подолу првично беше вклучен во внатрешната документација за програмери на Zalando.

Проверки на подготвеност и живост

Kubernetes обезбедува два важни механизми наречени сонди за живост и сонди за подготвеност. Тие периодично извршуваат некоја акција - како што е испраќање HTTP барање, отворање на TCP конекција или извршување на команда во контејнерот - за да потврдат дека апликацијата работи како што се очекува.

Kubernetes користи сонди за подготвеностда се разбере кога контејнерот е подготвен да прифати сообраќај. Мешунката се смета за подготвена за употреба ако сите нејзини контејнери се подготвени. Една од употребата на овој механизам е да се контролира кои подлоги се користат како задни за услугите на Kubernetes (и особено Ingress).

Сонди за живост помогнете му на Кубернетите да разберат кога е време да го рестартирате контејнерот. На пример, таквата проверка ви овозможува да пресретнете ќор-сокак кога апликацијата ќе се заглави на едно место. Рестартирањето на контејнерот во оваа состојба помага да се отстрани апликацијата и покрај грешките, но исто така може да доведе до каскадни дефекти (видете подолу).

Ако се обидете да распоредите ажурирање на апликацијата што не ги проверува живоста/подготвеноста, нејзиното објавување ќе биде закочено додека Kubernetes го чека статусот Ready од сите мешунки.

Пример

Еве пример на сонда за подготвеност која проверува патека /health преку HTTP со стандардни поставки (интервал: 10 секунди, тајм аут: 1 секунда, праг на успех: 1, праг на неуспех: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

Препораки

За микроуслуги со HTTP крајна точка (REST, итн.) секогаш дефинирајте сонда за подготвеност, кој проверува дали апликацијата (под) е подготвена да прифати сообраќај.
Уверете се во сондата за подготвеност ја покрива достапноста на вистинската порта за веб-сервер:
- користење на пристаништа за административни цели, наречени „администратор“ или „управување“ (на пример, 9090), за readinessProbe, проверете дали крајната точка се враќа во ред само ако примарната HTTP порта (како 8080) е подготвена да прифати сообраќај*;
  *Свесен сум за барем еден случај во Заландо каде тоа не се случило, т.е. readinessProbe Ја проверив портата „управување“, но самиот сервер не започна да работи поради проблеми со вчитување на кешот.
- прикачувањето на сонда за подготвеност на посебна порта може да доведе до фактот дека преоптоварувањето на главната порта нема да се одрази на здравствената проверка (односно, базенот за нишки на серверот е полн, но здравствената проверка сепак покажува дека сè е во ред ).
Осигурајте се дека сондата за подготвеност овозможува иницијализација/миграција на базата на податоци;
- Најлесен начин да се постигне ова е да се контактира со HTTP серверот само откако ќе заврши иницијализацијата (на пример, мигрирање на базата на податоци од Flyway и така натаму.); односно, наместо да го менувате статусот на здравствената проверка, едноставно не стартувајте го веб-серверот додека не заврши миграцијата на базата на податоци*.
  * Можете исто така да извршите миграции на базата на податоци од иницијалните контејнери надвор од подлогата. Сè уште сум љубител на самостојни апликации, односно оние во кои контејнерот за апликации знае како да ја доведе базата на податоци во посакуваната состојба без надворешна координација.
Користете httpGet за проверки на подготвеност преку типични крајни точки за здравствена проверка (на пример, /health).
Разберете ги стандардните параметри за проверка (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- стандардните опции значат дека подлогата ќе стане не-подготвен по околу 30 секунди (3 неуспешни проверки на разумот).
Користете посебна порта за „администратор“ или „управување“ ако стекот на технологија (на пр. Java/Spring) го дозволува тоа, за да го одделите управувањето со здравјето и метриката од редовниот сообраќај:
- но не заборавајте за точка 2.
Доколку е потребно, сондата за подготвеност може да се користи за загревање/вчитување на кешот и враќање на статусната шифра 503 додека контејнерот не се загрее:
- Ви препорачувам да ја прочитате и новата проверка startupProbe, се појави во верзијата 1.16 (напишавме за тоа на руски тука - прибл. превод.).

Предупредувања

Не потпирајте се на надворешни зависности (како што се складишта на податоци) кога се извршуваат тестови за подготвеност/живост - ова може да доведе до каскадни неуспеси:
- Како пример, да земеме државна услуга REST со 10 подови во зависност од една база на податоци на Postgres: кога проверката зависи од работната врска со DB, сите 10 места може да не успеат ако има доцнење на страната на мрежата/DB - обично тоа сè завршува полошо отколку што можеше;
- Ве молиме имајте предвид дека Spring Data стандардно ја проверува врската со базата на податоци*;
  * Ова е стандардното однесување на Spring Data Redis (барем тоа беше последен пат кога проверив), што доведе до „катастрофален“ неуспех: кога Redis беше накратко недостапен, сите подлоги „се урнаа“.
- „надворешно“ во оваа смисла може да значи и други мешунки од истата апликација, односно идеално е дека проверката не треба да зависи од состојбата на другите парчиња од истиот кластер за да се спречат каскадни падови:
  - резултатите може да варираат за апликации со дистрибуирана состојба (на пример, кеширање во меморијата во подлоги).
Не користете сонда за живост за мешунките (исклучоци се случаите кога тие се навистина неопходни и сте целосно свесни за спецификите и последиците од нивната употреба):
- Сондата за живост може да помогне во враќањето на обесените контејнери, но бидејќи имате целосна контрола врз вашата апликација, идеално не треба да се случуваат работи како што се обесени процеси и ќор-сокак: најдобрата алтернатива е намерно да се урне апликацијата и да се врати во претходната стабилна состојба;
- неуспешната истрага за живост ќе предизвика контејнерот да се рестартира, а со тоа потенцијално ќе ги влоши последиците од грешките поврзани со вчитувањето: рестартирањето на контејнерот ќе резултира со прекини (барем за времетраењето на стартувањето на апликацијата, да речеме 30 непарни секунди), предизвикувајќи нови грешки , зголемување на оптоварувањето на други контејнери и зголемување на веројатноста за нивно неуспех итн.;
- проверките на живост во комбинација со надворешна зависност се најлошата можна комбинација, заканувајќи се со каскадни неуспеси: мало доцнење на страната на базата на податоци ќе доведе до рестартирање на сите ваши контејнери!
Параметри на живост и проверки на подготвеност мора да бидат различни:
- може да користите сонда за живост со истата здравствена проверка, но повисок праг на одговор (failureThreshold), на пример, доделете го статусот не-подготвен по 3 обиди и сметајте дека сондата за живост не успеа по 10 обиди;
Не користете извршни проверки, бидејќи тие се поврзани со познати проблеми што доведуваат до појава на процеси на зомби:
- детали: види презентација од специјалисти на Datadog.

Краток преглед

Користете сонди за подготвеност за да одредите кога подлогата е подготвена да прими сообраќај.
Користете сонди за живост само кога се навистина потребни.
Неправилната употреба на сондите за подготвеност/живост може да доведе до намалена достапност и каскадни неуспеси.

Дополнителни материјали на оваа тема

Ажурирање бр. 1 од 2019

За init контејнерите за миграција на базата на податоци: Додадена е фуснота.

Ме потсети ЕЈ за PDB: еден од проблемите со проверките на живост е недостатокот на координација помеѓу мешунките. Кубернетес има Буџети за нарушување на подлогата (ПДБ) да се ограничи бројот на истовремени неуспеси што може да ги доживее апликацијата, но проверките не го земаат предвид ППБ. Идеално, би можеле да им кажеме на K8 да „Рестартирај една подлога ако нејзиниот тест не успее, но не ги рестартирај сите за да избегнеш влошување на работите“.

Брајан совршено го стави тоа: „Користете сондирање на живост кога точно знаете што најдоброто нешто што треба да направите е да ја убиете апликацијата„(повторно, не се занесувајте).

Ажурирање бр. 2 од 2019

Во однос на читање на документацијата пред употреба: Јас го создадов соодветното барање (барање за одлики) да се додаде документација за сонди за живост.

PS од преведувач

Прочитајте и на нашиот блог:

Извор: www.habr.com

Сондите за живост во Кубернетес може да бидат опасни