Блог компании Флант
DevOps
Анализ и проектирование систем
Программирование
Комментарии 18
+3
А после объединения микросервисов в логически связанные сервисы возникает мысль — «а нужен ли нам вобще kubernetes?» Но лучше молчать, а то опозоришься.
+3

Для нас Kubernetes — это просто один из инструментов. И очень мощный инструмент. И как и у любого мощного инструмента — у него достаточно высокий входной платеж. Нам, конечно же, удобней делать все проекты в Kubernetes, так-как именно для нас — так быстрей и удобней. Понятно, что в общем случае в первую очередь стоит исходить из возможностей команды и реальных потребностей проекта. Во многих может быть проще и правильней два хоста и docker-compose.

+2
А после объединения микросервисов в логически связанные сервисы возникает мысль — «а нужен ли нам вобще kubernetes?» Но лучше молчать, а то опозоришься.

Конечно Kubernetes это оверлишний управляющий софт, казалось бы, но… А чем замените?

Все равно нужно для серьезного проекта:

  • хоть какой-то надежный деплой, с возможностью отката в случае сбоя деплоя;
  • green-blue deployment или быстрые откаты до предыдущих версий в случае выкатки ошибочного кода;
  • запускать экземпляр сервиса, мониторить здоровье экземпляра сервиса, перезапускать экземпляр сервиса при сбое;
  • мониторить загрузку нод, запускать на менее загруженной ноде;
  • запускать дополнительный экземпляр сервиса при росте нагрузке;
  • направлять и перенаправлять трафик на нужный экземпляр сервиса;
  • staging, тестирование нового функционала на части пользователей;
  • под Kubernetes полным полно адаптированного софта и best practics и готовых к развертыванию пакетов Prometheus/Grafana/ELK, иначе придется настраивать нечто подобное ручками


В комментариях предложите пожалуйста варианты для реализации описанного выше, но решения проще, чем Kubernetes. Очень нужно.

Склоняюсь или переплачивать на ненужный фунционал Kubernetes лишним рабочим временем и лишними управляющими нодами Kubernetes.
Или реализовывать на базе nomad/consul/registrator.

0
Как минимум большинство требований закрывает docker swarm. Для автомасштабирования нужна будет внешняя обвязка, масштабирующая в ответ на изменение метрик. Изучали этот вариант?
+1
Как минимум большинство требований закрывает docker swarm.

habr.com/company/itsumma/blog/345976
Swarm при смерти
Когда Соломона Хайкеса спросили жив ли Docker Swarm, он ответил (в Твиттере): «Docker продолжит поддерживать и Kubernetes и Swarm на высшем уровне и будет стимулировать их взаимное развитие. Открытость и возможность выбора создают более здоровую экосистему для всех.» Проблема же здесь в том, что Docker Swarm поддерживается недостаточно хорошо. Совсем нет. Команда разработки Docker Swarm и горстка их опенсурсных разработчиков не смогут тягаться с сообществом Kubernetes. Как бы не был хорош Docker UI, Kubernetes UI гораздо лучше. Это почти как если бы Docker опустился до статуса маргинальной консалтинговой фирмы в мире контейнеров.

0
Я больше года не слежу за ченжлогами в связи со сменой обязанностей, отвечали лишь по требованиям на текущий (вернее на год+ назад момент).
+1

К сожалению мне нечего вам предложить. Мы никогда не выбирали между Kubernetes и чем-то другим. Зашел с первого взгляда, так сказать. Просто эволюционно шли шли и пришли.

+3

И да и нет. И чем больше я общаюсь с людьми и получаю обратной связи по конкретно этому докладу — скорей нет, чем да. Если вам очевидно — вы молодец!

+1
Полностью согласен с автором. Сейчас микросервисы пихают куда надо и не надо.
Зачем? Это модно и креативно. Для архитекторов замечательная задача нарисовать много блоков со стрелочками. За хорошие деньги и много думать не надо — разукрупняй все.
Для программеров, на самом деле, легче и приятней кодить свой маленький модуль на чем хочешь и как хочешь не беспокоясь о смежниках.
А потом и получается нечто монстрообразное и малопригодное для эксплуатации.
Но к тому времени проект уже завершен (тупо кончились деньги), все получили свои оплаты и скилы и радостно свалили на новые проекты по внедрению микросервисов.
Самое смешное, что архитекторы этого ужаса запишут в свои заслуги успешные внедрения микросервисов в крупных организациях и будут просить еще больше денег на следующей работе.
+2

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

0
Ну так я и не утверждаю, что архитектура из примера на слайде родилась по причине намеренного саботажа. Все из лучших побуждений, как всегда…
На самом деле, ключевой, на мой взгляд момент в докладе, что успешное внедрения чаще происходит при движении от монолита. А изначальное планирование такой архитектуры скорее ведет к неудаче. В докладе делается предположение, что это происходит из за лучшего знания предметной области. Я думаю, что это не самая главная причина. Плохое знание предметной области ведет к неудаче и на монолите. Принципиальная же разница в том, на мой взгляд, что при движении от монолита, гораздо более четко и конкретно осознается проблема и для чего именно меняется архитектура. Отсюда проистекает более рациональный, объективно обусловленный подход к проектированию.
При проектировании же 'с нуля', такого четкого понимания часто нет. А исходят, зачастую, лишь из субъективных, не достаточно обоснованных, представлений о том, что проект должен делаться на микросервисах, недооценивая момент значительного, как предположено в докладе, экспоненциального роста сложности.
По моему опыту, есть два варианта, почему такое происходит. Один, когда архитектор хорошо знает именно такую архитектуру и изначально закладывает ее в каждый свой проект не особо задумываясь о необходимости. Происходит как в анекдоте про проктолога, который удалял гланды через задний проход. Никто не ставит под сомнения скилы такого специалиста — они у него несомненно имеются. Но зачем?
Другой, когда кто-то (а часто и весь тим архитекторов во главе с бизнес начальством) в компании, где-то прослушал доклад на тему 'очередная панацея' и, окрыленные услышанным, не имея вообще никакого опыта (все же так просто и очевидно было в докладе на слайдах!), принимается решение — внедрять. Зачем? почему? как? — по ходу разберемся. Вероятность успеха в таком случае — примерно как выиграть в лотерею.
0
Немного обидно было про 85 проектов за год и везде одно и тоже. Мы зашли сразу с ориентиром на Kubernetes и без 20k dns запросов :)
0
34 микросервиса на слайде. У нас их ~350 и я не вижу как это все работало бы на монолите (или что сейчас аутсорсеры продают).

«Навыки команды первичны» это 100%. Но причем тут Kubernetes и микросервисы? Buzzwords anchors?
0
Но причем тут Kubernetes и микросервисы? Buzzwords anchors?

Тут я вынужден просить прощения — доклад изначально планировался больше про эксплуатацию и про Kubernetes, как и обычно… а получился больше про архитектуру. Кажется я сказал об этом в начале. В любом случае прошу простить.

+2
34 микросервиса на слайде. У нас их ~350 и я не вижу как это все работало бы на монолите (или что сейчас аутсорсеры продают).

Разве в тексте статьи сказано, что всегда и все должны использовать монолиты?
У нас как раз проект типа того, что на слайде — интернет-магазин. И да, вполне успешно живет всего на 3 сервисах. Kubernetes используется для reliability
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.