Спасибо за вопрос! На самом деле, никто не спорит с тем, что хороших инструментов существует великое множество. У большинства профессионалов не возникнет проблем ни с Messos, ни с Nomad, ни с libvirt-lxc 🙂 Весь вопрос в том, кто принимает решение об использовании инструмента, и для каких целей мы подбираем этот инструмент 😉

Если один отдельно взятый человек (возьмём для примера автора этой статьи) захочет в личных целях развернуть 10 микросервисов, то наверняка выберет какой-то более экзотический инструмент, чем Kubernetes — как минимум, просто потому что это интересно.

Но если мы ставим целью минимизировать затраты на поддержку и поиск специалистов, выбор с большой вероятностью падёт именно на кубер. Просто потому это уже давно де-факто стандарт в индустрии.

gecube Sep 26 at 07:13

Звучит круто, но есть нюанс: освоить и поддерживать Kubernetes в продакшене сложно.

Замени кубернетес на любую технологию, например, линукс - ничего не изменится. Тогда почему именно кубернетес сложный ? Непонятно. Решительно непонятно.

runity Sep 26 at 23:23

Можно ли ответить популярной гифкой?

duronus Sep 26 at 13:52

Ога, а когда в проде всего 2 реальных железяки и они справляются, тоже купер натягивать? Или когда у вас каждого разного сервака по одной штуке тоже кубер натягивать? Все технологии хороши, но пока настроишь все эти хелмы и прочее посидеешь, если виртуалок меньше 100шт да еще все разные он и "нафиг не нужон"@

runity Sep 26 at 23:19

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

gecube Sep 26 at 23:56

Ога, а когда в проде всего 2 реальных железяки и они справляются, тоже купер натягивать?

можно. k3s + пачка ямлов и поехали. Всяко лучше, чем ансибл.

Все технологии хороши, но пока настроишь все эти хелмы и прочее посидеешь

гы. Ну, типа если у тебя кубер везде - нет проблемы его настроить и на "2 реальных железках". Если ты его только на картинках в букваре видел... ну, так у тебя и с линуксом тогда проблемы будут... если линукс умеешь и кубер не умеешь - да, но вроде уже все изучили

duronus Sep 27 at 22:02

Вы видимо не работали с легаси, настроить кубер даже на 2 железки не проблема, более того дома у меня как раз к3 для поиграться вообще на одной железке, вот только тогда в этом кубере нет никакого смысла. Ниже отлично написали почему. Я еще не видел компаний где бы было 2-3 сервиса которые можно запихнуть в тот же докер и разворачивать на куберах, обычно это длинная цепочка сервисов которые друг от друга зависят и вот тут куберовский "автовозврат" может сломать вообще всю базу к чертовой матери потому что он то не знает что вот этот под можно откатить, а вот тот нельзя, а завтра наоборот. Кубер в первую очередь прям отличный для тех же хостингов и подобного. Ну или крупняков где куча однотипных серверов, а когда у вас каждый сервер в одном-двух экземляров, да еще которые время от времени требуют обновлений старый добрый ansible достаточен, конечно можно натянуть кубер, но зачем? стрелять из пушки по воробьям?

gecube Sep 28 at 10:43

которые друг от друга зависят и вот тут куберовский "автовозврат" может сломать вообще всю базу к чертовой матери потому что он то не знает что вот этот под можно откатить, а вот тот нельзя, а завтра наоборот

