Service Discovery на etcd: кластер с TLS и мониторинг

Почему etcd service discovery деградирует под нагрузкой

Кластер etcd держит карту сервисов: кто где слушает и какой узел ещё жив. Пока всё ровно, etcd service discovery отдаёт актуальные адреса почти мгновенно, и приложения ходят друг к другу напрямую, без промежуточного звена. Под нагрузкой ломается не сам сервис, а реестр: чем больше клиентов и ключей, тем дольше запись, и кластер начинает отставать от потока обновлений.

Стоит выпасть одному-двум узлам — наступает потеря кворума: кластер перестаёт принимать записи и остаётся только на чтение. Дальше потеря лидера кластера запускает выборы, и в это окно сервисы не могут продлить аренду ключа. Часть экземпляров регистрируется заново, часть — нет, и реестр расходится с реальным состоянием.

Устаревшие записи реестра опаснее явного отказа. Ключ с истёкшей арендой продолжает отдаваться потребителям, трафик уходит на остановленный экземпляр, и вместо нагрузки балансировщик копит ошибки связи. Обнаружение буксует: время от публикации адреса до первого успешного запроса растёт с секунд до десятков секунд, а часть соединений не устанавливается вовсе.

Аварийная реакция обычно ручная: инженер вписывает адрес в ручные списки адресов сервисов, перезапускает потребителей и надеется, что не забыл половину. Это работает до следующего релиза, а иногда — до следующего выпавшего узла. Дальше разбираем, как это закрывается: кворум, аренды и наблюдаемость вместо правок на глаз.

Устойчивость кластера: кворум, выборы лидера, время реакции

Кворум считается от полного состава, а не от числа живых машин: узел без связи с большинством работает, но не подтверждает записи и не может стать лидером, пока не догонит журнал. Пять узлов переживают отказ двух, а четыре — ровно тот же один отказ, что и три, поэтому состав берут нечётным и разводят по разным зонам отказа.

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

Для обнаружения сервисов меняется главное: клиенты вместо периодического опроса держат долгоживущую подписку на изменения. Инстанс регистрирует ключ с арендой и продлевает её, пока жив; при падении аренда истекает, событие уходит подписчикам, а балансировщик снимает трафик с мёртвого адреса. Время обнаружения сокращается с десятков секунд до единиц — раньше часть запросов уходила в никуда всё окно опроса.

Отказоустойчивость реестра — отдельная работа: резервные копии состояния с проверкой восстановления, квоты на размер базы, дефрагментация по расписанию, узлы в разных зонах отказа, чтобы потеря зоны не забрала кворум. Такой кластер мы собираем на etcd с TLS между узлами и клиентами и оповещениями на потерю кворума и смену лидера. В эксплуатации это видно как класс отказов, переставший быть аварией: падение узла или целой зоны не создаёт окна недоступности сервисов.

Режимы service discovery: клиентский, серверный, гибридный

В кластере на etcd обнаружение сервисов собирается тремя способами, и они решают разные задачи: разница в том, где живёт логика выбора инстанса и что происходит, когда узел реестра или сам сервис выпадает из строя. Выбор диктует не мода, а допустимая зона отказа, стоимость эксплуатации и совместимость с текущим контуром — сертификатами, сбором метрик, порядком выката.

Обе крайние схемы ложатся на существующий кластер с TLS без перестройки: сертификаты выпускаются тем же центром, доступ к ключам разграничивается ролями, подписка на изменения вместо периодического опроса даёт задержку обновления списка в пределах доли секунды. Балансировка между сервисами при этом остаётся управляемой — правила выбора инстанса описываются декларативно и не размазываются по коду приложений.

На этапе внедрения держим обратный путь: переключение между схемами выполняется конфигурацией, без переписывания сервисов. Это позволяет сравнить поведение вариантов на реальном трафике и откатиться, если выбранная схема даёт лишние отказы при деградации узла.

Развёртывание кластера: аудит, TLS, проверка отказов

Развёртывание кластера etcd — работа, в которой порядок шагов важнее скорости: ошибка в размещении узлов или в сертификатах проявляется не сразу, а в момент, когда один узел вышел из строя и кворум рассыпался. Ниже — последовательность, по которой мы ведём проект от аудита до передачи.

