Памятка: как определить, нужен ли вам Kubernetes?
 Публичный пост

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

Сегодня я попробую ответить (в первую очередь для себя, конечно) на вопрос: "А так ли нам нужен kubernetes?"

Забавно, что отношение к k8s у меня достаточно смешанное - я работаю с ним каждый день и неплохо понимаю как он устроен (как мне кажется - даже ресурсы свои для него пописываю), но иногда бесит прям. Тем не менее, как человек, который делал разные проекты с SOA, микросервисами и прочим (иногда все вместе), спешу поделиться радостной новостью: кубернетс нужен, но не всем.

Для себя я составил что-то типа чеклиста, по которому прохожусь каждый раз когда обсуждаю проекты внутри компании.

1. Тип системы

Если у вас много стейтфул компонентов, то ваш кластер будет выглядеть как пачка stateful sets, что не особо отличается от VMWare vSphere по факту, только в контейнерах и с большим геморроем (никогда не удаляли Persistent Volume Claim не у того сета? Я вот удалял). А вот если у вас уже построено все в stateless стиле, но вы еще почему-то не в кубернетсе, то можно и задуматься. Хотя ведь были причины почему вы еще не там?

2. Тип ворклоада

Вот тут уже сложнее. Дело в том, что по большому счету у кубернетса два преимущества:

  1. Возможность выкатывать относительно сложные релизы без отказов в обработке существующего ворклоада.
  2. Легко масштабировать кластер под эластичный ворклоад.

Так вот, если первое можно решить руками (ansible, chef, vagrant, просто скрипты на питоне каком), то со вторым уже сложнее - можно делать руками teeproxy или организовывать все через MQ, что иногда приводит к шапочному переделыванию половины системы. И тут мы должны себя спросить - а у нас точно ворклоад имеет такой характер или мы собираемся обслуживать плюс-минус 10к пользователей и не ожидаем роста.

3. Доступ к кластеру у DevOps

Итак, если у вас нет доступа к кластеру - забудьте. Нет, серьезно, по надиктованным логам ингресса или kubelet вам будет сложно понять что все-таки пошло не так. Кубернетс любит, когда опсы его могут потрогать в любой момент, когда очередная абстракция над сетью даст сбой.

4. Кто владеет кластером

Вроде бы это то же самое, что и предыдущий пункт, но на деле вас тут за жопу может взять лигал вы можете оказаться в неприятной ситуации и потерять интеллектуальную собственность. Помните, что когда отдаете контейнер и в базовом контейнере GPL, то это distribution (так считает FOSS и американские юристы) и ваше роскошное приложение может стать достоянием общественности, поэтому выбирайте базовый имадж правильно. Мы вот отдаем заказчикам RedHat UBI, себе деплоим на пролетарском CentOS или Debian.

Чтобы было понятнее, вот что пишет VMWare на тему:
https://blogs.vmware.com/opensource/2019/04/18/tracking-container-image-licenses/

А вот что пишет Red Hat:
https://developers.redhat.com/blog/2019/10/09/what-is-red-hat-universal-base-image/

Ну и, наконец, от linuxfoundation:
https://www.linuxfoundation.org/blog/2020/04/docker-containers-what-are-the-open-source-licensing-considerations/

Если деплоите систему заказчику (например, не в свою подписку AWS или Azure), используйте образы, которые в лицензии явно разрешают distribution.

5. Готовы ли вы менять процессы под деплой в k8s

Вам нужен gitops воркфлоу. Желательно с каким-нибудь нормальным шаблонизатором (helm3, например). Править руками YAML (один из худших форматов для конфигов) или делать шаблонизацию sed'ом можно, но вы этого не хотите.

Я, конечно, совсем поехавший и у меня в VCS практически все уже, кроме пдфок и документов в ворде, но когда у нас anything as a code, то гиты и прочие перфорсы неизбежны.

6. Оцените операционный контекст