какой-то набор шаблонов, которые вы удачно тиражируете. Короче, проблема не в том, что "Кубер в первую очередь прям отличный для тех же хостингов и подобного". Вообще никак. А в том, что это новая абстракция, с которой тупо надо научиться работать. Типичные проблемы при кубернетизации приложения: засунули стейтфул, забыли вольюмы (ну, это при докеризации происходит). Забыли реквесты-лимиты (но это в целом проблема на любом шареном хосте, когда напихали nginx+mysql+backend и процессы начали друг на друга лезть на нагрузке). Стратегия Rolling Update, когда приложение не умеет во много реплик. И так далее. В целом - когда мигрируешь на линукс, то у тебя все то же самое, только с другой стороны. SELinux - надо готовить, иначе проблемы. Народ же просто по туториалам отключает, а потом удивляется - а чо нас взломали. Система прав на ФС. Давайте бахнем 777 на crontab. А потом черви. Или давайте положим .git в web-сервер (вообще нерелевантно ни к куберу, но к докеру, но типичная ошибка). И так далее. И на самом деле - кубер при базовом использовании не так уж и сложен, как хочется показать тем, кто все еще сидит на ансибле и не считает, что "на 2 сервера нужен кубернетес". Может и нужен. А может и не нужен. Но ответ в совершенно другой плоскости. Вы же всерьез не выбираете уже в 2025 году - брать линукс или фрибсд для обычных задач, правда? Здесь так же. Кто не изучит кубер, завтра будет за пределами рынка труда. И точка.

duronus Sep 29 at 11:52

ЭЭЭ, а причем тут вообще линукс? у нас на тестах тот же selinux вырублен ибо тест даже не знает, что такое интернет, вот только это не говорит о том что на проде его тоже нужно выключать. По поводу выбора ОСи, еще как есть разница, на freebsd те же веб серваки бегают сильно бодрее и надежнее. По поводу кубера, если нужно его тупо запустить, да в нем вообще разбираться не нужно, вот только вопрос, нужно ли разбираться тому же DevOPS в кубере когда у него каждый сервак настроен индивидуально и имеет очень тонкий баланс между упасть нахрен все или чутка парочка лагает в пики? Опять же если проект маленький то его нужно поддерживать, пока ты сидишь настраиваешь лимиты в кубере ради выйгрыша пары ядер или пары секунд другие уже купили пару новых серваков и ввели их. То что кубер будет везде, очень в этом сомневаюсь, сейчас тот кто может собрать свой докер единицы, а дальше с этим будет еще хуже

gecube Sep 29 at 11:58

ЭЭЭ, а причем тут вообще линукс?

При том, что даже такая якобы базовая технология как линукс требует знаний. Жаль, что не ввели сертификация до допуска до клавиатуры.

на тестах тот же selinux вырублен ибо тест даже не знает, что такое интернет

очень жаль. Вы попались. Это примерно как говорить. Я не буду мыть руки после личного туалета. А после общественного буду. Ну, а чо такова ? В случае с тестом: во-первых, часто тест резко становится продом, или он рядышком, что позволяет так называемое lateral movement. Во-вторых, отсутствие интернета не индульгенция. В третьих, если на тесте другая конфигурация, чем на проде - мы знаем к чему это приводит.

Насчет фрибсд и ее перформанса - полностью согласен, но где вы ее реально видите вокруг ? Все собирают сервера на линуксе + nginx / envoy / haproxy и хорошо, если действительно исповедуют принцип один сервер одна роль, а не делают таких вот универсальных бойцов

Дальше даже комментировать не хочется, потому что это подобно бисеру и свиньям.

duronus Sep 29 at 20:51

вам либо лет 20 и вы только жить начинаете, либо вы живете в своем мирке и любая другая точка зрения не правильная. Настраивайте серваки как хотите, вот только реальная жизнь совсем иначе выглядит. Для справки, у нас фронт работает на фряхе, для теста selinux отключен потому что там за день может поменяться ядро 3 раза и обратно просто потому что у нас много продов и в том числе у клиентов свои проды стоят, которые мы же и обслуживаем, так что уж разница конфигураций мы отлично знаем в отличии от вас, ибо наш прод работает на всех актуальных линуксах, а не вот только одна единственная версия, а остальные гавно поэтому идите нафиг

gecube Sep 29 at 21:42

реальная жизнь - из известных мне крупных контор - фряха есть только у CloudFlare вот. Почему? Потому что "индустрия порешал. ". Если что-то есть сказать по делу - можете подать свою заявку на https://cfp.devopsconf.io/ 2026 года, коллеги будут рады посмотреть на альтернативный мир...

CodARM Sep 27 at 08:27

