🥇Кубернетестегі жандылық зондтары қауіпті болуы мүмкін

Ескерту. аударма: Заландодан келген жетекші инженер Хеннинг Джейкобс Kubernetes пайдаланушылары арасында жандылық (және дайындық) зондтарының мақсатын және оларды дұрыс пайдалануды түсінуде бірнеше рет қиындықтарды байқады. Сондықтан ол өз ойларын осы ауқымды жазбаға жинады, ол ақыр соңында K8s құжаттамасының бөлігі болады.

Денсаулықты тексеру, Кубернетесте белгілі тірілік зондтары (яғни, сөзбе-сөз «өмір сүруге қабілеттілік сынақтары» - шамамен аударма), өте қауіпті болуы мүмкін. Мүмкіндігінше олардан аулақ болуды ұсынамын: ерекше жағдайлар - олар шынымен қажет болғанда және сіз оларды пайдаланудың ерекшеліктері мен салдарын толықтай білесіз. Бұл жарияланымда жандылық пен дайындықты тексеру туралы айтылады, сондай-ақ қандай жағдайларда сізге айтылады құнды және сіз оларды пайдаланбауыңыз керек.

Менің әріптесім Шандор жақында Twitter-де жиі кездесетін қателіктермен бөлісті, соның ішінде дайындық/жандылық зондтарын пайдалануға қатысты:

Қате конфигурацияланған livenessProbe жоғары жүктеме жағдайларын нашарлатуы мүмкін (қар кесектерін өшіру + ықтимал ұзақ контейнер/қолданбаны іске қосу уақыты) және тәуелділіктің төмендеуі сияқты басқа жағымсыз салдарға әкелуі мүмкін (тағы қараңыз) менің соңғы мақалам K3s+ACME комбинациясындағы сұраулар санын шектеу туралы). Тірілік зонды сыртқы деректер базасы болып табылатын денсаулықты тексерумен біріктірілгенде одан да нашар: бір DB қатесі барлық контейнерлерді қайта іске қосады!

Жалпы хабарлама «Тірілік зондтарын қолданбаңыз» бұл жағдайда ол көп көмектеспейді, сондықтан дайындық пен жандылықты тексеру не үшін қажет екенін қарастырайық.

Ескерту: Төмендегі сынақтың көпшілігі бастапқыда Zalando-ның әзірлеуші ішкі құжаттамасына енгізілген.

Дайындық пен жандылықты тексеру

Кубернетес деп аталатын екі маңызды механизмді ұсынады жандылық зондтары және дайындық зондтары. Олар бағдарламаның күтілгендей жұмыс істеп тұрғанын растау үшін HTTP сұрауын жіберу, TCP қосылымын ашу немесе контейнерде пәрменді орындау сияқты кейбір әрекеттерді мерзімді түрде орындайды.

Кубернетес пайдаланады дайындық зондтарыконтейнер трафикті қабылдауға дайын болғанда түсіну. Егер барлық контейнерлер дайын болса, қорап пайдалануға дайын болып саналады. Бұл механизмді пайдаланудың бірі Kubernetes қызметтері (және әсіресе Ingress) үшін сервер ретінде пайдаланылатын подкасттарды басқару болып табылады.

Тірілік зондтары Кубернетеске контейнерді қайта іске қосу уақыты келгенде түсінуге көмектесіңіз. Мысалы, мұндай тексеру қолданба бір жерде тұрып қалған кезде тығырықтан шығуға мүмкіндік береді. Контейнерді осы күйде қайта іске қосу қателерге қарамастан қолданбаны жоюға көмектеседі, бірақ ол сонымен қатар каскадты сәтсіздіктерге әкелуі мүмкін (төменде қараңыз).

