Знание 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 у приложений.
На основе исторических данных она помогает подобрать правильные ресурсы для подов, что особенно важно при ограниченных мощностях, чтобы не тратить лишнее и не столкнуться с нехваткой ресурсов.

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