HAProxy Ingress Controller у Kubernetes: балансування, TCP, моніторинг

HAProxy Ingress Controller: вузькі місця балансування в кластері

HAProxy Ingress Controller майже завжди виявляється єдиною точкою входу в кластер: через неї проходить весь зовнішній трафік, і її відмова означає недоступність усіх сервісів одразу.

На спокійному навантаженні це непомітно, але як тільки з'являються довгі з'єднання — потокове відео, постійні канали зв'язку, стрімінгові виклики між сервісами — картина змінюється.

Контролер перестає бути прозорим посередником і перетворюється на вузьке місце, яке визначає, скільки запитів взагалі доїде до подів.

Перше слабке місце — маршрутизація довгих з'єднань. За замовчуванням балансувальник розкладає запити між подами, але при оновленні релізу поды перестворюються, і вже встановлені сесії рвуться на середині.

Без коректного дренажу з'єднань і балансування за кількістю активних потоків, а не лише за новими запитами, клієнти отримують обриви при кожному викаті.

Окрема складність — потокове балансування в кластері: для TCP-навантаження частина звичних правил маршрутизації на рівні HTTP просто не застосовується, і рішення доводиться приймати на вхідному шарі.

Друге — спостережуваність трафіку. Якщо не збирати метрики розподілу за бекендами, статистику часу відповіді та частку відмов, деградація виглядає як «у користувачів іноді не відкривається». Інженер не бачить, що один под забирає майже весь потік, а решта простоюють.

Розбираємо, як це закривається: як прибрати єдину точку відмови на вході, налаштувати балансування потокових з'єднань і отримати спостережуваність за розподілом запитів.

Що дає виділений вхідний шар: вимірюваний ефект

Перший вимірюваний ефект — частка успішних з'єднань. Коли вхідний шар тримає з'єднання і чекає на відповідь застосунку, обриви при викаті нової версії та перезапуску вузлів не доходять до клієнта: частка успішних запитів зростає з 97–98% до 99,9%. Збої залишаються в метриках, а не в зверненнях користувачів.

Другий — час перемикання при відмові. Перевірки доступності виводять вузол, що не відповів, з ротації за секунди, трафік переходить на живі, втручання чергового не потрібне. До цього така відмова означала хвилини недоступності для частини користувачів і ручний розбір причин.

Третій — поведінка при піковому навантаженні. Вхідний шар обмежує кількість одночасних з'єднань до кожного застосунку і ставить зайві в чергу, тому сплеск не перетворюється на каскадну відмову: вузли отримують рівно стільки, скільки встигають обробити.

Заодно із застосунків знімається все, що не стосується логіки — шифрування, стиснення відповідей, віддача статики.

Четвертий — зниклий клас відмов, коли єдиний вузол тримає весь трафік і його падіння валить сервіс. Точки входу резервуються, стан ротації відновлюється автоматично, а перезапуск окремого вузла перестає бути подією.

Збираємо такий шар на HAProxy і переносимо на нього маршрутизацію, перевірки доступності та метрики.

За цими величинами і приймаємо роботу: якщо частка успішних з'єднань не зросла, час перемикання не скоротився, а застосунки, як і раніше, витрачають ресурс на службові задачі — задача не вирішена.

Режими роботи Ingress: порівняння підходів

Вхідний шар можна тримати всередині кластера або винести перед ним — від цього залежить, хто володіє зовнішньою адресою, де завершується шифрування і як навантаження розкладається по робочих вузлах.

Контролер на HAProxy працює в обох режимах, тому вибір диктує не інструмент, а топологія. Нижче — три схеми з їхньою ціною супроводу.

Починати варто з питання, скільки середовищ має відповідати за однією адресою і чи є трафік, який не є веб-запитом. Якщо так, гібридна схема виявляється дешевшою в експлуатації, ніж спроби провести все через один вхідний шар.

Порядок впровадження: від аудиту до передачі в експлуатацію

Замовник зазвичай приходить із симптомом: вхідний шар перестав справлятися, частина запитів іде в таймаут, а при оновленні релізу трафік на кілька секунд зникає зовсім. Далі починається пошук винного — застосунок, мережа чи балансувальник. Ми ведемо роботи так, щоб на кожному переході був перевірюваний артефакт, а не усне «стало краще».

1. Аудит схеми трафіку. Збираємо карту: які сервіси приймають зовнішній трафік, де потрібен наскрізний TCP, де достатньо HTTP, які таймаути та ліміти з'єднань задані зараз. Результат — перелік вузьких місць з прив'язкою до конкретного маршруту.

2. Проєктування вхідного шару. Визначаємо кількість реплік контролера, розміщення за зонами доступності, розподіл ролей між ними, схему сертифікатів і порядок оновлення без простою. Результат — схема та специфікація конфігурації.

