Подключаем алерты с помощью Prometheus Alertmanager

У нас настроен мониторинг, рисуются красивые графики, но мы не можем сидеть и смотреть на них целый день

Чтобы быть осведомленным о проблемах — нам нужны оповещения об аномалиях или алерты

Настраивать мы их будем с помощью компонента Prometheus Alertmanager

Погнали:

1. Добавляем 16-alertmanager.yaml. Указываем, что тут у нас будут шифрованные секреты и нужно их расшифровывать с помощью sops

2. Прописываем его в kustomization.yaml

3. Добавляем компонент — alertmanager.yaml. Он разворачивается с помощью Prometheus Operator из состава kube-prometheus-stack

Из важного — указываем имя секрета, из которого будет браться конфиг алертменеджера:

configSecret: alertmanager-config

4. Дальше берем конфиг следующего содержания

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.example.com:465'
  smtp_require_tls: false
  smtp_auth_username: "mail@example.com"
  smtp_auth_password: "суперпуперпароль"
route:
  group_interval: 5m
  group_wait: 10s
  repeat_interval: 3h
  group_by: ['alertname', 'priority']
  receiver: mail

  routes:
    - matchers:
        - severity=~critical|warning
      receiver: mail

receivers:
- name: mail
  email_configs:
  - to: 'alert@example.com'
    from: 'mail@example.com'
    send_resolved: true

Отправлять алерты будем на почту и только уровня warning и critical. Алертменеджер умеет отправлять уведомления также в телеграм и другие источники. Полный список можно найти здесь

Берем данный конфиг, записываем в файл и делаем base64 file.txt. Полученный текст вставляем в kubernetes secret config-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: alertmanager-config
  namespace: monitoring
data:
  alertmanager.yaml: |
    Z2xvYmFsOgogIHJlc29sdmVfdGltZW91dDogNW0KICBzbXRwX3NtYXJ0aG9zdDogJ3NtdHAuZXhh
    bXBsZS5jb206NDY1JwogIHNtdHBfcmVxdWlyZV90bHM6IGZhbHNlCiAgc210cF9hdXRoX3VzZXJu
    YW1lOiAibWFpbEBleGFtcGxlLmNvbSIKICBzbXRwX2F1dGhfcGFzc3dvcmQ6ICLRgdGD0L/QtdGA
    0L/Rg9C/0LXRgNC/0LDRgNC+0LvRjCIKcm91dGU6CiAgZ3JvdXBfaW50ZXJ2YWw6IDVtCiAgZ3Jv
    dXBfd2FpdDogMTBzCiAgcmVwZWF0X2ludGVydmFsOiAzaAogIGdyb3VwX2J5OiBbJ2FsZXJ0bmFt
    ZScsICdwcmlvcml0eSddCiAgcmVjZWl2ZXI6IG1haWwKCiAgcm91dGVzOgogICAgLSBtYXRjaGVy
    czoKICAgICAgICAtIHNldmVyaXR5PX5jcml0aWNhbHx3YXJuaW5nCiAgICAgIHJlY2VpdmVyOiBt
    YWlsCgpyZWNlaXZlcnM6Ci0gbmFtZTogbWFpbAogIGVtYWlsX2NvbmZpZ3M6CiAgLSB0bzogJ2Fs
    ZXJ0QGV4YW1wbGUuY29tJwogICAgZnJvbTogJ21haWxAZXhhbXBsZS5jb20nCiAgICBzZW5kX3Jl
    c29sdmVkOiB0cnVlCg==

Ну и шифруем его с помощью sops:

sops --encrypt --encrypted-regex '^(data|stringData)$' --pgp 'B1B740FC8FCA25D9BE0C118CED0FB16FAF7A8471' --in-place config-secret.yaml

5. Отключаем дефолтные правила алертов из kube-prometheus-stack, так как многие относятся к prod ready кластеру и в dev будут просто постоянно висеть и раздражать нас

6. Говорим prompp, что нужно собирать все правила алертов во всех неймспейсах и отправлять их на сервис нашего alertmanager