Добрый день! Изучил статью и не увидел оборотной стороны монеты. В целом согласен, без нюансов выглядит как серебряная пуля для любого проекта, но давайте пройдёмся по большими НО. В вашей статье было приведены только примитивные примеры, разработчик без админа, helm, "выглядящий как магия", самолёт с "магией" внутри, всё это интересно только если у вас есть чёткий и маленький сервис, или постоянно меняющаяся инфра вроде хостинга или мини инфра из нескольких десятков сервисов. В моей практике, даже при р��сте компании, нормально работающие сервисы не отваливаются, при прохождении чек-листа по развертыванию сервиса раз 10, у меня остаётся только мелкие доработки и документирование сервисов. Kuber -- это про изменчивость и то, где нужно много ресурсов для множества малых проектов.
К примеру, сборка и тестовый деплой проекта. Данные процедуры, если автоматизировать, то займут вместе с тестами, тонну процессорного времени(и денег за ресурсы), что явно говорит о том что нужно выносить тестовую инфру на локальный сервер для тестирования и получения бОльшего контроля. Если брать другие варианты, то требуется развертывание своего kuber кластера или платить KaaS провайдеру бешеные деньги за смещение кнопочки на 2-3 пикселя и нормальный довод бекенда для этой же кнопки. При росте проекта у вас появляется потребность в дорогих специалистах по развёртыванию кубера, не забываем про ИБ, настройку сетей и безопасного взаимодействия с кластерами. Накидывается столько нюансов, что, к примеру, в своей структуре я больше склоняюсь к ansimble и стандартную виртуализацию, чем затаскивания файлообменника и условного гита, а так же БД в кубер.
Не стоит забывать и о важной проблеме кубера, он хорош ровно до того момента как не развалится. Малые команды смогут восстановить ~10 сервисов в кубере, но вот когда сервисов становится 50-100, и случилась большая беда, то могу только гадать как этот зоопарк поднимать.

runity Sep 30 at 13:05

Здравствуйте! Да, вы верно подметили, что в статье много упрощенных примеров. Сделано это намеренно, а одна из основных целей выбора такого стиля — слегка "подтолкнуть" к использованию k8s тех, кто могли бы его использовать, но пока не решаются🙂

Но в статье есть ряд мыслей и для опытных пользователей. Вот одна из них: k8s стал не просто стандартным инструментом для sysadmins/ops/devops/sre/platform/\…(aiops?), но и для разработки. Так, вчера любой разработчик умел поместить свой сервис в докер, а сегодня опытные разработчики с легкостью запустят свой сервис в k8s самостоятельно, поскольку умеют им пользоваться и знают принципы работы.

А это означает, что еще до написания кода все участники доставки ценности понимают, где сервис будет запущен, каким принципам должен соответствовать, каковы принципы межсервисного взаимодействия. Таким образом, общий контекст разработчиков/тестировщиков/админов — важная составляющая, которая существенно сокращает time-to-market.

gecube Sep 30 at 19:05

А это означает, что еще до написания кода все участники доставки ценности понимают, где сервис будет запущен, каким принципам должен соответствовать, каковы принципы межсервисного взаимодействия. Таким образом, общий контекст разработчиков/тестировщиков/админов — важная составляющая, которая существенно сокращает time-to-market.

поддержу! Я где-то в статьях на хабре видел тезис, что кубернетес стал lingua franca - общим языком между разработкой и эксплуатацией.

gecube Sep 30 at 19:04

Данные процедуры, если автоматизировать, то займут вместе с тестами, тонну процессорного времени(и денег за ресурсы), что явно говорит о том что нужно выносить тестовую инфру на локальный сервер для тестирования и получения бОльшего контроля.

очень странный тезис. Учитывая, что в случае облака - можно дешево брать спотовые и прерываемые инстансы, которые идеально подходят для такого рода применений. А еще учитывая тот факт, что сборки обычно идут в рабочее время (но это зависит от типа организации), а сервера жгут электричество 24/7, что вызывает соблазн, либо унифицировать ресурсы (и гонять по ночам, например, аналитику), или как раз сделать скейлинг вверх и вниз.