Comments 11
"Следующий шаг — перенос проекта, который был предварительно создан мной на GitHub, в GitLab для дальнейшей настройки конвейера CI/CD"
А вы пробовали с GitHub Actions?
Есть мнение, что кубернетес слишком дорого использовать (ведь нужен выделенный человек для обслуживания кластера), если в проекте меньше чем 15-20 сервисов. Так ли это?
Вполне себе возможно, что подряд-компания будет дешевле в долгосрочной перспективе на небольших проектах, но и проекты то разные. Где-то - "настроил и забыл", а где-то "новые фичи и новые сервисы непрерывно".
На мой взгляд, да. Не знаю, считать ли сервисы, или программистов, но в целом верно. Кубернетес - сложная система, ее надо изучать, настраивать, поддерживать, отлаживать.
"You need to have a million dollar problem to use Kubernetes" - https://twitter.com/changelog/status/1383491406618980364
Kubernetes -- это скорее реализация принципа Private Cloud (с возможностью временные/пиковые нагрузки размещать в Public Cloud).
Поэтому я бы в вопросе заменил 2 термина:
не проект, а организация, т.к. большая часть преимуществ -- это замена кластеров виртуальных машин на кластера K8s с еще большей стандартизацией / централизацией.
важно не кол-во сервисов (15-20), а кол-во вычислительных ресурсов. Уже где-то от 200 vCPU (3 сервера с 4 CPU по 20 vCPU/10 core) имеет смысл использовать K8s.
В целом, зависит от организации: если есть потребность в своих серверах (от 1000 vCPU) (тем более если уже есть сервера виртуалок), то имеет смысл принять стратегический курс на переход на K8s: сначала все новые системы запускать на нем, а затем постепенно старые перевести (аргументировать такой переход -- отдельная статья). Так же если организация занимается разработкой корпоративных систем, то имеет смысл, т.к. заказчики уже просят адаптированные системы и нужно иметь опыт такой эксплуатации. Если организация хостится в публичных облаках на постоянке, то лучше использовать провайдеров VPS без всяких K8s.
По поводу выделенного человека: все зависит от кол-ва изменений в кластерах и чем именно человек будет заниматься. Если только поддерживать уже работающее, то нужно 2 человека на инциденты, т.е. обычные сисадмины должны изучить и этот инструмент (не новые люди). Если на уровне приложения подготавливать все необходимые ресурсы, то обычно это делает команда разработки/внедрения. Это относительно разовые вещи: можно запросить у разработчика решения, можно аусорсить. Если сами разработчики и много команд, то можно взять выделенного человека, который бы помогал всем по очереди. В целом, все дополнительные затраты -- это на переобучение людей (ведь и раньше разворачиванием систем кто-то занимался) и перевод на новый механизм деплоя. Если делать с нуля и обученными людьми, то не вижу каких-то дополнительных затрат. Это как переезд на любую другую технологию.
Еще добавлю, что K8s в отличие от VM предъявляет дополнительные требования к самим приложениям (и за счет этого как многие плюсы, так и костыльные внедрения): не использовать протокол NFS, поддержка горизонтального масштабирования, поддержка относительно небольших экземпляров (до 8 vCPU), поддержка K8s-совместимых метрик и логов, явное описание работы с файлами (куда пишется, что, сколько), поддержка работы с одним IP. Это основное: бывают и более мелкие требования, и костыли для обхода перечисленных.
Недавно мой коллега писал статью как раз про сравнение Kubernetes self hosted и aas https://habr.com/ru/company/mailru/blog/559370/
Возможно вам будет интересно
Спасибо! Мне понравилась статья: всё конкретно и по делу. Прямо DevOps рецепт с расписанным CI/CD, со вскрытием "магии" и без ванили. Понятие "60 минут", конечно, утрировано, но от этого статья не хуже :)
Вы серьезно?
Космический корабль, чтобы просто запустить АПИ?
Запуск проекта в Kubernetes за 60 минут