Event Router

Коллеги, всем привет = )
Рано или поздно, во время например дебага, мы смотрим евенты внутри k8s
Историческая справка - event это события которые происходят в namespace, например создание пода, evict и тд
Конечно же у нас есть замечательна команда kubectl get events, но ходить по кластерам и неймспейсам - нууу такое себе, да и наверняка нам хочется поискать что-то в евентах
На помощь нам приходит Event Router
К сожалению проект уже давно не развивается, но это совершенно не мешает ему приносить пользу = )
Установить Event Router мы можем при помощи helm chart от wikimedia
В values нам нужно указать какой sinks мы будем использовать (sinks - это место куда мы хотим отправлять ивенты с кластеров), в нашем случае это stdout
Пример конфигурации:

```

sink: stdout

```

По итогу Event Router соберет ивенты со всех неймспейсов и “выкинет” их из своего stdout и тут мы их соберем при помощи какого нибудь логшиппера
А поиск и отрисовка “всякого полезного” уже дело Grafana или Kibana =)

Коллеги, всем дооообрейший вечерок!=)
Прошел KuberConf`24 где у меня был доклад "Твой Observability мертв, мой тоже"
Именно оттуда был скриншот с недоумевающим Томом
У меня было несколько целей, которые я приследовал во время подготовки:
— Подсветить, казалось бы, некоторые очевидные моменты построения комплексного Observability
— Подсветить что "серебряной пули" для Observability, увы, нет и на поиск перво причин инцидента может уходить много вермени
— К сожаланию, не существует единого инструмента который закроет все потребности в мониторинге, логирование, трейсинге, etc.

Ну и мое выступление доступ на Youtube вот тут

Да-да, с фамилией там "обшиблись" ???

Saint Highload 24

Пу-пу-пу, то пишу редко, то 2 поста и почти одновременно =)
24-25 буду на конферении Saint Highload 24
Встретить меня вы сможете на стенде Magnit Tech
Буду рад всех увидеть, а еще у нас будет много разных активностей за участие в которых вы сможете получить мерч и всякие прикольные штуки
А еще будет одна секретная активность, за которую можно будет получить ооооочень “не кислый” приз =)

Observability meetup - итоги P-4 (завершающая)

Коллеги, всем привет! =)
Четвертый и последний доклад митапа от Андрея Кречетова “Мониторинг под ключ”
Интересен сам подход - как “катить” стек мониторинга в кучу кластеров
Причем кластера зачастую не просто в условном облачном провайдере, а могут быть и на baremetall
Так же интересно посмотреть на весь туллинг который применятся для деплоя кластеров (у ребят это Terraform или CAPI), ну и Rancher Fleet (вот что что, а Fleet я не ожидал увидеть совсем)
Схема взаимодействия компонентов мониторинга тоже интересная, с учетом того что кластеров может быть прям ну очень много

Ссылка на доклад с тайм кодом тут

Observability meetup - итоги P-3

Коллеги, всем привет! =)
Третий доклад нашего митапа от Анны Гобрусевой - Alerts-Registry. Одно место управления алертами
В докладе Анна рассказывает про то как эволюционировал алертинг в Ozon
Интересно то как доставляют и обновляют алерты в кластера и как появился отдельный внутренний продукт и какие задачи он решает - Alerts-Registry
Так же интересно что в Ozon в качестве хранилища используется Thanos, удобно то что он умеет в down sampling (тот момент когда на “дальнем” промежутке времени нам не обязательно хранить метрики в разрешении раз в 30с)
Работа с метриками тоже реализована “не слабо”, метрик то может быть много, а у метрик есть еще и лейблы с потенциально большим “координалити”
Доклад получился ну прям огонь ^_^

Ссылка на доклад с тайм кодом тут

Observability meetup - итоги P-2

Коллеги, всем привет! =)
Второй доклад митапа от Сергея Будникова - Трассировка: как приручить 200 тысяч спанов в секунду при помощи Grafana Tempo и искать трейсы за 3 секунды

Забавный факт - мне тоже удалось принять участие в тюнинге Grafana Tempo =)

Как обычно внезапно все поняли, что трейсов стало ооочень много и все дружно кинулись тюнить Grafana Tempo
Конечно же тюнинг начался с заливания ресурсами, но помогло это только на время
Самая интересная часть доклада о том как определить что именно тормозит (а мы помним что Grafana Tempo типичное микросервисное приложение)
В своем докладе Сергей подробно рассказывает на какие компоненты и их параметры стоит обращать внимание и как их нужно корректировать в зависимости от нагрузки
Так же результатом тюнинга стал дашборд который “отрисовывает” все “узкие” места всего Grafana Tempo стека (ссылка на дашборд в презентации)
Ссылка на доклад с тайм кодом тут

Observability meetup - итоги P-1

Коллеги, всем привет! =)
Поговорим про доклады Observability meetup который мы не так давно провели
Первый доклад от Алексея Колоскова - Как внедрить распределенную трассировку на open source инструментах
Доклад интересен тем что Алексей рассказывает про историю выбора туллинга для построения распределенной трассировки с учетом определенных ограничений
И самое интересное ограничение в том что разработка не очень хочет имплементить либы для трассировки в свой код
Конечно же в таком случае можно втащить Istio и получить трассировку и много всего интересного, НО это большой “кусок” того за чем надо присматривать
Решение оказалось достаточно простым - использование OTEL-collector который как раз за счет инструментирования (Instrumentation) позволяет формировать трейсы
Интересный подход и интересная реализация

Ссылка на доклад с тайм кодом тут

Observability meetup - итоги

Коллеги, всем привет!
На прошлой недели прошел первый митап Magnit Tech и он был посвящен Observability
Ууууух, было интересно, обычно я выступаю на митах, в этот раз я был ведущим/модератором/тамадой
Определенно это новый, интересный опыт, теперь я точно знаю каково людям которые ведут =)

Что было:
— Поговорили про трейсинг и когда разработчики не хотят имплементить либы для трассировки в код
— Как раскачать Grafana Tempo до 200к span/s
— Как устроены алерты в Ozon и про инструмент Alert-registry
— Как устроен алертинг в МТС и как его доставлять до кластеров (в том числе и baremetall)

Запись митапа доступна по ссылке
Все презентации можно посмотреть тут
Если вы были с нами оффлайн, то новые аватарки можно добыть тут

В ближайшее время, обязательно напишу обо всех докладах по отдельности, stay tuned =)

Друзья, всем привет! ^_^

Мы с коллегами делаем “Observability meetup”
Когда - 17 апреля 2024, 18-05
Кто выступает - Magnit Tech, MTC, Hilbert Team, Ozon
Темы:
— Как внедрить распределенную трассировку на open source инструментах
Спикер: Алексей Колосков, Lead DevOps в Hilbert Team
— Трассировка: как приручить 200 тысяч спанов в секунду при помощи Grafana Tempo и искать трейсы за 3 секунды
Спикер: Сергей Будников, ведущий инженер DevOps в Magnit Tech
— Alerts-Registry. Одно место управления алертами
Спикер: Анна Гобрусева, руководитель команды инструментов мониторинга Ozon
— Мониторинг под ключ
Спикер: Андрей Кречетов, ведущий инженер DevOps в МТС
Оффлайн (в нашем офисе в МСК) + Онлайн (на Youtube)
Фанфакт - наверняка вы привыкли видеть меня как спикера, а в этот раз я буду ведущим ^_^
Ссылка на регистрацию и подробная информация
Приходи лично, смотри трансляцию, будет интересно =)

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

Поговорим про DNS внутри k8s и зачем нам нужен Node-local-dns
Суть следующая:
— k8s из коробки предоставляет нам весьма удобный Service Discovery (вспомним те же самые сущности типа Service)
— все это настраивается и менеджится автоматически
— да и работает все это весьма неплохо

НО при этом мы можем схватить следующий кейс
У нас в кластере много сервисов (имею ввиду приложений), которые общаются между собой, и подов всех сервисов у нас достаточно много
В какой то момент DNS у нас просто может отказать (из-за перегруза), отказать с концами, что потенциально приведет к практически полному выходу из строя кластера (имеется ввиду что сервисы не смогут найти друг друга по доменным именам или такой поиск будет сильно затруднен)
Ииииии естественно мы однажды встряли с такой проблемой да еще и в проде ^_^
Что с этим можно сделать что бы стало хорошо и не упасть в будущем?

Вспоминаем как устроен DNS:
— authoritative DNS - самый главный DNS сервер, у которого все зоны и всякое такое
— DNS recursor (иногда его еще называют resolver) - для простоты понимания, это проксян, который ооочень быстро обрабатывает DNS запросы, может их кэшировать, и может выполнять некоторую логику, тем самым сильно разгружая authoritative DNS
Получается что в нашем случае (если у вас кубик в проде - у вас тоже ^_^) нам нужен “рекурсор”, который разгрузит kube-dns и упростит/ускорит работу с DNS для приложений внутри k8s
И тут на сцену выходи Node-local-dns =)
Он как раз и будет выполнять роль DNS recursor
У себя мы его деплоим при помощи вот этого чарта
Все достаточно просто, но есть некоторые моменты на которые стоит обратить внимание

Для начала нужно узнать адрес kube dns
Достаточно выполнить команду

```

kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}

```

На выходите мы получим ip адрес котрый нам понадобится позже
У себя мы используем cilium в качестве основного CNI, по этому в values нужно добавить следующий блок

```

config:
localDnsIp: 192.168.14.12 ##Адрес который мы получили ранее, адрес для примера
cilium: ##Создаем ciliumlocalredirectpolicies для редиректа DNS трафика
clusterDNSService: kube-dns
clusterDNSNamespace: kube-system
udp:
enabled: true
portName: dns
tcp:
enabled: true
portName: dns-tcp

```

После правки этой части values и деплоя чарта у нас появится CiliumLocalRedirectPolicy внутри кластера
Который будет выглядеть так:

```

apiVersion: cilium.io/v2
kind: CiliumLocalRedirectPolicy
metadata:
annotations:
meta.helm.sh/release-name: node-local-dns
meta.helm.sh/release-namespace: kube-system
labels:
app.kubernetes.io/name: node-local-dns
helm.sh/chart: node-local-dns-1.6.0
helm.toolkit.fluxcd.io/name: node-local-dns
helm.toolkit.fluxcd.io/namespace: kube-system
name: node-local-dns
namespace: kube-system
spec:
redirectBackend:
localEndpointSelector:
matchLabels:
app.kubernetes.io/instance: node-local-dns
app.kubernetes.io/name: node-local-dns
toPorts:
- name: dns
port: "53"
protocol: UDP
- name: dns-tcp
port: "53"
protocol: TCP
redirectFrontend:
serviceMatcher:
namespace: kube-system
serviceName: kube-dns

```

Нужно нам это как раз для того что бы редиректить DNS запросы к kube-dns сервису, туда куда нам надо, а именно в node-local-dns
Не забываем настроить дополнительные tolerations, если они у вас есть, суть в том что node-local-dns развертывается при помощи Daemonset и полагаться на мысль о том что Daemonset не реагирует на “кастомные” taints не правильно =)
После успешного развертывания скорее всего вам не составит труда навесить мониторинг на node-local-dns
Базовый дашборд, который взят из Grafana Dashboards, выглядит достаточно информативно
Ну и собственно на этом все, основная часть конфига не этом окончена =)
Более подробно как работает DNS внутри k8s вы можете почитать тут
Надеюсь мой пост поможет вам стать более надежными ^_^