В последнее время я вижу много хайпа вокруг Kubernetes. Кажется, что он везде и всюду, а если кто-то его еще не использует, то он безнадежно отстал. Но странно принимать решение о внедрении технологии только на основе ее популярности в СМИ. Давайте разберемся: а вот лично вам правда нужен K8S?
Для чего используют Kubernetes?
Как правило, внедрение Kubernetes означает использование микросервисной архитектуры. Конечно, чтобы реализовать микросервисы, не обязательно внедрять Кубернетес. Но очень часто обращаются именно к нему.
Тогда сформулируем вопрос иначе: а вам правда нужны микросервисы? И потом вернемся к предыдущему вопросу.
Достоинств у микросервисной архитектуры много. Например:
Микросервисы удобны тем, что не нужно вносить изменения в весь проект. Можно изменить и протестировать (правда, не всегда) только его часть.
Внедряя микросервисы, вы минимизируете “незаменимость” конкретных разработчиков. Да и поддерживать кодовую базу становится проще. Что для руководителей довольно удобно.
Вы упрощаете понимание сложной системы. У вас есть кирпичики, каждый из которых, в идеале, выполняет свою роль. Можете даже проверить: если название полностью отражает функционал микросервиса, и по нему сразу можно понять, зачем микросервис нужен, то все хорошо. А вот если в названии 10 существительных через запятую или неочевидно, что за ним стоит, возможно, с архитектурой что-то не так.
Ускоряется скорость доставки изменений. Достаточно изменить маленький кусочек, а не весь большой проект.
Но, как бывает почти всегда, за преимущества приходится платить. И минусы микросервисов существенны.
Один из них – экспоненциально растущая сложность системы.
Если микросервисы вы можете хорошо протестировать по-отдельности, то когда они начинают работать вместе, их взаимодействие становится не до конца предсказуемым.
Основные проблемы как раз возникают не “внутри” микросервисов, а в точках их взаимодействия и взаимного влияния. Это и каскадные сбои, и просто очень сложные ошибки, когда проблема начинается в одном сервисе, а проявляется в работе другого, и установить исходную проблему тяжело.
К этому добавляются еще и проблемы сети. Ведь микросервисам нужно общаться друг с другом, а они, как правило, расположены на разных серверах, а в некоторых случаях, и в разных ЦОДах.
При этом проблемы могут возникать абсолютно неожиданно. Кажется, все работает стабильно, но затем внесли небольшие изменения, произошла “цепная реакция” и у вас все развалилось.
Есть даже “народная примета”: если вы используете микросервисную архитектуру, ваш сервис рано или поздно сломается. А если еще не сломался, то просто время не пришло.
Но поскольку хорош не тот Ops инженер, кто не роняет, а тот, кто быстро поднимает, было придумано множество инструментов и практик, чтобы хоть как-то контролировать то, что происходит в сложных микросервисных архитектурах. Это и трассировки, и анализ логов, и метрики в Grafana, и SRE подходы.
А теперь вернемся к вопросу о Kubernetes. При кажущейся простоте рецепта (всего несколько бинарников), его нужно знать, как готовить. Если не знать, то может случиться так, что головки HDD не успеют записать/прочитать данные, сломается etcd (внутренняя база данных) и CoreDNS, и будет долгий даунтайм. Это был печальный пример из собственного опыта. А знают, как Kubernetes правильно настроить и эксплуатировать либо облачные провайдеры (что дорого, да и, честно говоря, не так уж и надежно), либо редкие на рынке спецы, которые стоят еще дороже.
Но если все так сложно, вечно ломается, то не проще ли остановиться на монолите?
Скажу честно, мы в нашем проекте Amvera Cloud (контейнерное облако для хостинга IT-проектов) используем микросервисы и постоянно сталкиваемся с разными проблемами. И если бы была хоть малейшая возможность не использовать микросервисы, мы бы так и сделали.
Тут нет универсального ответа для всех, но лично для себя я формулирую принцип выбора так: если ваш проект относительно прост (статичный сайт, или не сложный интернет-магазин, или еще что-то, где мало движущихся частей), и главное, любой разработчик после месяца изучения проекта может спокойно его поддерживать и развивать, выбирайте монолит. Не надо вестись на шум из каждого утюга про Кубернетес. Будет не так модно, зато будет работать. Но если текущая или предполагаемая сложность проекта такая, что никто не может до конца понять, как он работает, вам не обойтись без абстракций в виде микросервисов. Микросервисы в общем и Kubernetes в частности – это то, за что вы вынуждены платить, чтобы иметь возможность строить большие и сложные проекты.
Это сравнимо с задачей прямого управления. При прямой коммуникации можно эффективно управлять группой в 7-12 человек. Но как только ваша группа (разрабатываемая система) становится больше, то ни нашего сознания ни коммуникативных навыков уже не хватает для эффективного прямого управления и приходится придумывать абстракции (отделы, команды, иерархию, микросервисы …).
Если вы можете обойтись без Kubernetes – постарайтесь обойтись, вы сбережете себе много нервных клеток и денег. А если нет, то приготовьтесь установить Grafana для мониторинга метрик, Jager для трейсов, ELK для логов, нанять SRE/ DevOps инженера, потратить много денег, и засыпая думать: интересно, будет ли лежать мой сервис, когда я проснусь?
P.S. Если вы все еще хотите попробовать использовать микросервисы или даже контейнерную архитектуру (например, для размещения Telegram-бота или Discord-бота), вы можете поучаствовать в бета-тесте нашего контейнерного облака Amvera Cloud. В нем вы можете арендовать отдельные контейнеры и, как в Heroku, делать обновления через push в GIT. На время бета-теста сервис полностью бесплатен. Потом мы зачислим всем 1000 руб. на баланс для продолжения использования облака, чего, в большинстве случаев, хватает на несколько месяцев. Буду благодарен за использование облака и обратную связь.