Өмірлік/дайындық тексерулерінен өтпеген қолданба жаңартуын орналастыруға әрекеттенсеңіз, Кубернетес күйді күткендіктен, оны шығару тоқтатылады. 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) трафикті қабылдауға дайын болғанда ғана соңғы нүкте OK қайтаратынына көз жеткізіңіз*;
  *Мен Заландода мұндай болмаған кем дегенде бір жағдайды білемін, яғни. readinessProbe Мен «басқару» портын тексердім, бірақ кэшті жүктеу ақауларына байланысты сервердің өзі жұмыс істей алмады.
- Дайындық зондының жеке портқа қосылуы негізгі портқа шамадан тыс жүктелу денсаулықты тексеруде көрсетілмейтініне әкелуі мүмкін (яғни сервердегі жіп пулы толы, бірақ денсаулықты тексеру бәрібір бәрі дұрыс екенін көрсетеді. ).
Бұған көз жеткізіңіз Дайындық тексеруі дерекқорды инициализациялау/тасымалдауға мүмкіндік береді;
- Бұған қол жеткізудің ең оңай жолы – инициализация аяқталғаннан кейін ғана HTTP серверімен байланысу (мысалы, дерекқорды келесіден тасымалдау). Ұшу жолы және т.б.); яғни денсаулықты тексеру күйін өзгертудің орнына дерекқорды тасымалдау аяқталғанша веб-серверді іске қоспаңыз*.
  * Сондай-ақ, дерекқорды тасымалдауды подкасттың сыртындағы init контейнерлерінен іске қосуға болады. Мен әлі де дербес қосымшалардың жанкүйерімін, яғни қолданбалар контейнері дерекқорды сыртқы үйлестірусіз қалаған күйге қалай жеткізуге болатынын біледі.
