Комментарии 33
Полностью со всем согласен. Только вот проблема в том, что донести до тех.диров стартапов что им не нужен (сейчас, пока не вышли в прод, и в ближайшие года три ещё точно) K8s - почему-то крайне сложно. При этом аргументации у них никакой нет. Просто - у нас куб, и всё, не обсуждается. И не обсуждается не потому, что идея взять docker swarm дурная, или потому что реально нужен куб, или потому что в компании полно девопсов с крепкой экспертизой по кубу - ничего подобного! Не обсуждается потому, что, с одной стороны, куб это модно, в managed варианте выглядит простым, и на 100% точно потянет любые наши нагрузки, а, с другой стороны, никаких аргументов почему бы на ближайшие годы не взять решение по-проще - нет.
Ещё было бы любопытно увидеть аналогичное сравнение с Nomad.
Так а зачем брать решение попроще, если заранее известно, что оно только на ближайшие годы? У нас был переход с Docker Swarm на K8s в процессе роста компании - было долго и тяжело. Причём практически изначально было понятно, что Docker Swarm нам будет не хватать по многим параметрам, но "стартап же, надо быстро и дёшево".
Во-первых, заранее ничего такого абсолютному большинству стартапов не известно.
Во-вторых, абсолютное большинство стартапов не дорастёт до той 1000 серверов, на которых swarm уже не тянет. Большинство даже до 100 серверов не дорастёт.
В-третьих, технологии сменяют друг друга очень быстро. Через 3 года куба может уже не быть (что маловероятно, но мало ли - гугл очень много проектов закрыл уже). Или может появиться лучшая альтернатива кубу (что весьма вероятно - куб всё-таки дико переусложнён и проблем у него дофига и больше).
В-четвёртых, с docker swarm у стартапа больше шансов выжить - именно потому, что он проще, требует не такую сильную экспертизу девопсов, и позволяет двигаться быстрее.
Как тот, кто личный небольшой проект переводил с docker-compose на swarm, потом на k8s, могу сказать, что k8s проще и стабильней чем первые два, когда у вас больше одной машины в кластере.
Так что идея сразу делать на k8s, если у вас предпологается что-то сложней лендинга-визитки - вполне себе здравая.
Можно пример в чём конкретно проявлялась нестабильность swarm в небольшом личном проекте?
Обратите внимание на фразу "когда у вас больше одной машины в кластере".
Если делать кластер из одной машины (просто чтоб удобно запускать контейнеры тем же свармом) - все работало хорошо.
Как только туда добавлялась новая машина, сварм начинал зависать, как ни странно. Просто банально переставал отвечать на запросы или делал это очень долго. Контейнеры при этом работали, но новые не запускались.
Разобраться с этим я так и не смог. Было это правда аж пару лет назад, но осадочек остался.
Нагуглить хоть что-то про сварм в то время было прям трудно. Он как будто не существовал в ИТ-поле. Есть базовые мануалы "как запустить" и добавить ноду, но вот описания каких-либо проблем - пустое место, увы.
Найти хостера с поддержкой сварм-как-сервис - думаю, невозможно.
Плюс я не особо представляю как можно работать с несколькими нодами в сварме, когда он банально не умеет распределять ресурсы. Может сейчас уже научили, но в то время он запускал контейнеры просто от балды. А в случае если ноды разные - это беда.
Ясно, спасибо. По поводу самой проблемы ничего не скажу - я swarm использовал довольно активно и много, такой проблемы никогда не наблюдал, и никогда не слышал (до этого момента), чтобы жаловались на проблемы с настолько базовым функционалом swarm.
Насколько я знаю, до встроенного в саму утилиту docker режима swarm существовал отдельный продукт, который так же назывался docker swarm - им я пользоваться не пробовал, если Вы тогда случайно взяли его - возможно проблема была в этом.
Managed swarm вряд ли существует, согласен, но это не удивительно - там нечего особо менеджить, а то что есть - не создаёт пользователям таких заметных сложностей, чтобы появился смысл нагородить целый специализированный сервис в облаке. Если кому-то нужен визуальный дашборд кластера - как минимум один такой есть в виде отдельного контейнера, запустить самостоятельно его не сложно.
Что до распределения ресурсов под конкретную ноду - раньше я помню обходился метками для нод разных типов и указанием при деплое на ноды какого типа выкатывать данный контейнер. Сейчас в доке вижу явное резервирование https://docs.docker.com/compose/compose-file/deploy/#resources
Это меня и остановило. Если появляется проблема в настолько базовом сценарии, то я стараюсь такие решения не использовать.
Хотя на тот момент сварм работал несколько месяцев на одной жирной ноде и проблем не знал.
Не, то был именно докеровский swarm :) Не знал даже, что там еще что-то было.
Для дашборда в то время использовал Portainer (кажется так) - отличная штука.
Да, действительно. Тогда не было указания ресурсов и все сводилось к "используйте k8s".
А можно чуть подробнее?
По каким именно параметрам было почти сразу понятно, что функционала swarm вашему проекту не хватит? Какие требования привели к принятию решению переходить на K8s?
Почему перейти было долго и тяжело? Ведь если проект уже работает в контейнерах, то смена оркестратора не должна быть прям долгой и тяжёлой. Да, там хватает отличий и нюансов, но если не пытаться сходу переделать всё "в стиле" куба то перенос один-к-одному или близко к этому не должен быть долгим и тяжёлым. Или долго и тяжело было как раз из-за сложности самого куба? :)
Чего не хватало в swarm? Самое главное, наверное, стабильности. Частенько что-то там зависало, надо было ручками перезапускать (только давайте не будем играть в "да вы просто неправильно его настроили" :-) ). Были проблемы с доступом к логам в режиме реального времени. Ну, и future proofing + общий стек (у нас еще и nomad встречается в некоторых командах). Это из того, что я знаю точно. Наверняка, еще было много чего и крупного, и по мелочи - это уже надо у девопсов спрашивать, у меня другая специализация.
Переходить было "долго и тяжело" в основном не по нетехническим причинам - просто к моменту принятия решения о переходе уже наплодили сервисов, и надо было переносить всё это без даунтайма, постепенно, плюс тестирование и пр. Ну, и в целом нашему начальству бывало непросто объяснить, почему тратится время на инфраструктуру, за которую с клиентов дополнительно денежку не взять, вместо новых фич, которые можно продать.
Естественно, в процессе перехода вылезали всякие баги и недочёты - где-то криворучки, где-то недостестировали. В общем, не виню в этом k8s.
Не, играть в это не будем, я не для того спрашивал. Инфа полезная, спасибо.
Только один вопрос ещё: понятно, регулярно случались проблемы, порядок проблем тоже понятен, перешли на куб, в процессе перехода было сложно но в результате успешно перешли и довольны… и что, с кубом в эксплуатации после завершения перехода проблем нет вообще? Или есть, но значительно меньше, чем было со swarm?
никаких аргументов почему бы на ближайшие годы не взять решение по-проще - нет.
Именно!
Если под текущие задачи одинаково хорошо подходит несколько решений, скорее всего возьмут не узкоспециализированное (запросы могут и поменяться), не самое простое (вдруг вырастем), а самое популярное (и при этом с достаточно низким порогом вхождения).
Нужны очень веские аргументы для выбора чего-то особенного. И как раз в отсутствие специалистов, способных аргументированно сравнить несколько решений, четко обосновать, почему именно для данных требований и с учетом планов развития лучше выбрать что-то альтернативное, чаще выбирают то, что легко внедрить, чего практически наверняка хватит на долгие годы и по чему (вследствие популярности) кучу всего легко нагуглить в случае проблем
(и при этом с достаточно низким порогом вхождения)
Вот! Вы всё верно сказали, кроме этого момента - тут и происходит когнитивное искажение: тех.дир лично нажатием пары кнопок поднимает первый тестовый managed-кластер, что и создаёт у него впечатление, что у куба "достаточно низкий порог входа". Но поднятием кластера ведь всё не заканчивается, на этом всё только-только начинается - и вот чем дальше этот кластер используется, тем понятнее становится, что порог входа в куб намного-намного выше, чем показалось на первый взгляд.
В одном из стартапов, где я эту картину не так давно наблюдал, доходило до смешного: да, оно managed, да, оно в облаке, да, мы платим только за используемые ресурсы… стоп! А откуда у нас в тестовом кластере с парой подов, которые ещё никто не использует вообще - 700GB логов за три месяца? А никто не знает, девопс мне на этот вопрос ответил "это служебные логи куба, это норм". А мы за них платим? Конечно… А они нам нужны? Вряд ли. А убрать их как-то можно и сделать чтобы в таком объёме не накапливались? Эээ… И, разумеется, никто с этим ничего делать не стал. Потому что хз что там происходит и разбираться в этом нужно довольно долго.
Неужели управлять кластером Кубера намного сложнее, нежели кластером Docker Swarm? У меня нет впечатления, что Кубер ломается на ровном месте, при типовых операциях. Я имею ввиду, если не используется особой специфики, просто запускаются какие-то поды.
Коли говорим про Docker Swarm полностью самостоятельно развернутый и управляемый, то и мастер ноду кубера самостоятельно поднимать надо (к вопросу о плате за логи).
Если о Managed Kubernetes речь зашла - это дополнительное облегчение, конечно. Но за дополнительные деньги, это понятно. Как и вообще облака.
И еще момент - когда я говорю про "низкий порог входа" я имею ввиду именно быстрый старт, запуск сервисов. Потом админам, разумеется, придется учиться, в т.ч. разбираться с логами. Кстати, будь я админом, я бы с большей мотивацией именно в потрохах Кубера разбирался, чем относительно редкой зверюшки.
Чтобы чем-то управлять его надо понимать. Сравните объёмы документации по обоим продуктам, и все вопросы отпадут.
Дело не в том, что он ломается на типовых операциях - он не ломается. Дело в том, что порог входа - это не порог на запуск кластера, а порог на всё оперирование кластером для типового проекта небольшого размера (включая борьбу с логами безумного размера, да). Т.е. условно сколько времени нужно потратить на обучение девопса и сколько времени у него уйдёт на выполнение всех задач, чтобы было сделано всё необходимое для проекта. И вот для k8s и docker swarm эти цифры отличаются порядка на два примерно.
Частично такая разница вызвана тем, что docker swarm базируется на docker-compose - который девопс, как предполагается, уже должен знать, и время на его изучение не включается в порог docker swarm. А вся остальная документация, специфичная именно для docker swarm, прочитывается за пару часов. Практический опыт с ним нарабатывается ещё где-то часов за 5-10 максимум. И на этом - всё. Больше ничего никогда не понадобится. Есть пара неочевидных грабель, о которых придётся узнать когда на них наступишь, но это ещё по часу на каждую. Т.е. два дня - и это не просто порог входа, это уже сразу уровень эксперта по docker swarm.
По кубу за два дня можно только подобрать список основных ссылок для изучения. Ещё пара дней может уйти на то, чтобы поднять кластер локально (нет, это не шутка, я лично это делал - в сумме где-то так и ушло: пока разобрался какие есть разные "упрощённые" инструменты для этой цели и чем они отличаются, пока отрепортил по ним несколько багов, пока из тех, которые заработали, выбрал тот, который решил использовать…). Для сравнения - в docker swarm это делается менее чем за минуту, одной командой.
Куб даёт безумную гибкость. Которая нужна гуглу. И абсолютно не нужна большинству текущих пользователей куба. За эти гибкость приходится очень дорого платить - своим временем, вниманием и плохим пониманием куба в целом.
Да, похоже, я слишком переоценил Docker Swarm. Ротация секретов едва ли не самое навороченное.
Теперь согласен. Спасибо!
Чтобы чем-то управлять его надо понимать
# cluster.yaml
nodes:
- address: 1.2.3.4
user: user
ssh_key_path: "~/.ssh/key"
role: [controlplane,worker,etcd]`rke up` в папке с этим файликом
В общем-то все. Ну разве что на саму ноду надо поставить докер, но это вроде не сложно.
Но поднятием кластера ведь всё не заканчивается, на этом всё только-только начинается - и вот чем дальше этот кластер используется, тем понятнее становится, что порог входа в куб намного-намного выше, чем показалось на первый взгляд
А можно конкретный пример?
Ну только не уровня гугла "у нас миллион машин и еще 10 на марсе", а что-то реальное. В k8s на самом деле две с половиной сущности. Просто это конструктор, но никто не заставляет собирать сложные штуки.
Когд а я к CKA готовился, самое сложное, наверное, было RBAC и, возможно, сертификаты, где какие находятся... Скорее всего потому, что при самостоятельных играх с кубером мне это не требовалось. Со всякими tolerance и affinity (типа как сделать на обычных подах аналог DaemonSet строго по одному поду на ноде) не с первой попытки получилось.
Хотя ставить это в минус по сравнению со Swarm некорректно, ибо там такого просто нет, насколько я понимаю. Не хочешь - не используй.
Но опять же, это гуглится достаточно просто. Да, там есть миллион нюансов, но распространенные кейсы вполне себе устоялись.
RBAC - да, не очень просто. Но мы тут вроде про простые случаи говорим (в сварме по другому не будет), так что оно либо не нужно, либо сводится к добавлению чуть ли не готовой роли из какого-нибудь helm чарта.
В k8s мне лично нравится эта фишка: можно все сделать просто и быстро, но если надо, то намудрить можно очень сложные схемы.
В k8s мне лично нравится эта фишка: можно все сделать просто и быстро, но если надо, то намудрить можно очень сложные схемы.
Да я тоже считаю что для простых задач кубер использовать не сликом сложно. Это дальше уже разрастаются нюансы.
Хотя если вот вообще ничего не знать ни про Swarm ни про Kubernetes, первый все-таки быстрее запустить, и читать надо ощутимо меньше.
Про Swarm реально прочитать все, глава за главой. А про Kubernetes так не получится, мне кажется. Когда ничего не знаешь и хочешь понять масштабирование, количество запущенных экземпляров пода, тут и ReplicaSet и Deployment, и DaemonSet. Даже если в рамках базового корпоративного пайплайна DaemonSet никогда не потребуется запускать, понять это надо. Пусть и не обязательно в первый день, но времени все-таки уйдет больше, чем на овладением Swarm той же функциональности. Хотя бы потому, что чтобы понять, что данная фича не нужна, хоть бегло, но прочитать про нее надо.
При этом я все равно за Kubernetes. Если просто машинки с докером уже не хватает, и речь уже идет об оркестрации, я предпочитаю вложиться чуть больше, но иметь запас и жить на этом долго.
Когда совсем ничего не знаешь, docker & docker-compose же :)
Именно так :)
Либо хватает docker & docker-compose, либо уже в сторону K8s двигаешься. Отрезать собаке хвост по чуть-чуть не мой стиль.
Спасибо за комментарий! Описанный вами случай действительно часто встречается. Часто это происходит именно из-за влияния комьюнити K8s, поскольку "аналоги" просто не обладают такой поддержкой.
Про сравнение с Nomad взяли на карандаш)
Во вторых я его не хочу знать.
Обычно тех специалистом платят за решения задач работодателя, а не за изучение того, что поможет найти работу получше. Возможность изучить новую технологию в ходе решения задачи работодателя это крутой бонус, но это только бонус, и это не должно мешать решению этих самых задач.
Подсадить компанию на него это страдать. Страдать с поиском типовых решений, страдать с поиском людей имеющих экспертизу. Страдать с нетипичными проблемами. Страдать с маштабированием.
Вот это все применимо к кубер в намного большей степени чем к сворму. Для поддержки сворм кластера нужно намного меньше квалификации чем для поддержки кластера кубера. И не факт что у компании вообще есть ресурсы на поддержку k8s кластера. Я вот в последние пару лет очень много компаний повидал, которые польстились на рассказы о том как легко рулить кубернетес кластером. И вот они там реально страдают. Ситуация когда товарищи что-то запустили и у них все данные похерились потомучто в качестве вольюма был emptyDir наблюдал не раз.
Касательно же масштабирования - нужно здраво оценивать эти самые масштабы. А то иногда выясняется, что ближайшие лет 5 можно вообще одной тачкой и каким-нибудь компоузом обойтись.
Это только если рынок работодателя, а не работника. Хороший специалист просто не пойдет на плохой стек.
Ок, кажется я вас не правильно понял. Если "Ну я бы тоже был против Сварма как тех специалист" читается как "я бы не выбрал компанию в которой такой стек", то тут вопросов нет, у меня тоже есть стеки на которые я бы не пошел ни за какие коврижки. Я же изначально это понял как "если бы в компании в которой я уже работаю нужно было бы выбирать оркестратор, то я бы не выбрал docker swarm просто потому что он мне не интересен".
Можно. А нужно ли? Жизнь только выбором оркестратора не заканчивается. Хороший грамотный специалист разбирающийся в кубере стоит 300-500 т.р. в месяц
Вы сейчас все правильно пишете, вот только это относится только к мопаниям с более-менее сложной IT инфраструктурой. В реальности же есть дофига компаний, где вся IT инфраструктура - это пяток серверов. И нет у них не то что админа за 300к-500к, а даже просто админа. А кластер им вподдерживают либо разработчик, либо и вовсе какой-нибудь датасайнтист (как блин это слово вообще на русском писать-то?). И вот такие товарищи наслушаются рассказов о простоте кубера и ставят его. А потом не могут вольюмы и ингрес там настроить и херят свои данные при рестарте.
Я уже давно перерос подход в айти "Готовое простое решение лучшее".
Я не уверен, что тут вообще применимо понятие "перерос". Скорее это просто временный этап, и через несколько лет Вы к этому подходу ещё вернётесь, частично потому, что устанете от лишних сложностей, частично потому, что появится больше понимания какие требования в проектах реальны, а какие просто хотелки на будущее, и что для реальных требований простых решений нередко хватает с головой.
Простые решения - лучшие до тех пор, пока наши требования не выходят за рамки возможностей этого решения. Эти рамки важно осознавать при выборе простых решений. Выход за эти рамки необходимо отслеживать, и либо блокировать такие требования, либо в этот момент переходить на другое решение, соответствующее изменившимся требованиям.
Подход, когда вместо простого решения сразу берётся самое сложное и навороченное "на вырост" - создаёт проблемы с первого дня. Ну т.е. с простым решением проблемы могут возникнуть через год-два, как Вы описали, а со сложным они гарантированно возникнут намного быстрее. Эти проблемы могут быть замаскированы непониманием сложного решения, т.е. вместо быстрого понимания "это не поддерживается и надо либо менять решение либо городить хак ручками" проблема выглядит как "я хз почему оно так себя ведёт или как это реализовать, но я почитаю доку с недельку, проконсультируюсь в сообществе, и, скорее всего, найду штатное решение".
Аргумент "у сложного решения большое коммьюнити и там можно найти решение любой проблемы" выглядит привлекательным, но ровно до тех пор, пока не оказывается, что с простым решением количество возникающих проблем меньше на два порядка, и, да, ответы на пяток известных проблем простого решения тоже легко гуглятся. Количество вопросов на SO определяется не только популярностью решения, но ещё и его проблемностью - об этом тоже стоит помнить.
Подход сразу брать сложное решение может быть вполне оправдан, если в компании уже есть крепкая экспертиза по этому решению. Но, как я писал в исходном комментарии, в тех ситуациях, которые я наблюдал лично, такой экспертизы не было.
Странное что то обсуждаете. Swarm мертв, и скажем спасибо за это.
Docker Swarm VS Kubernetes — как бизнес выбирает оркестраторы