Comments 15
Если появилась необходимость в одном из запущенных контейнеров в swarm-кластере, запускать другие контейнеры.
Как это правильно организовать с тем учетом, чтобы у запущенных контейнеров «второго порядка» был доступ в overlay сеть «родительского» контейнера.
Из альтернатив я бы тут выделил Kubernetes. Однако он сложнее в понимании и на данным момент не сильно функциональнее сварма
и на данным момент не сильно функциональнее сварма
Kubernetes немного дальше в например с той же интеграцией стораджа…
Ну и сама API не завязана на докер, это конечно как плюсы и минус можно видеть. Минус в сложности, так как ко всему есть абстракции, их надо один раз понять. Но зато, поняв их, вы становитесь независимы от сущностей облака или железа на которм бежит k8n. Как-бы принцип Контеэнров но в более широком смысле.
Со swarm пока больше возни в этом плане, но похоже с LinuxKit они тоже как-то по своему решают вопрос с абстракциями — IMHO пока слишком омбизиозный ( не совсем мне понятный) подход. Я бы сказал с k8n на данный момент не ошибится, он просто популярнее и активнее поддерживается (включая крупных игроков).
Но если есть/желание и возможность то и swarm надо иногда щупать
Касаемо стораджа. Я раньше тоже послушав как все прекрасно полез изучать. Оказалось не совсем. Вам в любом случае придется поднять ceph/glusterfs/поставьте своё руками. Так что магии нет. Апи возможно удобнее, но это кому как.
Не совсем понятно зачем быть не зависимым от докера. Он все равно под капотом. Лично мне приятнее использовать нативные инструменты.
Ну я же говорю это зависит от… Я к примеру тоже люблю.
С k8s вы не заморачиваетесь с тем где это все бежит. При случае можно и сменить все под k8s. Для больших и очень больших проектов это становится очень важно и не только по соображениям то-го что мы тоеоритически можем поменять облако, а скорее в более общем плане, как создание, абстркций — которые становятся технологически независимым стандартом.
В маленьком проекте может гораздо выжнее совсем другие вещи, как мотивация, одного девелопера ;)
Вот я в все пили свой частный проектик по ночам и там смотрю тоже на swarm но еще не решился.
Нет докер абстрагирует только процесс на ядре линукс (с разными плюшками конечно) на одной машине.
Сворм добавляет новую абстракцию, мы абстрагируемся от конкретной машины и деплоим в кластер тут у нас конечно и k8s он тоже это делает. Делают они это по разному и по своему интересно и поэтому мне оба интересны хоть и знаком поверхностно.
Но в k8s все немного шире. Особенно со стораджем (где конечно до сих пор не все гладко), но достаточно посмотреть список все-го того что можно подключить и как хорошо ИМХО это подлючение абстрагированно от деталей самих технологий.
https://kubernetes.io/docs/concepts/storage/persistent-volumes/
Или такая штука как igress которая если я правильно помню гораздо шире того, что предлагает sworm, где к сервису просто порт открывается и мэпится виртуально через кластер.
В k8s igress позволяет в большей степени не думать о нодах, сети (на до кибернетовском уровне) а перед sworm если не путаю надо сначало заглушку поставить если не хотите сервисы из кластера делать доступными по портам, не говоря уже о балансировке по путям, TLS и т.д.
И так во многом.
достаточно посмотреть список все-го того что можно подключить
Но у докера же volume драйверы. И драйверов явно не меньше, хоть и third party да, но это работает прозрачно, и переключение с одного стораджа на другой бесплатно.
В k8s igress позволяет в большей степени не думать о нодах, сети (на до кибернетовском уровне) а перед sworm если не путаю надо сначало заглушку поставить если не хотите сервисы из кластера делать доступными по портам
Load balancing идет из коробки, о нодах можно не думать. Dockre-Flow haproxy в коробку не входит, но он есть и прекрасно работает со свармом. Вариантов роутинга там достаточно
В целом Swarm еще пол года назад сильно уступал kubernetes, но развивается он очень быстро.
Плюс по поводу Kubrnetes у меня большие опасения. Это вендор лок, на этом самом Kubernetes. Swarm использует механизмы которые есть в докере. Что будет если Swarm победит? Вы привязаны к legacy технологии.
Но у докера же volume драйверы.
ими можно уже на уровне кластера управлять? а не на конкретной машине?
Load balancing идет из коробки
Вообщето это обширная тема. Из коробки там по портам. Если просто называть сущности.то никуда не придем ;)
LB есть и там и там
Scheduling есть и там и там
Persintance есть и там и там..
Dockre-Flow haproxy
Сторонние инструменты можно и с k8s использовать… Не аргумент. Да и костыль это например если интегрировать в ресурсе предостовлямые клауд-провайдерарами а k8s какраз под них заточен. и модули написаные под него абстрагируйту такие вещи. Это фишка дизйна…
Сворм похоже и не стремится туда..
Плюс по поводу Kubrnetes у меня большие опасения. Это вендор лок, на этом самом Kubernetes. Swarm использует механизмы которые есть в докере. Что будет если Swarm победит? Вы привязаны к legacy технологии.
Тут какраз все упорекают докер что это вендор лок ;)
k8s какраз и сторит все абстракцие которы могут быть реализованны где угодно и на чем угодно, вы многие компоненты можете выкинутЭи заменить, включая сам докер. А сворм это какраз больше на легаси похоже, потому что пытается быть минималистичным (что хорошо).
k8s преподносит себя как платформа, вот линукс с башем — тоже же вендор лок своебразный.
Что будет если Swarm победит?
swarm пока проигрывет очень в плане распространенности и поддержке, да и сырости.
ими можно уже на уровне кластера управлять? а не на конкретной машине?
Если это не локальный вольюм, а, какой то облачный драйвер, конечно он без проблем примонтируется к контейнеру, на какой бы ноде он не находился. А в kubernetes не так? Локальный вольюм по умолчанию расшарен на все ноды? Насколько я помню Kubernetes предлагает для этого использовать NFS, но NFS есть и в докере из коробки.
swarm пока проигрывет очень в плане распространенности и поддержке, да и сырости.
Я вот замечаю что его больше и больше внедряют в продакшн.
Я ставлю на Swarm, так как докер уже стал де факто стандартом. А если посмотреть на последние релизы то станет очевидно, что Swarm становится режимом по умолчанию (но еще не стал) даже для одиночных серверов. Ибо все новые плюшки, типа compose v3 с деплоем реализуются только под swarm mode.
PS Вы постоянно подчеркиваете что Kubernetes это абстракция. А много ли контейнерных движков вы знаете, что нужна абстракция?
Я вот замечаю что его больше и больше внедряют в продакшн.
k8s гораздо распространненей сворма. А гугл его как продукт в своейм облаке предлагает… из коробки.
А в kubernetes не так?
не так.
PS Вы постоянно подчеркиваете что Kubernetes это абстракция. А много ли контейнерных движков вы знаете, что нужна абстракция?
Абстракция от того где это все будет бежать полезна без того что-бы без того что-бы стравнивать движки...
Ну и как-бы ваша аргументаци о том что вы любите и что вам нравится…
Любите заниматься вопросами настройки кластера? — какие проблемы… Я вовсе не сказал что докер сворм плохой.
Сети Docker изнутри: связь между контейнерами в Docker Swarm и Overlay-сети