Сервисные экземпляры получают новые IP после каждого развёртывания. Как оркестратор сохраняет стабильную точку доступа для клиентов?
Оркестратор отделяет адрес сервиса от адресов его экземпляров с помощью служебной абстракции и service discovery. Клиент обращается к стабильному DNS-имени или виртуальному адресу, а оркестратор автоматически поддерживает список актуальных экземпляров и направляет к ним трафик.
В традиционной инфраструктуре серверы часто имели фиксированные адреса, поэтому приложения могли хранить их в конфигурации. Контейнерная среда сделала экземпляры краткоживущими: планировщик может пересоздать контейнер на другом узле, и его IP изменится.
Чтобы клиентам не приходилось отслеживать каждое изменение размещения, появилась отдельная логическая адресация сервисов. Она решает задачу обнаружения доступных экземпляров независимо от их текущих сетевых адресов.
Если клиент напрямую использует IP контейнера, пересоздание экземпляра разрывает связь с ним. Ручное обновление конфигураций создаёт задержки, ошибки синхронизации и сильную связанность между клиентом и инфраструктурой.
Кроме того, одного списка IP недостаточно: часть экземпляров может быть остановлена, перегружена или временно не принимать трафик. Система должна удалять такие экземпляры из набора назначения и возвращать их после восстановления пригодности.
Оркестратор создаёт логический объект сервиса со стабильным именем. Внутренний DNS разрешает это имя в виртуальный адрес или публикует набор адресов, после чего сетевой компонент перенаправляет соединение на один из зарегистрированных экземпляров.
Контроллер наблюдает за состоянием рабочих объектов и поддерживает реестр конечных точек. При создании, удалении или перемещении экземпляра реестр обновляется, а механизм маршрутизации использует уже актуальный набор адресатов.
В зависимости от реализации трафик может проходить через виртуальный IP, прокси, сетевой балансировщик или напрямую к адресам экземпляров. Это влияет на задержку, сохранение исходного IP клиента, поддерживаемые протоколы и место применения правил маршрутизации.
DNS-кэширование и задержки распространения изменений могут временно сохранять устаревшие адреса. Поэтому для критичных систем важны корректные TTL, обработка ошибок соединения и отсутствие предположения, что один IP или один экземпляр будет постоянным.
Такая абстракция не заменяет проверку состояния приложения. Она лишь предоставляет механизм выбора экземпляров; критерии допуска к трафику должны быть связаны с тем, может ли экземпляр реально обслуживать запросы.
В кластере работают несколько экземпляров API. После масштабирования часть контейнеров запускается на других узлах, а старые экземпляры удаляются; прямое обращение к их IP приводит к периодическим ошибкам клиентов.
Рассматривались два варианта. Передавать клиентам список IP было бы просто, но потребовало бы обновлять конфигурации и обрабатывать устаревшие адреса. Использовать внешний балансировщик дало бы единую точку доступа, но добавило бы стоимость, зависимость от внешней сети и дополнительный сетевой путь.
Выбрали внутренний сервис с DNS-именем и автоматически обновляемым реестром конечных точек. Клиенты стали зависеть только от имени сервиса, а оркестратор начал исключать удалённые экземпляры и добавлять новые без изменения клиентских конфигураций. В результате масштабирование и перемещение рабочих объектов перестали требовать ручного вмешательства.
1. Чем service discovery отличается от балансировки нагрузки?
Service discovery отвечает на вопрос, где находятся доступные экземпляры сервиса: через DNS, реестр или другой механизм обнаружения. Балансировка нагрузки выбирает, на какой из найденных экземпляров отправить конкретный запрос.
В некоторых системах обе функции объединены одним объектом или компонентом, но концептуально они различны. Сервис может обнаруживаться через DNS, а балансировка выполняться клиентом, прокси или сетевым уровнем.
2. Почему стабильный виртуальный адрес не означает стабильное соединение?
Виртуальный адрес стабилизирует точку начала подключения, но не сохраняет состояние уже установленного TCP-соединения. Если выбранный экземпляр будет удалён, существующее соединение может завершиться ошибкой, даже если следующий запрос по тому же имени попадёт на другой экземпляр.
Поэтому приложения должны корректно обрабатывать повторные подключения и, если это допустимо, повторять идемпотентные операции. Сессионное состояние обычно выносят во внешнее хранилище либо используют механизм привязки к экземпляру, понимая его ограничения.
3. Какие проблемы возникают при неправильном выборе DNS TTL?
Слишком большой TTL уменьшает число DNS-запросов, но дольше сохраняет у клиентов устаревшие адреса после изменения набора экземпляров. Слишком маленький TTL ускоряет обнаружение изменений, однако увеличивает нагрузку на DNS-инфраструктуру и не гарантирует мгновенное обновление из-за промежуточного кэширования.
TTL выбирают с учётом характера изменений и допустимого времени устаревания. При этом приложение всё равно должно быть готово к ошибкам соединения: DNS-кэш не является механизмом гарантированной синхронизации состояния сервиса.