Подумайте о том что вам нужно для эксплуатации. Например, о требованиях к управлению трафиком внутри кластера, о DMZ и прочем. К сожалению, я частенько вижу ситуации, когда люди согласны на Дикий Запад у себя в кластере, а потом данные утекают непонятно куда. А голый k8s - это как раз и есть тот самый Дикий Запад, поэтому народ придумывает istio и изобретает все что уже было, но теперь банановое.

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

Аватар Mikhail Aksenov
Mikhail Aksenov @thecoldwine
Винстон Вульф в команде разработки, решаю все проблемыHalliburton AS
📍Ставангер, Норвегия

Есть аккаунт в твитторе - thecoldwine и инстаграмчик mikhail.aksenov

19 комментариев 👇
Никита Карпухин, Fullstack, но ближе к бэкенду 2 июня 2020

Я думал внутри будет одна строчка "не нужен" и все :с

  Развернуть 1 комментарий
Artem Golovin, Consulting engineer 2 июня 2020

Я себе развернул персональный K8S в GKE потренироваться, да и скинуть все свои пет-проекты в одно место.

В целом, штука не такая уж и страшная, и во многих вещах — удобная. К тому же, становится стандартом почти во всех проектах, куда я прихожу, поэтому приобретенные знания — и возможность самостоятельно поковырять деплой меня очень радуют. Девопсы-то люди занятые ;-)

Лучше уж немного замороченный, но единый у всех подход к инфраструктуре, чем когда каждый пилил свое собственное колесо.

Единственный для меня серьезный минус — это высокая стоимость самого "базового" кластера. Мой плейграунд выходит под €60 в месяц всего с тремя инстансами, отдельной базой и лоад-балансером… Мой предыдущий dokku сетап на двух машинах обходился всего в €20.

  Развернуть 1 комментарий

Можно сократить расходы до €25, развернув кластер в Hetzner/Scaleway с помощью, например, kubespray.

Из плюсов: более глубокое погружение в администрирование k8s и как оно там всё работает внутри (это же и минус)

Минусы: нужно будет руками настроить volume storage подсистему, но если у тебя всё stateless, то этот пункт можно пропустить.

  Развернуть 1 комментарий
Anatoly Shipitsin, Специалист по НЕХ 3 июня 2020

А я думал тут будет написано конечно надо и все ПО надо класть в контейнеры!

  Развернуть 1 комментарий
Mark Volosiuk, Full Stack Engineer 👨🏻‍💻 3 июня 2020

Есть ли сейчас в сообществе конценсус по поводу developer expirience'а? Какое-то время уже не слежу за трендами, помню уже наплодилось инструментов, интересно узнать мнение людей, которые более тесно с этим столкнулись

https://garden.io
https://tilt.dev/
https://www.spinnaker.io
etc

  Развернуть 1 комментарий

Я не думаю, что есть консенсус. Конкретно в моей команде helm и gitops воркфлоу. Работает это примерно так:

  1. Ты делаешь сервис, описываешь helm-chart в специальном репозитории.
  2. Для каждой среды есть так называемые liverepo, в котором лежат настройки конкретной среды и liverepo подключен к CD серверу. Соответственно там же обновляются версии образов, переменные окружения и т.п.
  3. Когда все на месте разработчик идет и тыкает кнопку "deliver" в CD. Процесс обновления делается вручную, чтобы была возможность предупредить тестеров, что стенд может быть нестабилен и в целом занимает меньше времени, чем сборка система.

Когда нужно делать перенос из QA в UAT или в Production мы просто делаем diff между репозиториями и обновляем сооветствующий liverepo и снова идем на шаг 3.

Кажется, что процесс довольно сложный, но у него есть несколько преимуществ:

  1. Когда все в VSC я могу быстро отследить какая конфигурация работает, а какая - нет.
  2. Аккуратные шаблоны в helm'e позволяют делать чарты буквально за 10 минут и для конкретной среды тебе только файлик с общими настройками нужно менять (конкретные переменные окружения), поскольку в helm можно делать многоуровневые конфиги, которые применяются по очереди.
  3. После настройки всего не нужен выделенный девопс - разработчики не ходят в kubectl, а работают с интерфейсом CD.

