Как каждый уважающий себя человек, который провел достаточно много времени с определенной технологией, я ищу способ выплеснуть боль поделиться ценными знаниями с сообществом.
Сегодня я попробую ответить (в первую очередь для себя, конечно) на вопрос: "А так ли нам нужен kubernetes?"
Забавно, что отношение к k8s у меня достаточно смешанное - я работаю с ним каждый день и неплохо понимаю как он устроен (как мне кажется - даже ресурсы свои для него пописываю), но иногда бесит прям. Тем не менее, как человек, который делал разные проекты с SOA, микросервисами и прочим (иногда все вместе), спешу поделиться радостной новостью: кубернетс нужен, но не всем.
Для себя я составил что-то типа чеклиста, по которому прохожусь каждый раз когда обсуждаю проекты внутри компании.
1. Тип системы
Если у вас много стейтфул компонентов, то ваш кластер будет выглядеть как пачка stateful sets, что не особо отличается от VMWare vSphere по факту, только в контейнерах и с большим геморроем (никогда не удаляли Persistent Volume Claim не у того сета? Я вот удалял). А вот если у вас уже построено все в stateless стиле, но вы еще почему-то не в кубернетсе, то можно и задуматься. Хотя ведь были причины почему вы еще не там?
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 и изобретает все что уже было, но теперь банановое.
В заключение, этих шести пунктов может быть недостаточно, чтобы принять решение, но как задел "на подумать" они вполне подойдут.
Я думал внутри будет одна строчка "не нужен" и все :с
Я себе развернул персональный K8S в GKE потренироваться, да и скинуть все свои пет-проекты в одно место.
В целом, штука не такая уж и страшная, и во многих вещах — удобная. К тому же, становится стандартом почти во всех проектах, куда я прихожу, поэтому приобретенные знания — и возможность самостоятельно поковырять деплой меня очень радуют. Девопсы-то люди занятые ;-)
Лучше уж немного замороченный, но единый у всех подход к инфраструктуре, чем когда каждый пилил свое собственное колесо.
Единственный для меня серьезный минус — это высокая стоимость самого "базового" кластера. Мой плейграунд выходит под €60 в месяц всего с тремя инстансами, отдельной базой и лоад-балансером… Мой предыдущий dokku сетап на двух машинах обходился всего в €20.
У кубера может быть сильная кривая обучения, и на то что бы вкатиться может уйти пара месяцев (и потом анлим на то что бы обучить команду с ним нормально работать)
Конечно есть проблемы (но решаемые):
но в целом кубер дает кучу профита:
p.s. для сохранения единообразия процессов я бы даже для однонодовых vps рассмотрел варианты k3s и других вариантов
как бы ресурсов не сильно много потребляет (меня всегда удивляет как при нынешних зарплатах в it бизнес иногда жмотиться доплатить 5$ за более мощный сервак)
А я думал тут будет написано конечно надо и все ПО надо класть в контейнеры!
Есть ли сейчас в сообществе конценсус по поводу developer expirience'а? Какое-то время уже не слежу за трендами, помню уже наплодилось инструментов, интересно узнать мнение людей, которые более тесно с этим столкнулись
https://garden.io
https://tilt.dev/
https://www.spinnaker.io
etc
Увидел в твиттере анонс курса по куберу от Слёрм: https://slurm.io/kubernetes-for-developers-school
Стартует 1 октября, условно-бесплатный (платите персональными данными).
Записался, чтобы систематизировать обрывочные знания.
Для тех кто хочет поизучать k8s и покопаться как оно работает, можно арендовать в selectel железный сервер с 2 xeon + 24 gb ram (2200 руб/мес), развернуть там 8-10 виртуалок в kvm и развлекаться.
На одной из конференций общался с докладчиками один был из RedHat, второй из HashiCorp и оба сказали что если есть возможность то всегда-всегда брать managed k8s, а не развораичвать самому :)
А кто что думает про swarm? https://docs.docker.com/engine/swarm/