Всех с пятничкой, коллеги ^_^

Немного ранее я рассказывал про свои приключения с обновлением кластера k8s с elasticsearch на борту
Пришло время рассказать как мы обновляем кластера с нашими backend-сервисами
Какие у нас есть особенности:
- у нас есть возможность делать кластера достаточно большими, не только на момент обновления
- все backend-сервисы у нас stateless (они не хранят свое состояние), даже если у них есть RabbitMQ, Redis, etc. - об этом мы заранее договорились с разработкой. Если нужно какое то хранение состояния (база, очередь), все необходимое выносится за пределы кластера k8s и берется managed в облаке (кстати у нас Ya.cloud)

Дизайн кластеров:
- мультимастер - мастера размазаны в разные зоны доступности (A,B,C)
- минимум 2 нод группы для приложений в зонах A и B с автоскейлингом
- может быть дополнительная нод группа для “определенных” задач

Первое с чего мы всегда начинаем, это проверка “что у нас там с API k8s? нет ли чего то удаленного в API?”

Для этого мы используем утилитку pluto от FairwindsOps
После проверки:
- Все хорошо - можно смело обновляться
- Есть какие то замечания - обновляем какие то компоненты, в общем решаем проблемы с API

Обновление происходит в несколько этапов:

1 - обновляем мастера на +1 версию
2 - добавляем новую нод группу с +1 версией в нужной нам зоне (A или B )
3 - “кордоним” все ноды в кластере
4 - первую/обновляемую нод группу “фиксируем” по размеру, что бы не начали создаваться новые ноды со старой версией k8s (напоминаю что у нас автоскейлинг)
5 - “дрейним” первую/обновляемую нод группу
6 - проверяем по телеметрии что все ок и все работает
7 - при необходимости - повторяем

Не раз уже делаем так и все ок ^_^

PS - RMQ, Redis, etc. внутри k8s у нас в кластерном режиме и PV. Но относимся мы к ним все равно как к стейтлесс сервисам. И как мы знаем (надеюсь что вы знаете), PV не реплицируются между зонами я Ya.Cloud, по этому мы обновляем зону за зоной, что бы “подики” могли примонтировать свои PV.

PSS - однажды я вам расскажу про то как мы меняли сетевой плагин в кластере, спойлер - ухххх было весело =)

Что там с fluxcd?

Коллеги, всем привет!)
Проскочила тут в интернетах вот такая новость

Если вкратце - у Flux проблемы, большинство разработчиков либо ушли, либо “навострили лыжи”, в том числе и Stefan Prodan который является мейнтейнером FluxCD

И тут мы резко всей командой задумались - “А что делать если FluxCD падет смертью храбрых?”
У себя FluxCD мы используем для бутстрапа и конфигурирования k8s кластеров как основной инструмент

Пути тут, казалось бы, два:

- FluxCD - опенсорс и имеет достаточно большое комьюнити, активных разработчиков там достаточно, даже если кор мейнтейнеры уйдут, по идеи проект подхватят и он продолжить жить/развиваться
- Если FluxCD все таки “погибнет” нам точно придется искать альтернативу, и “десять девяток”, что выбор падет на ArgoCD (развивается он семимильными шагами и мы уже местами его используем)

Несмотря на то что FluxCD мы любим и умеем, периодически с ним были и свои “приколы”:

- Как же было весело когда FluxCD прыгнул из 0.4 в 2.0.0 практически без совместимости
- Зависимостями управлять там ооочень не тривиально

Как говориться посидим посмотрим ^_^

PS - ArgoCD (а точнее Argo Rollouts) мы используем в связке с Istio Service Mesh и Prometheus для организации Canary Deployment и я об этом точно напишу =)

Коллеги, привет! =)
Готовлюсь к внутреннему митапчику и буду рассказывать как мы считаем DORA-метрики
Есть у меня такой слайд
Как вам?=)
Если понравился и ты понял о чем он, ставь - 🔥
Если не понял, ставь - 👍
Ну и всем хорошего понедельника ^_^

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

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

Поговорим про 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, что бы в дальнейшем было немного проще
Ссылка на конференцию

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