Пайдаланыңыз httpGet әдеттегі денсаулық тексеру нүктелері арқылы дайындықты тексеру үшін (мысалы, /health).
Әдепкі тексеру параметрлерін түсіну (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
- әдепкі опциялар подводтың болатынын білдіреді дайын емес шамамен 30 секундтан кейін (3 сәтсіз есі дұрыс тексеру).
Технологиялық стек (мысалы, Java/Spring) рұқсат берсе, денсаулық пен көрсеткіштерді басқаруды қалыпты трафиктен бөлу үшін «әкімші» немесе «басқару» үшін бөлек портты пайдаланыңыз:
- бірақ 2-тармақты ұмытпаңыз.
Қажет болса, дайындық зондын кэшті жылыту/жүктеу және контейнер жылығанша 503 күй кодын қайтару үшін пайдалануға болады:
- Мен сізге жаңа чекті оқып шығуды ұсынамын startupProbe, 1.16 нұсқасында пайда болды (біз бұл туралы орыс тілінде жаздық осында - шамамен. аудар.).

Ескертулер

Сыртқы тәуелділіктерге сенбеңіз (мысалы, деректер қоймалары) дайындық/тұрақтылық сынақтарын орындау кезінде - бұл каскадты сәтсіздіктерге әкелуі мүмкін:
- Мысал ретінде, бір Postgres дерекқорына байланысты 10 позициясы бар жай-күйі бар REST қызметін алайық: тексеру ДҚ-ға жұмыс қосылымына байланысты болғанда, желі/ДҚ жағында кідіріс болса, барлық 10 подкаст істен шығуы мүмкін - әдетте ол бәрі мүмкін болғаннан да жаман аяқталады;
- Spring Data әдепкі бойынша дерекқор қосылымын тексеретінін ескеріңіз*;
  * Бұл Spring Data Redis әдепкі әрекеті (кем дегенде бұл мен соңғы рет тексердім), бұл «апаттық» сәтсіздікке әкелді: Redis қысқа уақытқа қолжетімсіз болған кезде, барлық подкладкалар «бұзылды».
- Бұл мағынада «сыртқы» сол қолданбаның басқа тармақтарын да білдіруі мүмкін, яғни каскадты бұзылулардың алдын алу үшін тексеру сол кластердің басқа түйіндерінің күйіне тәуелді болмауы керек:
  - Нәтижелер таратылған күйі бар қолданбалар үшін әр түрлі болуы мүмкін (мысалы, подкасттарда жадтағы кэштеу).
Тірілік зондын пайдаланбаңыз бөтелкелер үшін (ерекше жағдайлар - олар шынымен қажет және сіз оларды пайдаланудың ерекшеліктері мен салдары туралы толық хабардарсыз):
- Тірілік зонды ілулі тұрған контейнерлерді қалпына келтіруге көмектесе алады, бірақ қолданбаны толық басқара алатындықтан, ілулі процестер мен тығырықтан шығу сияқты жағдайлар орын алмау керек: ең жақсы балама - қолданбаны әдейі бұзып, оны бұрынғы тұрақты күйге қайтару;
- сәтсіз жандылық зонды контейнерді қайта іске қосады, осылайша жүктеуге қатысты қателердің салдарын күшейтеді: контейнерді қайта іске қосу тоқтап қалуға әкеледі (кем дегенде қолданбаны іске қосу уақытында, айталық, 30 тақ секунд), жаңа қателерді тудырады , басқа контейнерлерге жүктемені арттыру және олардың істен шығу ықтималдығын арттыру және т.б.;
- Сыртқы тәуелділікпен біріктірілген өмірлік тексерулер ең нашар ықтимал комбинация болып табылады, бұл каскадты сәтсіздіктерге қауіп төндіреді: дерекқор жағындағы сәл кідіріс барлық контейнерлердің қайта іске қосылуына әкеледі!
Жандылық пен дайындықты тексеру параметрлері әртүрлі болуы керек:
- бірдей денсаулық тексеруі бар, бірақ жауап шегі жоғарырақ (failureThreshold), мысалы, күйді тағайындаңыз дайын емес 3 әрекеттен кейін және тірілік зондының 10 әрекеттен кейін сәтсіз аяқталды деп есептеңіз;
Exec тексерулерін пайдаланбаңыз, өйткені олар зомби процестерінің пайда болуына әкелетін белгілі мәселелермен байланысты:
- толығырақ: қараңыз Datadog мамандарының презентациясы.

Резюме

Қосқыш трафикті қабылдауға қашан дайын екенін анықтау үшін дайындық зондтарын пайдаланыңыз.
Жандылық зондтарын олар шынымен қажет болғанда ғана пайдаланыңыз.
Дайындық/өмірлік зондтарды дұрыс пайдаланбау қолжетімділіктің төмендеуіне және каскадты сәтсіздіктерге әкелуі мүмкін.

Тақырып бойынша қосымша материалдар

Жаңартылған № 1 2019 ж

Дерекқорды тасымалдауға арналған init контейнерлері туралы: Сілтеме қосылды.

Едж есіме түсірді PDB туралы: тірілікті тексеруге қатысты мәселелердің бірі - бөтелкелер арасындағы үйлестірудің болмауы. Кубернетес бар Pod бұзу бюджеттері (PDB) қолданбада болуы мүмкін қатарлас сәтсіздіктердің санын шектеу үшін, бірақ тексерулер PDB ескермейді. Ең дұрысы, біз K8-ге «Егер сынақ сәтсіз болса, бір подкастты қайта іске қосыңыз, бірақ жағдайды нашарлатпау үшін барлығын қайта іске қоспаңыз» деп айта аламыз.

Брайан оны тамаша айтты: «Нақты білетін болсаңыз, жандылықты зондтауды пайдаланыңыз Ең жақсы нәрсе - қолданбаны жою«(қайтадан, ренжімеңіз).

Жаңартылған № 2 2019 ж

Қолданар алдында құжаттаманы оқуға қатысты: Сәйкес сұрауды жасадым (мүмкіндік туралы сұрау) жандылық зондтары туралы құжаттаманы қосу.

Аудармашыдан PS

Біздің блогта да оқыңыз:

Ақпарат көзі: www.habr.com

Кубернетестегі тіршілік зондтары қауіпті болуы мүмкін