DevOps не горит

23 апреля встречаемся на митапе в Магнит OMNI!

Ивент, на котором инженеры, администраторы и разработчиками обсудят, как сделать инфраструктуру устойчивой к сбоям, как развивать Observability в условиях распределенной инфраструктуры и какие внутренние протоколы помогают, когда все идет совсем не по плану.

🔸 Что будет:
— Спикеры из Магнит OMNI, Лаборатории Касперского, Авито, Cloud.ru и других компаний
— Разбор болей, кейсов и решений, которые работают.
— Розыгрыш призов от Магнит OMNI.
— Живой нетворкинг.

Митап можно посетить:
— Офлайн в московском офисе Магнита,
— Онлайн

📅 Дата: 23 апреля
🕔 Время: 17:30

Не упускайте возможность узнать новое и пообщаться с профессионалами!

Подробности и регистрация — по ссылке.
#OMNI_events
@magnit_omni_team

#рубрика - помогаю коллегам найти коллег
Привет!
Я Дмитрий, Tech Product трайба платформы компании mindbox.

Ищу Senior Platform Engineer.

🎯 Основная цель:
Создание инфраструктурных сервисов как продуктов для разработки, движение к IDP (Internal Developer Platform).

📊 О нас:
- 50 миллионов транзакций в день, 400+ миллионов профилей в базах, десятки миллиардов фактов, несколько тысяч подключенных касс, с доступностью 24/7.
- 9 стоек своего железа, два цода, быстро растем по 1-2 стойке в год.
- 40 000+ ядер в Yandex.Cloud, входим в TOP10 клиентов.


🛠️ Стек::
- Kubernetes в Yandex.Cloud , а также на своем железе на Deckhouse с поддержкой от Flant
- Terraform + Ansible + Packer (переходим на Crossplane)
- с GitHub мигрируем на GitLab
- Gitlab + OctopusDeploy + Helmfile
- Prometheus + VictoriaMetrics + Grafana + AlertManager + GrafanaOnCall
- MS SQL мигрируем на PostgreSQL
- Kafka, Cassandra, Clickhouse, Redis, RabbitMQ, Mongo
- Graylog (1Tb логов в день) + Sentry + Loki
- Виртуализация HyperV (мигрируем на Proxmox)
- Other: Teleport,skupper,vault,ChaosMesh & etc

Если тебе интересна эта вакансия, то го к нам на собес 🙂
Мой контакт в Telegram: @impel1o

─────────────────────
P.S. Плюшки:

🎓 Well-being программы: 350 000 ₽ в год на образование, медицину, спорт и путешествия
🏡 Удаленка (но есть и отличные офисы в Москве и Ереване)
💻 Техника: MacBook, мониторы, наушники и другое
🏢 Работа в аккредитованной IT-компании
🎉 Корпоративная жизнь: тимбилдинги, квесты, спортивные мероприятия

(Примечение автора канала - Дима хороший, и команда у него хорошая =))

Коллеги, всем пятнички!=)
Да-да, я снова готовлю очередной доклад (парой-тройкой постов назад рассказывал о нем)
Ну и немного слайдов вам в ленту =)

Kubernetes Aggregated ClusterRole
Коллеги, всем привет! =)
Ииии у нас рубрика век-живи-век-учись ^_^
Оказывается в k8s есть Aggregated ClusterRole
Суть следующая, если вдруг нам нужно предоставить кому-то доступ в k8s, например разработчику (вооот это очень холиварный вопрос), вы конечно же можете дать ему cluster admin и дело к стороне
Но это совершенно не наш метод =)
Aggregated ClusterRole позволяет агрегировать между собой несколько ClusterRole и по итогу агрегированный ClusterRole мы сможем навесить уже на конкретного пользователя. Выглядит достаточно удобным и контролируемым
Ссылка на официальную документацию
Пример использования в интернетах

Grafana Alloy

-- Придумайте предложение со словом Alloy
-- Alloy, kto eto zvonit?

Коллеги, всем привет! =)

13-02-2025 появилась новость о том, что выходит новая версия Grafana Loki, а именно 3.4
В целом, верхнеуровнево, в новой версии нет ничего сверх привлекательного и желания резко пойти и обновиться у нас не появилось
НО, в новости есть раздел в котором явно говориться, что Promtail (а я это чуть ли не нативный логшиппер для Loki) будет помержен с Grafana Alloy. Соотвественно никаких новых штук, а только багфиксы и “сисюрити” фиксы
Мы уже смотрели на Grafana Alloy некоторое время назад, но явных причин для перехода не нашли. Теперь причины кажется есть.

