Ang liveness probe sa Kubernetes mahimong delikado

Nota. transl.: Ang nanguna nga inhenyero gikan sa Zalando, Henning Jacobs, balik-balik nga nakamatikod sa mga problema sa mga tiggamit sa Kubernetes sa pagsabot sa katuyoan sa liveness (ug pagkaandam) nga mga pagsusi ug sa hustong paggamit niini. Busa, gikolekta niya ang iyang mga hunahuna niining lapad nga nota, nga sa kadugayan mahimong bahin sa dokumentasyon sa K8s.

Ang mga pagsusi sa kahimsog, nailhan sa Kubernetes nga liveness probes (т.е., дословно, «тесты на жизнеспособность» — прим. перев.), могут быть весьма опасными. Рекомендую по возможности избегать их: исключениями являются только случаи, когда они действительно необходимы и вы полностью осознаете специфику и последствия их использования. В этой публикации речь пойдет о liveness- и readiness-проверках, а также будет рассказано, в каких случаях bililhon и не стоит их применять.

Мой коллега Sandor недавно поделился в Twitter’е самыми частыми ошибками, которые ему встречаются, в том числе связанными с использованием readiness/liveness probes:

Неправильно настроенная livenessProbe mahimong makapasamot sa mga sitwasyon nga taas ang karga (snowball shutdown + posibleng taas nga container/application startup time) ug mosangpot sa uban pang negatibong resulta sama sa dependency drops (tan-awa usab akong bag-o nga artikulo об ограничении числа запросов в связке K3s+ACME). Mas grabe pa kung ang liveness probe gihiusa sa usa ka pagsusi sa kahimsog, nga usa ka eksternal nga database: единственный сбой БД перезапустит все ваши контейнеры!

Общий посыл «Не используйте liveness probes» sa niini nga kaso kini dili makatabang kaayo, mao nga atong tan-awon sa unsa ang kaandam ug liveness pagsusi alang sa.

Примечание: бόльшая часть приведенного ниже теста изначально была включена во внутреннюю документацию для разработчиков Zalando.

Проверки Readiness и Liveness

Ang Kubernetes naghatag og duha ka importante nga mekanismo nga gitawag liveness probes ug ready probes. Kanunay nilang gihimo ang pipila ka aksyon—sama sa pagpadala og HTTP nga hangyo, pag-abli og koneksyon sa TCP, o pagpatuman og command sa sudlanan—aron makumpirma nga ang aplikasyon nagtrabaho sama sa gipaabot.

Gigamit sa Kubernetes readiness probes, чтобы понять, когда контейнер готов принимать трафик. Pod считается готовым к работе, если все его контейнеры готовы. Одно из применений этого механизма состоит в том, чтобы контролировать, какие pod’ы используются в качестве бэкендов для сервисов Kubernetes (и особенно Ingress’а).

Liveness nga pagsusi tabangi ang mga Kubernetes nga masabtan kung panahon na nga i-restart ang sudlanan. Pananglitan, ang ingon nga tseke nagtugot kanimo sa pag-intercept sa usa ka deadlock kung ang usa ka aplikasyon ma-stuck sa usa ka lugar. Ang pag-restart sa sudlanan niini nga estado makatabang sa pagkuha sa aplikasyon gikan sa yuta bisan pa sa mga kasaypanan, apan mahimo usab kini nga mosangpot sa mga kapakyasan sa cascading (tan-awa sa ubos).

Если вы попытаетесь развернуть обновление приложения, которое проваливает проверки liveness/readiness, его выкатывание застопорится, поскольку Kubernetes будет ждать статуса Ready gikan sa tanang pod.

Pananglitan:

Ania ang usa ka pananglitan sa usa ka kaandam nga pagsusi sa usa ka agianan /health через HTTP с настройками по умолчанию (agianan: 10 секунд, timeout: 1 секунда, sukdanan sa kalampusan: 1, kapakyasan threshold: 3):

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

rekomendasyon

