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

Белешка. трансл.: Водећи инжењер из Заланда, Хеннинг Јацобс, више пута је приметио проблеме међу корисницима Кубернетес-а у разумевању сврхе сонди за животност (и спремности) и њихове правилне употребе. Стога је своје мисли сакупио у овој опширној белешци, која ће на крају постати део документације К8с.

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

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

Погрешно конфигурисано livenessProbe може погоршати ситуације високог оптерећења (гашење грудве снега + потенцијално дуго време покретања контејнера/апликације) и довести до других негативних последица као што је пад зависности (такође видети мој недавни чланак о ограничавању броја захтева у комбинацији К3с+АЦМЕ). Још је горе када се сонда за животност комбинује са здравственим прегледом, који је екстерна база података: једна грешка ДБ ће поново покренути све ваше контејнере!

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

Напомена: Већина тестова испод је првобитно била укључена у Заландову интерну документацију за програмере.

Провере спремности и животности

Кубернетес обезбеђује два важна механизма тзв сонде за животност и сонде за спремност. Они повремено обављају неку радњу — као што је слање ХТТП захтева, отварање ТЦП везе или извршавање команде у контејнеру — да би потврдили да апликација ради како се очекује.

Кубернетес користи сонде за спремностда разуме када је контејнер спреман да прихвати саобраћај. Махуна се сматра спремном за употребу ако су сви њени контејнери спремни. Једна употреба овог механизма је да контролишете који се подови користе као позадине за Кубернетес услуге (а посебно Ингресс).

Сонде за живост помозите Кубернетесу да разуме када је време да поново покренете контејнер. На пример, таква провера вам омогућава да пресретнете застој када се апликација заглави на једном месту. Поновно покретање контејнера у овом стању помаже да се апликација покрене упркос грешкама, али такође може довести до каскадних грешака (погледајте доле).

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

Пример

Ево примера сонде спремности која проверава путању /health преко ХТТП-а са подразумеваним подешавањима (интервал: 10 секунди, тајм-аут: 1 секунда, праг успеха: КСНУМКС, праг неуспеха: 3):

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

Препоруке

За микросервисе са ХТТП крајњом тачком (РЕСТ, итд.) увек дефинише сонду спремности, који проверава да ли је апликација (под) спремна да прихвати саобраћај.
Уверите се да је сонда спремности покрива доступност стварног порта веб сервера:
- коришћење портова у административне сврхе, назване „администратор“ или „менаџмент“ (на пример, 9090), за readinessProbe, уверите се да крајња тачка враћа ОК само ако је примарни ХТТП порт (као 8080) спреман да прихвати саобраћај*;
  * Познат ми је бар један случај у Заланду где се то није догодило, тј. readinessProbe Проверио сам порт за „управљање“, али сам сервер није почео да ради због проблема са учитавањем кеша.
- прикључивање сонде спремности на посебан порт може довести до тога да се преоптерећење главног порта неће одразити на проверу здравља (то јест, скуп нити на серверу је пун, али провера здравља и даље показује да је све у реду ).
Уверите се да сонда спремности омогућава иницијализацију/миграцију базе података;
- Најлакши начин да се то постигне је да контактирате ХТТП сервер тек након што је иницијализација завршена (на пример, миграција базе података са Фливаи и тако даље.); то јест, уместо да мењате статус провере здравља, једноставно немојте покретати веб сервер док се миграција базе података не заврши*.
  * Такође можете покренути миграције базе података из инит контејнера изван под. И даље сам љубитељ самосталних апликација, односно оних у којима контејнер апликације зна да доведе базу података у жељено стање без спољне координације.
Користите httpGet за провере спремности преко типичних крајњих тачака здравствене провере (нпр. /health).
Разумети подразумеване параметре провере (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- подразумеване опције значе да ће махуна постати није спреман после око 30 секунди (3 неуспеле провере урачунљивости).
Користите посебан порт за „администратор“ или „менаџмент“ ако то дозвољава технолошки скуп (нпр. Јава/Спринг) да одвојите управљање здрављем и метриком од редовног саобраћаја:
- али не заборавите на тачку 2.
Ако је потребно, сонда спремности се може користити за загревање/учитавање кеша и враћање статусног кода 503 док се контејнер не загреје:
- Такође препоручујем да прочитате нови чек startupProbe, појавио у верзији 1.16 (писали смо о томе на руском овде — прибл. превод).

Ограничења

Не ослањајте се на спољне зависности (као што су складишта података) када се изводе тестови спремности/живости – то може довести до каскадних кварова:
- Као пример, узмимо РЕСТ сервис са стањем са 10 подова у зависности од једне Постгрес базе података: када провера зависи од радне везе са ДБ-ом, свих 10 подова може пропасти ако дође до кашњења на страни мреже/ДБ - обично је тако све се завршава горе него што би могло;
- Имајте на уму да Спринг Дата подразумевано проверава везу са базом података*;
  * Ово је подразумевано понашање Спринг Дата Редис-а (барем је то био последњи пут да сам проверио), што је довело до „катастрофалног“ неуспеха: када је Редис накратко био недоступан, сви подови су се „срушили“.
- „спољни“ у овом смислу може да значи и друге модуле исте апликације, односно, у идеалном случају провера не би требало да зависи од стања других модула истог кластера како би се спречила каскадна рушења:
  - резултати могу да варирају за апликације са дистрибуираним стањем (на пример, кеширање у меморији у подовима).
Немојте користити сонду за живост за махуне (изузеци су случајеви када су заиста неопходне и када сте потпуно свесни специфичности и последица њихове употребе):
- Провера живог стања може помоћи да се опораве обешени контејнери, али пошто имате потпуну контролу над својом апликацијом, ствари као што су закачени процеси и застоји у идеалном случају не би требало да се дешавају: најбоља алтернатива је намерно срушити апликацију и вратити је у претходно стабилно стање;
- неуспела сонда животности ће довести до поновног покретања контејнера, што потенцијално може погоршати последице грешака у вези са учитавањем: поновно покретање контејнера ће довести до застоја (барем током трајања покретања апликације, рецимо 30-ак секунди), узрокујући нове грешке , повећање оптерећења на другим контејнерима и повећање вероватноће њиховог квара итд.;
- провере живости у комбинацији са спољном зависношћу су најгора могућа комбинација, која прети каскадним кваровима: мало кашњење на страни базе података ће довести до поновног покретања свих ваших контејнера!
Провере параметара животности и спремности мора бити другачији:
- можете користити сонду за живост са истим здравственим прегледом, али са вишим прагом одговора (failureThreshold), на пример, доделите статус није спреман након 3 покушаја и сматрати да је сонда живости неуспешна након 10 покушаја;
Не користите екец провере, пошто су повезани са познатим проблемима који доводе до појаве зомби процеса:
- детаљи: види презентација стручњака Датадог-а.

Резиме

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

Додатни материјали на ту тему

Кубернетес документи: Конфигуришите пробе за живост и спремност;
Ревидирани Кубернетес-ови тестови за живост и спремност: Како избећи пуцање у другу ногу;
НРЕ Лабс Оутаге Пост-мортем (он такође говори о ливенессПробе).

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

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

ЕЈ ме је подсетио о ПДБ-у: један од проблема са провером животности је недостатак координације између махуна. Кубернетес има Буџети за поремећаје у групи (ПДБ) да ограничи број истовремених грешака које апликација може да доживи, међутим провере не узимају у обзир ПДБ. У идеалном случају, могли бисмо да кажемо К8с да „Поново покрени једну подлогу ако њен тест не успе, али их немој поново покренути све да не би погоршао ствари“.

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

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

Што се тиче читања документације пре употребе: Направио сам одговарајући захтев (будући захтеви) да додате документацију о сондама за животност.

ПС од преводиоца

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

Извор: ввв.хабр.цом

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