В последнее время я вижу много хайпа вокруг Kubernetes. Кажется, что он везде и всюду, а если кто-то его еще не использует, то он безнадежно отстал. Но странно принимать решение о внедрении технологии только на основе ее популярности в СМИ. Давайте разберемся: а вот лично вам правда нужен K8S?
Для чего используют Kubernetes?
Как правило, внедрение Kubernetes означает использование микросервисной архитектуры. Конечно, чтобы реализовать микросервисы, не обязательно внедрять Кубернетес. Но очень часто обращаются именно к нему.
Тогда сформулируем вопрос иначе: а вам правда нужны микросервисы? И потом вернемся к предыдущему вопросу.
Достоинств у микросервисной архитектуры много. Например:
Микросервисы удобны тем, что не нужно вносить изменения в весь проект. Можно изменить и протестировать (правда, не всегда) только его часть.
Внедряя микросервисы, вы минимизируете “незаменимость” конкретных разработчиков. Да и поддерживать кодовую базу становится проще. Что для руководителей довольно удобно.
Вы упрощаете понимание сложной системы. У вас есть кирпичики, каждый из которых, в идеале, выполняет свою роль. Можете даже проверить: если название полностью отражает функционал микросервиса, и по нему сразу можно понять, зачем микросервис нужен, то все хорошо. А вот если в названии 10 существительных через запятую или неочевидно, что за ним стоит, возможно, с архитектурой что-то не так.
Ускоряется скорость доставки изменений. Достаточно изменить маленький кусочек, а не весь большой проект.
Но, как бывает почти всегда, за преимущества приходится платить. И минусы микросервисов существенны.
Один из них – экспоненциально растущая сложность системы.
Если микросервисы вы можете хорошо протестировать по-отдельности, то когда они начинают работать вместе, их взаимодействие становится не до конца предсказуемым.
Основные проблемы как раз возникают не “внутри” микросервисов, а в точках их взаимодействия и взаимного влияния. Это и каскадные сбои, и просто очень сложные ошибки, когда проблема начинается в одном сервисе, а проявляется в работе другого, и установить исходную проблему тяжело.
К этому добавляются еще и проблемы сети. Ведь микросервисам нужно общаться друг с другом, а они, как правило, расположены на разных серверах, а в некоторых случаях, и в разных ЦОДах.
При этом проблемы могут возникать абсолютно неожиданно. Кажется, все работает стабильно, но затем внесли небольшие изменения, произошла “цепная реакция” и у вас все развалилось.
Есть даже “народная примета”: если вы используете микросервисную архитектуру, ваш сервис рано или поздно сломается. А если еще не сломался, то просто время не пришло.
Но поскольку хорош не тот Ops инженер, кто не роняет, а тот, кто быстро поднимает, было придумано множество инструментов и практик, чтобы хоть как-то контролировать то, что происходит в сложных микросервисных архитектурах. Это и трассировки, и анализ логов, и метрики в Grafana, и SRE подходы.
А теперь вернемся к вопросу о Kubernetes. При кажущейся простоте рецепта (всего несколько бинарников), его нужно знать, как готовить. Если не знать, то может случиться так, что головки HDD не успеют записать/прочитать данные, сломается etcd (внутренняя база данных) и CoreDNS, и будет долгий даунтайм. Это был печальный пример из собственного опыта. А знают, как Kubernetes правильно настроить и эксплуатировать либо облачные провайдеры (что дорого, да и, честно говоря, не так уж и надежно), либо редкие на рынке спецы, которые стоят еще дороже.
Но если все так сложно, вечно ломается, то не проще ли остановиться на монолите?
Скажу честно, мы в нашем проекте Amvera Cloud (контейнерное облако для хостинга IT-проектов) используем Kubernetes и постоянно сталкиваемся с разными проблемами. И если бы была хоть малейшая возможность не использовать k8s, мы бы так и сделали.
Тут нет универсального ответа для всех, но лично для себя я формулирую принцип выбора так: если ваш проект относительно прост (статичный сайт, или не сложный интернет-магазин, или еще что-то, где мало движущихся частей), и главное, любой разработчик после месяца изучения проекта может спокойно его поддерживать и развивать, выбирайте монолит. Не надо вестись на шум из каждого утюга про Кубернетес. Будет не так модно, зато будет работать. Но если текущая или предполагаемая сложность проекта такая, что никто не может до конца понять, как он работает, вам не обойтись без абстракций в виде микросервисов. Микросервисы в общем и Kubernetes в частности – это то, за что вы вынуждены платить, чтобы иметь возможность строить большие и сложные проекты.
Это сравнимо с задачей прямого управления. При прямой коммуникации можно эффективно управлять группой в 7-12 человек. Но как только ваша группа (разрабатываемая система) становится больше, то ни нашего сознания ни коммуникативных навыков уже не хватает для эффективного прямого управления и приходится придумывать абстракции (отделы, команды, иерархию, микросервисы …).
Если вы можете обойтись без Kubernetes – постарайтесь обойтись, вы сбережете себе много нервных клеток и денег. А если нет, то приготовьтесь установить Grafana для мониторинга метрик, Jager для трейсов, ELK для логов, нанять SRE/ DevOps инженера, потратить много денег, и засыпая думать: интересно, будет ли лежать мой сервис, когда я проснусь?
P.S. Если вы все еще хотите попробовать использовать микросервисы или даже контейнерную архитектуру (например, для размещения Telegram-бота или Discord-бота), вы можете поучаствовать в бета-тесте нашего контейнерного облака Amvera Cloud. В нем вы можете арендовать отдельные контейнеры и, как в Heroku, делать обновления через push в GIT. На время бета-теста сервис полностью бесплатен. Потом мы зачислим всем 1000 руб. на баланс для продолжения использования облака, чего, в большинстве случаев, хватает на несколько месяцев. Буду благодарен за использование облака и обратную связь.
Комментарии (40)
xexeboi
19.05.2023 11:45+3xexe
Tzimie
19.05.2023 11:45Ковид более монолитен
shai_hulud
19.05.2023 11:45+1я бы сказал что у ковида нормальная структура зависимостей, прямо эталон. Ядро и сеттелиты.
nikis05
19.05.2023 11:45+3То, что мы видим на картинке - это скорее "ингрессы" (красные) и "фаерволл" (серый), то есть белки которые запускают процесс слияния мембраны клетки с мембраной вируса, и собственно сама мембрана. Вся самая интересная бизнес логика спрятана внутри)
MEJIOMAH
19.05.2023 11:45+2|Вы упрощаете понимание сложной системы
|Один из них – экспоненциально растущая сложность системы.
datacompboy
19.05.2023 11:45Есть даже “народная примета”: если вы используете микросервисную архитектуру, ваш сервис рано или поздно сломается. А если еще не сломался, то просто время не пришло.
Неважно какая архитектура вашего сервиса. Если у вас есть сервис, у вас есть проблемы.
exTvr
19.05.2023 11:45+1Если у вас есть сервис, у вас есть проблемы.
Нет пользователей — нет проблем :))
CrzyDocTI
19.05.2023 11:45а мне казалось что k8s это в первую очередь - масштабирование, во вторую - управление.
если не забывать об этом то сразу понятно становится что где и как применять. и стоит ли пилить монолит на микросервисы
Dynasaur
19.05.2023 11:45-2Все достоинства микросервисной архитектуры перечеркиваются правильным монолитом. Таким, как у САП. Там все эти достоинства также присутствуют, причём, в гораздо более удобном виде. Плюс колоссальное преимущество от того, что все данные в единой БД и доступны отовсюду. И без всяких этих ваших кубернетесов.
ggo
19.05.2023 11:45+3реальные внедренцы САПа думают немного по другому
Dynasaur
19.05.2023 11:45Я реальный внедренец САП. Буду рад услышать аргументированные возражения коллег.
vvpoloskin
19.05.2023 11:45Плюс колоссальное преимущество от того, что все данные в единой БД и доступны отовсюду.
Да, и под эту единую базу данных нужен единый сервер с 16 процессорами и террабайтами оперативки. Который сейчас нигде не купишь.
Dynasaur
19.05.2023 11:45+1Надуманная проблема. Если у вас 10 БД вместо одной, вам меньше вычислительной мощности потребуется? Заметно больше хотя бы по тому, что вы никогда не сбалансируете и не оптимизируете нагрузку 10 БД. А ещё их обслуживание. А ещё, "как мы любим" в мультисервисах, они будут все на разных СУБД - и вот с этим зоопарком вы упаритесь не считая всего остального.
А ещё эти 10 БД будут частично дублировать информацию друг из друга, а ещё информационные обмены между ними тоже не бесплатные. В итоге вы купите гораздо больше процессоров и оперативки, чем на одну БД.
vvpoloskin
19.05.2023 11:45Совсем не надуманная проблема проблема. Купить 8 серверов с двумя процессорами несложно, а вот один с 16тью уже квест. На счёт под каждый микросервис свою субд — ну дурость везде есть, кто то должен следить чтоб не притащили ничего лишнего.
Dynasaur
19.05.2023 11:45+1Я не спец по БД, но почему-то уверен, что расшардить (сегментировать) единую БД на 8 серверов по 2 проца выйдет дешевле и производительнее, чем порезать приложение на 8 СУБД и разложить по тем же серверам. Хотя бы по тому, что нагрузку между 8 сегментами можно перераспределять гораздо гибче, чем бизнес-логику. Если сервер с данными о движениях на складах захлёбывается, а сервер с бухгалтерскими проводками недозагружен, вы никак не перераспределите нагрузку между ними, с этим и будете жить. А между сегментами легко. И опять же сервер с данными о движениях товаров будет дублировать данные о клиентах с сервером с данными о проводках. И грузиться бесконечными пересылками этих данных друг другу.
fireSparrow
19.05.2023 11:45Очень зависит от специфики конкретного сервиса.
Если возникает необходимость независимо масштабировать части систему — монолит в пролёте.
Если возникает необходимость независимо выкатывать части системы — монолит в пролёте.
Ну а единая БД может быть и при микросервисной структуре (правда, многие считают это анти-паттерном).Dynasaur
19.05.2023 11:45-1Повторюсь, всё зависит от монолита. Если САП монолит (он имеет признаки и монолита и микросервиса), то я не встречал систем, которые масштабируются и расширяются удобнее. Нет проблем ни масштабировать, ни выкатывать релизы и обновлять хоть одну запятую, хоть тысячу человеко-дней разработки.
fireSparrow
19.05.2023 11:45Я про САП ничего не знаю :(
Можете объяснить на пальцах, как можно в монолите независимо масштабировать/деплоить части системы?Dynasaur
19.05.2023 11:45Быстро не объясню. :-) В САПе переносится исходный код. Каждое изменение кода и структур данных записывается в т.н. "запрос на перенос" и специальная транспортная система переносит эти запросы между средами. То есть можно поправить одну букву, записать в запрос, эта буква переедет в целевую систему (в тест, потом в прод) и там обновится только та подпрограммка, в которой произошли изменения и которая включена в запрос на перенос. В целевой системе перекомпилируется только одна подпрограммка/модуль в которой произошли изменения. Весь код хранится в БД - одна подпрограммка - одна запись. Скомпилированный код тоже в БД. При обращении он оттуда вызывается. Очень похоже на микросервис, но монолит :-) Причём "сервисы" нарезаны гораздо мельче, чем в микросервисе. В системе сотни тысяч таких кусочков кода-подпрограмм-модулей каждый из которых обновляется независимо и это здорово автоматизировано.
KReal
19.05.2023 11:45Расскажите, пожалуйста, с примерами)
Dynasaur
19.05.2023 11:45Допустим, мы нашли ошибку в каком-то сложном алгоритме, реализованном в виде десятков вызываемых друг из друга методов (модулей кода). И ошибка только в одном из этих модулей кода. И ещё надо поменять тип поля в какой-то структуре, например таблице. Мы записываем в запрос на изменение имя изменённого модуля и изменение в структуре (не мы, они сами записываются при нашем контроле). Потом мы говорим - перенести такой-то запрос в тестовую среду. Или не один запрос, а целую очередь запросов. Система поможет выстроить последовательность запросов в очереди, но мы можем сделать это сами. Специальная транспортная система переносит очередь или один запрос в тест и там обновляется только один модуль и одно поле - в соответствии с нашим запросом. Мы тестируем и утверждаем перенос дальше в прод. И там так же обновляется только один модуль кода и одно поле в одной таблице.
При всём при этом десятки и сотни коллег из разных проектов, стран и континентов могут параллельно делать свои изменения в других модулях кода и структурах данных и мы особо не мешаем друг другу. Конфликты возникают только если разные люди одновременно меняют один объект. Но объекты небольшие и это происходит не часто и разруливается организационно.
iwram
19.05.2023 11:45+2Как продать контейнеры с коробочным деплоем на основе данных с гит реппозитория? Правильно, надо самим продавать хостинг контейнеров и говорить, что кубер это дорого и неудобно. Это просто другая игла. Хорошо, я повелся на рекламу - зашел, открыл доку https://docs.amvera.ru/ - где на вашей стороне мониторинг, логирование и все остальное что было перечислено? Пожалуй, что не стоит потраченного времени. Удачи в работе, в том числе и надо ошибками.
kirillkosolapov Автор
19.05.2023 11:45Наш сервис это не аналог kubernetes. У нас размещают небольшие проекты из 1-5 контейнеров (боты и т.д.). И основное в чем фишка - это доствка обновлений через push в GIT. Мы не пересекаемся с потребителями kubernetes, поэтому можем его и ругать и хвалить без задней мысли. Задачи решаемые нашими пользователями и пользователями k8s просто совсем разные.
ch4t5ky
19.05.2023 11:45+1Как хорошая альтернатива Kubernetes - Hashicorp Nomad. Поставляется в виде бинарного файла, который можно запустить в режиме сервера и в режиме клиента. Для небольших и средних проектов идеально подойдёт.
sadPacman
19.05.2023 11:45Заголовок и выводы про кубернетес, а статья про микросервисы почему-то. Плюс SRE, метрики и логи, которые вообще ни от одного, ни от другого не зависят.
Статья для рекламы?..
Demacr
Странная статья. Почему монолит не может работать в кубе? И почему, не используя куб, не нужно будет использовать Grafana, трейсы, логи, нанимать SRE? Как будто в случае монолита и на "голых" виртуалках без этого всего можно обойтись. А так же ноль новых мыслей по сравнению с другими статьями на тему "монолит vs микросервисы".
kirillkosolapov Автор
Все можно и нужно, но для разных задач разные инструменты. Можно и монолит в kubernetes запускать, но вопрос - а зачем? Логи, метрики и т.д. вообще полезны, но если у вас простой сервис, который не обновляется и нет "движущихся" частей, скорее всего вы про них не вспомните после настройки. А вот когда что-то сложное, их не использовать - самоубийство. Да и если у вас сервис на одной виртуалке - кажется нанимать SRE в 99% это несколько избыточно, хотя редкие исключения, подтверждающие правило есть всегда.
shai_hulud
Для получения основных преимуществ контейнеров - изоляция, деплой.
Микро
пенисысервисы и кубер не обязательны друг с другом. И уж тем более не исключают другие подходы типа монолита с его зависимостями в кубере.kirillkosolapov Автор
Я согласен, что микросервисы и Kubernetes не обязательны друг с другом. Как и что и у контейнеров есть свои преимущества, и у виртуалок. Мысль была в том, что вот есть у вас конкретный проект - для него оптимален определенный технологический стек, и не всегда он самый модный. Т.е. лучше ответить себе на вопрос - оно правда нужно? Часто - преимущества перевешивают недостатки, но не всегда. А если принимать решение исходя из моды, можно добавить излишнюю сложность в свой проект не получив преимуществ.
divinity2000
Если уже определен стек, который соответствует всем условным требованиям и в нем нет кубера, то зачем туда пытаться пристроить кубер если решение не планируется быть встраиваемым?
Если смотреть со стороны где кубер просто решает определенные задачи, то его имеет смысл использовать при наличии таких задач, а с другой стороны можно подумать что раз модно -- значит надо. Вопрос -- на какой стороне Вы?)
jetteim
Так монолит же не в одиночку живёт, у него зависимости есть, может быть несколько инстансов монолита и так далее
aGGre55or
Разумеется. Только кол-во взаимосвязей между инстансами монолита несравнимо с количеством взаимосвязей которым монолит обзаведётся после "распиливания" на микросервисы. Ну, много у Вас зависимостей и взаимосвязей в типичном LNMP? Собственно, 4 (четыре), что и дало название.
CI/CD? Для сайта на "пэхапэ" (например, 1С-Битрик) это просто выкатывание кода в директорию web-сервера, git сверху. Нет никаких проблем организовать это без использования микросервисов. Причём сделав разработку и эксплуатацию в разы безопасней и стабильней. Потому что точек отказа в разы меньше.
Demacr
Звучит как будто бы монолиты - всегда что-то маленькое, а микросервисы - непомерно большое и комплексное. Кмк, можно делать 3.5 микросервиса, если команда посчитает это более удобным, так и делать монолит по функциональности в условный облачный провайдер.
kirillkosolapov Автор
Может так звучит в статье, и надо бы как-то переформулировать, но конечно нет. Тут же вопрос не в размере, а в архитектуре. И для каких случаев какая подходит лучше.
sparrowhawk
Канарейные развертывания для тестирования гипотез, изоляция, оверлейные сети и проч - все это и монолиту применимо