1. Инвентаризация сервисов. Собираем список того, что будет регистрироваться и находиться через кластер: ключи, время жизни записей, кто пишет и кто читает, какие сервисы зависят от карты адресов напрямую. Без этого списка нельзя ни посчитать нагрузку, ни настроить квоты.
2. Схема размещения узлов. Определяем число узлов кворума, раскладываем их по разным зонам отказа, проверяем задержки между площадками. Кворум держим нечётным, чтобы потеря одной зоны не останавливала запись.
3. Подготовка узлов и хранилища. Отдельные диски под журнал и данные, синхронизация времени, лимиты ресурсов и предсказуемое поведение при переполнении диска — самая частая причина деградации кластера.
4. Шифрование трафика. Настраиваем сертификаты для связи между узлами и для клиентов, включаем взаимную аутентификацию и описываем порядок ротации. Отдельно проверяем, что старый сертификат не остаётся рабочим после отзыва.
5. Мониторинг и оповещения. Выводим метрики кворума, задержки записи и состояния лидера, ставим оповещения на потерю кворума и рост времени отклика, чтобы сбой замечал дежурный, а не пользователь.
6. Проверка сценариев отказа. Планово гасим узел, выводим целую зону, рвём связь между площадками, перезапускаем кластер — и фиксируем, за какое время он возвращается в рабочее состояние.
7. Передача и регламент. Отдаём документацию, доступы, инструкции по обновлению и выводу узлов на обслуживание, разбираем типовые инциденты с дежурной сменой.

Пройденные проверки отказа — это то, что отличает работающий кластер от настроенного: дальше сопровождение идёт предсказуемо, потому что поведение системы при сбоях уже известно.

Конфигурации, схемы и регламенты: что остаётся в вашем контуре

После сдачи весь контур остаётся у вас — не «чёрный ящик подрядчика», а комплект артефактов, по которым ваша команда развернёт стенд с нуля, пройдёт аудит или примет дежурство без звонка нам. Каждое нестандартное значение в конфигурации имеет письменное обоснование: почему параметр такой, что сломается при его изменении и как откатиться к предыдущему состоянию.

• Комплект конфигураций кластера: параметры кворума, квоты хранилища, расписание снимков и правила компакции — с комментариями к нестандартным значениям и ссылками на причину их появления.
• Схема кластера: топология узлов, роли, разбиение по зонам доступности, точки отказа и поведение системы при потере каждой из них.
• Политики доступа: цепочка сертификатов, сроки действия, порядок ротации, разделение прав чтения и записи по сервисам и учётные записи дежурных.
• Регламент дежурства: что считается инцидентом, какие метрики и пороги смотреть, кому и в какой срок эскалировать, когда поднимать из снимка.
• Документация по эксплуатации: пошаговые инструкции на плановые операции — добавление узла, замена сертификата, изменение квот, восстановление после сбоя.
• Проверки и чек-лист приёмки: набор тестов, подтверждающих работоспособность после любого изменения, плюс протокол учений на тестовом стенде.

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

Кейс: реестр на 40 сервисов без ручных правок

Исходно адреса сорока сервисов жили в статических конфигурациях и частично в заметках дежурной смены. После переноса экземпляра на другой узел вызывающая сторона продолжала ходить на прежний адрес: сервис отвечал ошибкой 15–40 минут, пока инженер не находил устаревшую запись и не перевыпускал конфигурацию. Доля ручных изменений в маршрутизации составляла все 100%, а на дежурную смену за месяц приходило 12–14 вызовов только из-за неверных адресов.

Что изменили

Подняли отказоустойчивый реестр на etcd — три узла с кворумом, взаимная проверка подлинности по TLS, права на запись разграничены по путям. Каждый сервис получил небольшой агент: при старте он публикует свой адрес с арендой на короткий срок и продлевает её, при остановке — снимает запись сам. Если экземпляр падает и не продлевает аренду, ключ истекает, и вызывающая сторона в течение секунд перестаёт видеть устаревший адрес.

Метрики до и после

Класс отказов «клиент знает адрес, которого уже нет» ушёл полностью — при откате релиза адрес предыдущей версии остаётся опубликованным, поэтому возврат на неё не требует правок. Нагрузка на дежурную смену сместилась: вместо ручной синхронизации списков адресов инженеры разбирают только события живости самого реестра.