3. Налаштування контролера. Переносимо правила маршрутизації, перевірки доступності бекендів, обмеження за кількістю з'єднань і політики повторів в описи ресурсів кластера. Результат — конфігурація в системі контролю версій, відтворювана з нуля.

4. Моніторинг і оповіщення. Виводимо метрики балансування та стан бекендів на панелі, налаштовуємо оповіщення на зростання частки помилок і на випадіння вузлів. Результат — збій видно до звернення користувачів.

5. Перевірка відмовостійкості. По черзі гасимо репліки та цілі зони, фіксуємо час перемикання і кількість втрачених запитів. Результат — протокол випробувань з фактичними значеннями.

6. Навантажувальна перевірка. Прогоняємо профіль, близький до пікового, з тривалим утриманням і різким зростанням. Результат — граничні значення за запитами на секунду та точки деградації.

7. Передача в експлуатацію. Віддаємо регламент оновлення та відкату, схему доступів, інструкції для чергової зміни і розбір типових відмов. Результат — команда замовника змінює конфігурацію та відновлює шар самостійно.

Конфігурації, схеми та політики доступу

Після впровадження у команди замовника залишається не «налаштований балансувальник», а комплект артефактів, за якими вхідний шар можна супроводжувати і відтворювати без автора.

Конфігурація живе в репозиторії під контролем версій, зміни проходять рев'ю і застосовуються однаково в тестовому та промисловому середовищі.

• Конфігурація вхідного шару — файли та маніфести в репозиторії, розбиті за середовищами; жодне правило не правиться руками на живому вузлі.
• Схема потоків трафіку — шлях від зовнішньої адреси до контейнера: де завершується шифрування, внутрішні порти, таймаути, утримання сесії на одному екземплярі, проби готовності.
• Карта маршрутизації — домени, шляхи, заголовки та пріоритети правил із зазначенням, який сервіс за яким правилом стоїть.
• Політики доступу та ролі — рольова модель, розподіл прав між черговим, розробником і адміністратором, журнал дій.
• Регламент обслуговування — як підключити новий сервіс або змінити сертифікат, як оновити правила без простою і що перевіряється після.
• Інструкція з відкату — повернення до попередньої версії конфігурації однією операцією, із зазначенням часу відновлення та відповідального.
• Моніторинг вхідного шару — набір метрик, пороги спрацювання та порядок дій чергового при виході за них.

Кейс: перенесення робочого навантаження на виділений вхідний шар

До: вхідний шар ділив вузли із застосунками

Вхідний трафік ішов через той самий пул вузлів, де працювали застосунки та фонові завдання. При почерговому оновленні вхідні процеси завершувалися разом із відкритими з'єднаннями — клієнти бачили обриви на довгих вигрузках і потокових запитах.

Частка втрачених з'єднань у момент оновлення сягала 1,7%, а відмова вузла перемикала трафік за 60–90 секунд.

Окрема стаття — звернення до підтримки: 10–15 на місяць, частина з одним і тим самим формулюванням «під час оновлення все відвалилося». Інженери розбирали інциденти замість задач розвитку.

Що змінили

Вхідний шар винесли на окремий пул вузлів і зібрали на HAProxy Ingress Controller.

Перевірки доступності налаштували з коротким інтервалом і порогом відмов, час очікування підібрали під профіль навантаження: довгі запити не обриваються, неробочий вузол швидко виводиться з балансування.

Перед оновленням вузол переводиться в режим виведення — нові з'єднання на нього не йдуть, активні завершуються штатно.

Конфігурацію перевіряємо до застосування, тому помилка не йде в роботу. Частка помилок за кожним маршрутом, час відгуку та кількість активних з'єднань виведені в загальний моніторинг — інцидент видно раніше за звернення користувачів.

Після: цифри

Частка втрачених з'єднань при оновленні — нуль на кількох десятках оновлень поспіль, включаючи нічні вікна з піковим навантаженням. Перемикання при відмові вузла займає 2–4 секунди.

Звернення до підтримки щодо вхідного шару скоротилися з 10–15 до 1–2 на місяць, і ті про доступи та сертифікати. Застосування конфігурації та відкат на попередню версію займають секунди замість хвилин.

Що робити, якщо в кластері вже розгорнуто інший балансувальник

Якщо в кластері вже працює інший вхідний контролер, зносити його відразу не потрібно — обидві схеми спокійно живуть поруч.

HAProxy Ingress Controller розгортається окремим релізом зі своїм IngressClass, а існуючі маршрути продовжують обслуговуватися попереднім контролером: він бере лише об'єкти, які на нього посилаються. Вхідний трафік приходить на окрему адресу, тому стара та нова схеми не заважають одна одній.

