DockerCon EU 2017: Docker EE берёт Kubernetes - конец войны оркестраторов

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

Мы смотрели на выбор между Swarm и Kubernetes в апреле и не дали однозначного ответа. Теперь ответ немного прояснился - хотя и не так, как ожидалось.

Что именно объявлено

Согласно анонсу, в Docker EE появится:

• Kubernetes как первоклассный оркестратор наряду со Swarm - оба работают на одном control plane UCP.
• Единое пространство образов и сетей - Docker Trusted Registry и overlay-сети используются обоими оркестраторами.
• Выбор оркестратора на уровне namespace - один кластер может одновременно гонять Swarm-сервисы и Kubernetes-воркнагрузки.

Сроки конкретные не называются, говорят про «начало 2018 года». По нашему опыту с Enterprise-анонсами - это обычно означает «когда будет готово», но направление обозначено чётко.

Почему это важно именно сейчас

До этого анонса аргумент «подождём, кто победит» был технически состоятельным. Swarm заметно проще в операционном плане: меньше движущихся частей, нет etcd отдельно, Docker Compose-файл работает почти без изменений. Kubernetes мощнее, но порог входа выше и ecosystem-зрелость неоднородная.

Теперь Docker Inc. де-факто говорит: «Kubernetes победил в энтерпрайзе, мы это признаём». Когда сам вендор интегрирует конкурирующий инструмент в свой продукт - это сигнал достаточно чёткий.

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

Что меняется в нашем подходе

Честно говоря, для нас оперативно мало что меняется - мы уже де-факто остановились на Kubernetes для новых проектов. Но анонс снимает несколько практических вопросов.

Первое - обоснование для клиентов. До сих пор часть клиентов воспринимала Kubernetes как «сложный и молодой», а Swarm как «понятный и от Docker». Теперь сам Docker говорит, что K8s - это правильный путь для серьёзных нагрузок. Это другой разговор.

Второе - миграция существующих Swarm-установок. У нас есть несколько клиентов на Swarm, у которых нет острой необходимости мигрировать прямо сейчас. С этим анонсом горизонт планирования стал чуть понятнее: Swarm никуда не исчезает, но инвестиции в его развитие со стороны Docker явно перераспределятся.

Третье - Docker Compose-файлы. Часть клиентов использует Compose как формат описания приложения, а Swarm как runtime. Kubernetes не понимает Compose-формат нативно - это всегда был аргумент в пользу Swarm. Посмотрим, как Docker решит этот вопрос в интеграции - анонс про это молчит.

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

Детали интеграции пока на уровне презентационных слайдов. Непонятно:

• Как именно будет работать сетевая модель - overlay-сети Swarm и CNI-плагины Kubernetes устроены принципиально по-разному.
• Насколько «настоящий» это Kubernetes - или же UCP будет подмножеством с ограниченным API.
• Что будет с Kubernetes-специфичными объектами (CRD, операторы) в контексте UCP.

Детальный разбор архитектуры, судя по всему, будет позже - пока это именно анонс намерений, а не документация готового продукта.

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

Прекращаем ждать. Для всех новых проектов по умолчанию берём Kubernetes. Существующие Swarm-установки не трогаем без причины - они работают и нет смысла создавать проблему там, где её нет. Но новые обсуждения про «а может Swarm?» закрываем ссылкой на этот анонс: когда сам Docker голосует за Kubernetes - тема закрыта.

Как только выйдет бета Docker EE с K8s - посмотрим что там внутри. Интересует прежде всего сетевой слой и то, насколько реальный Kubernetes API доступен, а не обёртка над ним.