Что делать, если реестр сервисов уже развёрнут на другой системе?

Миграцию на etcd service discovery не делают одним переключением: сначала два контура работают параллельно. Новые инстансы регистрируются и в старом реестре, и в новом, а потребители читают привычный источник. Сосуществование двух контуров не ломает продуктивные сервисы — расхождение выдачи видно до того, как от него кто-то пострадал.

Запись ведёт небольшой агент рядом с сервисом: он держит аренду с коротким сроком и обновляет состояние в обоих реестрах, поэтому упавший инстанс пропадает из выдачи за секунды, а не по расписанию. Имена ключей в контурах должны совпадать, иначе сопоставление выдачи превращается в ручную сверку.

Доступ к etcd закрываем взаимной проверкой сертификатов и раздельными ролями на чтение и запись, чтобы потребитель не мог править чужие ключи. Критерий готовности группы сервисов — совпадение выдачи двух контуров и одинаковая реакция на остановку инстанса; только после этого переключаем читателей партиями.

Переходный период держим, пока все потребители не сменят источник, — обычно это несколько волн по группам сервисов. Обратный откат в это время стоит одного изменения точки чтения: старый контур остаётся живым и наполненным, восстанавливать данные не нужно, а его записи и узлы гасим последними.

Наблюдаемость важнее скорости: смотрим долю успешных разрешений, задержку ответа реестра, число записей с истёкшей арендой и расхождение счётчиков между контурами. Типовая ошибка — выключать старый реестр по календарю, а не по факту: пока хотя бы один потребитель читает его, контур обязан отвечать.

Частые технические вопросы: отказоустойчивость и эксплуатация

Перед стартом работ заказчик проверяет одно и то же: что будет при отказе узла, как реестр восстанавливается и что нужно со стороны инфраструктуры. Ниже — ответы на вопросы, которые мы разбираем с командой до первой выкатки.

Как устроено восстановление после сбоя?

Состояние реестра снимается в резервную копию по расписанию и хранится вне кластера. Восстановление идёт на чистый узел и занимает минуты, процедуру прогоняем на отдельном стенде, а не в момент аварии. После подъёма сервисы находят друг друга без правки конфигураций.

Есть ли запас по масштабированию?

Растёт не число узлов, а объём ключей: реестр хранит адреса сервисов, а не их трафик. Десятки тысяч записей обслуживает тот же состав из пяти узлов. При высокой нагрузке на чтение добавляем наблюдателей — они не участвуют в выборе лидера и не влияют на кворум.

Какие требования к окружению и доступам?

Выделенные узлы с быстрыми дисками и синхронизацией времени, предсказуемая задержка между ними, отдельный удостоверяющий центр для сертификатов и их автоматическая ротация. Доступ выдаём короткоживущими сертификатами с ролями — чтение, запись, администрирование.

Обсудим вашу задачу: схема реестра и план внедрения

Чтобы оценка была предметной, а не «на глаз», нам нужны исходные данные: перечень сервисов и их зависимости, требования к доступности и времени восстановления, текущая схема сети, место под кластер etcd и люди на вашей стороне, отвечающие за доступы и сетевые правила.

В ответ приходит рабочий документ, а не письмо с общими словами: схема размещения узлов, черновик конфигурации с TLS и разграничением прав, набор метрик и оповещений, регламент обновления и восстановления. Ниже — что именно вы получаете до старта работ.

• Схема реестра: топология узлов, размер кворума, зоны отказа и поведение кластера при потере узла.
• Оценка и план работ: этапы, длительность, точки контроля и риски на каждом шаге.
• Порядок старта: что нужно от вас на входе и какой шаг выполняем первым.
• Состав команды: инженер по инфраструктуре, специалист по мониторингу, ответственный за приёмку — роли и зона ответственности.
• Регламент эксплуатации: резервное копирование, ротация сертификатов, обновление, дежурство.
• Критерии приёмки: проверки, которые кластер проходит до передачи.

Обсудить задачу можно в переписке или на коротком разборе: что уже есть, что не работает, какие сроки. Вернёмся с оценкой и планом, где видно объём и порядок шагов.