7. Ну и добавим одно простое правило для алертов в prometheus-rules.yaml. Если количество подов Deployment равно нулю в течении одной минуты — будем присылать алерт. Правило тут задается с помощью PromQL, в секции expr. В описании потом можно использовать все labels, которые можно получить, выполнив promql запрос

Готово! Пушим всё в репо, дожидаемся применения и проверяем наш алерт:

Отскейлим наше приложение до нулевого кол-ва реплик

kubectl -n app-example scale deployment/app-example-deployment --replicas=0

Дождемся уведомления

Отслейклим обратно

kubectl -n app-example scale deployment/app-example-deployment --replicas=1

Все прекрасно работает!

На этом цикл постов, посвященный dev кластеру почти завершен, дальше начнем готовить prod кластер

Нам осталось рассмотреть еще одну тему — обновление кластера до свежих версий k8s

Скорее всего данный процесс я продемонстрирую в виде стрима или запишу видео

Stay tuned!

PHP_INI_DIR

Я тут немного приболел, поэтому постов давно не было

Голос еще не очень нормальный, видео по обновлению куба будет позже

Ловите пока маленький лайфхак, о котором мне рассказал Валентин Удальцов

Раньше я prod конфиг в докерфайле копировал примерно так:

RUN cp /usr/local/etc/php/php.ini-production /usr/local/etc/php/php.ini

Но оказалось, что есть в PHP образах переменная среды PHP_INI_DIR и можно сделать так:

RUN cp ${PHP_INI_DIR}/php.ini-production ${PHP_INI_DIR}/php.ini

На этом на сегодня все. Не переключайтесь!

Корректный инкремент версии при публикации Helm chart

В посте про упаковку приложения в Helm chart я использовал переменную гитлаба CI_JOB_ID как patch версию чарта. Это не совсем корректно и на больших инсталляциях гитлаба там будут не очень разумные цифры

Давайте исправляться. Совместно с ChatGPT насочинял скрипт, который делает следующее:

1. Пытается получить последнюю версию опубликованного в гитлабе helm чарта приложения
2. Если мы еще ничего не публиковали — берет версию из Chart.yaml
3. Инкрементирует патч версию
4. Пакует и публикует чарт в gitlab package registry

На раннере нам потребуется утилита jq (Она доступна в большинстве репозиториев популярных linux дистрибутивов) и yq (тут нужна версия 4.x, поэтому ставьте любым доступным методом, описанным в секции Installation. В репозитории вашего дистрибутива скорее всего будет 3.x)

Ну и собственно сам коммит с изменениями. Коммитим, пушим, проверяем, что все корректно работает

Enjoy!

Используем GitVersion для получения версии helm chart

В комментариях к посту про версию helm chart @ebugusey предложил считать версию из истории коммитов при публикации чарта. И посоветовал софт GitVersion

Это еще более правильный и простой способ определения версии и он не требует похода в API гитлаба

Нам понадобится скачать версию для linux x64 на машину с gitlab-runner (Или вы можете использовать docker образ), также будем использовать jq — для получения нужного нам значения из выхлопа GitVersion

Давайте вносить правки:

1. Говорим гитлаб раннеру при запуске джобы склонировать репозиторий со всей историей коммитов (Это может замедлить джобу на больших репозиториях при первом запуске)

2. Добавляем в корень репозитория конфиг для GitVersion. Взял его из примеров в документации

3. Получаем новую версию для упаковки чарта

Вот и все правки. Мы получили более стабильный вариант расчета версии, не требующий похода в API. Спасибо @ebugusey за совет

Обновление dev кластера k8s до актуальной версии

Вот наконец и дошли руки записать видео по обновлению dev кластера. На этом про кластер для разработки всё. Вскоре начнем собирать production ready инсталляцию

YouTube — https://www.youtube.com/watch?v=_C5DLcAtQMA
ВКВидео — https://vkvideo.ru/video-232188619_456239017

Пых.Конф всё ближе, свободного времени всё меньше, поэтому с постами пока затык

Раз так — буду шарить полезное от коллег. Сегодня нововведения и изменения в недавно вышедшем кубе 1.34 от компании Флант

Приятного чтения — https://habr.com/ru/companies/flant/articles/940394/

Опасные места в YAML

YAML позиционируется как человекочитаемый формат данных, но при этом это склад подводных камней. Рассмотрим самые тупые особенности, которые могут привести к неожиданным ошибкам.

Шестидесятеричные числа

port_mapping:
  - 22:22
  - 80:80
  - 443:443

Что вы ожидаете увидеть? Скорее всего, список строк для настройки портов. Но YAML 1.1 интерпретирует 22:22 как шестидесятеричное число и превращает его в 1342. В YAML 1.2 эту "фичу" убрали, но многие парсеры до сих пор используют старую версию.

Проблема Норвегии

countries:
  - dk
  - fi 
  - is
  - no  
  - se

Код страны Норвегии no будет интерпретирован как булево значение false. То же самое произойдет с off, n, yes, on, y в различных вариантах написания. Классическая ловушка, получившая название "Norway Problem".

Случайные числа

versions:
  - 9.5.25  # строка
  - 9.6.24  # строка
  - 10.23   # Число!
  - 12.13   # Тоже число!

Строки без кавычек могут неожиданно стать числами. 10.23 превратится в float, а 9.5.25 останется строкой, потому что имеет "слишком много" точек.

Ключи не только строки

settings:
  on: [push, deploy]
  priority: high

Здесь on интерпретируется как булево true, поэтому ключом становится не строка "on", а логическое значение. В JSON это может превратиться в "True" или вызвать ошибку.

Теги и небезопасность

user_data: !python/object/apply:subprocess.check_output [['rm', '-rf', '/']]

Теги, говорят, иногда полезны, но при определенных условиях позволяют выполнять произвольный код при загрузке. Всегда используйте safe_load вместо load в Python и аналогичные безопасные методы в других языках.

Получил свой первый сертификат по кубу. Теперь я сертифицированный кубовод)

Привет!
Коллеги проводят исследование, чтобы понять, что реально происходит внутри ИТ-команд и какие закономерности можно в этом увидеть.

Уже нащупаны интересные корреляции:
– между скоростью пайплайнов и качеством code review,
– между алертингом и стабильностью релизов,
– между ролями в команде и удовлетворённостью релизным процессом.

Но нужно больше данных, чтобы отделить закономерности от шума.

Пройти анкету можно за 10 минут. Её же можно использовать как мини-чек-лист для самооценки зрелости инженерной культуры.

Принять участие: https://forms.gle/NszR7VDuXL9sBbVAA

P.S. Вчера прошел сам, довольно интересно будет посмотреть на результаты, коими обязательно поделюсь, после того как ребята завершат исследование

P.P.S. Довольно давно не выходило моих постов про инфру — подготовка идет полным ходом. Скоро возобновлю регулярные посты про кубер в проде

Создание production кластера kubernetes под управлением Talos Linux

Начинаем цикл видео про production ready k8s кластер

YouTube — https://youtu.be/_QwJRZa52QU
ВКВидео — https://vkvideo.ru/video-232188619_456239018
Ну и буду прикреплять к посту в Telegram

Видео будут выходить примерно раз в 2 недели, так как их создание требует гораздо больше усилий, чем написание поста.
Иногда буду разбавлять другими темами

P.S. Забыл в видео удалить токен после flux bootstrap. Не забудьте это сделать!

Полезные ссылки и информация, которые вам потребуются при просмотре видео:

Proxmox terraform provider. Документация по добавлению пользователя для terraform

Репозиторий с конфигами для terraform

Установка talosctl

Установка kubectl

Установка helm

Установка flux

Talos Image Factory

Установка cilium в кластер talos

Flux Bootstrap Gitlab

Доклад про Talos от Дмитрия Рыбалки

Список разрешений для пользователя terraform:

SDN.Use, VM.Monitor, Datastore.AllocateSpace, VM.Clone, VM.Allocate, VM.Config.Options, VM.Config.Memory, VM.Config.HWType, VM.Config.CPU, VM.Config.Cloudinit, VM.Config.Disk, VM.PowerMgmt, Datastore.Audit, VM.Config.Network, VM.Config.CDROM, VM.Audit

.terraformrc:

provider_installation {
  network_mirror {
    url = "https://terraform-mirror.yandexcloud.net/"
    include = ["registry.terraform.io/*/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

Команда для flux bootstrap:

GITLAB_TOKEN=<токен> flux bootstrap gitlab \
  --owner=<repo_group> \
  --repository=<repo_name> \
  --path=cluster \
  --hostname=gitlab.example.com \
  --components-extra='image-reflector-controller,image-automation-controller' \
  --read-write-key \
  --deploy-token-auth

Процесс обновления Talos Linux

YouTube — https://youtu.be/ikiPtVs78YI
ВКВидео — https://vkvideo.ru/video-232188619_456239020

Команды, которые вам потребуются:

Просмотр списка доступных нод — kubectl get nodes -o wide

Обновление Talos — talosctl -n <ip ноды> upgrade -i registry.example.com/talos:1.11.3

Talos Dashboard - talosctl -n <ip ноды> dashboard

Обновление image в конфигах Talos — sed -i "s|factory.talos.dev/metal-installer/6adc7e7fba27948460e2231e5272e88b85159da3f3db980551976bf9898ff64b:v1.11.2|registry.example.com/talos:1.11.3|" *.yaml

Поднятие локального docker registry — docker run -d -p 5000:5000 --restart always --name registry registry:3

А вот и результаты опроса подъехали!

А вот и аналитика по инженерной зрелости компаний(статья на хабре), в которой многие из вас участвовали.
Помните мы устраивали опрос?
Большое спасибо всем кто принял в нем участие.
Ответ каждого из вас сделал эту статью более глубокой и честной.

А вот вам выводы для затравки
1) Для роста нужно не геройство, а системность
2) мы релизим так же хреново как ведем документацию. (такая вот авторская интерпретация подтвержденная цифрами)

притяного чтения)

PS. спасибо ребятам осуществлявшим информационную поддержку, без вас результаты были бы в разы скромнее)

Смотрю интересный стрим от ребят из Cozystack. Присоединяйтесь!

https://www.youtube.com/watch?v=hl9LMcxg1qM

Последние недельки на работе выдались тяжелые, поэтому я пока не подготовил новые посты для вас. Но предлагаю посмотреть интересный доклад.

Я уже упоминал на канале такой продукт, как Cozystack. Давайте смотреть как же он устроен.

https://www.youtube.com/watch?v=fzA3WxoZFYg

Устанавливаем Flux через Flux

Сегодня будем переводить Flux под управление его же самого. Чтобы у нас был настоящий GitOps

YouTube — https://youtu.be/023CIvGaDTA
ВКВидео — https://vkvideo.ru/video-232188619_456239021
Текстовая версия — https://etherlord.org/posts/переводим-fluxcd-под-управление-fluxcd/

Коммит с изменениями в рамках этого поста — тык сюда.

С наступающим!

Пора подвести итоги года. Они на картинке :)

Всех с наступающими праздниками!

Декабрь был трудным, потому ничего не писал. Надеюсь после праздников возобновить регулярные посты и продолжить цикл по production ready k8s

Удаляем FluxCD манифесты, которые были созданы при первоначальном бутстрапе

В этом году было достаточно сложно раскачаться и войти в рабочий ритм. Но у меня получилось :)

Первый пост в этом году будет маленький, как дополнение к предыдущему.

После того как мы перевели Flux под управление самого себя — была забыта одна вещь. А именно — нам нужно удалить старые манифесты, которые записал Flux в репозиторий, когда делался первоначальный bootstrap. Они нам теперь не нужны.

Исправляемся — коммитим, пушим, убеждаемся, что все работает.

Путь миграции с flux bootstrap на flux operator описан в официальной документации flux operator. То, что мы сейчас делали описано в разделе Cleanup the repository

На след. неделе будем передавать Cilium под управление Flux