Разговор о том, кто на самом деле контролирует облако, часто начинается с регионов: где выполняется рабочая нагрузка и где хранятся её данные. Но выбор региона — только часть картины, архитектура платформы значит ровно столько же. Особенно важно, как она разделяет между кластерами ответственность за управление, исполнение, сборку и наблюдаемость.
Недавняя публикация сообщества CNCF, «От резидентности данных к цифровому суверенитету: архитектурные паттерны для cloud native-платформ», хорошо это обосновала. Под такими режимами, как EU Data Act, NIS-2, DORA и UK Data (Use and Access) Act, платформенным командам теперь приходится показывать не только то, где выполняются рабочие нагрузки. Нужно показать и то, как платформу эксплуатируют, защищают и по каким правилам ею распоряжаются, вплоть до плоскости управления.
Та статья изложила требования и представила паттерн «кластер на тенант» как один из способов провести границы изоляции. Команда VK Cloud перевела статью, в которой на те же требования смотрят под другим, но дополняющим углом: что происходит, если считать контроль над платформой свойством топологии её плоскостей. В качестве примера, который можно изучить самому, авторы берут OpenChoreo, внутреннюю open source-платформу разработки и проект CNCF Sandbox. Впрочем, сами архитектурные идеи применимы широко.
О чём аудиторы спрашивают платформенные команды
Предыдущая публикация сводит регуляторный и закупочный шум к четырём практическим свойствам. Повторять их не будем, а переформулируем в вопросы, которые аудитор или закупочная команда реально задаёт платформенной команде:
Можете ли вы назвать юридическую юрисдикцию, под которой работает каждый компонент, способный коснуться данных тенанта, включая плоскость управления, а также логи и метаданные вокруг неё?
Если хостируемый сервис вашего вендора завтра исчезнет, сможет ли ваша команда продолжить эксплуатировать рабочую нагрузку, пересобрать её и перенести в другое место?
Может ли кто-нибудь за пределами границы добраться до ваших ключей, состояния кластера или административных учётных данных?
Если меняется провайдер, оборудование или страна, рабочая нагрузка переезжает или её нужно переписывать?
Посмотрите, что объединяет эти вопросы. Почти все они не о физическом расположении данных. Речь о другом: где находятся контроль и состояние — и у кого есть к ним доступ.
Один общий Kubernetes-кластер мешает дать на эти вопросы однозначный ответ. Все тенанты используют один API-сервер, один etcd, общий набор контроллеров и admission-вебхуков. Поэтому во время аудита бывает трудно провести чёткую архитектурную границу между ними.
Паттерн «отдельный кластер для каждого тенанта» решает эту проблему: у каждой изолированной среды появляется собственная плоскость управления. Платформа с несколькими плоскостями управления работает по тому же принципу, но на более высоком уровне. Эти два подхода можно сочетать — далее мы покажем, как именно.
Топология из нескольких плоскостей
OpenChoreo разделяет платформу на плоскости. Каждая плоскость — отдельный кластер со своим жизненным циклом, поведением при масштабировании и границей безопасности:
Плоскость управления хранит желаемое состояние через декларативные API и запускает контроллеры согласования. Она оркестрирует, но не выполняет рабочие нагрузки тенантов.
Одна или несколько плоскостей данных — сертифицированные Kubernetes-кластеры, которые собственно и выполняют рабочие нагрузки. У каждой плоскости данных свой API-сервер и своё состояние.
Одна или несколько плоскостей наблюдаемости собирают и отдают логи, метрики и трейсы.
Одна или несколько плоскостей workflow исполняют CI- и GitOps-workflow.
Плоскость взаимодействия предоставляет портал разработчика, CLI и поверхности API/MCP.
Модель соединения — ключевой элемент контроля над платформой. Именно поэтому на рисунке 1 стрелки направлены именно так: плоскости данных, наблюдаемости и выполнения workflow сами устанавливают исходящие соединения с взаимной аутентификацией по mTLS к шлюзу плоскости управления. Плоскость управления никогда не инициирует подключения к ним.
Из этого следуют два важных вывода.
Во-первых, поскольку соединения устанавливаются только в исходящем направлении, API-серверы кластеров с регулируемыми рабочими нагрузками никогда не становятся доступными из интернета.
Во-вторых, плоскость управления хранит желаемое состояние, а не фактическое состояние выполнения задач у тенанта. Она преобразует высокоуровневые ресурсы в Kubernetes-ресурсы, а затем передаёт их согласование API-серверу соответствующей плоскости данных. Поэтому плоскость данных продолжает обслуживать трафик, даже если связь с плоскостью управления потеряна.
Благодаря такому разделению одна оркестрирующая плоскость управления может работать при строгом разграничении регионов, не превращаясь в единое место хранения всего состояния выполнения.
Как топология выдерживает проверку
Вопрос 1: можете ли вы назвать юрисдикцию?
При модели «одна юрисдикция, одна плоскость данных» ответ можно прямо выразить в архитектуре и защитить на аудите. Вот как это выглядит с двумя юрисдикциями:
Схема наблюдаемости не нарушает это разделение. Каждая плоскость данных передаёт телеметрию в региональную плоскость наблюдаемости, а портал обращается к ней напрямую — данные не возвращаются через плоскость управления.
Именно такой подход описан в документации OpenChoreo для мультирегиональных развёртываний, к которым применяются региональные требования к защите персональных данных. Состояние выполнения у каждого тенанта остаётся в его региональной плоскости данных, а журналы и телеметрия не выходят за пределы региона.
Вопрос 2: можете ли вы работать без вендора?
Каждая плоскость данных — это полноценный Kubernetes-кластер, который можно сертифицировать и проверять отдельно. Это не закрытая управляемая среда: кластер сохраняет работоспособность даже при потере связи с плоскостью управления.
Нижележащий стек построен на ПО с открытым исходным кодом, прежде всего на проектах CNCF и cloud-native-экосистемы: Argo Workflows, Cloud Native Buildpacks, OpenSearch, Prometheus, OpenTelemetry, Flux, cert-manager и Cilium. Модульная архитектура позволяет заменить отдельный компонент или подключить уже используемую систему наблюдаемости через тот же интерфейс запросов. При этом ни один внешний управляемый сервис не участвует в критическом пути обработки запросов.
Вопрос 3: могут ли посторонние добраться до ключей, состояния или учётных данных?
Модель mTLS с исходящими соединениями по умолчанию исключает доступ к чувствительным кластерам из интернета. Секреты и ключи команда хранит там, где ей удобно: в любом хранилище или Vault-решении, совместимом с External Secrets Operator. Таким образом, владение ключами становится осознанным архитектурным выбором, а не настройкой по умолчанию.
Авторизацию можно настроить с точностью до отдельных пространств имён, проектов и компонентов. Группы пользователей при этом синхронизируются из любого провайдера идентификации с поддержкой OAuth 2.0 и OIDC. Одна и та же модель авторизации действует для всех способов доступа: через интерфейс разработчика, CLI или ИИ-агента.
Вопрос 4: означает ли смена провайдера переписывание?
Рабочие нагрузки описываются стандартными ресурсами Kubernetes и запускаются в сертифицированных Kubernetes-кластерах — независимо от того, где они размещены: в публичном облаке, в собственной инфраструктуре или на bare metal.
Продвижение между средами — встроенная возможность платформы. Конвейер может перенести компонент из среды разработки в одной плоскости данных в продакшен в другой — в другом регионе или у другого облачного провайдера, — применив по пути конфигурацию целевого окружения. Поэтому замена инфраструктуры в пределах одной юрисдикции становится изменением топологии, а не отдельным миграционным проектом.
Разворачивайте кластеры с Managed Kubernetes
Автоматизируйте деплой и снижайте затраты на инфраструктуру до 60%
Как слой платформы стыкуется со слоем инфраструктуры
В предыдущей публикации изоляция рассматривалась через паттерн «кластер на тенанта»: каждому тенанту выделяется собственный виртуальный кластер внутри общего хост-кластера. Этот подход полезно рассмотреть вместе с платформенным слоем, поскольку они решают разные задачи, связанные с контролем над платформой.
Начнём с того, что даёт виртуальный кластер на инфраструктурном уровне. Каждый тенант получает собственную виртуальную плоскость управления — отдельный API-сервер и собственное хранилище данных, которые работают в виде подов внутри общего хост-кластера. Тенант A не видит ресурсы тенанта B, не страдает от его неисправных CRD или вебхуков и не может изменить состояние его кластера. Это полноценная изоляция плоскости управления при существенно меньшей стоимости по сравнению с выделенным кластером: все тенанты используют общий пул узлов.
Однако паттерн «кластер на тенанта» намеренно не отвечает на ряд других вопросов. Он не определяет, в какой юрисдикции будет размещён тенант, куда будут передаваться его логи и трассировки, кто вправе продвигать рабочую нагрузку из staging в одном регионе в production в другом и при каких условиях это допустимо. Он также не даёт разработчикам единый рекомендуемый способ работы с платформой и не исключает прямой ручной доступ к базовым кластерам через kubeconfig.
Это не недостатки паттерна, а задачи другого — платформенного — уровня. Именно к ним сводятся ключевые вопросы контроля: где хранится состояние, куда передаётся телеметрия, кто может выполнять действия через границы сред и можно ли всё это доказать на аудите.
Здесь и проявляется ценность разделения ответственности между слоями. Для плоскости управления OpenChoreo виртуальный кластер — это просто ещё один сертифицированный Kubernetes API. Достаточно зарегистрировать его как плоскость данных — и к нему будут применяться все механизмы контроля, которые предоставляет платформенный слой:
Ресурс
DataPlaneнесёт метку юрисдикции, поэтому размещение тенанта становится декларативным и проверяемым на ревью, а не негласным знанием команды.observabilityPlaneRefприкрепляет телеметрию к региональной плоскости наблюдаемости, поэтому логи тенанта наследуют ту же гарантию резидентности9, что и его рабочие нагрузки.Конвейеры продвижения, определённые на слое платформы, решают, между какими окружениями может перемещаться компонент, поэтому рабочая нагрузка не может уехать не в ту юрисдикцию через развёртывание ad hoc.
Та же детализированная авторизация действует для каждого тенанта, с отображением групп из того же провайдера идентификации, независимо от того, кто вызывает: разработчик, CLI или ИИ-агент.
Разработчики получают эталонные пути и портал вместо прямого доступа к кластеру, и это сокращает число людей, у которых вообще появляются учётные данные к чувствительным кластерам.
На иллюстрации ниже показана составная топология: в каждой юрисдикции развёрнут один физический хост-кластер, а внутри него для каждого тенанта работают виртуальные кластеры, выступающие в роли плоскостей данных. Всеми ими управляет единая плоскость управления, которая взаимодействует с кластерами через те же исходящие mTLS-соединения.
С точки зрения регистрации неважно, является ли плоскость данных физическим или виртуальным кластером: процедура остаётся той же. Если при такой интеграции возникнут ограничения или неудобства, это хороший повод внести вклад в развитие проекта.
Читайте эту схему как разделение ответственности между двумя слоями. Инфраструктурный слой отвечает на вопрос: «Кто от кого изолирован?» Платформенный слой — на вопросы: «Какие взаимодействия разрешены, куда могут передаваться данные и можно ли это подтвердить на аудите?» Один слой не заменяет другой.
Виртуальные кластеры сами по себе не определяют правила размещения, маршрутизации телеметрии и продвижения между средами. Всё это остаётся ручной политикой, которую приходится поддерживать организационными мерами. В то же время платформа, которая запускает тенантов просто в отдельных пространствах имён общего кластера, отделяет их друг от друга лишь корректностью настройки admission-вебхуков. Совместно эти подходы позволяют закрыть все четыре вопроса контроля, при этом стоимость масштабируется с числом юрисдикций, а не с количеством тенантов.
Важно учитывать ограничение, которое показано на рисунке 3: тенанты на одном хост-кластере по-прежнему используют общие узлы и одно ядро ОС. Если модель угроз требует аппаратной изоляции для каждого тенанта, виртуального кластера недостаточно — такому тенанту понадобится собственная физическая плоскость данных. Преимущество компонуемой топологии в том, что и это можно оформить как решение о регистрации новой плоскости данных, а не как полное перепроектирование платформы.
Контроль над платформой как декларативная конфигурация
Предыдущая публикация завершается важной мыслью: контроль над платформой должен быть не просто пунктом в договоре, а сущностью с понятным названием, шаблоном и историей изменений в Git.
Этой идее соответствует топология плоскостей, описанная декларативными ресурсами Kubernetes. Плоскости данных, окружения и конвейеры развёртывания задаются через Custom Resources. Всю топологию можно хранить в Git: например, фиксировать, какая плоскость данных работает в каком регионе, какой региональный контур наблюдаемости она использует и по каким маршрутам разрешено продвигать изменения между средами.
Ниже приведён упрощённый манифест с сокращёнными именами полей. Он показывает общий подход, а не точную схему ресурсов:
# Только для иллюстрации. Реальную поверхность API смотрите в документации проекта. kind: DataPlane metadata: name: eu-west labels: jurisdiction: eu spec: observabilityPlaneRef: eu-observability # телеметрия остаётся в регионе # настройки реестра, шлюза и сети, ограниченные границей ЕС --- kind: Environment metadata: name: production-eu spec: dataPlaneRef: eu-west
Тогда добавление новой юрисдикции становится пулреквестом, прошедшим ревью. А когда кто-то спрашивает «почему данные этого тенанта в этой юрисдикции?», ответом становится история коммитов, а не скриншот консоли.
Что топология даёт и чего не даёт
Во-первых, топология из нескольких плоскостей не меняет правовую юрисдикцию организации, которая эксплуатирует инфраструктуру. Если оператор кластера подпадает под определённый правовой режим, связанные с ним риски сохраняются. Когда модель угроз требует, чтобы оборудование или оператор находились в конкретной юрисдикции, это должно обеспечиваться на инфраструктурном уровне. Топология позволяет разделить и сузить зоны правового риска, но не отменяет правовой контекст оператора.
Во-вторых, топология задаёт границы, но сама по себе не обеспечивает соблюдение политик внутри этих границ. Контроль политик, аттестация цепочки поставок и SBOM, аудит-логирование, а также идентификация рабочих нагрузок с помощью решений наподобие SPIFFE/SPIRE — отдельные задачи. Для платформы, от которой требуется доказуемый контроль, могут понадобиться все эти механизмы.
Здесь важно различать архитектурный паттерн и реализацию платформы. Сам по себе паттерн не предоставляет необходимых средств контроля, но платформенный слой хорошо подходит для их интеграции. Модульная архитектура OpenChoreo позволяет подключать такие механизмы так же, как она оркестрирует Cilium, Flux и cert-manager. Сначала задаётся граница, затем поверх неё накладываются средства контроля и проверки.
В-третьих, каждая дополнительная плоскость увеличивает эксплуатационные затраты. Каждый кластер необходимо мониторить, обновлять и резервировать. Такой паттерн оправдан, только если создаваемая граница действительно существенна с точки зрения права или управления рисками. В противном случае он будет избыточным.
Именно здесь особенно полезно сочетание с виртуальными кластерами, описанное выше: оно позволяет привязать число физических кластеров к числу юрисдикций, а не к числу тенантов.
Выводы
Главный вывод исходной публикации остаётся в силе: контроль над платформой определяется не столько регионом, выбранным в интерфейсе, сколько тем, как в архитектуре распределены управление, состояние, ключи и данные аудита.
Если смотреть на задачу с этой точки зрения, ключевой вопрос проектирования — как разделить ответственность между уровнями. Кластеры для отдельных тенантов служат механизмом изоляции. Топология с несколькими плоскостями задаёт карту границ между юрисдикциями, средами и контурами данных. Наиболее гибкий вариант — сочетать оба подхода.
Когда такие границы описаны декларативными объектами и хранятся в системе контроля версий, «контроль над платформой» перестаёт быть обещанием из коммерческого предложения. Он становится частью архитектуры, которую команда может сопровождать, проверять и предъявлять аудиторам.
OpenChoreo — open-source проект в CNCF Sandbox. Исходный код, документация и ссылки на сообщество доступны на openchoreo.dev.