Что мне нравится в Grafana Alloy - из него можно сделать полноценный Observability комбаин =)
Сейчас больше всего интересует функционал flame graph. Профилирование для гошки у нас есть уже давно, а вот какого-то централизованного профелирования - все еще нет
В общем будем-посмотреть, к тому же на рынке есть некоторое количество туллинга для профилирования, например Grafana Pyroscope и недавно вышедший Yandex Perforator

Обновили мы тут Victoria Metrics 0_о

Коллеги, всем привет!)
Обновили мы тут как то VM Operator в своих кластерах и потеряли некоторое количество метрик, речь про метрики от blackbox exporter
Минутка спойлеров ON
Зачем нам VM Operator? Смысл заключается в том, что ооогромная часть продуктов конечно же имеет метрики и в комплекте с ними идут podmonitor/servicemonitor/etc. и VM operator их конвертирует в привычные для себя ресурсы. Ну и простота развертывания VM Agent и вот это вот все
Минутка спойлеров OFF
Стали разбираться, куда пропали наши метрики? (Кстати для сбора метрик с blackbox exporter используется VMScrapeConfig)
Оказалось, что в одном из релизов были изменены следующие поля в CRD описывающей VMScrapeConfig
А именно:

Было metricsPath - стало path
Было scrapeInterval - стало scrape_interval

Иииии к сожалению, в релизах это явно указано не было, было только небольшое упоминание в Issue связанное с соблюдением конвенций =(
Версию чарта мы обновляли с 0.24.x на 0.33.x
Имейте ввиду, будьте бдительны =)

Kubectl neat

Коллеги, всем привет!)
На просторах интернета/чатиков проскочил интересный плагин для kubectl
Иногда бывает нужно получить спецификацию какого-то объекта из kubernetes в yaml формате
Конечно же мы можем выполнить команду:

kubectl get object-name 4to-to-tam -o yaml

И получить в консоль здоровенный yaml в котором помимо спецификации объекта будет большое количество мета информации об объекте (creationtimestaml, uid, etc., всякое что нам может и не понадобиться)
Kubectl neat позволяет удалить все эти поля и оставить нам более-менее чистый манифест который гораздо удобнее в случае чего разбирать/использовать
Поставляется kubectl neat как плагин или же как отдельный бинарь
Установить neat можно следующим образом:

kubectl krew install neat

Пример использования:

kubectl get object-name 4to-to-tam -o yaml | kubectl neat
### OR
kubectl neat get -- object-name 4to-to-tam -o yaml

Что-то моргнуло
Коллеги, всем привет!)
Многие из вас на своей шкуре вчера в 17-00 ощутили падение буквально всего
В нашем случае это выразилось в том, что как будто бы большая часть наших клиентов “испарилась”
Конечно же мы пошутили всякие разные шутки про DNS, BGP, уборщицу в серверной и все такое и стали следить за ситуацией и думать, а что же все таки произошло и что делать
По итогу через примерно через 30 минут “все отлегло”
На графике который я приложил видно как раз этот инцидент
Обычной историей в такой ситуации является burst нагрузка, проще говоря клиенты сидели/ждали, все починилось и они резко начали пользоваться приложением
По итогу мы получили +10к RPS к привычным RPS в это время года/суток/etc.
Burst нагрузку мы пережили без проблем, автомасштабирование и вот это вот все
В ситуациях когда по какой либо причине мы перестаем быть доступными для клиентов и потом восстанавливаемся всегда стоит учитывать burst нагрузку, что бы не прилечь снова =)

Infrastructure meetup

Коллеги, всем привет! =)
Рассказывая про планы на 2025 год я упоминал, что мы планируем сделать большой онлайн/офлайн митап посвященный инфраструктуре
Рабочее название “Infrastructure meetup”, да-да название в процессе может измениться, но суть и цель останутся неизменными
А суть и цели следующие, рассказать/поделиться опытом о:
— Построение отказоустойчивой инфраструктуры
— Chaos Engineering - тестирование отказоустойчивости инфраструктуры
— Резервные площадки и мультиклауд
— “Отказоустойчивость поверх отказоустойчивости облака”
В рамках митапа мы, сейчас я про Magnit OMNI, поделимся как устроена наша инфраструктура для бизнес сервисов и вспомогательных компонентов, как мы обеспечиваем отказоустойчивость инфраструктуры, Observability в рамках распределенной инфраструктуры, какие у нас есть вспомогательные протоколы в случае если у нас все идет ну совсем не так
Если у вас есть предложения/пожелания/темы - велкам в комментарии или в лс
ЗЫ - а еще я очень скоро начну ходить к некоторым в личку и зазывать в спикеры =)

