Comments 34
Swarm был хорош для своего времени. Жаль что его забросили, не так уж много фич ему нужно для маленьких кластеров. Выбор между Кубером и Номадом такое себе
Кубы хороши хотя бы тем что сварм сейчас полуживой, с багами по 10 лет и без каких-либо надежд на их исправление. Самый вкусный баг какой видел - система прибивает контейнер по оом или отключению хоста, и менеджер забивает убрать адрес этого контейнера из днс. И все, стабильно unavailable. Лечится только полным удалением сервиса. Аналогично алиасы, это лучше вообще не трогать
На сколько помню в k8s перезапуск тоже делается репликами в ноль и обратно. И ничего, работает.
В то же время Swarm ужасен, да. Я пробовал пользоваться.
В k8s есть перезапуск деплоймента `kubectl rollout restart deployment -n namespace name` и перезапуск можно настроить, там минимальное количество не перезагружающихся реплик и количество дополнительно создаваемых реплик. Вот только кажется там нет времени задержки между началом перезапуска следующей реплики.
readiness/startup probe сгенерят задержку.
И да, это все еще пересоздание подов, не рестарт.
Спасибо за комментарий. Хм, интересно. В k8s получается тоже нету перезапуска подов?
А что вы понимаете под перезупском подов? Контейнер, это сущность которая живёт не то что бы долго, в парадигме куба. Под, по факту уровень виртуализации и контроллер для контейнеров.
В чем принципиальная разница между перезапуском (я немного слабо понимаю суть этого) и создал/убил, стандартный роллаут? У вас же стэйтлес если это деплоймент
Спасибо за ответ. Моё мышление в этом вопросе на базе Docker формировалось.
Вот например есть сервис, которому нужно несколько дополнительных системных зависимостей. Через скрипт в docker-compose.yml service.entrypoint их устанавлиешь и обходишься без Dockerfile.
Когда понадобилось перезапустить сервис, после изменения файлов в volumes, чтобы изменения вступили в силу. Просто делаешь docker restart name.
А в swarm, так не получается. Только пересоздание. Но пересоздание не годится, так как каждый раз будет срабатывать долгий entrypoint.
В Kubernetes сейчас смотрю с entrypoint похоже тоже не получится.
Получается от entrypoint на уровне конфигов в кубере придется забыть?
Я правильно понимаю, что ваш entrypoint это условно `apt-get install xxx` и потом собственно запуск сервиса? О таком действительно стоит забыть и не вспоминать.
При выполнении docker restart - `apt-get install xxx` выполняется тоже, но благодаря тому, что это тот же самый контейнер и xxx уже установлен в этом контейнере, не выполняет собственно установку.
Это вообще крайне вредная практика. Скажем, в репозитории xxx обновилось, и при новом запуске этот скрипт на старте поставит новую версию xxx, с которой ваш скрипт работать не умеет. И получается, что сервис неожиданно сломался. В противоположность самой идее stateless image, который всегда одинаковый.
А если сделать правильно - через Dockerfile, то эта долгая установка выполнится только один раз при сборке. И хоть файлы в volume поменял, хоть всю хост-машину перезапустил - медленного старта не будет.
Ну а если просто хочется переопределить endpoint в конфиге - то это kubernetes умеет. https://docs.docker.com/reference/cli/docker/compose/restart/ А если действительно нужно сделать что-то перед стартом, то readiness пробы в помощь.
С Dockerfile для нашего хостинга не подходящее решение. Мы не даём пользователям возможности собирать свои контейнеры на базе Dockerfile, а только предоставляем возможность запустить поддерживаемые образы.
Махинации над контейнером только через entrypoint, поэтому и встал этот вопрос с перезапуском. Ведь изначально, когда работало на docker compose этой проблемы не было. Enntrypoint срабатывал только после создания контейнера, а при обновлении файлов только рестарт и command.
Вы, кажется, не ту ссылку привели.
Это плохая практика, согласен с объяснением ниже. Я не очень понимаю как в этом случае работает дистрибуция, как вы понимаете что там внутри, если вы потом ещё тянете руками какие то зависимости.
Несите все в контейнер, делайте его самодостаточным. Новые зависимости новый билд, новый имидж.
Вы же все равно рано или поздно захотите ci/cd, и потом начнутся танцы с бубнами. Лучше сразу заложить эту возможность
Подождите, в смысле в сворме нет рестарта сервиса? А как же docker service scale servicename=0 и затем ....=1? Я всегда так перезапускал. Или я неправильно что-то понял?
Я заблуждался, благодарю Вас ещё раз за обратную связь. Дописал вконце статьи об этом.
Да, все так.
Если можно удалить под, и деплоймент его запустит заново. Но проблемы с пробами здесь тоже самые
Год назад я перевёл все скрипты из "просто контейнеры" в Swarm. Kubernetes тоже показался слишком сложным и тяжёлым, и все знакомые с опытом наперебой от него отговаривали.
Много чего не хватало (например, шедулер для запуска по расписанию), но яжпрограммист и знаю что делать с фатальными недостатками. В комментариях полгода назад я вкратце рассказал как я решил вопрос и даже скриншоты показал.
Сейчас, спустя год, в принципе, всё работает и практически не требует особого сопровождения, однако остаётся самописным продуктом для внутреннего использования с очевидными недостатками.
Понимаю вашу боль. Прохожу через всё это. Точно могу сказать, что год назад мне ума не хватило бы разобраться с кубером, сейчас с помощью GPT, более менее продвигаюсь в освоении. На самом деле вещь крутая, не удивляюсь теперь что это новый стандарт. Там можно даже сделать CRD (Custom Resource Definition) и создавать свои ресурсы, которыми также управлять через kubectl, и навешивать контроллеры которые обслуживают логику.
Теперь вижу, что если грамотно использовать кубер, то от старого кода можно половину выкинуть.
Ваш работодатель так и не согласился опубликовать код, да?
Пользуюсь вот этим шедуллером https://github.com/crazy-max/swarm-cronjob
Да, я его смотрел, но это вообще несерьёзно. У меня 100+ сервисов в Swarm - нужен какой-то дашборд чтобы видеть список, видеть топ ошибок, расписание и т.п. В этом сервисе нет вообще ничего.
Конфигурация через labels - сначала мне тоже показалось интересным, но потом я понял насколько это неудобно. При смене label сервис обновляется и Swarm может его прибить и перезапустить.
Особенно неудобно оказалось это для конфигурирования Traefik - если все параметры он берет из labels, то получается, что для того чтобы поменять, например, внешний хостнейм или добавить фильтр по IP - нужно обновлять сам сервис чтобы применить labels. Логики мало, поскольку сервис за это не отвечает. Так что в конфигурировании через labels я разочаровался.
По поводу пропадания контейнеров из Swarm при остановке - это что-то странное. Я, имея Swarm-сервисы, иногда делаю "docker kill" для контейнера на ноде и он прибивается, а спустя несколько секунд запускается новый - как я понимаю это его Swarm-сервис и перезапускает. Делаю так когда обновил образ и лень кликать рестарт на вебе.
Это, да. Если убить, то сварм новый запустит. Речь о том если остановить или перезапустить, то он станет самостоятельным, сварм про него забудет, а вместо него другой запустит.
Swarm был хорош для своего времени. Жаль что его забросили, не так уж много фич ему нужно для маленьких кластеров. Выбор между Кубером и Номадом такое себе
dokku - очень удобно, попробуйте
Насчет сетей не понял, там есть overlay networks всё прекрасно работает на трёхнодном кластере
https://docs.docker.com/engine/swarm/networking/
Контейнеры запускаются на любой ноде, как он там сам захочет, связь между контейнерами есть (если overlay сеть одна). Порты снаружи по идее с любой ноды попадут в нужный контейнер, где бы он не был запущен.
Но я использую vrrp, так что в любой момент трафик заходит через одну ноду.
Есть один контейнер с сетью host (это nginx который проксирует трафик до контейнеров) нужно было, чтоб он бегал за IP vrrp. Даже вполне легко решилось, сервис привязал к label ноды, а label актуализирую в хуках keepalived.
Работает, но нужно управление политиками. Для хостинга важно ограничивать, например, возможность исходящих запросов на какие-то порты, например почтовые, или запретить звонить из контейнеров в хост систему по IP. С помощью calico это можно сделать на уровне сети, при помощи конфига сервисов, а без этого придется добавлять ограничения в iptables на каждой отдельной ноде.
Все проще
Если у вас отдел из 2+ девопс то вам кубернетес выбирать.
Если 2 админа ваш потолок, то swarm
В swarm в разы меньше проблем, сущностей и задач, связанных с поддержкой и развитием.
На короткой дистанции да. Но если потом, например, вы захотите шифровать траффик между сервисами на уровне сети или маршрутизировать траффик на уровне сети по заголовкам или адресам, или анализировать траффик. То проще будет всё таки грокнуть кубер и внедрить в него Istio с Envoy для всех этих задач чем изобретать свои велосипеды.
Кубы хороши хотя бы тем что сварм сейчас полуживой, с багами по 10 лет и без каких-либо надежд на их исправление. Самый вкусный баг какой видел - система прибивает контейнер по оом или отключению хоста, и менеджер забивает убрать адрес этого контейнера из днс. И все, стабильно unavailable. Лечится только полным удалением сервиса. Аналогично алиасы, это лучше вообще не трогать
Автор, пожалуйста, читайте свою статью перед публикацией, вы по три раза повторяете одно и то же.
Спасибо, за замечание. Если Вы имеете в виду "нет возможности перезапуска", то считаю, что оно справедливое.
Просто в трёх разных контекстах с этим столкнулся:
Не поднять упавший контейнер
Не перезапустить без пересоздания
Не управляется через docker cli
И на примере реальных кейсов хотел показать, с чем сам столнулся. А литературного таланта не хватило, чтобы это правильно обыграть. Может если нумерацию заголовков убрать, то не будет вызывать ожидание, что в списке должны быть разные недостатки🤔
Чем Kubernetes лучше Docker Swarm