DevOps не горит – Telegram
DevOps не горит
490 subscribers
37 photos
2 files
65 links
Привет!)
Я Володя @Mrgreyves
Пришло время наконец-то завести свой канал
Что тут будет: инженерка, статьи про всякие полезные штуки и мемесы
Попробую даже регулярно что-то постить ^_^
Download Telegram
Привет Yandex Scale!)
🔥162
"Кубернетис это инструмент который позволяет деплоить баги на 1000 серверов" Паша Селиванов, а это , IT Standup
😁18🤩3
Коллеги, всем привет!=)
Минутка интересных наблюдений
С командой обновили Grafana Tempo с версии 2.5 на версию 2.6
И получили следующую картину (на скриншоте)
Все компоненты Grafana Tempo при той же нагрузки стали потреблять гораздо меньше ресурсов (CPU, RAM)
Так же система, а я сейчас про поиск трейсов и визуализацию, стала более отзывчива =)
JFYI, коллеги =)
🔥21
Коллеги, всем привет!)
Готовлюсь к митапу (анонс сделаю немного позже), собираю в своем докладе все грабли/костыли/косяки которые мы ловили с мониторингом/логированием/трейсингом
И вспомнил про самый "веселый" прикол с которым сталкивался (смотри мем)
А какие интересные проблемы вы решали в своем observability?=)
😁13🔥5👏1
Коллеги, всем привет!=)
Задумался я тут о том, что пора превратить нашу Grafana в Grafana HA (это не ha-ha-ha classic, а Grafana High Abailability)
Кажется, что все достаточно просто, Grafana живет в k8s, проставишь в чарте
replicas: 3
и дело к стороне
И сразу же начинают всплывать определенные нюансы
Основной нюанс заключается в том что наша Grafana иногда отправляет алерты которые настраивали команды разработки и если просто увеличить количество реплик с ооооочень большой вероятностью мы получим х3 алертов, что не очень весело
Отправил читать документацию, HA режим для алертов доступен и может работать как с "отдельно стоящим" Redis, так и с самой Grafana
Вариант когда инстансы Grafana синхронизируются между собой, показался более привлекательным, так как нет необходимости в доп компоненте
Конфиг для Grafana выглядит следующий образом

grafana.ini:
unified_alerting:
enabled: true
ha_listen_address: "${POD_IP}:9094"
ha_peers: "grafana-alerting.grafana:9094"
ha_advertise_address: "${POD_IP}:9094"
ha_peer_timeout: 15s
ha_reconnect_timeout: 2m

