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.

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