Kubernetes для ретроградов.
Из обсуждений о прошлой статье рассказывал в фейсбуке курс быстрого погружения в Kubernetes для ретроградов.
Ретроград - это не плохое слово, я им сам, как инженер, ретроград - концепция "работает - не трогай", отлично подходит для сохранности системы, и, к сожалению, мешает при смене технической парадигмы.
Каждый год молодые горящие умы рассказывают о революционной вещи, которая изменит все – и 99 из 100 этих революций заканчиваются ничем. Однако одна революция, все же происходит – и вдруг, в какой-то момент, ты понимаешь, что мир изменился, а ты остался в старой парадигме. У меня есть байка про то, что надо всегда следить за собой не стал ли ты перл-разработчиком. Аргументация: “Всю жизнь писал на перле, зачем мне что-то новое? Они все одинаковые” – действительно имеет смысл для повторяющихся задач. Перл, действительно, может быть хорошим языком, но просто в один момент окажется что на нем никто больше не пишет и не создают проектов. Именно поэтому важно “оставаться живым”, не кидаться на каждую новую технологию, но следить за их развитием.
Текст из комментов, извиняюсь за стилистику. Позже напишу на Хабр детальный пост.
Часть 1: зачем нужен Kubernetes для ретроградов:
1. Если ты разработчик, который научился разработке недавно (последние годы), то скорее всего ты запускаешь приложение в докере. Считай, что докер это exe - у exe-формата может быть есть свои минусы, но никто уже об этом особо не думает.
2. Как когда-то ООП появилось для того чтобы большим командам стало проще писать большой софт, стандартом стали микросервисы. Их даже те же люди культивируют (см. Фаулера). В этом есть разум - при соблюдении версионности API приложения отдельным командам проще писать самостоятельные приложения, чем одно большое.
Зачем и маленькие приложения пишут микросервисно - можно поспорить, но и маленькие приложения в какой-то момент все стали писать в ООП-стиле, просто так привычно (см. выше про exe).
3. Таким образом, тебе надо как-то менеджерить запущенные докеры. Ты можешь это делать сам и на выделенных серверах, а можешь использовать K8S, который дают клауды - не думать о менеджменте нод, не думать о конфигурации ОС.
Ты даже базы будешь использовать клаудные - RDS/Cloud SQL позволят тебе не парить мозг про "автовакуум" и "размер буферпула в MySQL", обновления, бэкапы итп.
Таким образом, ты можешь сказать: "Стартани мне кластер из 3-х машин, а дальше по обстоятельствам сам добавляй машины в кластер, и уменьшай машины в кластере".
Ты будешь говорить "вот по такому адресу у меня лежит докер образ, раскатай его на 4 запущенных докера вот такой конфигурации", сможешь делать rollout-ы на обновления, и K8S будет тебе переподнимать упавшие докеры.
4. Кроме того есть Helm. Вот я себе сейчас на ноут хочу поставить MongoDB/ClickHouse/Prometheus/Grafana. Я поставлю щас себе K8S и, утрируя буду запускать кластер командой helm install clickhouse. Оно скачает докеры, запустит их как надо сконфигурит, и все вопросы с сетью разрулит.
Рассматривай кубик как ОС над ОС.
P.S. Собирать кубик на железе последние несколько месяцев я считаю извращением. Облачный кубик закрывает вопрос менеджмента железа, поднятия дискового стораджа, настройки самого K8S итп. Для большинства нехайлоадных задач это не нужно.
Часть 2: как погрузиться в Kubernetes для ретроградов.
“я вот сейчас в личке обсуждал курс быстрого погружения в современный стек для ретроградов (я тоже ретроград, это не плохое слово )
Наверное норм тема
1. Взять триал в гуглклауде или на яклауде
2. Взять приложение на NodeJS, упаковать его в докерфайл, научиться паковать докеры
3. Взять бесплатный план на circleci как CI-ке которую не надо ставить, конфиги похожи
4. Написать хельмчарт для апликухи, задеплоить самому
5. Задеплоить через CIку
6. Сделать CD по GitOps (см, например ArgoCD)
7. Не по порядку - описать инфраструктуру в Terraform/Pulumi”