Коллеги, всем привет!=)
От всей души поздравляю вас с наступившим Новым Годом🎄
Во многих каналах вчера подводились итоги года, у себя я это делать не стал
Лучше я напишу про планы на 2025, а "их есть меня" (с)
— DevOps Conf 2025 Гибкое управление доступами для распределенной инфраструктуры - ооо, это будет весело =)
— Мы с коллегами планируем организовать большой митап основная тема которого будет связана с инфраструктурой для сервисов (да-да, ко многим из вас я буду приходить в личку и зазывать что нибудь рассказать)
— С коллегой планируем сделать подкаст про нелегкую жизнь DevOps/Platform engineer
— Думаю, что получится стать членом программного комитета одной большой конференции и сделать ее еще круче ^_^
— Надеюсь что у меня получится писать сюда больше различных, полезных заметок =)
Ииииии, это только те планы которые есть сейчас, дальше-больше =)
ЗЫ - спасибо вам большое, что остаетесь со мной, читаете мои посты, пишите комментарии =)

Grafana Tempo - бьем рекорды, весело чиним упавшее

Коллеги, всем привет!)
#Рубрика - по горячим следам
Пятница, новый год, что еще может быть лучше?=)
В очередной раз побили рекорд по трейсам и все бы ничего, но пришлось нашему Grafana Tempo немного полежать. Ingester не пережил пиковой нагрузки, отвалился по OOM, а потом не смог стартануть. С OOM все более менее понятно, выросла нагрузка - подкинь ресурсы, но приключения только начались.

Основная ошибка у нас была следующая:

found an existing instance(s) with a problem in the ring, this instance cannot become ready until this problem is resolved. The /ring http endpoint on the distributor (or single binary) provides visibility into the ring

О чем она - Ingester и Distributor при помощи протокола Gossip Ring собираются в кластера для синхронизации, обмена информацией и балансировки нагрузки. И для Ingester кластер развалился. Ну развалился и развалился, можно все почистить и собрать заново, данные то не критичные. А как это сделать?
1 - перезапустить поды Ingester`а (ууупс, ошибка на месте =))
2 - почистить PV (Ошибка снова на месте =))
3 - пойти почитать документацию (Надо было сделать это сразу)
Оказалось что у Distibutor есть свой api через который вы сможете посмотреть “что-где-куда” и посмотреть что с Ring Status. Доступен api по следующем эндпоинтам:

#localhost в данном случае "форвартнутый" сервис k8s distibutor
http://localhost:3200/status #общий статус
http://localhost:3200/ingester/ring #Ingester Gossip Ring Status

Благодаря этому мы сможем увидеть общее состояние кластера Ingester и в случае если в кластере есть проблемные ноды Ingester`а удалить их. После этого кластер благополучно соберется снова =)
ЗЫ - на скриншоте в пике 1.33kk трейсов в секунду =)

Коллеги, всем привет! =)
У ребят из Flant вышла интересная статья про то как они решали проблему 3 way merge при развертывании ресурсов при помощи Helm.

Не то что бы я был фанатом Werf, но почитать про 3 way merger, для освежения памяти было интересно =)
Проблема кроется в том, что некоторые ресурсы могут появляться в кластере и Helm про них может сооовсем ничего не знать. Например у нас есть deployment и при помощи аннотации мы добавляем Istio Sidecar в pod нашго deployment. Обычно при выполнение helm upgrade проблем не возникает, чаще всего проблемы могут возникнуть если мы выполнили helm rollback или “стопнули” helm upgrade —install.

Как работает 3 way merge:
1 - Получаем манифесты ресурса из релиза который установлен в кластере k8s
2 - Получаем манифесты из чарта который хотим установить/обновить
3 - Получаем манифест из кластера k8s (самый спорный пункт, много думал)
4 - Собираем в кучу все 3 манифеста и мержим их
5 - Отправляем PATCH запрос в k8s

Что бы решить проблему 3WM, пришел новый механизм под названием Server-Side Apply или SSA

Он “из коробки” лишен недостатков 3WM и выполняет гораздо меньше действий с ресурсами:
1 - Получаем манифесты из чарта
2 - Отправляем PATCH запрос в k8s
Ииии у нас все работает хорошо =)

А если вы давно пользуетесь ArgoCD, скорее всего server-side apply включен у вас для большинства ресурсов =)
ЗЫ - с приколами 3WM периодически сталкиваемся, решений обычно два, отправиться править ресурсы руками внутри k8s, сделать helm uninstall и развернуть приложение заново.

