Всем привет!

В связи с ростом подписчиков имеет смысл чуть подробнее представиться, учитывая, что до этого это был блог больше "из кейсов знакомых и для знакомых".
Хочу чуть подробнее рассказать о себе, о своем бекграунде, и каких-то специфических предпочтениях.
Также расскажу, о том, какие топики я бы хотел освещать.

Немного о себе:

🟠 DevOps Culture First.
Начём с того, что изначально мой путь виделся мне, как путь "Linux engineer"! Я копался в Linux, разбирался в сетях, бился головой, изучая, как работает инфраструктурный софт типа nginx или MySQL.
Больше всего мне нравилась автоматизация... Bash-скрипты, cron, немного Python, сама мысль, что с помощью автоматизации можно строить по-настоящему крутые и автономные системы.
При этом, мне нравилось и программировать, я разбирался в том, как работают бекенды, базы данных, как устроена большая разработка.
Пока рос я и мои компетенции, развивалась и сама индустрия. У нас появились контейнеры, Infrastructure as Code инструменты, и целая культура, которая призвана объеденить все то, что мне так нравится. DevOps!
Когда я услышал о DevOps впервые, кажется, я сразу же почувствовал, что это резонирует с тем, что мне искренне нравится.

Я всегда оставался сторонником мнения, что культура и процессы первичны, и только потом идут конкретные паттерны или инструменты. Я всегда старался быть get in touch с командами разработки, хоть рынок старательно пытался выделить DevOps в отдельную роль.

🟠 Kubernetes Enjoyer.
Признаюсь честно — я большой фанат Kubernetes :)
Иногда, когда ко мне приходят с проблемой X, я шучу: "Просто поставь Kubernetes — и всё будет!" Конечно, это сильное преувеличение. Но правда в том, что Kubernetes — технология, которую я искренне люблю. Видно, как она стала стандартом в индустрии. Она закрывает массу задач "из коробки", а возможности по расширению...

Немного о топиках и о том, какого рода контент здесь будет.

🟧: Разбор культурного аспекта работы DevOps и взаимодействия с командой(беки, фронты, QA, PM).
🟧: Практические кейсы из разряда: "Ко мне пришли с проблемой Х и я хочу поделиться решением со всеми"
🟧: Мои эксперименты и отражение моего пути обучения новым технологиям

Я рад видеть всех пристутствующих на моем канале!

Один из культурных аспектов DevOps — это мотивация, с которой инженеры совершают те или иные изменения.
Продвигая data-driven decisions, мы всё чаще смотрим на цифры, а не на ощущения.
Я бы хотел рассказать о четырёх основных метриках, которые двигают DevOps.
О четырёх метриках, из-за которых у вас опять перепиливаются пайплайны снова и снова.

Речь идёт о DORA метриках.
DORA – DevOps Research and Assessment
Это исследовательская группа, которая вывела 4 метрики по которым можно понять "девопсовость" команды.

Вот эти 4 метрики:
1. Deployment Frequency
Частота деплоев в прод. Больше лучше.
2. Lead Time for Changes
Время от момента, когда задача получила статус "В работе", до момента когда задача оказалась на проде. Меньше лучше.
3. Change Failure Rate
Процент деплоев на прод, которые привели к ошибкам(С какой частотой у нас падает прод после релиза). Меньше лучше.
4. Time to Restore Service.
Время, которое требуется, чтобы упавший сервис, снова начал работать. Менньше Лучше.

Именно на эти показатели ориентируются devops в своей работе.

Deployment Frequency

Девопс: У нас stage вообще не соответствует проду. Давайте за неделю стабилизируем stage.
И все изменения сначала будут попадать туда.

Стабилизация stage может повлиять на количество доставленных фич, но на самом деле
Стабильный прод -> тестирование на актуальном stage -> меньше страха -> чаще катимся в прод, быстрее доставляем фичи.

Lead Time for Changes

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

Данный пример показывает, как изменение, которое кажется наоборот замедляющим(автозакрытие MR)
Может спровоцировать ускорение ревью.

Change Failure Rate(CFR)
Процент деплоев на прод, которые завершились ошибкой.

Девопс: Нам нужно добавить endpoint /healthz
Который будет отдавать 200 OK если сервис работает корректно.

Казалось бы это не несёт никакого value, и опять какое-то странное требование, но на самом деле мониторинг этого эндпоинта напрямую влияет на CFR

Time to Restore Service

Девопс: Нам нужно добавить smoke-тесты
В случае провала которых мы будем откатывать прод автоматически

По-сути, это изменение, которое может очень сильно сократить время которое требуется, на восстановление сервиса.

Когда DevOps приходит с идеей:
- Давайте настроим stage
- Давайте добавим smoke-тесты
- Давайте перепишем пайпы
Это не прихоть и не абстрактное желание "сделать красиво".
Почти каждое такое изменение призвано улучшить одну из DORA метрик.
И такие предложения являются ответом на проблемы, которые появляются в общем процессе доставки и эксплуатации кода.