Далі — паралельна робота двох схем на службових маршрутах і одному бойовому. Порівнюємо поведінку за метриками: коди відповідей, час відгуку на бекендах, розподіл з'єднань між подами, реакцію на відмову вузла.

Окремо перевіряємо нестандартні сценарії — термінацію TLS, довгі з'єднання, WebSocket і TCP-трафік повз HTTP.

Частку трафіку переводимо вагами на зовнішньому балансувальнику або через DNS з коротким TTL: 5, 10, 25, 50, 100 відсотків.

Керування саме вагою, а не перемиканням, дає перехід без простою: у будь-який момент видно, скільки запитів іде в нову схему і як вона на них відповідає, при цьому маршрут завжди є хоча б з одного боку.

План відкату готуємо до початку переведення і перевіряємо на практиці, а не на папері.

Старий контролер залишається розгорнутим, маніфести маршрутів — у системі контролю версій, повернення ваги до нуля і класу маршруту до попереднього значення займає секунди і не потребує перезбирання конфігурації.

Тривалість переходу визначає не розмір кластера, а кількість нестандартних сценаріїв: самописні перевірки, зовнішні сервіси, нестандартні анотації. Зазвичай це кілька тижнів спокійної роботи без зупинки сервісу.

Технічні сумніви перед стартом робіт

Перед стартом інженери замовника перевіряють п'ять речей: де втрачається час на вході, що відбувається з довгими сесіями, як відсікаються недоступні вузли, чи доходить до застосунку реальна адреса клієнта і чи можна виводити HAProxy на бойовий трафік без простою.

Чи рвуться довгі з'єднання — чати, вигрузки, стрімінг?

За замовчуванням закривається все, що мовчить довше таймауту, і для користувача це виглядає випадковим обривом. Узгоджуємо інтервали утримання та частоту перевірок: активна сесія живе, зависла — звільняє ресурс.

Як вхідний шар дізнається, що вузол недоступний?

Активні перевірки стану плюс аналіз кодів відповідей у живому трафіку. Перші ловлять відмову процесу, другі — вузол, який відповідає, але помиляється. Збійний екземпляр виводиться з ротації і повертається поступово.

Чи дійде до застосунку реальна адреса клієнта?

Тільки якщо пробросити службовий заголовок з вихідною адресою від вхідного шару до застосунку. Інакше в логах і на бекенді видно адресу балансувальника: ламаються обмеження за частотою, аудит і регіональні правила.

Чи можна перейти на новий вхідний шар без зупинки сервісу?

Так. Новий шар піднімається паралельно, трафік перемикається записами в системі розв'язання імен, старий тримаємо в резерві до підтвердження метрик. Відкат — повернення записів, займає хвилини.

Обговоримо вашу схему трафіку та повернемося з планом

Щоб оцінка була предметною, а не «середньою по галузі», нам потрібні дві речі: ваша схема потоків і перелік обмежень середовища. Опишіть, що вже працює, що лише планується і які вимоги жорсткі — щодо доступів, щодо збереження адреси клієнта, щодо вікна змін.

З цим набором ми розберемо, де достатньо звичайного балансування HTTP, а де потрібен наскрізний режим TCP з проксіюванням на рівні з'єднання.

Далі повернемося з варіантами схеми та планом робіт: що робимо на першому етапі, що розумно винести пізніше, де є розвилки і чим кожна з них обходиться при експлуатації. Нижче — короткий перелік, який закриває майже всі питання ще до дзвінка.

• Схема потоків: джерела трафіку, точки входу, сервіси за балансувальником, зовнішні споживачі.
• Обмеження середовища: де розміщуємося — хмара, власні машини чи гібрид; що доступно за адресами та портами.
• Режими: де потрібен розбір шляхів і заголовків, а де — збереження вихідної адреси клієнта для застосунку.
• Шифрування: де видаються та продовжуються сертифікати, чи потрібен наскрізний канал до застосунку.
• Спостережуваність: які метрики та журнали потрібні черговій зміні і куди їх віддавати.
• Вимоги до відкату: допустимий час простою та глибина повернення на попередню версію конфігурації.
• Хто на вашому боці приймає роботу та узгоджує зміни в робочому контурі.

У відповідь ви отримаєте оцінку та план робіт, варіанти схеми з плюсами і мінусами кожного та склад матеріалів, що передаються — конфігурації, схеми потоків, регламент обслуговування і документацію з розгортання HAProxy Ingress Controller.

Опишіть задачу у вільній формі: надішліть схему та обмеження, далі зв'яжемося і звіримо деталі.