Коллеги, всем привет! =)

В одном из чатиков проскочила вот такая вот штука Kafka Visualization
Softwaremill сделали наглядный визуализатор того, что происходит внутри Kafka
Можно посмотреть/понастраивать:
-- Конфигурацию топика, его репликейшин фактор и партиционирование
-- Количество брокеров сообщений (именно они хранят и обрабатывают сообщения)
-- Количество консюмеров и их группы (именно они ходят за сообщения)
Вцелом выглядит очень наглядно и будет точно полезно тем кто хочет посмотреть, а как оно там вообще =)

Коллеги, всем привет! =)

Небольшой экскурс про то как катить миграции баз данных приложений которые развернуты в k8s.
Очень часто на просторах интернетов вы можете столкнуться к тем, что катить миграции предлагают при помощи инит контайнеров в подах. План надежный как швейцарские часы, но есть одно большое НО😤
Миграции в случае использования инит контейнеров будут прокатываться всегда, например когда вы поскейлили количество подов или отработал HPA. И потенциально миграции могут приводить к локам таблиц БД, что в проде, да еще в рабочее время максимально не весело.
Как еще есть варианты?
Конечно же использовать jobs в k8s.
Суть заключается в том, что “джоба” эта такая сущность, которая может отработать только один раз. Соотвественно у нас не будет проблем с повторной накаткой миграций.
Ну сделали мы джобу, а дальше то что? Как сделать так что бы джоба отрабатывала перед началом, к примеру обновления, самого приложения?
В случае с helm нам на помощь придут helm hooks
В нашем случае, нам прекрасно подойдет pre-install и pre-upgrade.
И если вы проставите эти хуки в аннотация соотвествующих ресурсов, а мы с вами говорим про джобы, то эти ресурсы будут задеплоины первыми и уже после них будут задеплоины оставшиеся ресурсы.

Зачем я это пишу - обновлял я тут defectdojo в k8s и что-то пошло не так. Посмотрел, хуки на месте, install и upgrade. Посмотрел внимательно, а хуки то post-install и post-upgrade, то есть миграции defectdojo исходя из конфига должны отрабатывать после всех действий. И все благополучно падало =)

Коллеги, всем привет =)

Небольшая заметка про oci registry и хранения всякого внутри. Для начала давайте разберемся, что такое OCI.
OCI - это Open Container Initiative и эта организация занимается “описыванием/написанием” правил игры для разработки cloud native продуктов.
Иииии OCI реджестри как раз и использую стандарт организации.
В рамках реджестри мы подразумеваем хранение докер образов, НО если реджестри OCI совмести (назовем это так), в реджестри можно хранить хельм чарты и !!!ВНИМАНИЕ!!! файлы (файлы в дальнейшем будут называться артифактами)
Если докер образами все понятно, с хельм чартами есть некоторые различия между реждестри:
— в “дефолтном” реджестри для хранения создается индексный файл в котором описывается содержимое хельм реджестри
— в OCI совместимом его нет и формат взаимодействия отличается, например

 helm pull oci://cr.yandex/myregistry/charts/chart-name --version 0.0.1

Что там и причем тут файлы? А разбираться я начал, когда пошел реконфигурировать Trivy по мотивам вот этой истории
Выполнив стандартный докер пул из реджестри я получил ошибку

unsupported media type application/vnd.oci.empty.v1+json

И пошел разбираться. Оказалось, что Trivy хранит свои базы в условновном докер реджестри и это не просто докер образ, а просто файл, что уже интересно.
Для того что бы все таки получить “файлик” мы можем использовать oras
Выполнив команду

oras pull registry-1.docker.io/aquasec/trivy-db:2

Мы успешно скачаем последнюю доступную базу Trivy
Кстати говоря, если у вас уже есть harbor для dockerhub настроенный в режиме кэширующего прокси, он будет из коробки проксировать и артифакты =)

Коллеги, всем отличной субботы!=)
DevOops 2024 прошел, было интересно, было много крутых докладов =)
А в этом посте я выкладываю презентацию Ивана, именно на его докладе я был тех экспертом =)
Спойлер1 - где то там, на видео, будет шутка про пшеничный смузи =)
Спойлер2 - как только появится возможножность выложить доклад, я обязательно это сделаю =)

Back to primitives, если вы понимаете о чем я)))

Поиграл в рулетку где надо рассказать про инструмент который выпадет))
Кажется организаторы что-то знают обо мне😂😂😂

Привет DevOops conf 2024 ^_^
Да-да, сегодня в канале будет некоторое количество фоток с конференции =)