Docker EE с Kubernetes: Swarm остаётся, K8s добавляется - смотрим что это даёт

На прошлой неделе Docker официально объявил, что Docker Enterprise Edition теперь включает Kubernetes как полноценный второй оркестратор рядом со Swarm. Не вместо - именно рядом. Это сдвиг, который меняет расклад для нескольких наших клиентов, и мы потратили пару дней, чтобы разобраться, что это означает на практике.

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

До этого Docker EE продавался как Swarm-платформа с enterprise-обёрткой: Universal Control Plane для управления, Docker Trusted Registry для хранения образов, встроенный RBAC и scanning. Kubernetes в этой картине отсутствовал, и клиенты, которые хотели K8s, шли либо к чистому upstream, либо к Rancher, OpenShift, GKE и прочим.

Теперь в Docker EE оба оркестратора живут параллельно. UCP умеет разворачивать и Swarm-сервисы, и Kubernetes-воркловы через одну и ту же управляющую плоскость. Один кластер, одна консоль, оба движка. Можно держать часть нагрузки на Swarm, часть - на K8s, и администрировать это из одного места.

Docker позиционирует это как плавный путь для тех, кто уже на Swarm: не нужно резко переходить, можно запускать новые сервисы на Kubernetes, пока старые продолжают работать на Swarm. Теоретически звучит разумно.

Почему это интересно нашим клиентам

У нас есть несколько клиентов с production-нагрузкой на Docker EE и Swarm. Для них вопрос «когда переходить на Kubernetes» стоит уже несколько месяцев, но конкретного ответа не было - потому что переход предполагал смену всей платформы.

Сейчас картина другая. Если ты на Docker EE, ты уже можешь начать деплоить на Kubernetes без покупки другого продукта, без переноса в другую инфраструктуру и без объяснений менеджменту зачем вы вообще меняете платформу, которая работает.

Это аргумент. Не технический - операционный. Продажа внутреннего изменения часто сложнее самого изменения.

Что смотрели при первом знакомстве

Мы подняли тестовый Docker EE с Kubernetes на нашем стенде. Несколько наблюдений:

• Kubernetes-интеграция в UCP выглядит работоспособной для базовых сценариев. Деплой через kubectl работает, Dashboard доступен через UCP. RBAC из UCP проецируется на Kubernetes - это важно, потому что переписывать права с нуля никому не хочется.
• Swarm и K8s делят один overlay-network. Это означает, что сервисы из разных оркестраторов могут общаться через DNS. На бумаге это мощно, на практике это нужно тщательно проверять - потому что сетевая изоляция между Swarm и K8s при таком подходе требует явной конфигурации.
• Docker Trusted Registry работает с обоими. Image scanning, content trust, pull-through cache - всё это доступно для K8s-деплоев через те же механизмы, что для Swarm. Это реальная ценность для тех, у кого DTR уже встроен в CI/CD.
• Версия Kubernetes в EE - 1.11. Upstream сейчас на 1.12, то есть отставание на один релиз. Это минус, который надо иметь в виду: часть возможностей, которые GA в upstream, в Docker EE пока недоступны.

Последний пункт - это не мелочь. Если клиенту нужны RuntimeClass, TTL-контроллер или что-то из 1.11-1.12 - он этого в Docker EE не получит в ближайшее время.

Как это выглядит как путь миграции

Если описывать честно, то Docker EE даёт не «бесшовную миграцию», а «возможность начать параллельно». Это разные вещи.

Swarm-сервисы никуда не конвертируются. Docker Compose v3 с секцией deploy можно запустить через docker stack deploy на Swarm - но это не тот же манифест, что Kubernetes Deployment с Service, Ingress, ConfigMap и NetworkPolicy. Конвертация всё равно ручная, просто теперь делать её можно постепенно, не спеша и не выключая то, что работает.

Для клиентов с простыми Swarm-стеками - три-пять сервисов без хитрых сетевых требований - это вполне рабочий сценарий. Новые сервисы пишем сразу как K8s-манифесты, старые трогаем по мере готовности.

Для клиентов, у которых Swarm-нагрузка сложная - кастомные overlay-сети, специфичные constraints, secrets с rotation - переход будет нетривиальным независимо от того, есть ли K8s в том же Docker EE или нет. Платформа помогает с управлением, но не убирает работу по адаптации конфигурации.

Что пока неясно

Несколько вещей, которые мы хотим понять перед тем, как рекомендовать это клиентам как путь миграции:

• Как Docker будет синхронизировать версию Kubernetes в EE с upstream - сейчас разрыв большой.
• Как ведёт себя сеть при высокой нагрузке с обоими оркестраторами на одних нодах.
• Насколько UCP-RBAC покрывает реальные K8s-сценарии, а не только базовый namespace-изоляцию.

Пока это интересный вариант для клиентов, которые уже купили Docker EE и хотят начать двигаться к K8s без смены платформы. Для тех, кто только выбирает - вопрос открытый, потому что upstream Kubernetes с Rancher или собственным дистрибутивом даёт более свежую версию без vendor lock-in на Docker.

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