Что такое docker swarm
Краткое введение в Docker Swarm mode
Docker — прекрасен. С ним можно упаковать приложение по контейнерам, забросить их на случайный хост, и всё будет просто работать. Но на одном хосте особо не отмасштабируешься. Да и если хост прикажет долго жить, всё приложение отправится на тот свет вместе с ним. Конечно, для масштабирования можно завести сразу несколько хостов, объединить их при помощи overlay сети, так что и места больше будет, и возможность для контейнеров общаться останется.
Но опять же, как всем этим управлять? Хосты всё ещё могут отмирать. Как быстро определить, какой именно? Какие контейнеры на нём были? Куда теперь их переносить?
Начиная с версии 1.12.0 Docker может работать в режиме Swarm («Рой». В старых версиях был просто Docker Swarm, но тот работал по-другому), и потому способен решать все эти проблемы самостоятельно.
Что такое режим Swarm
Docker в Swarm режиме это просто Docker Engine, работающий в кластере. Кроме того, что он считает все кластерные хосты единым контейнерным пространством, он получает в нагрузку несколько новых команд (вроде docker node и docker service ) и концепцию сервисов.
Сервисы — это ещё один уровень абстракции над контейнерами. Как и у контейнера, у сервиса будет имя, базовый образ, опубликованные порты и тома (volumes). В отличие от контейнера, сервису можно задать требования к хосту (constraints), на которых его можно запускать. Да и вообще, сервис можно масштабировать прямо в момент создания, указав, сколько именно контейнеров для него нужно запустить.
Но важно понимать одну большую разницу. Сама по себе команда docker service create не создаёт никаких контейнеров. Она описывает желаемое состояние сервиса, а дальше уже Swarm менеджер будет искать способы это состояние достигнуть. Найдёт подходящие хосты, запустит контейнеры, будет следить, чтобы с ними (и хостами под ними) всё было хорошо, и перезапустит контейнер, если «хорошо» закончится. Иногда желаемое состояние сервиса так и не будет достигнуто. Например, если в кластере закончились доступные хосты. В таком случае сервис будет висеть в режиме ожидания до тех пор, пока что-нибудь не изменится.
План на сегодня
Будем играться. Пользы от абстрактной и непонятной теории — ноль, так что создадим-ка свой собственный уютный Docker кластер на три виртуальные машины. Запустим в нём один сервис для визуализации кластера, и ещё один, например web, чтобы масштабировался и заодно демонстрировал, как он успешно восстанавливается от внезапно упавшего хоста.
Что понадобится
Нам понадобится установленный Docker версии 1.12.0 и новее, docker-machine и VirtualBox. Первые два обычно устанавливаются вместе c Docker Toolbox на Маке и Windows. На Linux, ЕМНИП, docker-machine устанавливается отдельно, но всё ещё достаточно понятно. С установкой же VirtualBox проблем вообще не бывает. Обычно.
Я буду использовать Docker 17.03.1-ce для Mac и VirtualBox 5.1.20
Шаг 0. Создаём три виртуальные машины
Создавать машины при помощи именно docker-machine имеет смысл хотя бы потому, что они сразу будут идти с предустановленным Docker. Из трёх хостов на одном мы поселим менеджера Swarm, а на двух других — обычных рабочих. Собственно, создание виртуальных машин — удивительно безболезненное занятие:
Свой облачный хостинг за 5 минут. Часть 1: Ansible, Docker, Docker Swarm
Привет Хабр! Последние 1.5 года я работал над своим проектом, которому был необходим надежный облачный хостинг. До этого момента я больше 10 лет занимался веб-программированием и когда я решил построить свой хостинг у меня были относительно поверхностные знания в этой области, я и сейчас не являюсь системным администратором. Все что я буду рассказывать может выполнить обычный программист в течение 5 минут, просто запустив набор сценариев для Ansible, которые я подготовил специально для вас и выложил на GitHub.
Моя цель – дать вам список инструментов и общее понимание, что бы вы знали от чего отталкиваться, если у вас появится необходимость в собственном облачном хостинге. При выборе используемых инструментов я ориентировался на простоту, качество документации и стабильность. Прежде, чем использовать все это у себя в продакшене, вам определенно стоит проконсультироваться с системным администратором (я использую некоторые компоненты, которые находятся в статусе «BETA» (июнь 2015)).
Содержание
Зачем свой хостинг?
Основная причина — я хотел получить необходимый опыт. Я все больше отхожу от программирования и занимаюсь административными вопросами. Хорошему предпринимателю надо пройти весь путь самому и поработать, по возможности, на всех должностях, что бы понять как все устроено, как этим управлять, от каких людей и что требовать, как оценить их работу и их самих.
Вторая причина заключается в специфике моего проекта, он связан с приватностью персональных данных. У меня нет причин кому-то просто доверять свои данные, а своих пользователей тем-более. Меня очень волнует этот вопрос, и я обеспокоен тем, что ему уделяется так мало внимания.
Последняя причина в целях и ориентирах у стартапа в Российских реалиях. Здесь основная цель – начать зарабатывать деньги и выйти в плюс. Нет прибыли – нет стартапа, есть убыточное хобби. Поэтому, третья причина – это стоимость. У меня сейчас
5Tb данных, которые я регулярно обрабатываю, обходится мне все это
100$/месяц (можете посчитать сколько это будет стоить на AWS). Я знаю, что в следующем месяце у меня будет такая же стоимость, а проект я строю на свои деньги.
Подготовка
Первое, что необходимо сделать – раздобыть 3 сервера в одном датацентре (они должны находится как можно ближе друг к другу, что бы ping между ними был минимальный). Не имеет значения, будут это виртуальные выделенные сервера (на время тестирования) или настоящие и у какого провайдера вы их арендуете. Я заказал у DigitalOcean, выбрал установку Debian 8.1 x64 и указал добавить свой SSH ключ:
Установка закончена и у нас в распоряжении 3 «голых» сервера:
Ansible
Как вы уже поняли, мы будем использовать Ansible для конфигурирования наших серверов. Если вы не знаете что это такое и как этим пользоваться, то на Хабре есть ответы на эти вопросы:
Ansible не единственная система управления конфигурациями (есть Puppet, Chef, Salt и т.д.), так почему именно она?
Как я написал выше, один из приоритетов при выборе инструментов – простота. На управляемые машины не надо устанавливать клиенты (все работает через SSH), язык сценариев предельно прост, у проекта свежая и подробная документация, а код модулей написан на Python (что для нас преимущество, потому что Python является основным языком в стартапе).
Вообще для меня простота является признаком глубокого понимания предмета. Если один человек (знакомый с предметом), не может объяснить другому человеку (с предметом не знакомому), как он работает, значит он сам до конца не понимает этот предмет.
Это хорошо раскрыто в книге Стива Возняка – «Cтив Джобс и Я», там отец начинает рассказывать принципы электротехники Стиву, когда он еще не достиг четырех лет (книга будет интересна всем инженерам, даже если вас не интересует история Apple).
На этом этапе Ansible должен быть установлен на вашей клиентской машине (инструкция). Мне, на OS X 10.9, для этого понадобилось выполнить всего 2 команды:
Проверяем, что все ок:
Docker
Это, без сомнения, один из лучших инструментов с которыми я познакомился за последние несколько лет. Именно Docker будет сердцем нашего облачного хостинга, наделяя его по-настоящему большими возможностями.
«Из коробки» мы получаем доступ к огромному количеству готовых образов, которые мы сможем моментально выполнить в нашем облаке. У нас появляется возможность изолированно запускать необходимые сервисы разных версий одновременно, для тестирования совместимости или удовлетворения зависимостей наших веб-приложений.
Мы можем запустить 20 контейнеров с 1-ой версией нашего веб-приложения, 2 контейнера со 2-ой версией и распределив между ними нагрузку, показать новую версию только
10% посетителей, оценив стабильность работы и отзывы пользователей.
Сейчас вам необходимо установить Docker на клиентскую машину, он понадобится нам для управления будущим кластером Docker’ов. Самый простой способ сделать это – скачать GUI клиент Kitematic (доступен для Mac OS X 10.9+ и Windows 7+ 64-bit), зайти в главное меню и выбрав «Install Docker Commands» установить консольные комманды Docker’а.
Альтернативные варианты установки вы можете узнать из официальной документации (она хорошо написана и своевременно обновляется). Убедиться, что все в порядке, можно следующим образом:
Docker Swarm
Наконец-то мы дошли до самого интересного, до того, что придаст нашему хостингу «облачности». Странно, но я не нашел никакой информации о Docker Swarm на Хабре.
Docker Swarm служит для объединения множества Docker хостов в один виртуальный хост и делает это элегантно. Docker Swarm предоставляет REST API интерфейс, совместимый с Docker API. Таким образом, все инструменты, которые работают с API Docker’a (клиент Docker’a, Dokku, Compose, Krane, Flynn, Deis, DockerUI, Shipyard, Drone, Jenkins и т.д.), смогут работать с Docker Swarm, не подозревая о том, что за ним стоит кластер Docker’ов, а не одна машина.
Давайте уже построим наше облако и на практике посмотрим на что способен Docker Swarm.
Приступаем
К этому моменту у вас на клиентской машине должен быть установлен Ansible и Docker. В наличии должно быть 3 сервера с авторизацией по ключу и Debian 8.1 x64 на борту (вы можете использовать любой другой дистрибутив, внеся небольшие изменения в сценарии). Я подготовил набор сценариев для Ansible, которые сделают всю работу за вас, поэтому вам не понадобится много времени.
Скачиваем набор сценариев или клонируем репозиторий:
Открываем файл stage и заменяем в нем IP адреса на IP своих серверов:
Для того, что бы Docker Swarm мог соединяться с нодами Docker’a, они должны быть доступны снаружи (по умолчанию на 2375-ом порту для HTTP и на 2376-ом для HTTPS). Также нам надо сделать доступным снаружи и Docker Swarm Manager, что бы мы могли управлять кластером. HTTP нам для этих целей не подходит (мы же строим облако для себя, а не любого интернет-пользователя), остаётся HTTPS, а точнее TLS (подробнее можно почитать в официальной документации).
Принцип работы следующий: мы создаём свой центр сертификации (далее ЦС), подписываем сертификаты для сервера и клиента Docker’a. После этого «демон» докера принимает соединения от клиентов, сертификат которых подписан тем же ЦС, что и сертификат «демона». Клиент Docker’а выполняет такую же проверку и подключается только к тем серверам Docker’a, сертификат которых подписан тем же ЦС. Docker Swarm Manager использует такую же схему. Таким образом обеспечивается аутентификация и безопасность нашего мини-облака.
Единственное, что вам требуется сделать, это сгенерировать ключи для вашего ЦС (все остальное выполнится в автоматическом режиме). Просто выполните следующие команды из корневой директории проекта (пароль, который вы укажите, необходимо запомнить, он нам понадобится) и заполните ответы на вопросы (тут нет никаких конкретный требований, домен можете указать любой):
Осталось заполнить значения некоторых переменных в файле:
Переменная certs.ca.password должна содержать пароль, который мы указали, когда генерировали приватный ключ для нашего центра сертификации.
Переменная docker_swarm.token должна содержать идентификатор нашего будущего кластера, который можно сгенерировать следующей командой:
Переменная docker_swarm.manager должна содержать IP адрес хоста, где будет запущен Docker Swarm Manager (укажите IP адрес любого из ваших серверов).
В сценариях Ansible указано, что необходимо создать пользователя support, добавить его в группу sudo и запретить root‘у возможность авторизации по SSH. Значение переменной ssh.users[].password должно быть хешем пароля для указанного выше пользователя. Для того, что бы его получить, необходимо выполнить следующую команду на любой Linux машине (можете зайти на один из ваших серверов по SSH и выполнить ее):
Значение ssh.users[].key должно быть вашим публичным ключом, который по умолчанию находится тут
Пример заполненного файла конфигурации можете глянуть ниже:
Теперь мы готовы приступить к построению долгожданного облака:
Из-за того, что мы отключили возможность авторизации root‘ом, а также добавили пользователя support (это прописано в сценариях Ansible), все последующие запуски надо выполнять с флагами -s (sudo) и -K (для запроса пароля для sudo):
Проверка и использование
Мы готовы к проверке нашего новоиспеченного облака:
Ура! Я почти дописал эту большую статью, а вы успешно закончили построение своего облака.
Если у вас появится необходимость, то вы можете подключаться к любому из Docker хостов отдельно:
Но мы же не для этого прошли весь этот путь, правда? Давайте попробуем запустить несколько экземпляров Nginx в нашем облаке:
Проверяем:
Давайте попробуем запустить еще 2 экземпляра Nginx:
Как мы видим 3-ий экземпляр запустился, а вот 4-ый нет: FATA[0001] Error response from daemon: unable to find a node with port 80 available. Docker Swarm Scheduler видит, что нет хостов со свободным 80-ым портом.
Мы можем посмотреть, какие контейнеры сейчас выполняются у нас в кластере и удостовериться, что каждая копия Nginx была запущена на разной машине:
Возможности Docker Swarm на этом не заканчиваются, а только начинаются (об этом можно почитать тут и тут).
Как я писал в начале статьи, моя цель – дать вам список инструментов и общее понимание, что бы вы знали от чего отталкиваться и я надеюсь, что она достигнута.
В следующей части я расскажу, что такое Service Discovery, как распределять нагрузку в нашем облаке и какие для этого есть инструменты.
На этом все. Всем спасибо за внимание. Стабильных вам облаков и удачи!
Подписывайтесь на меня в Twitter, я рассказываю о работе в стартапе, своих ошибках и правильных решениях, о python и всём, что касается веб-разработки.
Docker swarm mode (режим роя)
На хабре уже писали про Docker swarm mode (режим роя), который является новой фичей версии 1.12. Данная опция внесла небольшую путаницу в головы тех, кто знаком с отдельно стоящей реализацией Docker Swarm имевшей распространение ранее и не отличавшейся удобством настройки и использования. Однако, после добавления Swarm в коробку с Docker все стало намного проще, очевиднее и функциональнее.
Подробнее о том, как устроен новый кластер Docker контейнеров с точки зрения пользователя, а также о простом и удобном способе разворачивания сервисов Docker на произвольной инфраструктуре далее под катом.
Для начала, как я и обещал в предыдущей статье, с небольшой задержкой, но все же выпущен релиз Fabricio с поддержкой сервисов Docker. При этом по-прежнему сохраняется возможность работать с отдельными контейнерами, плюс, остались неизменными интерфейс пользователя и разработчика конфигурации, что значительно упрощает переход от конфигураций, основанных на отдельных контейнерах к отказоустойчивым и горизонтально масштабируемым сервисам.
Активация Docker swarm mode
В режиме swarm все ноды делятся на два типа: manager и worker. При этом полноценный кластер может обходиться без рабочих нод вообще, то есть менеджеры по-умолчанию являются также и рабочими.
Среди менеджеров всегда присутствует один, который на данный момент является лидером кластера. Все управляющие команды, которые выполняются на других менеджерах автоматически перенаправляются на него.
Для включения режима swarm достаточно выбрать хост, который будет начальным лидером в будущем кластере, и выполнить на нем всего одну команду:
После того, как «рой» инициализирован, он уже готов для запуска на нем любого количества сервисов. Правда, состояние такого кластера будет неконсистентным (консистентное состояние достигается при количестве менеджеров не менее 3). И конечно ни о каком масштабировании и отказоустойчивости в этом случае речи также быть не может. Для этого к кластеру нужно подключить еще хотя бы две управляющие ноды. Узнать о том, как это сделать, можно выполнив на лидере следующие команды:
Добавлять и удалять ноды можно в любой момент жизни кластера — это никаким серьезным образом не влияет на его работоспособность.
Создание сервиса
Создание сервиса в Docker принципиально не отличается от создания контейнера:
Отличия, как правило, заключаются в различном наборе опций. Например, у сервиса нет опции —volume, но есть опция —mount — эти опции позволяют подключать к контейнерам локальные ресурсы нод, но делают это по-разному.
Обновление сервиса
Здесь начинается самое большое отличие работы контейнеров от работы кластера контейнеров (сервиса). Обычно, чтобы обновить одиночный контейнер, приходится останавливать текущий и запускать новый. Это приводит хоть и к незначительному, но существующему времени простоя вашего сервиса (если вы не озаботились о том, чтобы обрабатывать такие ситуации при помощи других инструментов).
При использовании сервиса с количеством реплик не менее 2 простоя сервиса в большинстве случаев не присходит. Это достигается за счет того, что Docker обновляет контейнеры сервиса по очереди. То есть в один и тот же момент времени всегда есть хотя бы один работающий контейнер, который может обслужить запрос пользователя.
Для обновления (в том числе добавления и удаления) свойств сервиса, которые могут иметь несколько значений (например, —publish или —label), Docker предлагает использовать специальные опции, оканчивающиеся суффиксами -add и -rm:
Удаление некоторых опций, однако, менее тривиально и часто зависит от самой опции:
Подробности о каждой опции можно узнать в описании команды docker service update.
Масштабирование и балансировка
Для распределения запросов между имеющимися нодами Docker используется схема называемая ingress load balacing. Суть этого механизма заключается в том, что на какую бы из нод не пришел запрос пользователя, он сначала пройдет через внутренний механизм балансировки, а затем будет перенаправлен на ту ноду, которая в данный момент может обслужить такой запрос. То есть, любая нода способна обработать запрос к любому из сервисов кластера.
Масштабирование сервиса Docker достигается за счет указания необходимого количества реплик. В тот момент, когда вам необходимо увеличить (или уменьшить) количество нод, обслуживающих запросы от клиента, вы просто обновляете свойства сервиса с указанием нужного значения опции —replicas:
В этом случае надо не забыть предварительно убедиться, что количество доступных нод не меньше, чем количество реплик, которые вы хотите использовать. Хотя ничего страшного не произойдет даже если нод меньше, чем реплик — просто некоторые ноды запустят у себя более одного контейнера одного и того же сервиса (в противном случае Docker будет стараться запускать реплики одного сервиса на разных нодах).
Отказоустойчивость
Отказоустойчивость сервиса гарантируется самим Docker. Это достигается в том числе за счет того, что в кластере могут одновременно работать несколько управляющих нод, которые могут в любой момент заменить вышедшего из строя лидера. Если говорить более подробно, то используется так называемый алгоритм поддержания распределенного консенсуса — Raft. Интересующимся рекомендую посмотреть эту замечательную визуальную демонстрацию: Raft в работе.
Автоматический деплой
Несмотря на то, что сервисы Docker предлагают вполне надежный способ запуска и обновления приложения, довольно часто быстрый откат к предыдущей версии затруднен по той или иной причине, что может служить причиной недоступности вашего сервиса пользователям в течении многих часов.
Самый надежный способ избежать проблем при обновлении приложения — автоматизация и тестирование. Именно для этого разрабатываются системы автоматического деплоя. Важной частью таких систем, как правило, является возможность быстрого обновления и отката к предыдущей версии на любой выбранной инфраструктуре.
Fabricio
Большинство инструментов для автоматизации деплоя предлагают описывать конфигурацию при помощи популярных языков разметки вроде XML или YAML. Некоторые идут дальше и разрабатывают свой собственный язык описания таких конфигураций (например, HCL или Puppet language). Я же не вижу необходимости идти ни по одному из этих путей по следующим причинам:
Конечно, многие могут возразить по этому поводу, что мол не все разработчики и DevOps знают Python. Ну, во-первых, Python (так же как и Bash) входит в джентльменский набор скриптовых языков, которые должен знать каждый уважающий себя DevOps (ну или почти каждый). А во-вторых, как это не парадоксально, знать Python практически необязательно. В подтверждение своих слов привожу пример конфигурации сервиса основанного на Django для Fabricio:
Согласитесь, что этот пример не сложнее, чем аналогичное описание на YAML. Человек, владеющий хотя бы одним языком программирования, разберется в данном конфиге без особых проблем.
Но довольно лирики.
Процесс деплоя
Схематически процесс деплоя сервиса при помощи Fabricio выглядит так, как представлено на рисунке ниже (после выполнения команды fab django для описанного выше конфига):
Рассмотрим каждый пункт по порядку. Для начала, сразу хочу заметить, что представленная схема актуальна при включенном режиме параллельного выполнения (с указанной опцией —parallel). Отличие последовательного режима только в том, что все действия в нем выполняются строго последовательно.
Сразу после запуска команды деплоя последовательно начинают выполняться следующие шаги:
Все команды Fabricio (кроме backup и restore) являются идемпотентными, то есть безопасными при повторном выполнении с теми же самыми параметрами.
Чем полезен Docker Swarm и в каких случаях лучше использовать Kubernetes
Технология контейнеризации позволяет запускать приложения в отдельных независимых средах — контейнерах. Они упрощают развертывание приложений, изолируют их друг от друга и ускоряют разработку. Но когда контейнеров становится слишком много, ими трудно управлять. Тут на помощь приходят системы оркестровки.
В статье разберем, чем может быть полезен Docker Swarm и в каких случаях стоит присмотреться к более продвинутым решениям.
Что такое Docker Swarm и чем он может быть полезен
При построении крупной продакшн-системы в нее обязательно закладывают требования по отказоустойчивости, производительности и масштабируемости. То есть система должна быть защищена от сбоев, не тормозить и иметь возможность для увеличения мощности.
Обычно для этого создают кластер — отдельностоящие хосты (серверы) объединяют под общим управлением, со стороны это выглядит как единая система. При этом она намного устойчивее к сбоям и производительнее:
При работе с контейнерами эти задачи решают системы оркестровки. Оркестровка — это управление и координация взаимодействия между контейнерами. Контейнеры запускаются на хостах, а хосты объединяют в кластер.
У Docker есть стандартный инструмент оркестровки — Docker Swarm Mode, или просто Docker Swarm. Он поставляется «из коробки», довольно прост в настройке и позволяет создать простой кластер буквально за минуту.
Кластер Swarm (Docker Swarm Cluster) состоит из нод, которые делят на два типа:
Схематичное устройство кластера Docker Swarm: три управляющих ноды и семь рабочих. Источник
В Docker Swarm вместо прямого использования контейнеров используются сервисы (Docker Swarm Service). Они похожи на контейнеры, но всё же это немного другое понятие.
Сервис — это что-то вроде уровня абстракции над контейнерами. В Swarm мы не запускаем контейнеры явно — этим занимаются сервисы. Для достижения отказоустойчивости мы лишь указываем сервису количество реплик — нод, на которых он должен запустить контейнеры. А Swarm уже сам проследит за тем, чтобы это требование выполнялось: найдет подходящие хосты, запустит контейнеры и будет следить за ними. Если один из хостов отвалится — создаст новую реплику на другом хосте.
Что такое Kubernetes и в чем его преимущества перед Swarm
Кроме стандартного Docker Swarm есть и другие инструменты оркестровки, например Kubernetes. Это сложная система, которая позволяет построить отказоустойчивую и масштабируемую платформу для управления контейнерами. Он умеет работать не только с контейнерами Docker, но и с другими контейнерами: rkt, CRI-O.
У Kubernetes довольно много возможностей, которые позволяют строить масштабные распределенные системы. Из-за этого порог вхождения в технологию гораздо выше, чем в Swarm. Нужно обладать определенным уровнем знаний, а на первоначальную установку и настройку может уйти несколько дней.
Если смотреть глобально, то устройство Kubernetes похоже на Swarm. Кластер состоит из двух типов нод: главной (Master) и рабочих (Worker):
Но если смотреть глубже, то устройство Kubernetes гораздо сложнее. В нем отдельные модули, например: proxy-балансировщик, etcd для хранения состояния кластера и другие компоненты. Не будем подробно всё это описывать. Достаточно понять, что Kubernetes устроен гораздо сложнее, чем Docker Swarm.
Глобально Kubernetes похож на Swarm. Но внутри все гораздо сложнее. Источник
Так зачем нужен Kubernetes со своими сложностями, когда уже есть «родной» и простой Docker Swarm?
Дело в том, что Kubernetes позволяет решать задачи, которые не под силу Docker Swarm. Для примера возьмем автомасштабирование: это когда система сама подстраивает свою мощность под нагрузку. Для этого в кластер автоматически добавляются/удаляются ноды, либо в существующих нодах для «тяжелых» задач будет выделяться больше/меньше ресурсов.
Но если система умеет масштабироваться, она отреагирует на возросшую нагрузку и увеличит ресурсы для этих задач. А когда нагрузка спадет, снова освободит эти мощности. Если кластер размещен в облаке, автомасштабирование сильно экономит деньги. В моменты простоя неиспользуемые ресурсы освобождаются, и за них не нужно переплачивать.
Так вот, в Kubernetes можно настроить автомасштабирование. Да, придется написать конфигурационный файл и выполнить другие настройки, но в результате вы получите рабочую и стабильную систему. А если развернуть кластер в облаке, которое поддерживает автомасштабирование, то на настройку уйдет всего несколько минут.
Docker Swarm не умеет делать этого «из коробки». Можно построить автомасштабируемую систему с использованием Swarm. Но для этого придется вручную писать скрипты или программы, которые будут следить за нагрузкой, принимать решения и посылать команды в Docker Swarm. Либо можно использовать сторонние разработки, вроде Orbiter, но его возможности тоже ограничены, и в любом случае это еще одна дополнительная надстройка над Swarm.
Теперь представьте, что кроме автомасштабирования у вас есть другие задачи, для которых приходится городить кучу инструментов над Swarm. Всё это нужно поддерживать, понимать как оно работает и тщательно тестировать при обновлениях. В Kubernetes такие сложности спрятаны внутри, и они стабильно работают.