Коллеги, всем привет! =)
У ребят из 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 и развернуть приложение заново.

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 трейсов в секунду =)

Infrastructure meetup

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

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

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

Обновили мы тут 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
Имейте ввиду, будьте бдительны =)

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

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

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

#рубрика - помогаю коллегам найти коллег
Привет!
Я Дмитрий, 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-компании
🎉 Корпоративная жизнь: тимбилдинги, квесты, спортивные мероприятия

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

Оооочень интересный дебаг
Коллеги, всем привет! =)
После небольшое затишься, очередной, надеюсь интересный пост про то как мы дебажили историю “а почему поды не разворачиваются”
Вводная: k8s 1.31, cilium, Istio, 30-03-2025 авария в я.облаке
Все началось с классического запроса от разработчика “сервисы не деплоятся, обновления не катятся”. Хммм, подумал я и пошел дебажить.
helm upgrade - отваливается по таймауту. Последствия воскресного инцидент я.облака и возможно какая то часть инфры находится в залипшем состоянии, а мы и не вкурсе. Проверил раннеры, обновил версию helm`а (чисто на всякий случай, текущая была не сильно новой) - проблема сохраняется. Хмм подумал я второй раз и решил попробовать развернуть сервис “начисто”. У сервиса в чарте сабчартом подключен redis.
Ииии redis разворачивается, а подов сервиса нет 0_о
В events совершенно ничего интересно. Посмотрел всякое, посмотрел телеметрию - ничего сильно страшного не видно. Иииии потом я вспоминаю, что deployment сервиса, на самом деле “внтури” replicaset (вы же знаете, что весь k8s - это абстракция на абстракции). Посмотрел, что там с replicaset и увидел следующее:

Warning FailedCreate 26s replicaset-controller Error creating: Internal error occurred: failed calling webhook "object.sidecar-injector.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/inject?timeout=10s": dial tcp ${istio-pod-ip}:15017: connect: connection timed out

Опппа, контроллер не может отправить вебхук в истио, что бы он добавил сайдкар в наш под. Становится интересно.
Из неймспейса проверяю связность при помощи nc, curl - все хорошо. Replicaset все еще не может отправить вебхук в истио.
Перезапускаю istio контроллер (просто делаю роллаут) и на всякий случай “пинаю” mutatingwebhook istio. Результата нет. На всякий случай “собираю” отдельный деплоймент и тестирую его в отдельном неймспейсе, что бы исключить сетевые политики, после тестирую размещение на разных нодах - результат тот же.
Ооооокай, что там у нас с cilium?
Проверяю ns kube-system и вижу что там, после “воскресных приключений”, ооочень много подов istio-operator висят в статусе containerstatusunknown. Подчищаю контейнеры и делаю роллаут подов cilium. Результат все тот же. Все кому нужно “хукануть” истио, что бы произошел инжект сайдкара не могут этого сделать.
Штош, тут мои полномочия все, оформляю критикал тикет в саппорт.
Саппорт отвечает быстро, и предлагает выполнить команду

k get ciliumnodes.cilium.io

На выходе мы получаем список нод нашего кластера, которые “входят в сеть cillium”
И видим мы там ооочень интересные вещи, а именно:

NAME CILIUMINTERNALIP 
master-a 1.1.1.1
master-c 1.1.1.2
master-d 1.1.1.2
k8s-master-a 1.1.1.1
k8s-master-b 1.1.1.3
k8s-master-c 1.1.1.2
k8s-master-d 1.1.1.2
#адреса конечно же не такие, следите за последним октетом

И первый же мой вопрос: “Чегооооо? Откуда у меня мастера в зоне С которую мы разорабрали 2 квартала назад? И почему мастеров так много если их должно быть 3?”
Естественно я уточнил, а какой мастер актуален для кластера на данный момент. Саппорт уточнил актуального мастера и рекомендовал, удалить старые. Старые мастера удалены, вебхуки работают, приложения деплоятся/обновляются, все счастливы.
Произойти такое могло, скорее всего из-за той мега аварии в я.облаке 30-03-2025 (но это не точно, так как старые мастера у меня были достаточно давно)
Мораль сего приключения такова - не забывайте, что в k8s много абстракций =)
Фан факт - коллеги с соседних бизнес доменом с таким сталкивались ранее и ответили мне быстрее чем саппорт =)
ЗЫ1 - как это можно обнаружить заранее - логи управляющих компонентов, там по идеи все должно быть видно =)
ЗЫ2 - весь пост написан от моего лица, но на самом деле нас было двое, Серег, спасибо большое ^_^
ЗЫ3 - коллеги, из соседнего домена, Дим, Макс, Лех, спасибо за помощь в дебаге ^_^

Коллеги, всем хорошей пятнички!=)
Иии, это первый гостевой пост
Глеб в своем канале пишет всякое-интересное и не только про k8s
А еще у него крутые карточки, как вот эти, вдруг вы захотите вспомнить, а как оно там работает =)