1. Para sa mga microservice nga adunay HTTP endpoint (REST, etc.) всегда определяйте readiness probe, которая проверяет, готово ли приложение (pod) принимать трафик.
2. Убедитесь, что readiness probe покрывает готовность фактического порта веб-сервера:
   • gamit ang mga pantalan alang sa administratibo nga katuyoan, gitawag nga "admin" o "pagdumala" (pananglitan, 9090), alang sa readinessProbe, убедитесь, что endpoint возвращает ОК только в том случае, если основной HTTP-порт (вроде 8080) готов принимать трафик*;

     *Nakahibalo ko nga bisan usa ka kaso sa Zalando kung diin wala kini nahitabo, i.e. readinessProbe проверила порт «management», но сам сервер так и не начал работать из-за проблем с загрузкой кэша.

   • Ang paglakip sa usa ka andam nga pagsusi sa usa ka lahi nga pantalan mahimong mosangpot sa kamatuoran nga ang sobra nga gibug-aton sa main port dili makita sa pagsusi sa kahimsog (nga mao, ang thread pool sa server puno, apan ang pagsusi sa kahimsog nagpakita gihapon nga OK ra ang tanan. ).
3. Siguruha nga Ang pagkaandam nga pagsusi makahimo sa database initialization/migration;
   • Ang pinakasayon ​​nga paagi aron makab-ot kini mao ang pagkontak sa HTTP server human lang makompleto ang initialization (pananglitan, pagbalhin sa database gikan sa Flyway и т.п.); то есть вместо того, чтобы менять статус health check’а, просто не запускайте веб-сервер до завершения миграции БД*.

     * Также можно запускать миграции БД из init-контейнеров снаружи pod’а. Я по-прежнему являюсь поклонником самостоятельных (self-contained) приложений, то есть таких, в которых контейнер приложения без внешней координации знает, как привести БД в нужное состояние.