А у вас отслеживаются DORA метрики?
Как вы считаете пайпланы должны постоянно меняться/улучшаться?
Или работает и не трогаем?

Знание DevOps = рост в ЗП? Окупится ли обучение?

Количество вакансий, где требуется DevOps‑компетенция, выросло почти в  2,5  раза за последние пять  лет.
Даже чайка‑менеджеров теперь просят понимать, как выкатывать сервисы в  продакшен…

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

Антон - Senior DevOps, построивший с 0 инфраструктуру и CI/CD процессы в нескольких компаниях. Он ведет канал о популяризации девопс технологий и знает, какие навыки необходимы для заработка от 500к+ в этой сфере.

Вместе с ним мы разберемся с чем придется столкнуться человеку вкатывающемуся в девопс и выясним будут ли потраченные усилия стоить результата?

❗️Оставь свой вопрос в форме под анонсом стрима -мы обязательно на него ответим. Подписка на стрим поможет не упустить разбор конкретно твоего кейса.

Дата стрима - 31.07 в 18:00

Ужe через 30 минуток начинаем совместный стрим c JAVA GYM RAT !!!

Обменяемся взглядами на DevOps и разработку, поговорим вкате, ответим на ваши вопросики!!!🐳

Ссылка!!!

В прошлый раз мы разобрали базовую настройку кластера и доступ извне. Сегодня шагнём дальше: как сделать так, чтобы Kubernetes был наблюдаемым и приложения не теряли свои данные.

Базовый мониторинг. Grafana/Promehteus/Loki
После настройки базового доступа внешнего трафика внутрь k8s-кластера, надо заняться observability.
Наверное таким же распространенным решением для небольших инсталляций куба может являться связка: Grafana+Prometheus+Loki
Особенно, хочется отметить проект kube-prometheus-stack
Который позволяет быстро с помощью одного Helm чарта развернуть Grafana+Prometheus+AlertManager сразу.
При этом, в гарафане, уже будут доступы дашборды для отслеживания основных метрик кластера.
Отдельно, стоит рассмотреть Loki в режиме monolith и fluentbit, как легковесные обработчик и сборщик логов соответственно.
Получается простой, но рабочий стек для наблюдаемости.

Начинем хранить state. Использование PVC и делой StorageContoller
Чтобы приложения не теряли данные при перезапусках, мы настроили поддержку Persistent Volume Claims и определили default StorageClass.
В нашем случае подключены два CSI-провайдера:

- nfs-provider — для пользовательского хранения данных;
- local-storage-provider — чтобы работать с hostVolumes через PVC.

Сразу оговорюсь: такие провайдеры подходят только для dev- или около-dev-инсталляций.
Для продакшена и высоких нагрузок стоит интегрироваться с облачным хранилищем или с ЦХД, если Kubernetes развёрнут на bare-metal.
Это особенно критично для баз данных, кэшей и любых сервисов, где потеря данных недопустима.

Теперь разработчики могут получить постоянное хранилище буквально одной строкой в манифесте.

Соседи не должны мешать друг другу. Namespace ResourceQuota.

В одном кластере могут работать сразу несколько команд или пользователей, и чтобы никто не съел больше ресурсов, чем положено, мы настроили ResourceQuota на уровне namespace.
Это своего рода "лимит" на CPU, память и диски на каждый namespace.
Вот пример ResourceQuota:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: student-quota
  namespace: student-ns
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    persistentvolumeclaims: "5"
    pods: "10"

Благодаря этому, если кто-то случайно запустит слишком "жадное" приложение, оно не сможет "забрать" ресурсы у других и не вызовет проблем для всего кластера.
Так Kubernetes остаётся стабильным, а пользователи — довольными.

Особенности проекта. Ресурсы и очистка дев-стендов.

Хотя кластер вполне может работать и без этих дополнительных инструментов, нам очень помогли две утилиты — kube-janitor и krr.
Особенно это важно, когда нужно поднять кластер с множеством dev-стендов на ограниченных ресурсах.

kube-janitor

Kube-Janitor — это сервис на Python , который хоть и немного устарел, но по-прежнему отлично справляется с задачей очистки кластера.
Он читает правила из конфигурационного файла и автоматически удаляет ресурсы по заданным паттернам. Например, можно настроить удаление namespace’ов старше недели или деплойментов с названием, содержащим "test". Это помогает держать кластер чистым от мусора и освобождать ресурсы.

krr

krr — это клиентская утилита, которая анализирует метрики из Prometheus и строит отчёты по тому, насколько оптимально настроены requests и limits у приложений.
На основе исторических данных она помогает подобрать правильные ресурсы для подов, что особенно важно при ограниченных мощностях, чтобы не тратить лишнее и не столкнуться с нехваткой ресурсов.

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