Kubernetes (K8s) по праву считается отраслевым стандартом управления контейнерами, но это вовсе не значит, что решение подходит каждому типу бизнеса. Порог входа в K8s высок, а преимущества не всегда очевидны. Гораздо эффективнее может быть использование альтернативных оркестраторов. OpenShift, Nomad или Apache Mesos при помощи дополнительных утилит умеют многое из того, что предлагает K8s. Эти решения на порядок проще в освоении и настройке, пусть и не обладают таким активным сообществом. Тогда почему их нельзя использовать везде?
Проблема в том, что сравнивать эти оркестраторы и считать, что в итоге окажется выгоднее, не совсем корректно. Придется сравнивать двигатели и автомобиль. Эти решения выступают в разных весовых категориях.
Наиболее близкую альтернативу Kubernetes сейчас, пожалуй, представляет Docker Swarm.
Чтобы понять, почему многие компании стали так активно использовать контейнеры, и чем они руководствуются, когда выбирают оркестраторы для работы с ними, придется вернуться к истокам.
Как контейнеры появились (почти) везде
В 2013 году, на этапе бурного развития контейнеризации, Docker предлагал по сути революционное решение и как формат упаковки, и как среду выполнения контейнеров. В Docker-контейнер можно было упаковать все настройки, бинарные файлы, среду и библиотеки в изолированный контейнер. Это значительно ускоряло выпуск новых продуктов. Кроме этого, технология открывала возможность работать с контейнерами как в облаке, так и на домашнем железе.
Технология контейнеризации схожа с работой виртуальных машин (ВМ), но компании не стали делать выбор в пользу какого-то одного решения, а встали на путь использования лучших практик из обоих миров.
Контейнеры оказались менее ресурсоемкими и не такими требовательными к оборудованию. Оказалось, что на одном железе можно запустить в 2-3 раза больше контейнеров, чем ВМ. При этом ВМ более надежны, поэтому их чаще используют для секьюрных компонентов.
Решение Docker было достаточно простым и открывало массу возможностей для работы с контейнерами. Полностью готовый к использованию контейнер можно было скачать из общей библиотеки и запустить у себя.
По мере развития проекта, контейнеров будет становиться больше. Эффективно управлять сотней контейнеров уже сложно — это заметно влияет на клиентскую удовлетворенность продуктом. Расширение штата для поддержки такой громоздкой системы скорее полумера. Здесь на помощь приходят системы оркестрации. С их помощью контейнеры можно объединять в кластеры.
Для управления и кластеризации нод Docker предлагал использовать встроенный оркестратор Swarm.
В Docker Swarm контейнеры собираются из нод двух типов:
- Worker: нода-исполнитель контейнеров, которые возможно поднять в кластере.
- Manager: обеспечивает управление кластером. Как и worker, может выполнять запуск и работу контейнеров.
В кластерах приложение может работать сразу на нескольких нодах для балансировки нагрузки, масштабирования и повышения отказоустойчивости.
Docker Swarm VS Kubernetes
Сам факт сравнения K8s и Docker Swarm имеет место быть, хотя к управлению контейнерами они подходят скорее с противоположных сторон.
Нельзя отрицать, что коробочный Docker прост в установке, но со всем, что связано уже с администрированием контейнеров, K8s оказалось использовать проще и удобнее, поскольку это комплексный инструмент.
Далее мы проведем сравнительный анализ по критическим компонентам, которые влияют на выбор оркестратора.
Автомасштабирование
Автомасштабирование нужно не только в моменты пиковых нагрузок на инфраструктуру, чтобы никто не почувствовал задержку в работах сервисов. Автомасштабирование также позволяет экономить. Главное — вовремя выключать дополнительные ноды и перераспределять выделенные ресурсы, когда это перестает быть актуальным.
Масштабирование в Docker Swarm ручное. Сначала для каждой службы прописывается количество задач для запуска. Когда управляющий узел замечает изменения, он самостоятельно адаптируется и перераспределяет задачи, чтобы добиться необходимой конфигурации.
Автомасштабирование в K8s опирается на потребление CPU и RAM, а также с недавнего времени с использованием кастомных метрик, и доступно на трех уровнях:
- Горизонтальное автомасштабирование (HPA) отталкивается от выбранных значений и изменяет количество групп контейнеров (подов).
- Вертикальное автомасштабирование (VPA) контролирует количество ресурсов, которые выделяются для уже запущенных контейнеров.
- Автомасштабирование самого кластера и количества узлов внутри.
Безопасность
Вопрос безопасности для контейнеров всегда был дискуссионным. Самыми частотными проблемами можно считать ошибки в конфигурации.
Когда кластер уже развернут, оба оркестратора могут использовать специальное решение Vault «поверх» встроенной системы секретов.
Каждый узел в Docker Swarm защищается аутентификацией и шифрованием TLS. Коммуникация между узлами чаще всего и является проблемной областью.
В Kubernetes активно развивается система настроек сетевых политик и использование пространств имен. В последних версиях K8s оркестратор консолидировал защиту на всех трех уровнях: control panel, worker node и Cluster network.
Технически защиту K8s вряд ли можно назвать надежнее, чем в Docker Swarm. Тем не менее в системе реализовано больше практик и «красных кнопок», которые подменяют и дублируют друг друга на случай проникновения.
Сетевая архитектура
Docker Swarm неплохо адаптирован для работы с оверлейными сетями. Система автоматически прописывает IP-адреса контейнеров при инициализации или обновлении. Для работы с нативными сетями есть практика дополнять функциональность оркестратора сетевыми плагинами, чтобы избежать потерь производительности.
Откаты и обновления
В работе с распаковкой обновлений Docker Swarm и Kubernetes предлагают похожие алгоритмы последовательных апдейтов. Это позволяет быстро возвращаться к стабильным версиям, если при обновлении произошел сбой.
Функциональность Swarm фокусируется на установке временных лимитов в развертывании сервисов. Например, на случай, когда по каким-то причинам развертывание пошло не по плану. В больших проектах этой функциональности часто недостаточно, чтобы эффективно управлять контейнерами при пиковых нагрузках.
Преимущество Kubernetes здесь в более гибкой настройке сценариев обновлений. Например, в K8s можно задать минимальное количество доступных реплик. Количество сценариев, которое могут учесть настройки K8s покрывает любую задачу из этой области.
Кажется, что Kubernetes выигрывает во всех критических аспектах, но нельзя исключать из уравнения сложность его поднятия и обслуживания. Есть инструменты, которые частично облегчают работу с поддержкой и обновлениями, например, Kubespray, но нет гарантии, что этот процесс будет проходить органично.
Как правило, для этого требуется полноценная команда DevOps инженеров, которую не всегда выгодно держать в штате и сложно собрать из-за уникальности компетенций.
Managed Kubernetes в этом смысле помогает снять часть ответственности и разгрузить штатных специалистов компании, поэтому подход оказывается более эффективным способом управления инфраструктурой.
Как бизнес осваивает оркестраторы
В 2022 году можно говорить, что фаза активного противостояния Docker Swarm и Kubernetes завершилась несколько лет назад, когда K8s научился работать с CRI-O и обходиться без установки Docker на все узлы кластера. На сокращение сектора влияния Docker Swarm также повлияла продажа Enterprise Edition в 2019 году. Таким образом Docker Swarm потерял свой аналог шаблонизатора Helm, который использует K8s.
Еще один фактор, который повлиял на расположение сил: с 31 января 2022 Docker перевел всех клиентов на модель подписок. Бесплатный тариф для личного пользования тоже есть, но для команд от 5 человек сейчас уже могут быть сложности с оплатой.
Для каких компаний Docker Swarm будет оптимальным выбором
- Для компаний, чье устройство пока не предполагает наличие команды DevOps-специалистов. К этой категории относятся многие стартапы, исключение составляют команды, которые работают с большими объемами данных и машинным обучением. Возможностей Docker Swarm для таких проектов может быть недостаточно.
- Оркестратор чаще используют компании, которые могут прогнозировать сезонные всплески нагрузок и могут настроить сценарии масштабирования под конкретные даты. Например, бухгалтерия в периоды отчетности или туристические сервисы в сезон отпусков. Здесь многое зависит от масштабов компании и количества контейнеров, с которыми приходится работать, поскольку управлять ресурсами конкретных нод не так удобно, как контролировать их количество. С учетом отсутствия автомасштабирования в Swarm комфортным количеством узлов будет <1000.
- Docker Swarm чаще используют команды, которые сами занимаются поддержкой инфраструктурных решений.
Если компания не работает с большим объемом рабочих нагрузок и они вполне укладываются в Docker API, плюс нет потребности пользоваться другим типом контейнеров — выбрать Docker Swarm в качестве оркестратора будет правильным решением. Гибкость настроек K8s для таких проектов будет только мешать и усложнять процессы релизов.
Для каких компаний Kubernetes будет оптимальным выбором
Относительно недавно Gartner писали о том, что в 2022 году 75% компаний перейдут на контейнерные приложения. Их прогноз основывается на двух предпосылках, связанных с популяризацией K8s:
- Функциональность K8s можно адаптировать под любой проект — это универсальное решение для Enterprise-сегмента. Для многих компаний K8s — это решение «на вырост». Это забота о будущих процессах разработки, когда появится необходимость быстро масштабироваться.
- Модель управления Managed Kubernetes становится удобнее для обеих сторон. С одной стороны, это происходит, потому что K8s в облаке решает проблемы, связанные с настройкой и развертыванием. С другой, пользователи оплачивают только ресурсы, которые фактически использовали, и не несут эксплуатационные риски.
Правильнее всего было бы вынести за скобки фактор сложности управления K8s. Согласно исследованию Datadog, на западном рынке услугами Managed Kubernetes пользуются 90% компаний, работающих с решением. В качестве альтернативного источника данных можно привести данные Flexera: Enterprise-клиентами Managed Kubernetes оказались 637 из 750 респондентов.
- Интернет-магазины чувствительнее всего относятся к повышениям нагрузки. Управлять ресурсами таких площадок в период акций или сезонного спроса через Docker Swarm или Apache Mesos может быть просто невозможно и крайне болезненно как для продавцов, так и для покупателей.
- K8s подходит для сервисов, которые активно используют машинное обучение и Big Data. Отлаженная работа оркестратора обеспечит высокий уровень доступности и консолидации данных и скажется на качественных ожиданиях от сервиса. О том, какие продукты используют Kubernetes можно посмотреть здесь.
- Игровые приложения, работающие на сложной микросервисной архитектуре. Быстрое поднятие новых кластеров обеспечивает доступность серверов и стабильный обмен данными и сохранение прогресса вне зависимости от откатов.
Заключение
По-настоящему идентичных альтернатив K8s на сегодняшний день, пожалуй, не существует, но это нормально. Не каждый проект нуждается в таком мощном решении для оркестрации.
Если проект не требует гибкой системы масштабирования и управления ресурсами, то выбрать более доступное решение окажется верным ходом. Стоимость доработок, которые будет необходимо внести для нетипичных задач окажется все равно ниже, чем управление инфраструктурой своими силами с помощью K8s.
Kubernetes можно считать излишне сложным, но Managed Kubernetes снимает большую часть проблем, связанных с управлением кластерами.
powerman
Полностью со всем согласен. Только вот проблема в том, что донести до тех.диров стартапов что им не нужен (сейчас, пока не вышли в прод, и в ближайшие года три ещё точно) K8s - почему-то крайне сложно. При этом аргументации у них никакой нет. Просто - у нас куб, и всё, не обсуждается. И не обсуждается не потому, что идея взять docker swarm дурная, или потому что реально нужен куб, или потому что в компании полно девопсов с крепкой экспертизой по кубу - ничего подобного! Не обсуждается потому, что, с одной стороны, куб это модно, в managed варианте выглядит простым, и на 100% точно потянет любые наши нагрузки, а, с другой стороны, никаких аргументов почему бы на ближайшие годы не взять решение по-проще - нет.
Ещё было бы любопытно увидеть аналогичное сравнение с Nomad.
exfizik
Так а зачем брать решение попроще, если заранее известно, что оно только на ближайшие годы? У нас был переход с Docker Swarm на K8s в процессе роста компании - было долго и тяжело. Причём практически изначально было понятно, что Docker Swarm нам будет не хватать по многим параметрам, но "стартап же, надо быстро и дёшево".
powerman
Во-первых, заранее ничего такого абсолютному большинству стартапов не известно.
Во-вторых, абсолютное большинство стартапов не дорастёт до той 1000 серверов, на которых swarm уже не тянет. Большинство даже до 100 серверов не дорастёт.
В-третьих, технологии сменяют друг друга очень быстро. Через 3 года куба может уже не быть (что маловероятно, но мало ли - гугл очень много проектов закрыл уже). Или может появиться лучшая альтернатива кубу (что весьма вероятно - куб всё-таки дико переусложнён и проблем у него дофига и больше).
В-четвёртых, с docker swarm у стартапа больше шансов выжить - именно потому, что он проще, требует не такую сильную экспертизу девопсов, и позволяет двигаться быстрее.
Akuma
Как тот, кто личный небольшой проект переводил с docker-compose на swarm, потом на k8s, могу сказать, что k8s проще и стабильней чем первые два, когда у вас больше одной машины в кластере.
Так что идея сразу делать на k8s, если у вас предпологается что-то сложней лендинга-визитки - вполне себе здравая.
powerman
Можно пример в чём конкретно проявлялась нестабильность swarm в небольшом личном проекте?
Akuma
Обратите внимание на фразу "когда у вас больше одной машины в кластере".
Если делать кластер из одной машины (просто чтоб удобно запускать контейнеры тем же свармом) - все работало хорошо.
Как только туда добавлялась новая машина, сварм начинал зависать, как ни странно. Просто банально переставал отвечать на запросы или делал это очень долго. Контейнеры при этом работали, но новые не запускались.
Разобраться с этим я так и не смог. Было это правда аж пару лет назад, но осадочек остался.
Нагуглить хоть что-то про сварм в то время было прям трудно. Он как будто не существовал в ИТ-поле. Есть базовые мануалы "как запустить" и добавить ноду, но вот описания каких-либо проблем - пустое место, увы.
Найти хостера с поддержкой сварм-как-сервис - думаю, невозможно.
Плюс я не особо представляю как можно работать с несколькими нодами в сварме, когда он банально не умеет распределять ресурсы. Может сейчас уже научили, но в то время он запускал контейнеры просто от балды. А в случае если ноды разные - это беда.
powerman
Ясно, спасибо. По поводу самой проблемы ничего не скажу - я swarm использовал довольно активно и много, такой проблемы никогда не наблюдал, и никогда не слышал (до этого момента), чтобы жаловались на проблемы с настолько базовым функционалом swarm.
Насколько я знаю, до встроенного в саму утилиту docker режима swarm существовал отдельный продукт, который так же назывался docker swarm - им я пользоваться не пробовал, если Вы тогда случайно взяли его - возможно проблема была в этом.
Managed swarm вряд ли существует, согласен, но это не удивительно - там нечего особо менеджить, а то что есть - не создаёт пользователям таких заметных сложностей, чтобы появился смысл нагородить целый специализированный сервис в облаке. Если кому-то нужен визуальный дашборд кластера - как минимум один такой есть в виде отдельного контейнера, запустить самостоятельно его не сложно.
Что до распределения ресурсов под конкретную ноду - раньше я помню обходился метками для нод разных типов и указанием при деплое на ноды какого типа выкатывать данный контейнер. Сейчас в доке вижу явное резервирование https://docs.docker.com/compose/compose-file/deploy/#resources
Akuma
Это меня и остановило. Если появляется проблема в настолько базовом сценарии, то я стараюсь такие решения не использовать.
Хотя на тот момент сварм работал несколько месяцев на одной жирной ноде и проблем не знал.
Не, то был именно докеровский swarm :) Не знал даже, что там еще что-то было.
Для дашборда в то время использовал Portainer (кажется так) - отличная штука.
Да, действительно. Тогда не было указания ресурсов и все сводилось к "используйте k8s".
powerman
А можно чуть подробнее?
По каким именно параметрам было почти сразу понятно, что функционала swarm вашему проекту не хватит? Какие требования привели к принятию решению переходить на K8s?
Почему перейти было долго и тяжело? Ведь если проект уже работает в контейнерах, то смена оркестратора не должна быть прям долгой и тяжёлой. Да, там хватает отличий и нюансов, но если не пытаться сходу переделать всё "в стиле" куба то перенос один-к-одному или близко к этому не должен быть долгим и тяжёлым. Или долго и тяжело было как раз из-за сложности самого куба? :)
exfizik
Чего не хватало в swarm? Самое главное, наверное, стабильности. Частенько что-то там зависало, надо было ручками перезапускать (только давайте не будем играть в "да вы просто неправильно его настроили" :-) ). Были проблемы с доступом к логам в режиме реального времени. Ну, и future proofing + общий стек (у нас еще и nomad встречается в некоторых командах). Это из того, что я знаю точно. Наверняка, еще было много чего и крупного, и по мелочи - это уже надо у девопсов спрашивать, у меня другая специализация.
Переходить было "долго и тяжело" в основном не по нетехническим причинам - просто к моменту принятия решения о переходе уже наплодили сервисов, и надо было переносить всё это без даунтайма, постепенно, плюс тестирование и пр. Ну, и в целом нашему начальству бывало непросто объяснить, почему тратится время на инфраструктуру, за которую с клиентов дополнительно денежку не взять, вместо новых фич, которые можно продать.
Естественно, в процессе перехода вылезали всякие баги и недочёты - где-то криворучки, где-то недостестировали. В общем, не виню в этом k8s.
powerman
Не, играть в это не будем, я не для того спрашивал. Инфа полезная, спасибо.
Только один вопрос ещё: понятно, регулярно случались проблемы, порядок проблем тоже понятен, перешли на куб, в процессе перехода было сложно но в результате успешно перешли и довольны… и что, с кубом в эксплуатации после завершения перехода проблем нет вообще? Или есть, но значительно меньше, чем было со swarm?
Antra
Именно!
Если под текущие задачи одинаково хорошо подходит несколько решений, скорее всего возьмут не узкоспециализированное (запросы могут и поменяться), не самое простое (вдруг вырастем), а самое популярное (и при этом с достаточно низким порогом вхождения).
Нужны очень веские аргументы для выбора чего-то особенного. И как раз в отсутствие специалистов, способных аргументированно сравнить несколько решений, четко обосновать, почему именно для данных требований и с учетом планов развития лучше выбрать что-то альтернативное, чаще выбирают то, что легко внедрить, чего практически наверняка хватит на долгие годы и по чему (вследствие популярности) кучу всего легко нагуглить в случае проблем
powerman
Вот! Вы всё верно сказали, кроме этого момента - тут и происходит когнитивное искажение: тех.дир лично нажатием пары кнопок поднимает первый тестовый managed-кластер, что и создаёт у него впечатление, что у куба "достаточно низкий порог входа". Но поднятием кластера ведь всё не заканчивается, на этом всё только-только начинается - и вот чем дальше этот кластер используется, тем понятнее становится, что порог входа в куб намного-намного выше, чем показалось на первый взгляд.
В одном из стартапов, где я эту картину не так давно наблюдал, доходило до смешного: да, оно managed, да, оно в облаке, да, мы платим только за используемые ресурсы… стоп! А откуда у нас в тестовом кластере с парой подов, которые ещё никто не использует вообще - 700GB логов за три месяца? А никто не знает, девопс мне на этот вопрос ответил "это служебные логи куба, это норм". А мы за них платим? Конечно… А они нам нужны? Вряд ли. А убрать их как-то можно и сделать чтобы в таком объёме не накапливались? Эээ… И, разумеется, никто с этим ничего делать не стал. Потому что хз что там происходит и разбираться в этом нужно довольно долго.
Antra
Неужели управлять кластером Кубера намного сложнее, нежели кластером Docker Swarm? У меня нет впечатления, что Кубер ломается на ровном месте, при типовых операциях. Я имею ввиду, если не используется особой специфики, просто запускаются какие-то поды.
Коли говорим про Docker Swarm полностью самостоятельно развернутый и управляемый, то и мастер ноду кубера самостоятельно поднимать надо (к вопросу о плате за логи).
Если о Managed Kubernetes речь зашла - это дополнительное облегчение, конечно. Но за дополнительные деньги, это понятно. Как и вообще облака.
И еще момент - когда я говорю про "низкий порог входа" я имею ввиду именно быстрый старт, запуск сервисов. Потом админам, разумеется, придется учиться, в т.ч. разбираться с логами. Кстати, будь я админом, я бы с большей мотивацией именно в потрохах Кубера разбирался, чем относительно редкой зверюшки.
powerman
Чтобы чем-то управлять его надо понимать. Сравните объёмы документации по обоим продуктам, и все вопросы отпадут.
Дело не в том, что он ломается на типовых операциях - он не ломается. Дело в том, что порог входа - это не порог на запуск кластера, а порог на всё оперирование кластером для типового проекта небольшого размера (включая борьбу с логами безумного размера, да). Т.е. условно сколько времени нужно потратить на обучение девопса и сколько времени у него уйдёт на выполнение всех задач, чтобы было сделано всё необходимое для проекта. И вот для k8s и docker swarm эти цифры отличаются порядка на два примерно.
Частично такая разница вызвана тем, что docker swarm базируется на docker-compose - который девопс, как предполагается, уже должен знать, и время на его изучение не включается в порог docker swarm. А вся остальная документация, специфичная именно для docker swarm, прочитывается за пару часов. Практический опыт с ним нарабатывается ещё где-то часов за 5-10 максимум. И на этом - всё. Больше ничего никогда не понадобится. Есть пара неочевидных грабель, о которых придётся узнать когда на них наступишь, но это ещё по часу на каждую. Т.е. два дня - и это не просто порог входа, это уже сразу уровень эксперта по docker swarm.
По кубу за два дня можно только подобрать список основных ссылок для изучения. Ещё пара дней может уйти на то, чтобы поднять кластер локально (нет, это не шутка, я лично это делал - в сумме где-то так и ушло: пока разобрался какие есть разные "упрощённые" инструменты для этой цели и чем они отличаются, пока отрепортил по ним несколько багов, пока из тех, которые заработали, выбрал тот, который решил использовать…). Для сравнения - в docker swarm это делается менее чем за минуту, одной командой.
Куб даёт безумную гибкость. Которая нужна гуглу. И абсолютно не нужна большинству текущих пользователей куба. За эти гибкость приходится очень дорого платить - своим временем, вниманием и плохим пониманием куба в целом.
Antra
Да, похоже, я слишком переоценил Docker Swarm. Ротация секретов едва ли не самое навороченное.
Теперь согласен. Спасибо!
Akuma
`rke up` в папке с этим файликом
В общем-то все. Ну разве что на саму ноду надо поставить докер, но это вроде не сложно.
Akuma
А можно конкретный пример?
Ну только не уровня гугла "у нас миллион машин и еще 10 на марсе", а что-то реальное. В k8s на самом деле две с половиной сущности. Просто это конструктор, но никто не заставляет собирать сложные штуки.
Antra
Когд а я к CKA готовился, самое сложное, наверное, было RBAC и, возможно, сертификаты, где какие находятся... Скорее всего потому, что при самостоятельных играх с кубером мне это не требовалось. Со всякими tolerance и affinity (типа как сделать на обычных подах аналог DaemonSet строго по одному поду на ноде) не с первой попытки получилось.
Хотя ставить это в минус по сравнению со Swarm некорректно, ибо там такого просто нет, насколько я понимаю. Не хочешь - не используй.
Akuma
Но опять же, это гуглится достаточно просто. Да, там есть миллион нюансов, но распространенные кейсы вполне себе устоялись.
RBAC - да, не очень просто. Но мы тут вроде про простые случаи говорим (в сварме по другому не будет), так что оно либо не нужно, либо сводится к добавлению чуть ли не готовой роли из какого-нибудь helm чарта.
В k8s мне лично нравится эта фишка: можно все сделать просто и быстро, но если надо, то намудрить можно очень сложные схемы.
Antra
Да я тоже считаю что для простых задач кубер использовать не сликом сложно. Это дальше уже разрастаются нюансы.
Хотя если вот вообще ничего не знать ни про Swarm ни про Kubernetes, первый все-таки быстрее запустить, и читать надо ощутимо меньше.
Про Swarm реально прочитать все, глава за главой. А про Kubernetes так не получится, мне кажется. Когда ничего не знаешь и хочешь понять масштабирование, количество запущенных экземпляров пода, тут и ReplicaSet и Deployment, и DaemonSet. Даже если в рамках базового корпоративного пайплайна DaemonSet никогда не потребуется запускать, понять это надо. Пусть и не обязательно в первый день, но времени все-таки уйдет больше, чем на овладением Swarm той же функциональности. Хотя бы потому, что чтобы понять, что данная фича не нужна, хоть бегло, но прочитать про нее надо.
При этом я все равно за Kubernetes. Если просто машинки с докером уже не хватает, и речь уже идет об оркестрации, я предпочитаю вложиться чуть больше, но иметь запас и жить на этом долго.
Akuma
Когда совсем ничего не знаешь, docker & docker-compose же :)
Antra
Именно так :)
Либо хватает docker & docker-compose, либо уже в сторону K8s двигаешься. Отрезать собаке хвост по чуть-чуть не мой стиль.
powerman
Почему бы не воспринимать swarm как тот же compose, просто с парой дополнительных фич - вроде выката на несколько серверов и rollback при ошибках выката? Многим стартапам больше ничего и не нужно, на самом-то деле.
Antra
Если рассматривать Swarm как "расширение докера" (я на самом деле к нему пару-тройку лет назад интерес проявил, когда использовал простой докер для дома для семьи, и сунулся искать к нему прибамбас для управления секретами) - да, норм позиционирование.
selenzorn Автор
Спасибо за комментарий! Описанный вами случай действительно часто встречается. Часто это происходит именно из-за влияния комьюнити K8s, поскольку "аналоги" просто не обладают такой поддержкой.
Про сравнение с Nomad взяли на карандаш)
Jammarra
Ну я бы тоже был против Сварма как тех специалист. Во первых я его не знаю. Во вторых я его не хочу знать. Зачем учить то что не нужно на рынке?
Подсадить компанию на него это страдать. Страдать с поиском типовых решений, страдать с поиском людей имеющих экспертизу. Страдать с нетипичными проблемами. Страдать с маштабированием.
Я уже давно перерос подход в айти "Готовое простое решение лучшее". Обычно оказывается что оно через 1-2 года создаст лютые проблемы с которыми будешь страдать каждый день. И заниматься тушением пожаров вместо развития инфраструктуры.
Ну а кубер не обязательно брать нативный и поднимать самому. Для стартапа и проверки взлетит или нет можно вообще взять k8s готовый где то в azure например или можно взять OKD
А для локальное разработки и подобного если не вышли в прод и вообще ничего непонятно, то миникуб или минишифт.
mrsantak
Обычно тех специалистом платят за решения задач работодателя, а не за изучение того, что поможет найти работу получше. Возможность изучить новую технологию в ходе решения задачи работодателя это крутой бонус, но это только бонус, и это не должно мешать решению этих самых задач.
Вот это все применимо к кубер в намного большей степени чем к сворму. Для поддержки сворм кластера нужно намного меньше квалификации чем для поддержки кластера кубера. И не факт что у компании вообще есть ресурсы на поддержку k8s кластера. Я вот в последние пару лет очень много компаний повидал, которые польстились на рассказы о том как легко рулить кубернетес кластером. И вот они там реально страдают. Ситуация когда товарищи что-то запустили и у них все данные похерились потомучто в качестве вольюма был emptyDir наблюдал не раз.
Касательно же масштабирования - нужно здраво оценивать эти самые масштабы. А то иногда выясняется, что ближайшие лет 5 можно вообще одной тачкой и каким-нибудь компоузом обойтись.
Jammarra
Обычно тех специалистом платят за решения задач работодателя, а не за изучение того, что поможет найти работу получше.Это только если рынок работодателя, а не работника. Хороший специалист просто не пойдет на плохой стек. Нет если конечно ЗП будет в 2 раза выше рынка то можно и подумать) И я даже встречал такие предложения. Но все равно отказался. ну не интересно мне поддерживать адовое легаси про которое потом написать нечего в резюме.
Поэтому если ты решил делать непопулярный/неинтересный стек будь готов к тому что к тебе пойдут только те кого больше никуда не берут.
Для поддержки сворм кластера нужно намного меньше квалификации чем для поддержки кластера кубера.Можно. А нужно ли? Жизнь только выбором оркестратора не заканчивается. Хороший грамотный специалист разбирающийся в кубере стоит 300-500 т.р. в месяц
Окей почем мы будим искать человека который будет админить что то другое? за 50-100? 100-200?
А не приведет ли кроиволо к попадалову? Да окей наняли специалиста за 50к. Но не бывает такого уже в современном мире что хороший админ/devops/sre не знает кубер или не может в нем разобраться. Зато идеально знает все остальное.
Так что помимо отсуствия кубера вы получите еще и отсутсвие адекватных пайпов, тестов, мониторинга и прочего. Что выльется в том через 2-4 года у вас все будет на соплях работать. И что если захотите переделать то это будет стоит раз в 10 дороже чем было сразу выстраивать нормальные процессы. Потому что это закончится отделом в 10-20 человек которые каждый день будут тушить пожары и заниматься "посмотрите у меня тут что то сломалось"
Вообще нужно понимать что хорошие специалисты идущие в стартап идут туда в первую очередь по причине того что они могут сами выбирать стек, делать сразу хорошо и что бы им не указывали. В противном случае если это будет работа вида "Делай как я сказал я начальник ты дурак" они пойдут в условный ВТБ который все равно предложит больше денег)
mrsantak
Ок, кажется я вас не правильно понял. Если "Ну я бы тоже был против Сварма как тех специалист" читается как "я бы не выбрал компанию в которой такой стек", то тут вопросов нет, у меня тоже есть стеки на которые я бы не пошел ни за какие коврижки. Я же изначально это понял как "если бы в компании в которой я уже работаю нужно было бы выбирать оркестратор, то я бы не выбрал docker swarm просто потому что он мне не интересен".
Вы сейчас все правильно пишете, вот только это относится только к мопаниям с более-менее сложной IT инфраструктурой. В реальности же есть дофига компаний, где вся IT инфраструктура - это пяток серверов. И нет у них не то что админа за 300к-500к, а даже просто админа. А кластер им вподдерживают либо разработчик, либо и вовсе какой-нибудь датасайнтист (как блин это слово вообще на русском писать-то?). И вот такие товарищи наслушаются рассказов о простоте кубера и ставят его. А потом не могут вольюмы и ингрес там настроить и херят свои данные при рестарте.
powerman
Я не уверен, что тут вообще применимо понятие "перерос". Скорее это просто временный этап, и через несколько лет Вы к этому подходу ещё вернётесь, частично потому, что устанете от лишних сложностей, частично потому, что появится больше понимания какие требования в проектах реальны, а какие просто хотелки на будущее, и что для реальных требований простых решений нередко хватает с головой.
Простые решения - лучшие до тех пор, пока наши требования не выходят за рамки возможностей этого решения. Эти рамки важно осознавать при выборе простых решений. Выход за эти рамки необходимо отслеживать, и либо блокировать такие требования, либо в этот момент переходить на другое решение, соответствующее изменившимся требованиям.
Подход, когда вместо простого решения сразу берётся самое сложное и навороченное "на вырост" - создаёт проблемы с первого дня. Ну т.е. с простым решением проблемы могут возникнуть через год-два, как Вы описали, а со сложным они гарантированно возникнут намного быстрее. Эти проблемы могут быть замаскированы непониманием сложного решения, т.е. вместо быстрого понимания "это не поддерживается и надо либо менять решение либо городить хак ручками" проблема выглядит как "я хз почему оно так себя ведёт или как это реализовать, но я почитаю доку с недельку, проконсультируюсь в сообществе, и, скорее всего, найду штатное решение".
Аргумент "у сложного решения большое коммьюнити и там можно найти решение любой проблемы" выглядит привлекательным, но ровно до тех пор, пока не оказывается, что с простым решением количество возникающих проблем меньше на два порядка, и, да, ответы на пяток известных проблем простого решения тоже легко гуглятся. Количество вопросов на SO определяется не только популярностью решения, но ещё и его проблемностью - об этом тоже стоит помнить.
Подход сразу брать сложное решение может быть вполне оправдан, если в компании уже есть крепкая экспертиза по этому решению. Но, как я писал в исходном комментарии, в тех ситуациях, которые я наблюдал лично, такой экспертизы не было.