Из мониторинга мне очень нравится NewRelic, который умеет почти все что нужно, хотя kubectl все еще нужен и я слабо верю, что есть тулза, которая его полностью убирает.

  Развернуть 1 комментарий

@thecoldwine, Спасибо, но меня больше интересует все что происходит до кнопки "deliver"
Как поднимать проект, бутстрапить все локально, ассеты, прокси, вот это вот все.

Если уж совсем упрощать, то я хочу чтобы когда я провожу онбоардинг, был какой-то условный make setup-dev-env после которого новый инженер может прямо открывать свой любимый редактор/ide и комиттить в проект, без потраченого дня на чтение устаревающего README.md и лишней головной боли на установку/настойку всех зависимостей.

  Развернуть 1 комментарий

@MarchiMartius, ну, тут я вижу два варианта:

  1. Написать свой скрипт или сделать шаблонные проекты (мы плюс-минус так и делаем: есть maven archetype для джавы и шаблоны контейнеров под node.js и python flask).
  2. Попытатсья использовать готовые штуки по типу https://github.com/foundweekends/giter8 или https://yeoman.io/.

Например, для студентов я когда-то делал такой шаблон: https://github.com/thecoldwine/tsnode-template и это было удобно именно потому что они просто клонировали реп и делали все что надо уже сами.

p.s. для меня работает условный bash-history первого сетапа складывать в скрипт, который я потом чекиню в репозиторий с шаблонным проектом. То же самое я делаю с лоад тестами, которые вырастают из интеграционных тестов параллельно разработке. В итоге постепенно вырисовывается воркфлоу и полезные практики, а вся шелуха, которую я додумал вначале, отваливается.

  Развернуть 1 комментарий

На одной из конференций общался с докладчиками один был из RedHat, второй из HashiCorp и оба сказали что если есть возможность то всегда-всегда брать managed k8s, а не развораичвать самому :)

  Развернуть 1 комментарий

Иногда может хотеться запретного, например гетерогенный (win+lx) кластер, а GA в Azure AKS был только в мае.

А вообще разделяю, кубернетс руками тот еще геморрой и в итоге может быть дороже managed service.

  Развернуть 1 комментарий

@thecoldwine, мне сейчас для небольших проектов вообще больше AWS ECS нравится, проще и дешевле выходит.

  Развернуть 1 комментарий

@luvs, Затащили с коллегами мелкий проект в AWS EKS. Пока все очень даже нравится.
Просто придерживаюсь правила, что в кубере не должно быть никакого стейта. База отдельно, файлики на s3

  Развернуть 1 комментарий

А кто что думает про swarm? https://docs.docker.com/engine/swarm/

  Развернуть 1 комментарий

сворм скорее мертв чем жив, если хочется чего-то маленького для оркестрации, то можно глянуть hashicorp nomad. Если проект совсем маленький и помещается на 1 сервер, то compose. А так k8s всех победил и имеет смысл тратить силы на изучение его

  Развернуть 1 комментарий

@luvs, есть еще k3s для любителей.

  Развернуть 1 комментарий

@thecoldwine, да вариантов много на самом деле, мне поиграться Kind больше всего понравился.

  Развернуть 1 комментарий

Для тех кто хочет поизучать k8s и покопаться как оно работает, можно арендовать в selectel железный сервер с 2 xeon + 24 gb ram (2200 руб/мес), развернуть там 8-10 виртуалок в kvm и развлекаться.

  Развернуть 1 комментарий

А можно и minikube локально поднять, нет?

  Развернуть 1 комментарий

@rozhok, да можно и не только minikube, есть еще k3s, kind, micro8s. Но если хочется production-like кластер, чтобы поймать максимальное количество проблем, посмотреть как там сеть работает, разные сетевые плагины потыкать, то имхо вариант нормального кластера интереснее. Но вообще для девопсов/админов больше подходит, чтобы потом в продакшене проще было. Для разработчика микровариантов достаточно чтобы посомтреть как туда деплоить.

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб