В 2016 году не было очевидно, какая платформа оркестрации контейнеров победит. Преимущество Docker Swarm заключалось в том, что он был встроен непосредственно в интерфейс командной строки Docker — если у вас уже был запущен Docker, режим Swarm находился на расстоянии одной команды. Kubernetes, от com...
В 2016 году не было очевидно, какая платформа оркестрации контейнеров победит. Преимущество Docker Swarm заключалось в том, что он был встроен непосредственно в интерфейс командной строки Docker — если у вас уже был запущен Docker, режим Swarm находился на расстоянии одной команды. Kubernetes, напротив, был более сложным в настройке, требовал более длительного обучения и возник из внутренней инфраструктуры Google, а не из инструмента, который большинство разработчиков уже использовали ежедневно.
Пять лет спустя этот вопрос уже не был вопросом. Kubernetes стал стандартным ответом на вопрос «как мы запускаем контейнеры в производстве», а Docker Swarm превратился в сноску — все еще функционирующий, все еще поддерживаемый, но уже не тот, на который направлено внимание или инвестиции отрасли.
Простота потеряна. Вот почему.
1. Kubernetes построил экосистему; Swarm создал новую функцию
Docker Swarm был разработан для того, чтобы хорошо выполнять одну задачу: организовывать контейнеры с минимальной настройкой. Этот фокус был также и его потолком. Swarm поставлялся с фиксированным набором возможностей, и его расширение означало работу в рамках собственной дорожной карты и цикла выпуска Docker.
Kubernetes с самого начала использовал другой подход: небольшое стабильное ядро (сервер API, планировщик, диспетчер контроллеров), окруженное моделью расширения — Cu.