Docker UCP с Kubernetes: единая плоскость управления - заманчиво, но цена вопроса есть

Месяц назад на DockerCon EU объявили о планах встроить Kubernetes в Docker EE. Теперь это не только слайды - Docker выкатил техническое превью в составе Docker EE 17.06, и можно посмотреть на архитектуру не как на маркетинг, а как на работающую систему. Мы потратили несколько дней на изучение того, что там внутри.

Как устроена интеграция

Universal Control Plane - это веб-интерфейс и API поверх Docker, через который Docker EE управляет Swarm-кластером. В новой версии UCP превратился в мета-оркестратор: он запускает поверх Swarm-кластера плоскость управления Kubernetes, и дальше оба оркестратора живут бок о бок.

Технически это выглядит так: UCP использует Swarm для размещения системных компонентов K8s - kube-apiserver, kube-controller-manager, kube-scheduler. Все они крутятся как Swarm-сервисы в системном namespace. etcd Docker запускает отдельно, тоже через Swarm. Рабочие ноды регистрируются одновременно и в Swarm, и в Kubernetes - kubelet запускается как системный контейнер на каждой ноде.

UCP (Universal Control Plane)
  |
  +--- Swarm orchestrator
  |       |
  |       +--- kube-apiserver (system service)
  |       +--- kube-controller-manager (system service)
  |       +--- kube-scheduler (system service)
  |       +--- etcd (system service)
  |
  +--- Kubernetes API
          |
          +--- user workloads (Pods, Deployments...)

На каждой ноде - и kubelet, и Docker daemon, которым управляет Swarm-агент. Один контейнер-рантайм, два оркестратора.

Что реально работает в превью

Нельзя сказать, что это полноценный Kubernetes. Работает базовый набор:

• Pods, Deployments, Services, ConfigMaps, Secrets - стандартные объекты создаются и работают.
• Namespaces - изоляция между командами через K8s namespace соответствует UCP-организациям.
• kubectl - стандартный клиент подключается к kube-apiserver в UCP и работает как ожидается.
• RBAC - интегрирован с UCP-авторизацией, права раздаются через UCP, а не напрямую через Kubernetes RBAC.

Чего нет в превью:

• CRD (Custom Resource Definitions) - операторы и расширения API не поддерживаются.
• Сетевые политики - NetworkPolicy-объекты парсятся, но не применяются.
• LoadBalancer и Ingress - только ClusterIP и NodePort, внешняя балансировка через механизмы UCP.
• PersistentVolumes - хранилище только через HostPath или внешние FlexVolume-плагины, которых нет.

Это честное «подмножество» - достаточно для простых stateless-приложений, недостаточно для чего-то серьёзного.

Сеть: главная проблема архитектуры

Самый интересный вопрос - как Swarm-сети и Kubernetes-сети живут вместе. Overlay-сеть в Swarm реализована через libnetwork с VXLAN-инкапсуляцией. Kubernetes по умолчанию ожидает CNI-плагин. Docker решил это через собственный CNI-плагин поверх libnetwork - то есть Kubernetes получает «своей сетью» то, что на самом деле является Swarm-overlay.

Для базовых случаев это работает: Pod-to-Pod трафик идёт, DNS резолвится. Проблема в том, что ни один сторонний CNI-плагин (Calico, Weave, Cilium) в эту схему не встраивается - у них нет интеграции с libnetwork. Вы получаете сеть в том виде, в котором её сделал Docker, без возможности поменять.

Для наших managed-кластеров это критично: у нас есть клиенты с требованиями к сетевой политике, где именно Calico в BGP-режиме даёт нужную производительность и гранулярность правил. В Docker EE эта опция закрыта.

Vendor lock-in: честный разговор

Вот здесь и зарыта собака. Docker EE с K8s - это не «стандартный Kubernetes плюс удобный интерфейс». Это Kubernetes, вшитый в UCP с намеренно ограниченным выходом наружу.

Посмотрим на конкретные точки привязки:

• Авторизация - RBAC настраивается через UCP, а не через kubectl и Kubernetes RBAC напрямую. Перенести конфигурацию прав на другой кластер - отдельная работа.
• Сеть - libnetwork-based CNI не заменяется, сетевые политики реализованы через UCP-механизмы, а не через стандартный NetworkPolicy.
• Хранилище - нет поддержки стандартных volume-плагинов Kubernetes, есть только то, что интегрировал Docker.
• Реестр образов - Docker Trusted Registry не является стандартным OCI-совместимым реестром во всех аспектах, хотя pull/push работает.

Если компания уже вложила деньги в Docker EE лицензии и обучение UCP - интеграция выглядит логично. Один интерфейс, который управляет и Swarm-сервисами, и Kubernetes-воркнагрузками, - это реально удобно для операционной команды, которая не хочет учить два инструмента.

Но для тех, кто строит с нуля, вопрос звучит иначе: зачем платить за Docker EE, если «голый» Kubernetes через kubeadm даёт полную свободу в выборе CNI, хранилища, авторизации, и при этом бесплатен?

Для кого это имеет смысл

Мы видим ограниченный, но реальный сценарий, где Docker EE с K8s выигрывает:

Организации на Swarm с действующими лицензиями Docker EE. Переход на «голый» Kubernetes - это смена всего: оркестратор, инструментарий, обучение команды, переработка CI/CD. UCP с K8s позволяет делать это постепенно: часть нагрузок остаётся на Swarm, новые идут в Kubernetes, одна операционная команда управляет всем.

Регулируемые среды с требованием единой точки аудита. UCP даёт единый журнал действий поверх обоих оркестраторов. Для некоторых compliance-сценариев это аргумент.

Для greenfield-проектов без привязки к Docker EE - нет, не видим причины выбирать эту схему.

Наш вывод на сегодня

Техническое исполнение интеграции аккуратное - понятно, что команда Docker потратила серьёзные усилия на то, чтобы два оркестратора не мешали друг другу на одних нодах. Архитектурно это работает.

Но ограничения CNI и отсутствие полного K8s API в превью - это не просто «пока не реализовано». Это следствие того, что Docker взял Kubernetes и вшил его в собственную платформу, а не наоборот. Вопрос в том, куда они двинутся дальше: к полному Kubernetes API с заменяемыми компонентами, или оставят UCP как прослойку с ограниченным подмножеством. От ответа зависит, стоит ли эта платформа Enterprise-лицензии.

Следим за релизом EE 17.12, который по дорожной карте должен расширить поддержку K8s API. Там и посмотрим, насколько далеко Docker готов открыть платформу.