LINUX.ORG.RU
ФорумAdmin

Docker Swarm / Kubernetes

 , , ,


2

3

Кто что использует? Какие преимущества и сложность внедрения в небольших командах, порог входа? Docker swarm, разве, не умер? Как-то слабо его пиарят на фоне Kubernetes...

★★★★★

swarm давно уже часть докера, то бишь встроен в демона и клиент, так что нет смысла его пиарить

Deleted
()
Ответ на: комментарий от stave

шо? k8s это внешняя тузла, которая _может_ юзать и докер. Может они там что-то в докере доковыряли под k8s, я не следил. Но встроить его в докер, когда уже там есть swarm ?

Deleted
()

Цубернетес - переусложнённое говнище, как и всё, что в последние лет 10 высирает гугол. Юзай Swarm.

anonymous
()
Ответ на: комментарий от Deleted

Я бы сказал, не доковыряли, а наоборот выковыряли из докера самый базовый функционал контейнеризации, назвали containerd и теперь всякие девопс-вундервафли используют его вместо докера (openshift, например, переехал на него).

l0stparadise ★★★★★
()

Для небольших команд с небольшой инфраструктурой под CI/CD - проще сварм, он где-то с 1.10 вшит в докер и поднимается одной командой.

Для чего-то более комплексного - кубернетес.

А вообще пробуй оба. Кубернетес посложнее для вхождения, но с ним сейчас интегрируется чуть более чем все (в отличие от того же сварма).

l0stparadise ★★★★★
()
Ответ на: комментарий от Deleted

Может и так. Я как-то проглядел момент появления, месяц назад начальство попросило задеплоить опеншифт - наткнулся, что вместо докера ставится containerd. Да и сварм мне никогда не нравился

l0stparadise ★★★★★
()
Ответ на: комментарий от l0stparadise

Ну там был докер он же запускалка контейнеров, он же клиент, он же петя, он же вася.

Потом сделали снаружи сварм (мы какакраз пилил к этому всему UI) там внутри был ад и погибель. Они видимо догадались об этом, и отрефакторили. Так что часть сварма вплыла в демон докера, который стал containerd, клиент выделился в просто docker.

Deleted
()

Кто что использует?

k8s

сложность внедрения в небольших командах

Внедрял в одиночку.

порог входа?

Читаешь неспешно доки недельку.

anonymous
()

Я внедрил кубернетес исходя из логики «когда-нибудь будет крупный клиент, а мы опа-опа кубернетес-мастера». И считаю это правильным шагом, потому что k8s сложный, состоит из кучи компонент и лучше всю эту машинерию выучить заранее.

После года эксплуатации могу сказать, что на масштабе меньше десяти нод в кластере, пара десятков стручков максимум кубернетес себя не оправдывает. Так что всё зависит от задач и масштабов.

ugoday ★★★★★
()
Ответ на: комментарий от l0stparadise

А на самом деле, шапку и куб задрали выверты ребят из докера, и они начали всеми силами его выпиливать. Это еще к вопросу о версии докера в репе шапки.

stave ★★★★★
()
Ответ на: комментарий от stave

Попробуй последний виндовое клиент. https://www.docker.com/kubernetes

нет уж спасибо. но да в клиенте какй-то поддержка k8s заявлена

Сварить умер, зачем о покойниках говорить.

Фиг там, он по твоей же ссылке живёт и здравствует.

Deleted
()
Ответ на: комментарий от stave

Это еще к вопросу о версии докера в репе шапки.

Даже не смотрел, честно говоря. На Openshift хостах что ансибл подтянул, то и стоит. А на хостах с «ванильным» докером используем репы докера, пока партия не запретила. Но да, я подозреваю, что там какой-нибудь 1.8.

l0stparadise ★★★★★
()
Ответ на: комментарий от l0stparadise

Мне кажется, или сам docker начиная с 18.03 использует containerd? Т. е. это просто «взяли кусок докера и запилили к нему стабильный интерфейс», не?

intelfx ★★★★★
()
Ответ на: комментарий от Deleted

Что он дает по сравнению с просто развертыванием кубера тем же kops-ом?

anonymous
()
Ответ на: комментарий от ugoday

Можно более развернуто по поводу «пара десятков стручков максимум кубернетес себя не оправдывает»?

