Комментарии 75
А у меня с docker swarm наоборот не сложилось. Очень многое приходилось делать руками, писать скрипты, допиливать напильником. k8s же хоть и требовал начального погружения, но зато очень многие проблемы решаются с пол пинка. Я уже не говорю про комьюнити которое просто огромное. В то время когда я взялся за k8s я был просто разработчиком, после чего так затянуло, что перешли переквалифицироваться в sre
Нет, уж лучше K8s
Если слишком сложно, то используйте Rancher (который раньше был на Swarm).
Хотя документация и комьюнити такие обширные, что всё-таки рекомендую GKE + Gitlab.
Вхождение в k8s непростое и тут все-таки нужно соблюдать баланс между деятельностью. Сидеть сутками поднимать кластер вместо того, чтобы писать код все-таки не очень хорошо. Для каждой задачи свои инструменты и я думаю, что swarm с приличным ui вроде swarmpit или portainer экономит огромное количество времени для разработчиков и позволяет добиться цели малой кровью.
Вы преувеличиваете сложность K8s.
Точнее так: если вам нужно делать простые вещи, то K8s это может лучше и не усложняйте, оставьте всё на дефолтах :)
К тому же по любому чиху есть доки, форумы и чаты, где можно проконсультироваться.
1) У Кубера сложные для понимания базовые сущности
2) поднятие простейшего сервиса превращается в написание длиннющего ямла, тот же docker-compose и swarm сильно лаконичнее
В то же время соглашусь, swarm мертв.
Но пока для базовых кластеров вроде функционала хватает, другое дело, что однажды его могут выкинуть, не захотев поддерживать
docs.docker.com/swarm/get-swarm
You are viewing docs for legacy standalone Swarm. These topics describe standalone Docker Swarm. In Docker 1.12 and higher, Swarm mode is integrated with Docker Engine.
И снова Вы ошибаетесь и совершенно зря хороните swarm. При выходе последней на данный момент версии докера 19.03 в swarm была добавлена кучка фич, включая очень полезную поддержку sysctl. И вышла эта версия примерно пол года назад.
Нет, уж лучше K8s
Чем конкретно лучше, если брать относительно небольшие проекты с парой десятков микросервисов? Безусловно, фич у k8s намного больше, но какие из них реально необходимы этим небольшим проектам, и при этом отсутствуют в swarm?
Банально всем.
Вас никто не обязывает использовать все фичи K8s, но если вы захотите их использовать, то вы сможете это сделать. И что Gitlab что GKE дают возможность сделать это какое-то достаточно продолжительное время бесплатно, хотя при этом это инструменты Enterprise Production уровня.
А ещё есть Minicube и K3s, но по мне так Rancher наиболее прост для освоения.
Банально всем.
Это максимально далеко от адекватного ответа на вопрос "чем конкретно".
Тратить кучу времени на изучение k8s ради потенциальной возможности воспользоваться в будущем фичами, необходимости в которых прямо сейчас нет, и может никогда не возникнуть — ну, такое. Есть много более полезных способов потратить время.
В своё время Rancher ушёл от Swarm под капотом на K8s и я был очень этому рад, т.к. мой проект примерно в то же время достиг определённых ограничений в Swarm.
Если вы столкнетесь с проблемой или нестабильностью, то в Swarm вы можете её просто не решить или решать очень долго из-за отсутствия информации или ограниченности Swarm. С K8s вероятность такого близка к 0.
Один из ваших небольших проектов когда-то созреет для чего-то бОльшего, вы созреете, ведь раньше вам и compose хватало, а сейчас вам уже нужен оркестратор. K8s это логичное продолжение цепочки.
На мой взгляд, для разработчика инфраструктура должна быть как код — это естественно. K8s этой парадигме максимально соответствует, а Swarm в этом плане… кривоват.
В K8s есть реализация практически всего, что вам может прийти в голову, не понятно зачем ограничивать себя Swarm, который занимает на рынке всё меньше и меньше и скоро просто вымрет.
https://medium.com/@fairwinds/docker-swarm-is-dead-long-live-kubernetes-2d0db0609e09
Вы сами ответили на свой вопрос: "когда-то созреет для чего-то бОльшего". Вот когда (и если) созреет — тогда и будет пора переходить на что-то бо́льшее.
Частично потому, что есть шанс, что к тому моменту может и swarm станет чем-то бо́льшим, и его всё ещё будет достаточно. Но суть данного обсуждения вовсе не в том, всегда ли будет хватать swarm, и не в том, что уже сейчас есть достаточно большие проекты, которым swarm уже не хватает. А в том, что k8s сейчас просто модная тема, и его тащат во все проекты подряд, вне зависимости от того, насколько он реально им необходим. И у этого есть своя цена: увеличение сложности, которая пока что не окупается ничем, кроме абстрактных обещаний "может быть, когда-нибудь, этому проекту реально понадобятся все эти фичи и сложности". И это очень плохо, потому что абсолютному большинству проектов они не понадобятся никогда, а платить сложностью требуется уже сейчас!
В программировании уже все осознали, что если фича не нужна прямо сейчас, то её не нужно ни проектировать ни кодить. Потому что когда это делается преждевременно, в надежде что "в будущем она нам обязательно пригодится", то это практически всегда очень плохо заканчивается. Осталось подождать, пока эта же концепция дойдёт до девопсов…
Swarm умирает, K8s это мейнстрим, стандарт в индустрии оркестраторов, а не какой-то новомодный хайповый проект и работает уже надёжнее и предсказуемее Swarm на дефолтах.
Вам сложно разобраться со всеми настройками K8s, оставьте же дефолт, не нужно все трогать, там действительно есть где заблудиться :)
Вы свою цену заплатите, когда у вас будет заточенный под Swarm проект, в котором что-то будет постоянно идти не так или вы не сможете что-то сделать, но вместо трудоемкого для вас переноса на K8s вы будете тратить время на костыли.
Самая большая сложность, скорее психологическая — это первоначально окружение себе настроить.
Вот это вот сложно?!
https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app
Swarm умирает
Откуда такая информация?
K8s это мейнстрим
XML тоже был мейнстримом… а потом пришёл JSON. Некоторые технологии таки успевают проплыть мимо, пока ты сидел на берегу, и это к лучшему.
у вас будет заточенный под Swarm проект, в котором что-то будет постоянно идти не так или вы не сможете что-то сделать
Простите, но это либо тупой FUD, либо та самая конкретика, которую я от Вас пытаюсь услышать с самого начала: что конкретно в swarm может "постоянно идти не так", и какие конкретно реально нужные небольшим проектам вещи мы "не сможем сделать"?
Анализ market shares разных оркестраторов, вероятно.
Я, правда, не смог быстро найти отчеты, в которых упомянут Swarm.
Уже тогда все было очень грустно, с тех пор лучше не стало.
Да, по уровню популярности у swarm около 10%. НО.
Во-первых, это довольно далеко от "swarm умирает" (у firefox примерно столько же, но он на умирающего тоже не сильно похож).
Во-вторых, аналитика по google trends и SO показывает про что чаще задают вопросы, и нет ничего удивительного в том, что про намного более сложный k8s вопросов задаётся намного больше (только вот что в этом хорошего).
В-третьих, оценка популярности — это далеко не единственно важный критерий при выборе используемой технологии.
В-четвёртых мы уже не раз видели дико популярные технологии, в т.ч. захватывавшие 90+% рынка, и некоторые из них уже не с нами.
В общем, из оценки популярности вполне корректно делать выводы на темы "что перспективнее изучать", "на чём легче найти работу". Но не корректно делать вывод "что лучше подойдёт для конкретно вот этого проекта" — это нужно решать исходя из специфики конкретного проекта и технических особенностей доступных технологий, среди которых рейтинг популярности влияет только на то, насколько сложно нанять новых сотрудников уже знакомых с технологией (и этот фактор вполне компенсируется простотой освоения альтернативной технологии в случае swarm).
про намного более сложный k8s
Я, все еще, не могу понять, чем именно он намного более сложный, точнее, что такое «намного». Объективно — более сложный, да, больше кодовая база, например. Субъективно — что то оркестратор, что это. Цели и задачи одни и те же, сказать, что в Kubernetes есть какие-то лишние сущности, я не могу. У системы контроля версий Mercurial тоже есть какая-то пользовательская база, но я не вижу никаких преимуществ перед Git (который, кажется, тоже «намного более сложный»), между Swarm и K8s разница того же порядка.
Есть очень простое, измеримое определение сложности: время (в контексте этой дискуссии — кривая обучаемости). Сколько времени необходимо потратить на изучение новой технологии, чтобы просто начать ей пользоваться на среднем (достаточным для большинства в первые пару лет использования) уровне, и сколько времени необходимо для того, чтобы освоить систему на достаточно высоком (достаточном для того, чтобы можно было самостоятельно выявить и починить любую проблему в течении часа) уровне.
Выход на средний уровень для mercurial занимал около часа, для git около пары дней. Выход на высокий уровень для mercurial — без понятия (у меня не возникало с ним проблем которые бы этого уровня требовали), для git — неделя. Абсолютное большинство разработчиков эту неделю "на git" не выделили, поэтому раз в несколько месяцев умудряются довести локальное репо до состояния, когда им проще его убить и склонировать начисто с нуля, чем понять в чём проблема и починить. Это вполне себе показатель излишней сложности инструмента.
Если отойти от измеримых характеристик, то основное преимущество mercurial перед git в том, что UI mercurial оперирует сущностями/понятиями с точки зрения пользователя (что намного удобнее и всё упрощает), а UI git оперирует внутренними понятиями и подробностями реализации самого git (именно по этой причине всем кажется, что git checkout делает совершенно разные и не связанные между собой вещи — потому что они не связанные с точки зрения пользователя, а с точки зрения внутреннего устройства git эта команда делает только одну вещь).
Изучение swarm до среднего уровня занимает около часа (если уже знать docker и docker-compose). До высокого — часа 4. Сколько времени требует куб — я лично пока не выяснял, но судя по тому, что пишут абсолютно все — там другой порядок цифр (несколько дней/неделя до среднего, несколько недель до высокого). И лично я пока не вижу у куба настолько значительных преимуществ, которые бы оправдывали эти затраты времени. Особенно для разработчиков, которым понимание устройства кластера и управления им нужно в значительно меньшей степени, чем админам.
Ну вот и я бы не против иметь в копилке k8s. По сути, я в данной дискуссии не столько защищаю swarm, как может показаться, сколько надеюсь, что оппоненты мне покажут, зачем реально лично мне необходим куб, чтобы я оправдал выделение значительного времени на его изучение. Но, увы, пока никто ничего конкретного мне так и не ответил.
Не соглашусь:
1) swarm high level за 4 часа? Вы просто не сталкивались с действительно серьёзными проблемами.
2) "Сколько времени требует куб — я лично пока не выяснял, но судя по тому, что пишут абсолютно все — там другой порядок цифр"
Не читал, но осуждаю!
Вы уже потратили кучу времени на то, чтобы прочитать, что другие пишут про K8s и ещё кучу на все эти комментарии и обдумывания, вместо того, чтобы изучить уже K8s на базовом уровне и наслаждаться. Мне кажется, что вам просто не хочется делать, условно говоря, как все, как большинство, но иногда в этом действительно есть смысл.
Я потратил около трёх месяцев чистого рабочего времени на перевод проекта с docker-compose в пару сотен строк на k8s с основной задачей упростить деплой и локальную разработку. Сейчас это несколько тысяч сырых строк. Я не уверен, что что-то реально полезное сделал для проекта. Вернее, что не мог бы достигнуть лучшего результата с swarm, потратив в разы меньше времени и сэкономив порядка 10000 usd только на своей зп.
Страшные вы истории рассказываете.
Более 500 часов уже зная Swarm потратили на изучение и переезд на K8s?
Без обид, но судя по всему действительно не стоило этим заниматься с такой эффективностью.
Или вы свой проект параллельно переписывали, а не "просто переводили его со Swarm на K8s".
Было/стало, если можно, в студию.
Перечитал ваше сообщение и увидел, что проект был на docker-compose, а это не Swarm. Compose не оркестратор, со всеми вытекающими из этого выводами, поэтому вполне допускаю, что в принципе осваивая концепцию оркестра, который занимается в том числе автоматическим поднятием нод по необходимости ресурсов сервисам и т.д. и т.п. вы потратили действительно очень много времени.
Но речь тут именно о Swarm > K8s, а не Compose > K8s.
Хотя я присутствовал в команде, где разработчики вообще не разрабатывали в docker и за примерно ваше время (3 месяца) успешно перешли на разработку и выкатку именно в кубер, с добавлением куда нужно переменных и необходимых сервису ресурсов.
Я, зная Swarm, пришёл на проект, где был docker-compose в продакшене, но уже было принято решение о переезде на k8s, которым я и занялся, как единственный человек, хоть с чем-то сложнее docker-compose работавший.
Итоговое решение функционально оказалось проще, чем я реализовывал на swarm (в частности тут фиксированное число сред, без динамического создания на каждую ветку для демо и тестов), но вот "кода" оказалось заметно больше на примерно то же количество сервисов (считая поды с, например, nginx+php-fpm за два сервиса в docker-compose/swarm). В том числе пришлось выбирать между написанием своего шаблонизатора и добавлением в проект Helm и helmfile из-за того, что k8s не поддерживает интерполяцию переменных окружения. kustomize не осилил, да. Выбрал Helm+helmfile, что внесло ещё заметную долю сложности. Minikube для локальной разработки сложнее, чем docker swarm оказался. Документация k8s хуже организована с точки зрения версионирования.
Плюс, не совсем в сторону k8s минус, а в сторону managed кластеров — кластеры docker swarm у меня были под прямым управлением, или сам что-то менял, или админов просил. С managed это сложнее, в некоторых настройках или просьбах что-то обновить просто отказали или запросили адский ценник, пришлось искать костыли для обхода типа демонсетов пишуших в sysctl. Ну и по мелочи типа требования какое-то время поддерживать старый прод на docker-compose как fallback с синхронизацией файлов онлайн.
Ну и активная разработка самого продукта не останавливалась.
P.S. видимо разное имеем в виду под оркестраторами, я про оркестратор контейнеров. docker-compose оркестрирует контейнеры в пределах одного хоста, docker swarm и k8s позволяют делать это в пределах кластера из нескольких нод.
У k8s более 50 типов сущностей из коробки, просто разобраться какие тебе нужны, а какие нет на конкретном проекте, может занять неделю и более
Ладно разработчики или девопсы стараются проташить ради "строчки в резюме", так вот недавно релизнули ь первый раз в к8с и это было бизнес-требование, типа не солидно предлагать SaaS без k8s
Про Swarm вы говорите про Docker Swarm или Docker in swarm mode?
Docker Swarm, ещё называемый Docker Swarm standalone — первая реализация кластера для докера от команды докера. Сейчас вроде уже не поддерживается. Работает независимо от докер-демона, просто оркестриует в нём контейнеры, для демона просто клиент.
Docker swarm mode — с какой-то достаточно древней по нынешним временам версии, режим работы обычного докер-демона в режиме кластера. Актуально и потихоньку развивается.
Моментально попадали все сервисы, которые были в Swarm.
Не знаю, ожидаемое это поведение или нет. В Kubernetes надо долго трудиться, чтобы получить похожий результат. При настройках по умолчанию подобное там невозможно.
Нет, не ожидаемое. Но если после перезапуска запустилась более новая версия докера — тогда всё может быть, надо сначала читать доки как корректно обновлять узлы кластера (и это касается абсолютно любого кластерного сервиса, у всех свои заморочки, и swarm тут ничем не выделяется). Ещё, наверное, возможны проблемы если узлов было два, и один перезапустился — но это тоже штатная беда всех кластерных сервисов, поэтому и рекомендуется запускать нечётное количество узлов.
У меня как-то рухнул локальный minikube кластер, где-то прав не хватило. Я полдня вычищал систему от его остатков, чтобы запустить с нуля.
Мне понравилось две фичи k8s: поды и ингрессы "из коробки". Но не уверен, что их удобство компенсирует сложность. Тем более, что из-за нужд проекта, ингресс сводится к прописыванию доменов для неймспейса, а дальше рулит обычный nginx, типа api gateway.
Какая разница под ранчером k8s или нет? Если всё равно надо писать километровые yaml.
Как минимум, сварм не учитывает доступные ресурсы при запуске сервисов.
Плюс, если заходите переехать в облако, то Swarm-а в облаках нет вообще. А k8s практически везде, хоть и с небольшими изменениями.
Поднять k8s можно на обычных vds-ках тем же rancher с пол пинка. Если что-то отвалилось, удаляете и ставите заново, никаких проблем, специально ломал и тестировал.
Плюс, если заходите переехать в облако, то Swarm-а в облаках нет вообще.
Можно подробнее?
заходите переехать в облако
Что вы имеете в виду? Нет кнопки «развернуть swarm»?
Для Сварма такого нет. Само-собой, вы можете купить десяток серверов и самостоятельно там все поднять. Я так на k8s работаю, т.к. это сильно дешевле.
Но с k8s при возникновении необходимости, я могу довольно быстро переехать в любое облако, а во из Сварма вы будете переезжать несколько больнее.
Изначально вообще был один большой сервер. Докер ради контейнеров, компос ради удобства.
Потом перешел на сварм, попробовал добавить еще нод, но оно как-то странно себя вело при сбоях. А при добавлении ноды из другого датацентра — вообще хаос, пару часов не мог поднять. Вроде должна быть отказоустойчивость, в итоге получаешь только кучу проблем. Остался на одном большом сервере со свармом (ибо уже перешел, ну и сервисы лучше компоса восстанавливаются после сбоев).
Еще в сварме не работали readness/liveness пробы. Они вроде есть, вроде все создается, но не работает. Разбираться сложно, т.к. свармом фиг кто пользуется.
Потом еще понадобилось взаимодействие с АПИ сварма из приложения для запуска задач. И решил до кучи перейти на k8s, т.к. работает куда стабильнее (специально около месяца пробовал как что, пробовал все ломать, крушить, смотреть как поднимется) и есть возможность стучаться в АПИ из любого языка.
Автомасштабированием я не пользуюсь, т.к. все крутится на обычных серверах, оно там по сути и не будет работать, т.к. новые машины из воздуха не появятся. А просто накидывать число реплик я и так могу.
Я пока тестировал на небольших приложениях со скейлингом и лоад балансингом между нодами на разных дроплетах в DO. Там они общаются по приватной сети и вроде все очень шустро работает. Хочу попробовать перевезти более нагруженные системы, т.к. скорость и удобство пока радуют. Если не выйдет, то видимо пора будет серьезно осваивать k8s
Отдельные сервера: FirstVDS, Vscale, тот же Селектел, RuWeb
Из облаков GKE круче всех. Банально потому что там можно удобно создавать машины разных конфигураций в одном кластере. В других либо я не нашел как, либо вовсе нельзя. А, ну еще там нет платы за мастера. Мастеров там по сути как бы нет, вы их не видите, что очень удобно. В том же AWS мастера обходятся как неплохой сервер, хотя 90% проектам оно нафиг не сдалось.
Селектел на тот момент ломал кластер при масштабировании и где-то за неделю проблему они не решили, а я на них забил. Но у них очень классные технические параметры машин, все очень шустро.
Маил.ру тоже были какие-то мелкие проблемы. Плюс как и у многих болезнь невозможности сделать разные ноды в одном кластере. Не знаю почему, но это прям эпидемия какая-то.
Яндекс ничем не выделяется, а на тот момент и вовсе был в закрытой бете, кажется.
В целом это все довольно дорого. Если у вас реально нет потребности в авто-выделении новых нод, то в 99% случаях облака не пригодятся и проще сделать парк VDS.
В зарубежных облаках еще есть плата за трафик, что иногда очень и очень критично.
Якобы проблема со стораджами на bare-metal, как по мне, больше надумана адептами «А вдруг нода сломается». Если у вас не реальное облако, то забейте на это все.
Сейчас остановился на Ruweb, порядка 10 машин в кластере. И VDS и железо. Пробовал подключать к этому парку ноды из VScale (это другой ДЦ) — все круто.
Очень много могу рассказывать про k8s, докер и разработку вот-этого-всего, т.к. свой проект уже 2.5 года на нем веду, как работа 24/7.
Что-то это либо система, либо какая-то нода, причем иногда нормальным ребутом, иногда прям в жесткую.
С GKE/AWS/Azure проблем в этом плане нет. Там вот очень классно. С российскими облаками постоянно какой-то треш, да простят меня сотрудники Яндекса/Маила/Селектела.
Chaos Engineering называется.
https://www.cncf.io/blog/2019/11/06/cloud-native-chaos-engineering-enhancing-kubernetes-application-resiliency/
А при добавлении ноды из другого датацентра — вообще хаос, пару часов не мог поднять.
Не ubuntu 18, часом, пользовали? У нас была проблема со схожим описанием, выяснилось, что шифрованные сети работают только с версией 16.04.x (kernel > 4.4).
Правда, не совсем непонятно, как это все относится к переезду между облаками… :)
К переезду именно это не относится.
Ну, вы попробуйте, а там расскажете. И параллельно попробуйте k8s.
Я тоже долго не мог понять в чем же разница. А разница в меньшем числе проблем, все просто :)
Попробуйте поронять ноды, уронить мастер, заблокировать сеть у ноды, разделить кластер на две группы. У меня он такие тесты не проходил, увы.
До сих пор не знаю почему так получалось, но это было больно, потому как Сварм считает, что все ок и не стремится его перезапустить. Хотя иногда надо было именно удалить и создать заново.
Еще сварм не умел не-обновлять не-изменившиеся сервисы. YML файл один, внутри изменился только один сервис. А перезапускается вообще все.
Потом он вроде как научился, но как-то через раз. И опять же — гадай почему.
Первое возможно было вызвано https://success.docker.com/article/ipvs-connection-timeout-issue
Сворм практически мертв. Это видно по количеству багов/фичец в каждом рилизе.
Попробуйте поднимать кубер через терраформ — синтаксически это не так вырвиглазно чем бесконечные ямлы, да и проверка синтаксиса будет, и не понадобится изучать вмякие кощенитские приблуды типа Helm (хотя в третьей версии они уже приблизились к тому что делает терраформ)
Новичкам проще с Rancher или GKE начинать, там вообще в gui можно всё поднять за пару минут без кода.
Дальше берёте связку gitlab + gke, по мануалам Gitlab делаете базовую настройку и спокойно ведёте разработку.
В такой связке Gitlab позволяет получить дополнительные 200$ к 300$ дающимся новым аккаунтам самим Google, а 500$ это вполне себе ощутимая цифра.
И не как на AWS счёта выставляются, а по-моему гораздо более предсказуемо и внезапно большие цифры как на AWS не прилетают, да и выше $500 просто так с меня не начали снимать, что особо порадовало.
Если ещё и preemptible нодами научитесь пользоваться, то этих 500 на небольших проектах может ооочень надолго хватить.
Управление кластером Docker Swarm с помощью Swarmpit