Azure Fleet Manager связал кластеры без самодельных VPN

Microsoft добавляет в Azure Kubernetes Fleet Manager межкластерную сеть на базе Cilium. Функция рассчитана на команды, которые запускают нагрузки сразу в нескольких кластерах AKS fleet и не хотят собирать собственную паутину из VPN, шлюзов и ручного обнаружения сервисов.

Главное здесь не слово «seamless». Полезнее то, что, по словам Microsoft, теперь берет на себя управляемый слой: east-west-связность pod между кластерами, глобальное обнаружение сервисов через аннотацию Kubernetes Service, наблюдаемость по нескольким кластерам и применение политик безопасности, которые могут следовать за нагрузками за пределы одного кластера.

Что изменилось#

Azure Kubernetes Fleet Manager уже закрывал часть задач управления несколькими кластерами: распространение нагрузок по member clusters и поэтапную оркестрацию обновлений. В новой публикации Microsoft говорит, что оставшейся болезненной точкой была сеть между этими кластерами.

Анонсированная возможность использует межкластерную сеть на базе Cilium через Advanced Container Networking Services. Microsoft описывает это как управляемую сеть, которая может охватывать AKS fleet и позволять сервисам и нагрузкам общаться через границы кластеров «как будто они локальные», сохраняя изоляцию и управление на уровне кластера.

В источнике названы конкретные элементы:

• east-west-связность с маршрутизацией на базе eBPF через Azure CNI powered by Cilium
• отсутствие требования к proxy или gateway для pod-to-pod-связи между кластерами, по утверждению Microsoft
• глобальное обнаружение сервисов через добавление service.cilium.io/global=true к стандартному Kubernetes Service
• автоматическое обнаружение endpoints в присоединенных member clusters
• прозрачная балансировка нагрузки и failover между этими endpoints
• агрегированные метрики, логи и видимость потоков между кластерами
• сетевые политики и наблюдаемость через Advanced Container Networking Services
• управляемый жизненный цикл сертификатов и сетевой конфигурации

Для архитектур, где межкластерная связность сейчас держится на ручной инфраструктурной склейке, это заметный сдвиг. Часть проблемы переезжает из самописной обвязки в управляемую модель Azure и Cilium.

Но проектировать систему все равно придется. Просто давление смещается в другие места.

Почему многокластерные нагрузки сложны#

Multi-cluster Kubernetes редко строят ради красоты схемы. Кластеры разделяют из-за регуляторных границ, disaster recovery, региональной задержки, управления емкостью, tenancy или ограничения blast radius. Эти причины часто оправданы. Цена появляется позже, когда сервисам нужно общаться через эти границы.

Один Kubernetes-кластер дает разработчикам привычную модель сервисов. Несколько кластеров ломают эту иллюзию. Обнаружение становится сложнее. Failover приходится описывать явнее. Сетевая политика должна учитывать мир шире, чем «внутри этого кластера». Инструменты наблюдаемости должны объяснять пути трафика, которые теперь пересекают административные и региональные линии.

Microsoft подает Fleet Manager как способ сделать границу кластера менее заметной для прикладных команд. Для платформенных команд это привлекательно: разработчики продолжают использовать стандартные паттерны Kubernetes Service, а платформенный слой занимается маршрутизацией между кластерами и обнаружением endpoints.

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

Для security operations именно здесь анонс особенно важен. Межкластерная сеть — это не только транспорт. Это identity, политики, телеметрия, работа с сертификатами, поведение при отказах и границы расследования инцидентов.

Что это значит для безопасности#

Cilium — серьезная open source-основа для безопасности и сетей, а eBPF стал одним из ключевых строительных блоков современной Kubernetes-сети и наблюдаемости. То, что Microsoft опирается на эту основу, — хороший сигнал для переносимости и совместимости с экосистемой. Но командам понадобятся люди, которые понимают, как поведение Cilium отражается в управляемой реализации Azure, а не только абстрактно знают Kubernetes Services.

Обещание безопасности в публикации — единые политики и governance по всему fleet. Направление правильное. Политики, которые заканчиваются на границе кластера, слабее в мире, где нагрузки, failover-пути и общие сервисы эту границу пересекают.

Но «единое» нужно проверять. Security-командам не стоит считать, что замысел политики, enforcement, логирование и алерты одинаковы для локальных и межкластерных путей, пока это не проверено в собственной среде. Важные вопросы здесь практические:

• Ведет ли себя deny policy одинаково для локальных и удаленных endpoints?
• Видны ли cross-cluster flows в инструментах, которыми уже пользуется команда incident response?
• Могут ли responders понять, какой кластер, namespace, сервис и workload обработали запрос?
• Достаточно ли видны события жизненного цикла сертификатов, чтобы разбирать сбои без небезопасных обходных решений?
• Создает ли глобальное обнаружение сервисов пути, которых не было в исходной threat model?

Это не аргументы против функции. Это цена использования управляемой абстракции в production.

Здесь виден и более широкий паттерн open source security: артефакты и основы важны только тогда, когда становятся операционными. Cilium и другие CNCF-проекты дают прозрачность и более сильную общую базу, но безопасность в production все равно зависит от конфигурации, наблюдаемости, обновлений и патчей. См. также: Апрельский сигнал OpenSSF: артефакты безопасности должны работать на практике.

Что проверить перед внедрением#

Начните с топологии. Определите, какие кластеры могут входить во fleet, какие namespaces вообще имеют право выставлять глобальные сервисы и какие команды могут применять аннотацию, делающую Service глобальным. Относитесь к этой аннотации как к контролируемой возможности, а не как к удобному флажку.

Затем проверьте поведение политик на реальных сценариях. Соберите небольшую матрицу: allowed внутри одного кластера, denied внутри одного кластера, allowed между кластерами, denied между кластерами, failover при потере endpoint, трафик при частично здоровом кластере. Если политика между кластерами слабее, чем внутри одного кластера, исправьте это до масштабного внедрения.

Наблюдаемость нужно проверить до заявлений о надежности. Microsoft указывает на агрегированные метрики, логи и видимость потоков через Advanced Container Networking Services и телеметрию Cilium. Это полезно только если операторы во время инцидента могут ответить на конкретные вопросы: кто с кем общался, откуда, под какой политикой и что изменилось перед сбоем.

Пересмотрите предположения о приватности и границах данных. Межкластерная сеть может упростить эксплуатацию регионального и tenant-разделения, но она же может размыть границы, если сервисы выставлены слишком широко. Если кластеры разделены из-за регуляторных требований или data locality, метка «global» не должна обходить саму причину такого разделения.

Емкость и поведение при отказах тоже нужно репетировать. Прозрачная балансировка и failover аккуратно выглядят на схеме. В production failover может перенести нагрузку в регион или кластер, который не был на это рассчитан. Если архитектура зависит от переноса нагрузок между регионами ради емкости или задержки, план емкости должен совпадать с планом маршрутизации.

Наконец, задокументируйте rollback. Управляемая сеть может снизить стоимость настройки, но командам все равно нужен путь отхода, если глобальный сервис ведет себя плохо. Нужно заранее знать, как убрать глобальную экспозицию, изолировать member cluster и подтвердить, что трафик перестал пересекать fleet.

Чего не стоит обещать#

Публикация Microsoft — это анонс и позиционирование, а не независимый benchmark и не аудит безопасности. В ней сказано, что сеть управляемая и high-performance. Сказано, что маршрутизация на базе eBPF обходится без proxy и gateway. Сказано, что Fleet Manager берет на себя жизненный цикл сертификатов и сетевой конфигурации. Эти заявления важны, но их нужно проверять на форме ваших нагрузок, раскладке регионов и существующих контролях безопасности.

Не воспринимайте межкластерную сеть как замену устойчивости приложения. Если приложение не переносит удаленную задержку, несогласованные зависимости или частичный отказ, глобальная сервисная абстракция сама по себе не сделает его устойчивым.

Не считайте open source-основу автоматической безопасностью. Open source security улучшает проверяемость и дает больше обзора со стороны экосистемы, но итог в эксплуатации зависит от конфигурации, дисциплины обновлений, покрытия политиками и телеметрии. Похожий пример о том, почему покрытие должно стать реальным контролем, а не лозунгом: 100% package test coverage is the point, not the slogan.

И не путайте управляемый жизненный цикл с отсутствием жизненного цикла. Сертификаты, сетевая конфигурация, membership кластеров и экспозиция сервисов остаются частью control plane. Они просто переходят в другую операционную модель.

Практический вывод#

Это полезное дополнение к Azure Kubernetes Fleet Manager для организаций, которые уже используют AKS fleets или планируют multi-region Kubernetes, shared services либо архитектуры с активным failover. Функция бьет в реальную боль: запуск многокластерных нагрузок без необходимости каждой платформенной команде строить собственный межкластерный сетевой стек.

Внедрять ее стоит контролируемо. Начните с некритичных сервисов, докажите работу политик и наблюдаемости, отрепетируйте failover и решите, кто может создавать глобальные сервисы. Функция может уменьшить сетевую рутину. Она не должна уменьшать проверку.