Мое личное ИМХО что даже одна нода под k8s привнесет много прекрасного в имеющиеся CI/CD. Ну и helm для прод. деплоев незаменим.

bonds
()
Ответ на: комментарий от bonds

Кубернетес большой и сложный, состоит из большого количества компонент с которыми нужно разбираться. Чтобы это хозяйство работало более-менее стабильно нужно инвестировать время. Если нужно оркестрировать пару десятков контейнеров, то проще написать свой кубернетес на баше.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

С позиции инвестирования времени и если речь идет о построении совсем маленьких окружений - конечно да. Проще запускаться на том что знаешь и умеешь.

Но если Вы связаны с разработкой и требуется организовать CI/CD, то лучше инвестировать время в k8s. Больше профита будет при использовании кубера и в эксплуатации.

bonds
()
Ответ на: комментарий от bonds

Всё зависит от целей. Если вы хотите прокачаться за счёт работадателя и добавить красивую строчку в CV, то безусловно

лучше инвестировать время в k8s

P.S. Ни в коем случае не осуждаю, сам такой.

ugoday ★★★★★
()
Ответ на: комментарий от bonds

Мне думается, что в этом кубернетесе наворотили огороды, которые не так-то просто будет развернуть на разношерстных хостинг площадках. Как быть, например, если нет возможности обновить kernel и установить новое ядро linux, на какой-нибудь ноде или даже на пятерке нод? Или обновление кернела вызывает проблемы и дальше все приходится ручками разруливать. Или, к примеру, затыки в сетевой подсистеме докер-кубернетес, которые заранее не предугадаешь. Такое изредка бывает на всяких virtual серваках в hetzner.

menangen ★★★★★
() автор топика
Последнее исправление: menangen (всего исправлений: 1)

Самое дерьмовое это несовместимость версий Куба между собой, а так норм.

AUX ★★★
()
Ответ на: комментарий от menangen

Мне думается, что в этом кубернетесе наворотили огороды, которые не так-то просто будет развернуть на разношерстных хостинг площадках.

kubespray с этим более-менее справляется.

Как быть, например, если нет возможности обновить kernel и установить новое ядро linux, на какой-нибудь ноде или даже на пятерке нод?

Почему нельзя?

Или обновление кернела вызывает проблемы

Это не кубернетес. Это докер. Он, к сожалению, вот такой. Иногда надо вручную подбирать удачную комбинацию железа-ядра-докера.

к примеру, затыки в сетевой подсистеме докер-кубернетес, которые заранее не предугадаешь.

Не сталкивался. По крайней мере calico-network работает великолепно.

ugoday ★★★★★
()
Ответ на: комментарий от AUX

k8s — это javascript от devops. Некогда думать о совместимости, нужно доставлять фичи. Фичи! Больше! Быстрее!

ugoday ★★★★★
()

Использовал на localhost кластере дома из нескольких машин.

Docker Swarm:

Плюсы: Встроен в докер и заводится парой тривиальных команд. Не занимает больше ресурсов чем просто докер демон. Удобно настраиваются сети, легко включается шифрование. Для WebUI можно пользоваться Portainer.

Минусы: Баги! Сети docker swarm тригеррят уйму багов в разном софте, который любит подключаться по сокету, сутками ничего по нему не слать и удивляться что тихо отвалилось. --mode=global сервисы тригерят баги в деплойменте сетей. Нельзя временно отключить --mode=global сервис не удаляя. Не совсем ясная связь Docker Compose и его маппинга на Docker Swarm - прийдется играться методом проб и ошибок. Например насколько я понял нельзя сначала сконфигурировать сервис из Compose файла, поменять файл и обновить сервис с этим изменением (могу ошибаться). Убогий способ управления кластером с удаленной ноды, большинство как я понял SSH логинятся на manager node и запускают команды там

Kubernetes:

Плюсы: Значительно стабильнее. Намного больше фич. Намного лучше UI. Можно конфигурировать сугубо из файлов 100% фич как source of truth. Более очерчена концепция Ingress.

Минусы: Если получаешь кластер одним кликом в облаке - молодец, если сам ставишь на железо - готовься к длительной возне. Много демонов для обслуживания.

vertexua ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.