Сонди за готовност и жизненост на Kubernetes - най-добри практики

„Човек, гледащ живопис“ от Атена на Unsplash

В Kubernetes шушулките са най-малките разгъваеми единици на изчисления, които могат да бъдат създадени и управлявани. Една шушулка е група от един или повече контейнери (Докер, ракета и т.н.) със споделено хранилище / мрежа и спецификация за това как да стартирате контейнерите.

Проверките за готовност и оживление могат да бъдат извикани в контекста на Kubernetes Health Checkes. Съдовете за контейнери са малки процеси, които протичат периодично. Резултатът от тези сонди (успех, неуспех или неизвестност) определя Kubernetes перспектива за състоянието на контейнера. Въз основа на тях Kubernetes решава как да обработва всеки контейнер, за да поддържа устойчивост, висока наличност и по-висока продължителност на работа.

Здравните проверки са изискване за всяка разпределена система!

Проверки на здравето на Kubernetes:

Kubernetes предлага два вида здравни проверки: готовност и жизненост и двамата имат собствено предназначение. В контекста на тази статия ще изберете:

  • /.well-known/live - за HTTP сонда на живо
  • /.well- unknown/ready - за HTTP сонда

С няколко думи HTTP сондата означава, че Kubernetes изпълнява през определени интервали от време HTTP Получаване на заявки на /.well-known/live и /.well-known/ready. Кодът на състоянието на отговора се използва, за да се реши какво трябва да се направи с шушулката. Ако кодът на състоянието е в интервала [200, 300), тогава всичко е наред. В противен случай:

  • ако състоянието на кода на сондата на живо е 4xx или 5xx, шушулката се рестартира
  • ако състоянието на кода за готовата сонда е 4xx или 5xx, тогава шушулката е маркирана като нездравословна и HTTP трафик вече няма да бъде пренасочен към нея за повишаване на надеждността и продължителността на работа.
Ако контейнерите са независими от всякакви резервни услуги, контейнерите могат да бъдат подложени на проверки за жизнеспособност и готовност на един и същ манипулатор и следващото не се прилага.

Заедно с съотборници от Metro Systems Romania - Екип за надеждност на сайта, ние идентифицирахме списък с най-добри практики за здравните проверки и посъветвахме разработчиците на приложения да ги следват. Такива най-добри практики са:

  1. Манипулаторите на Live & Ready трябва да бъдат независими функции!

Както беше споменато по-горе, за всеки продукт, внедрен в контекста на Kubernetes, трябва да се приложат 2 обработващи, които отговарят на HTTP обаждания за „на живо“ и „готово“. Първата най-добра практика по отношение на тези сонди е, че всеки манипулатор трябва да има своя собствена функция.

2. Не отделяйте логиката за „живо“ / „готово“ от приложението си!

Това е приложимо за приложения за обработка на задания. За Kubernetes е важно да знаят дали приложението за обработка работи или не. Ако логиката за live / ready беше отделена в нов процес, резултатът не е категоричен.

3. Не прилагайте никаква логика на "живия" манипулатор. Необходимо е да върне статус 200, ако основната нишка работи и 5xx, ако не е.

Тази сонда позволява на Kubernetes да знае дали приложението е живо или мъртво. Решението се взема, като се провери кодът за състояние за /.well-known/live и ако приложението бъде обявено за мъртво, Kubernetes рестартира шушулката. От гледна точка на надеждността, отговорът на сондата на живо трябва да е истина, ако основната тема на приложението е стартирана и работи невярна в противен случай.

В този контекст „логика“ означава извършване на някакъв вид проверки на взаимосвързаните услуги.

4. Внедрете логиката в „готов“ манипулатор, за да предложите пълен отговор за готовността на приложението.

Готовата сонда позволява на Kubernetes да знае дали шушулката е готова да получава HTTP трафик. Като програмист е важно да приложите тук някаква логика, за да проверите наличността на всичките си резервни зависимости за приложението. Когато „готовият“ манипулатор е приложен, е много важно ясно да знаете какво готово наистина означава за вашето приложение. С други думи, в „готовия“ манипулатор е важно да изпълните всички стъпки, които определят, че приложението е готово да получава и да обработва https заявки. Например, ако приложението трябва да установи връзка с база данни, за да бъде готово да обработва HTTP заявки, сондата за готовност е от съществено значение, за да проверите дали връзката с базата данни е установена и готова ли е да се използва.

Нека разгледаме конкретен случай: приложението се блокира, като прави някаква обработка на отделна тема, но основната нишка работи добре. Като разработчик знаете, че рестартирането на pod ще реши проблема и можете да убедите Kubernetes да го извърши автоматично за вас. Всичко, което трябва да направите, е да се уверите, че приложението отговаря с 5xx на готовата сонда и да принуди сондата на живо да върне минимално количество от 5xx отговори при повиквания от Kubernetes. В този случай Kubernetes ще рестартира шушулката, защото се счита за мъртъв.

5. Не се опитвайте да установите отново състоянието на готовност на приложението на готовия манипулатор. Това се прави само, за да се провери дали приложението е готово, а не да го направи готово.

Препоръчва се, че няма въведена логика, която да се опитва да възстанови състоянието на готовност. Наличието на такава логика може да бъде опасно за някои от компонентите на системата.

Изводи:

Сондите на живо и готови са сърцето и душата на приложенията, внедрени в Kubernetes. Те са стандартните начини да общуват с хипервизора и да говорят за техния статус и техните проблеми. Живите и готови сонди са мощни оръжия, от които разработчикът и приложението се нуждаят, за да се уверят, че приложението е надеждно и еластично.

Специални благодарности на Ionut Ilie. Част от този материал е резултат от неговите изследвания и мъдрост.