4. Paggamit httpGet для readiness-проверок через типичные endpoint’ы health check’ов (например, /health).
5. Sabta ang default check parameters (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • ang default nga mga kapilian nagpasabot nga ang pod mahimong not-ready human sa mga 30 segundos (3 napakyas sa sanity checks).
6. Paggamit ug bulag nga pantalan para sa "admin" o "pagdumala" kung ang teknolohiya stack (e.g. Java/Spring) nagtugot niini, sa pagbulag sa panglawas ug metrics management gikan sa regular nga trapiko:
   • pero ayaw kalimti ang point 2.
7. При необходимости readiness probe можно использовать для разогрева/загрузки кэша и возвращать код состояния 503, пока контейнер не «разогреется»:
   • Girekomenda ko usab nga basahon nimo ang bag-ong tseke startupProbe, nagpakita sa bersyon 1.16 (мы писали о ней на русском dinhi - gibanabana. transl.).

Mga Kaayuhan

1. Не полагайтесь на внешние зависимости (sama sa mga bodega sa datos) kung nagpadagan sa mga pagsulay sa pagkaandam/kabuhayan - mahimo’g mosangput kini sa mga kapakyasan sa kaskad:
   • в качестве примера возьмем stateful-сервис REST с 10-ю pod’ами, зависящими от одной базы данных Postgres: когда проверка зависит от работающего подключения к БД, все 10 pod’ов могут упасть, если возникнет задержка в сети/на стороне БД — обычно все это заканчивается хуже, чем могло бы;
   • обратите внимание, что Spring Data по умолчанию проверяет соединение с БД*;

     * Таково поведение по умолчанию Spring Data Redis (по крайней мере, оно было таким, когда я проверял в прошлый раз), что привело к «катастрофическому» сбою: когда на короткое время Redis оказался недоступен, все pod’ы «упали».

   • Ang "eksternal" niini nga diwa mahimo usab nga magpasabot sa ubang mga pod nga parehas nga aplikasyon, nga mao, ang tseke kinahanglan dili magdepende sa kahimtang sa ubang mga pod sa parehas nga cluster aron malikayan ang mga pag-crash sa cascading:
     • результаты могут варьироваться для приложений с распределенным состоянием (например, in-memory-кэширование в pod’ах).
2. Не используйте liveness probe alang sa mga pod (mga eksepsiyon kay mga kaso kung gikinahanglan gyud kini ug hingpit ka nga nakahibalo sa mga detalye ug mga sangputanan sa ilang paggamit):
   • Ang liveness probe makatabang sa pagbawi sa gibitay nga mga sudlanan, apan tungod kay ikaw adunay bug-os nga kontrol sa imong aplikasyon, ang mga butang sama sa gibitay nga mga proseso ug mga deadlock kinahanglan nga dili mahitabo: ang labing maayo nga alternatibo mao ang tinuyo nga pag-crash sa aplikasyon ug ibalik kini sa kaniadto nga makanunayon nga kahimtang;
   • неудавшаяся liveness probe приведет к перезапуску контейнера, тем самым потенциально усугубляя последствия ошибок, связанных с загрузкой: перезапуск контейнера приведет к простою (по крайней мере, на время запуска приложения, скажем, на 30 с лишним секунд), вызывая новые ошибки, увеличивая нагрузку на другие контейнеры и повышая вероятность их сбоя, и т.д.;
   • liveness-проверки в сочетании с внешней зависимостью — худшая из возможных комбинаций, грозящая каскадными отказами: незначительная задержка на стороне БД приведет к перезапуску всех ваших контейнеров!
3. Parameter sa liveness ug kaandam checks kinahanglan nga lahi:
   • mahimo nimong gamiton ang liveness probe nga adunay parehas nga pagsusi sa kahimsog, apan mas taas nga sukaranan sa pagtubag (failureThreshold), например, присваивать статус not-ready после 3 попыток и считать, что liveness probe провалился после 10 попыток;
4. Не используйте exec-проверки, поскольку с ними связаны известные проблемы, приводящие к появлению зомби-процессов:
   • mga detalye: tan-awa выступление специалистов компании Datadog.

Sumaryo

• Используйте readiness probes, чтобы определить, когда pod готов принимать трафик.
• Gamita lang ang liveness probes kung gikinahanglan gyud kini.
• Ang dili husto nga paggamit sa mga probe sa pagkaandam/liveness mahimong mosangpot sa pagkunhod sa pagkaanaa ug mga kapakyasan sa cascading.

Dugang nga mga materyal sa hilisgutan

• Kubernetes docs: I-configure ang Liveness ug Readiness Probes;
• Ang Kubernetes Liveness ug Readiness Probes Gisusi pag-usab: Unsaon Paglikay sa Pagpusil sa Imong Kaugalingon sa Ubang Tiil;
• Ang NRE Labs Outage Post-Mortem (рассказывает и про livenessProbe).

Обновление №1 от 2019-09-29

Mahitungod sa init nga mga sudlanan alang sa paglalin sa database: добавлена сноска.

EJ напомнил мне о PDB: одна из бед liveness-проверок — отсутствие координации между pod’ами. В Kubernetes есть Pod Disruption Budgets (PDB) aron limitahan ang gidaghanon sa dungan nga mga kapakyasan nga masinati sa usa ka aplikasyon, bisan pa ang mga tseke wala magtagad sa PDB. Sa tinuud, mahimo namon isulti ang mga K8 nga "I-restart ang usa ka pod kung mapakyas ang pagsulay niini, apan ayaw i-restart silang tanan aron malikayan ang paghimo sa mga butang nga mas grabe."

Bryan отлично сформулировал: «Используйте liveness-зондирование, когда точно знаете, что лучшее, что можно сделать, — это «убить» приложение» (опять же, увлекаться не стоит).

Обновление №2 от 2019-09-29

Mahitungod sa pagbasa sa dokumentasyon sa dili pa gamiton: Gibuhat nako ang katugbang nga hangyo (hangyo sa bahin) aron idugang ang dokumentasyon bahin sa liveness probes.

PS gikan sa tighubad

Basaha usab sa among blog:

• «Kubernetes: жизнь пода";
• «7 labing maayo nga mga gawi sa paggamit sa mga sudlanan sumala sa Google";
• «7 Mga Prinsipyo sa Pagdesinyo sa mga Aplikasyon nga Gibase sa Container".

Source: www.habr.com