Вижу что мои слайды вам нравятся🤣
Подкину еще один
Знаете что за мем, ставите - 🔥
Не знаете, но вам понравилась картинка - 👍

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

Поговорим про 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 вы можете почитать тут
Надеюсь мой пост поможет вам стать более надежными ^_^

Коллеги, всем привет!=)
4 марта буду на DevOps Conf 2024 где в 10:00 в зале Уфа
буду рассказывать как мы устроены и как сделали запуск новых новых
сервисов максимально быстрым
Ссылка на доклад тут
Кто хочет пообщаться вживую, буду очень рад =)

Коллеги, привет!)
Первый день DevOps Conf 2024, уже успел выступить, кажется что все хорошо и надеюсь что всем понравилось
Добавлю свою презентацию попозже)

Коллеги, всем привет!=)
DevOps Conf 2024 отгремел, я уже почти от него отдохнул и понемногу врываюсь в рабочие будни
Я к вам с хорошими новостями =)
20 марта 2024 в 18-00
Состоится online meetup
Где MagnitTech (я и мои коллеги) и Sbermarket Tech расскажим про всякое-интересное
Буду рассказывать как устроены наши пайплайны, как устроена выкатка сервисов, расскажу про DORA-metrics
Обязательно приходи, будет интересно ^_^
Ссылка на регистрацию тут

Коллеги, всем привет=)
Вчера прошел митап который я анонсил немного ранее
Ссылку на запись конечно же прикладываю =)

К сожалению, в последнее время пишу не так часто, увы накопилось очень много всего
Обязательно обещаю исправиться =)
В ближайших планах рассказать вам про Goldilocks и особенностях его работы с VPA, да и mattermost не обойду стороной =)

Коллеги, всем привет!)
А вот и очередная заметка на моем канальчике ^_^
В ней я рассказываю про "Златовласку" и управление ресурсами
Заодно потестировал telegra.ph как площадку для написания постов,
к сожалению объема поста уже не хватает
Приятного чтения =)

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

Мы с коллегами делаем “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)
Фанфакт - наверняка вы привыкли видеть меня как спикера, а в этот раз я буду ведущим ^_^
Ссылка на регистрацию и подробная информация
Приходи лично, смотри трансляцию, будет интересно =)

У меня был друг, и он мечтал о звезде
И фотку Гагарина таскал с собой везде...
Ребята во дворе говорили 'ненормально,
Что макет ракеты занимает пол спальни' (с)

Всех с Днем авиции и космонавтики =)
Точно знаю что многим эта тема как минимум интересна =)

Observability meetup - итоги

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

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

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

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

Вечерний пост или Docker image infratools

Периодически мне нужен docker образ с некоторым количеством тулинга что бы подебажить что-то внутри k8s, а внутри запущенного подика снова устанавливать все что понадобится максимально ну такое.
Наконец то дошли руки и я его собрал =)

Сам докер образ и его репа вот тут

Заодно немного размял пальцы с Github Actions и вспомнил почему он мне не очень нравится😂😂😂

А еще я включил комментарии, так что можем пообщаться там =)
Надеюсь образ вам пригодится, а если вам что-то понадобится - смело создавайте пулл-реквесты =)

Observability meetup - итоги P-1

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

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

Observability meetup - итоги P-2

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

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

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

Observability meetup - итоги P-3

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

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

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

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

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

Kubernetes CNI benchmark

Коллеги, всем привет! =)
Пост для любителей k8s и его CNI
Свежий benchmark популярных сетевых плагинов
Наверняка про многие вы слышали, а некоторые у вас даже используются (у меня например Cilium, а переезжали мы с Calico по определенным причинам ^_^)
Для меня Antrea стал новым CNI, ни разу до этого про него не слышал
По моим скромным ощущения на рынке сейчас доминируют Cilium и Calico
Да и показатели у них весь приличные в тестах, хотя в некоторых тестах выигрывают другие CNI

А какой у CNI? Пишите в комментах =)

Коллеги, всем привет!=)
Минутка шутка-юмора 🤣
Со всей силы готовлюсь к одному большому митапу и есть у меня вот такой слайдик
Как вам?=)
ЗЫ - анонс митапа сделаю позже, как только будет готова официальная страница =)

Kuberconf24
Коллеги, всем привет! =)
Пришло время приоткрыть завесу тайна и ответить откуда предыдущий слайд
4 июля 2024 состоится KuberConf/24
Где я буду выступать с докладом “Твой observability мертв, мой тоже”
В нем я расскажу про крайне не простой путь построения эффективного observability в “некой небольшой организации”
Подсвечу неочевидные моменты, препятствия и трудности
Ну и расскажу на что стоит обращать внимание сразу при построении observability, что бы в дальнейшем было немного проще
Ссылка на конференцию

Будет онлайн/офлайн - приходите, будет интересно =)

Saint Highload 24

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

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

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

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

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 =)