Так же нам нужен сервис, что бы Grafana`ы могли найти друг друга

apiVersion: v1
kind: Service
metadata:
name: grafana-alerting
namespace: grafana
labels:
app.kubernetes.io/name: grafana-alerting
app.kubernetes.io/part-of: grafana
spec:
type: ClusterIP
clusterIP: 'None'
ports:
- port: 9094
selector:
app.kubernetes.io/name: grafana

Благодаря этому мы получаем Grafana HA, что добавляет нам "выживаемости" в случае внештатных ситуаций с инфрой
Ну и напоследок, как сказать Grafana, что бы она расползалась по разным нодам и зонам кластера

affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app.kubernetes.io/name
operator: In
values:
- grafana
topologyKey: topology.kubernetes.io/zone
- weight: 99
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app.kubernetes.io/name
operator: In
values:
- grafana
topologyKey: topology.kubernetes.io/hostname

PS - для Grafana у нас поднят отдельно стоящий кластер PG
🔥9👍621🤔1
Коллеги, всем пятнички!=)

Как то мимо меня прошла новость о том что в бету вышел Prometheus 3 (спойлер - скорее всего у вас 2.x)
Что там нового:
-- Новый интерфейс, добавили темную тему - не ну такое срочно в прод надо 💃
-- Новый интерфейс для графиков и алертов - вцелом, я всегда использовал интерфейс Prometheus для дебага чего либо, если новый интерфейс позволит делать это удобнее/быстрее - отлично =)
-- Remote Write 2.0 - многие используют remote write что бы "сливать" метрики в какую то большую хранилку, интересно что добавили отсылку exemplars и тд
-- Поддержка OpenTelemetry - а вот это уже действительно круто, так как OpenTelemetry врывается в индустрию и очень скоро станет стандартом, предполагаю что будет возможность пушить метрички напрямую в Prometheus, это точно будет удобно для каких нибудь CronJob
Чего лично мне не хватило, с Prometheus вот все хорошо, кроме потребления ресурсов, особеноо в кластерах в большим количеством сервисов, и потребление ресурсов у Prometheus просто невероятное. Если вопрос потребления ресурсов каким либо образом "порешают", будет вообще пушка-гонка-красота =)

Оригинальный пост вы можете прочитать тут

Ииии всем хорошей пятнички =)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13🔥31
Коллеги, всем привет!=)

Не так давно писал про то как мы накручивали отказоустойчивость у Grafana
И там мы использовали affinity rules
В k8s есть множество различных возможностей для управления тем как поды будут размещены внутри кластера
К примеру, у нас есть 3 зоны доступности A,B,D (особенно внимательные наверняка увидели Yandex Cloud) и нам нужно сделать так что бы 3 пода "разъехались" гарантированно по трем разным зонам, при этом если одна зона не доступна под не мигрировал в другую
Зачем - кейс с blackbox экспортером и мониторингом каких то "внешних" ресурсов из разных зон доступности, дублировать проверки из одной и той же зоны мы не хотим
Для решения этой задачи нам прекрасно подойдет Pod Topology Spread Constraints
Доп конфигурация для официального helm чарта может выглядеть следующим образом:

replicas: 3
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app.kubernetes.io/name: prometheus-blackbox-exporter


Что произойдет:
-- мы поставили 3 реплики
-- поды разъедутся по одному в каждую зону
-- если какая то зона отвалится, под будет висеть в статусе Pending

Благодаря этому поды разъезжаются по разным зонам, в случае тотального падения зоны под не переезжает в доступную зону и метрики не дублируются =)
👍5🔥51
Коллеги, всем привет!=)

Как восстанавливливать дашборды Grafana если они "внезапно" испарились?0_o
Пришли к нам разработчики с вопросом - "Мы тут наводили порядок в своей директории и парочка важных дашбордов у нас испарилась, спасите, помогите!!!"
Вцелом то ничего страшного, в качестве бекэнда у нас используется Postgresql который к слову бекапится и все такое
Подумали, что достаточно развернуть базe из бекапа, завести вторую Grafana и вытащить Json, ну а дальше его импортнуть
Но все оказалось сильно проще💻
В базе Grafana есть табличка dashboard в которой как раз и хранятся наши дашборды в Json формате, то есть поднимать вторую Grafana уже и не надо, достаточно просто "вытащить" нужный нам дашборд, а потом импортировать. Grafana у нас 11.3.0 версии, у предыдущих версий думаю хранение организовано так же
Вот так мы сэкономили немного вермени, пользуйтесь, коллеги!^_^
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥41
Коллеги, всем привет!=)
Рубрика "мамая, я в телевизоре"
23 октября выступал на Observability Days в Т-банке где рассказывал про наши приключения с Observability в Магнит Омни
Собрал большое количество различных приколов, костылей и мемов в своем докладе
Записи всех докладов доступны тут, Enjoy!

PS - сегодня будет еще один анонс, я надеюсь =)
🔥12👍41
Коллеги, всем добрый вечер!=)
Иииии очередной анонс про который я писал немного ранее
13-11-2024 буду на DevOops Conf 2024

Вместе с Иваном мы расскажем про Cluster API, что это такое, как его можно использовать, как можно катать свои k8s кластера на виртуалках и на железе, да причем тут целая куча k8s операторов

Ссылка на страничку доклада

PS - да, да, я умею не только в Observability ^_^
🔥102👍1
Привет DevOops conf 2024 ^_^
Да-да, сегодня в канале будет некоторое количество фоток с конференции =)
🔥7👍2
Поиграл в рулетку где надо рассказать про инструмент который выпадет))
Кажется организаторы что-то знают обо мне😂😂😂
😁6👍3👏1
Back to primitives, если вы понимаете о чем я)))
👍13🔥86
Расширяем возможности clusterapi.pdf
28.2 MB
Коллеги, всем отличной субботы!=)
DevOops 2024 прошел, было интересно, было много крутых докладов =)
А в этом посте я выкладываю презентацию Ивана, именно на его докладе я был тех экспертом =)
Спойлер1 - где то там, на видео, будет шутка про пшеничный смузи =)
Спойлер2 - как только появится возможножность выложить доклад, я обязательно это сделаю =)
👍9🔥72
Коллеги, всем привет =)

Небольшая заметка про 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 настроенный в режиме кэширующего прокси, он будет из коробки проксировать и артифакты =)
👍4🤔3🔥2
Коллеги, всем привет! =)

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

Зачем я это пишу - обновлял я тут defectdojo в k8s и что-то пошло не так. Посмотрел, хуки на месте, install и upgrade. Посмотрел внимательно, а хуки то post-install и post-upgrade, то есть миграции defectdojo исходя из конфига должны отрабатывать после всех действий. И все благополучно падало =)
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥73😁2👍1
Коллеги, всем привет! =)

В одном из чатиков проскочила вот такая вот штука Kafka Visualization
Softwaremill сделали наглядный визуализатор того, что происходит внутри Kafka
Можно посмотреть/понастраивать:
-- Конфигурацию топика, его репликейшин фактор и партиционирование
-- Количество брокеров сообщений (именно они хранят и обрабатывают сообщения)
-- Количество консюмеров и их группы (именно они ходят за сообщения)
Вцелом выглядит очень наглядно и будет точно полезно тем кто хочет посмотреть, а как оно там вообще =)
🔥10👍93
Коллеги, всем привет! =)
У ребят из 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 и развернуть приложение заново.
🔥8👍42
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 трейсов в секунду =)
🔥9👍3
Коллеги, всем привет!=)
От всей души поздравляю вас с наступившим Новым Годом🎄
Во многих каналах вчера подводились итоги года, у себя я это делать не стал
Лучше я напишу про планы на 2025, а "их есть меня" (с)
DevOps Conf 2025 Гибкое управление доступами для распределенной инфраструктуры - ооо, это будет весело =)
— Мы с коллегами планируем организовать большой митап основная тема которого будет связана с инфраструктурой для сервисов (да-да, ко многим из вас я буду приходить в личку и зазывать что нибудь рассказать)
— С коллегой планируем сделать подкаст про нелегкую жизнь DevOps/Platform engineer
— Думаю, что получится стать членом программного комитета одной большой конференции и сделать ее еще круче ^_^
— Надеюсь что у меня получится писать сюда больше различных, полезных заметок =)
Ииииии, это только те планы которые есть сейчас, дальше-больше =)
ЗЫ - спасибо вам большое, что остаетесь со мной, читаете мои посты, пишите комментарии =)
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥103