Розподіленими системами буває важко керувати через те, що в них є безліч рухливих елементів, що змінюються, і всі вони повинні нормально працювати для забезпечення функціональності системи. Якщо один із елементів вийде з ладу, то система повинна його виявити, обійти та виправити, причому все це потрібно робити автоматично. У цій серії «Kubernetes Best Practices» ми дізнаємось, як налаштовувати тести Readiness та Liveness для перевірки життєздатності кластера Kubernetes.
Перевірка здоров'я Health Check - це простий спосіб дозволити системі знати, чи працює екземпляр вашої програми чи ні. Якщо екземпляр вашої програми не працює, інші служби не повинні звертатися до нього або надсилати йому запити. Натомість запит повинен бути надісланий іншому примірнику програми, який вже запущено або запуститься пізніше. Крім того, система повинна повернути вашому додатку втрачену працездатність.
За замовчуванням Kubernetes почне відправляти трафік у pod, коли всі контейнери всередині подів будуть запущені, та перезавантажувати контейнери, коли вони аварійно завершать роботу. Для початку така поведінка системи за умовчанням може бути досить хорошим, проте ви можете підвищити надійність розгортання свого продукту, використовуючи перевірки перевірки працездатності.
На щастя, Kubernetes дозволяє зробити це досить просто, тому ігнорування подібних перевірок немає жодних виправдань. Kubernetes надає два типи тестів Health Check, причому важливо розуміти відмінності у застосуванні кожного з них.
Тест готовності Readiness призначений для того, щоб повідомляти Kubernetes про готовність вашої програми обслуговувати трафік. Перш ніж дозволити сервісу відправити трафік у pod, Kubernetes має переконатися в успішності перевірки готовності. Якщо тест Readiness дасть збій, Kubernetes припинить відправляти трафік у під, доки тестування не пройде успішно.
Тест життєздатності Liveness повідомляє Kubernetes про те, жваво чи мертво ваше застосування. У першому випадку Kubernetes дасть йому спокій, у другому видалить мертвий pod і замінить його новим.
Давайте уявимо сценарій, в якому вашому додатку на «розігрів» і запуск потрібно 1 хвилина. Ваш сервіс не почне працювати, поки програма повністю не завантажиться і не запуститься, хоча робочий процес вже почався. Причому у вас також виникнуть проблеми, якщо ви захочете збільшити масштаб цього розгортання до кількох копій, адже ці копії не повинні отримувати трафік доти, доки вони не будуть повністю готові. Однак за замовчуванням Kubernetes запустить відправку трафіку відразу після початку процесів усередині контейнера.
При використанні тесту готовності Readiness, Kubernetes буде чекати, поки програма не буде повністю запущена і тільки після цього дозволить сервісу надсилати трафік на нову копію.
Давайте уявімо інший сценарій, при якому програма зависає на тривалий час, перестаючи обслуговувати запити. Оскільки процес продовжує виконуватися, за замовчуванням Kubernetes вважатиме, що все гаразд і продовжить надсилати запити на неробочий pod. Але при використанні Liveness, Kubernetes виявить, що програма більше не обслуговує запити і за замовчуванням перезапустить неробочий pod.
Розглянемо, за допомогою чого тестується готовність та життєздатність. Існує три способи тестування – HTTP, Сommand та TCP. Для перевірки можна використовувати будь-який з них. Найбільш поширений спосіб тесту користувача - це HTTP probe.
Навіть якщо ваша програма не є HTTP-сервером, ви все одно можете створити легковажний HTTP-сервер усередині вашої програми для взаємодії з тестом Liveness. Після цього Kubernetes почне пінгувати pod, і якщо відповідь HTTP перебуватиме в діапазоні 200 або 300 мс, це означатиме, що pod «здоровий». В іншому випадку модуль буде позначений як "хворий".
Для тестів за допомогою Command Kubernetes виконує команду усередині вашого контейнера. Якщо команда повертається з нульовим exit code, контейнер буде позначений як здоровий, в іншому випадку, при отриманні числа exit status від 1 до 255, контейнер буде відзначений як «хворий». Цей спосіб тестування корисний, якщо ви не можете або не хочете запускати HTTP-сервер, але здатні запустити команду, яка перевірить здоров'я вашої програми.
Останній механізм перевірки – це тест TCP. Kubernetes спробує встановити з'єднання TCP на вказаному порту. Якщо це вдається зробити, контейнер вважається здоровим, якщо ні – нежиттєздатним. Цей спосіб може стати в нагоді, якщо ви використовуєте сценарій, при якому тестування за допомогою HTTP-запиту або виконання команди працює не дуже добре. Наприклад, основними сервісами для перевірки за допомогою TCP будуть gRPC або FTP.
Тести можна налаштувати кількома способами з різними параметрами. Ви можете вказати, як часто вони повинні виконуватися, які порогові значення успіху та невдачі, як довго чекати на відповіді. Більш детальну інформацію викладено у документації до тестів Readiness та Liveness. Однак є один дуже важливий момент у налаштуванні тесту Liveness – початкове встановлення затримки тестування initialDelaySeconds. Як я згадував, невдале виконання цього тесту призведе до перезапуску модуля. Тому вам потрібно переконатися, що тестування не почнеться до тих пір, поки програма не буде готова до роботи, інакше вона почне циклічно перезапускатися. Я рекомендую використовувати час стартапу P99 або середній час запуску програми з буфера. Не забувайте коригувати це значення в міру того, як час запуску вашої програми стає все швидше або сповільнюється.
Більшість фахівців підтвердить, що Health Check є обов'язковою перевіркою для будь-якої розподіленої системи, і Kubernetes не є винятком. Використання перевірки «здоров'я» сервісів забезпечує надійну та безвідмовну роботу Kubernetes і не складає для користувачів жодних труднощів.
Продовження буде зовсім скоро.
Небагато реклами 🙂
Дякую, що залишаєтеся з нами. Вам подобаються наші статті? Бажаєте бачити більше цікавих матеріалів? Підтримайте нас, оформивши замовлення або порекомендувавши знайомим, , унікальний аналог entry-level серверів, який був винайдений нами для Вас: (Доступні варіанти з RAID1 і RAID10, до 24 ядер і до 40GB DDR4).
Dell R730xd вдвічі дешевше в дата-центрі Equinix Tier IV в Амстердамі? Тільки в нас у Нідерландах! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – від $99! Читайте про те
Джерело: habr.com