DevOps не горит
前往频道在 Telegram
Девопс не горит — канал про инфраструктуру, Kubernetes, Observability и Platform Engineering. Продакшен, интересные инструменты, инженерные грабли и немного конференционной движухи. Иногда всё-таки горит =) Связаться с автором - @mrgreyves
显示更多518
订阅者
无数据24 小时
+17 天
+730 天
正在加载数据
吸引订阅者
十一月 '2611月 '26
十一月 '260
在0个频道中
十月 '26
+188
在2个频道中
Get PRO
九月 '260
在2个频道中
Get PRO
八月 '260
在1个频道中
Get PRO
七月 '260
在0个频道中
Get PRO
六月 '260
在3个频道中
Get PRO
五月 '260
在0个频道中
Get PRO
四月 '260
在0个频道中
Get PRO
三月 '260
在0个频道中
Get PRO
二月 '260
在0个频道中
Get PRO
一月 '260
在0个频道中
Get PRO
十二月 '250
在0个频道中
Get PRO
十一月 '250
在0个频道中
Get PRO
十月 '250
在0个频道中
Get PRO
九月 '250
在0个频道中
Get PRO
八月 '250
在0个频道中
Get PRO
七月 '250
在0个频道中
Get PRO
六月 '250
在0个频道中
Get PRO
五月 '250
在1个频道中
Get PRO
四月 '250
在2个频道中
Get PRO
三月 '250
在0个频道中
Get PRO
二月 '250
在0个频道中
Get PRO
一月 '250
在0个频道中
Get PRO
十二月 '24
+8
在0个频道中
Get PRO
十一月 '24
+36
在0个频道中
Get PRO
十月 '24
+19
在0个频道中
Get PRO
九月 '24
+65
在1个频道中
Get PRO
八月 '240
在0个频道中
Get PRO
七月 '240
在1个频道中
Get PRO
六月 '240
在0个频道中
Get PRO
五月 '240
在0个频道中
Get PRO
四月 '240
在0个频道中
Get PRO
三月 '240
在0个频道中
Get PRO
二月 '24
+210
在1个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 01 十一月 | 0 |
频道帖子
Коллеги, всем привет! =)
Сегодня у нас новый подкаст, а говорить в нем мы будем про «ИИ-агенты вместо DevOps: куда пропал n8n и кто удалил 148 DNS-записей в проде?»
Кажется, сейчас из каждого утюга нам рассказывают, что AI вот-вот заменит инженеров =)
Сам найдет проблему, сам разберет инцидент, сам напишет Terraform, сам задеплоит в прод
Красота! Что может пойти не так? =)
На DevOops 2026 Евгений Дехтярев будет рассказывать про то, как он взял open-source фреймворк Paperclip и собрал целую команду из шести виртуальных агентов: SRE, FinOps, Reviewer и не только
!!!НО!!!
Мы-то помним, что еще совсем недавно Женя рассказывал про автоматизацию инфраструктуры при помощи n8n и визуальных no-code кубиков =)
А теперь в новом докладе n8n куда-то таинственно исчез…
Ииии у нас появились вопросы =)
Куда делся n8n?
Почему low-code автоматизацию решили поменять на агентов, написанных на коде?
Сколько на самом деле стоит поддержка всей этой красоты?
И главное — насколько хорошая идея дать AI-агенту ключи от инфраструктуры и сказать: «Ну ты там разберись»? =)
Поэтому в восьмом выпуске DevOops Podcast мы решили немного попрожаривать Женю и поговорить не только про красивую сторону AI-агентов, но и про то, что происходит, когда они встречаются с настоящим продом
Обсудим:
• куда пропал n8n и почему от него в итоге отказались
• что использовать вместо него
• где заканчивается автоматизация и начинается новый Shadow IT
• можно ли вообще доверять AI-агентам инфраструктуру
• ну и, конечно, кто и зачем удалил 148 DNS-записей в проде =)
В общем, сегодня в 16:00 по МСК будем выяснять, наступило ли будущее, в котором DevOps больше не нужен, или теперь DevOps просто должен присматривать еще и за командой AI-агентов =)
Подключайтесь!
Трансляция будет: на YouTube и VK Видео
| 2 |  Коллеги, всем привет! =)
Мои коллеги из коммуникаций сделали шоу «ПРОДАКТовая корзина»
Ииии, вышел второй выпуск, который как раз-таки нам с вами будет интересен =)
В этом выпуске много AI, но не в формате «мы прикрутили LLM к чат-боту и теперь у нас AI» =)
AI-агенты — больше чем инструменты, которые просто отвечают на вопросы. Они сами ставят эксперименты, распоряжаются бюджетами и ищут товары =)
Обсудили AI-lab, где агент уже выступает не советчиком, а экспериментатором
Посмотрели на Cloudflare Wallets, где агент может самостоятельно контролировать свой бюджет
Ну и куда же без роботакси, персональных цен и немного безумного ритейла, где магазин постепенно превращается в склад, а склад — в магазин =)
В общем, технологий много, тем для холивара тоже хватает =)
А обсуждают всё это:
• Сева Ловкачёв — стендап-комик и голос обычного пользователя
• Артём Петренко — CPO Магнит Плюс
• Александра Прокшина — руководитель Security Development, Авито
• Антон Сачков — CTO MAGNIT OMNI
• Даниил Гаврилов — руководитель научной лаборатории T-Банк AI Research, специалист по LLM
Формат получился достаточно бодрый: новости, обсуждения, споры и попытки разобраться, что из всего этого действительно интересно, а что можно смело отправлять в мусорку =)
В общем, если вам интересно посмотреть, куда сейчас движутся AI, продукты и ритейл — рекомендую глянуть =)
Посмотреть вы можете на: Youtube и VK Video
Ну и коллегам отдельное спасибо за формат ^_^
Подписывайтесь на их канал — там про продукты, технологии и ритейл MAGNIT OMNI Team | 324 |
| 3 | Коллеги, всем привет! =)
Открываю рубрику «Мама, твой сын вайб-кодер!» =)
У меня давно в голове крутилась идея сделать некоторого агента мониторинга, который бы периодически проверял «соседей» и сам им говорил, что с ним все ок
У вас может возникнуть резонный вопрос: а зачем все это?
Отвечая словами поэта - «Все переплетено»
Инфраструктурные домены, про которые я много раз рассказывал в своих докладах, ооочень сильно связаны друг с другом, и нам важно знать, что у соседей все хорошо =)
Причем важно знать это в обе стороны
Из этой проблемы/идеи и появился «Привет, сосед!» =)
«Привет, сосед!», или hello-neighbor, решает достаточно простую задачу — следит за тем, что с соседними инфраструктурными доменами все в порядке
Вы можете задать вопрос: у нас же есть blackbox-exporter, настрой его и не парься
И в некотором роде вы будете правы =)
Blackbox-exporter прекрасно отвечает на вопрос: «Могу ли Я достучаться до X?»
Но мне хотелось отвечать еще на один вопрос: «А может ли X достучаться до МЕНЯ?»
Потому что связность не всегда симметрична
Мы можем прекрасно ходить в соседний инфраструктурный домен, а он к нам — уже нет Где-нибудь поменяли ACL, настройки огнестенки, маршрутизацию — иии привет =)
Отсюда и появилась идея сделать проверку именно между соседями
Каждый hello-neighbor одновременно клиент и сервер: сам ходит к соседям и запоминает тех, кто приходит к нему
Причем для входящих соседей работает автоматическое обнаружение — достаточно, чтобы сосед хотя бы один раз пришел к нам, после чего мы его запомним и начнем следить, не пропал ли он
Получается примерно так:
domain-A → domain-B — работает
domain-B → domain-A — НЕ работает
И мы об этом узнаем =)
Ручная конфигурация тоже никуда не делась. Список соседей можно заполнить в любимом нами YAML-формате и раскатить при помощи GitOps хоть вообще на все инфраструктурные домены =)
На выходе получаем метрики в формате Prometheus и готовые алерты на всякие неприятные ситуации:
- сосед перестал ходить к нам;
- мы перестали ходить к соседу;
- связь стала асимметричной;
- изменился сетевой маршрут.
Ну и дополнительная КИЛЛЕР-ФИЧА — ICMP-диагностика =)
Кроме HTTP-проверок можно отдельно смотреть RTT, потерю пакетов и количество хопов до соседа
Причем HTTP и ICMP специально живут отдельно
ICMP может быть запрещен совершенно легально, поэтому его проблемы никак не делают соседа «мертвым»
А вот изменение количества хопов уже интереснее
Если вчера до соседа было 5 хопов, сегодня стало 9, а latency внезапно выросла — кажется, у нас появилась зацепка, куда смотреть =)
Можно включить и полноценный traceroute, чтобы посмотреть, как именно изменился путь.
Репозиторий доступен по ссылке
Enjoy =)
PS1 — пойду, что ли, разверну его где-нибудь =)
PS2 — с пожеланиями/предложениями приходите в репозиторий или приносите свой PR =) | 431 |
| 4 | Коллеги, всем привет! =)
Сегодня продолжаем записывать наш DevOops Podcast, внезапно! =)
В этот раз гостем будет Григорий Кошелев, который в прошлом году на DevOops рассказывал про Observability распределенных систем.
Иии тема мне особенно близка =)
Я тоже рассказывал про Observability распределенных систем, правда со своей стороны, своим опытом и своими граблями.
Поэтому сегодня предлагаю немного вернуться назад и поговорить о том, как вообще строится Observability больших распределенных систем и что происходит с красивыми архитектурными схемами после встречи с продом =)
Метрики, логи, трейсы, тысячи сервисов, алерты, инциденты — поговорим о том, как во всем этом не утонуть и действительно понимать, что происходит с системой.
Обсудим прошлый доклад Григория, что изменилось за прошедший год, какие решения действительно работают, а какие оказались не такими прекрасными, как казалось изначально.
Ну иии немного заглянем в будущее =)
На DevOops 2026 Григорий готовит новый доклад:
DORA metrics: a story of failure
Доклада еще не было, поэтому сегодня мы его немножечко поспойлерим =)
Поговорим о том, почему после попытки научиться измерять распределенные системы возникает желание измерить еще и эффективность инженерных процессов.
И почему с Kubernetes, кажется, иногда разобраться проще, чем с людьми и процессами =)
Так что сегодня будет много Observability, немного DORA и, надеюсь, много интересных инженерных историй.
Подключайтесь сегодня, 18 сентября, в 18:00 МСК к прямой трансляции на Youtube!
Иии конечно, задавайте вопросы прямо во время эфира =)
Enjoy =) | 453 |
| 5 |  +2DevOops 2026
Коллеги, всем привет! =)
Возможно, вы знаете, что я член программного комитета DevOops Conf
Ииии мы готовы! =)
Конференция пройдет 12–13 октября в Санкт-Петербурге
Мы подготовили для вас крутейшие доклады: от AI для инженеров до жидкостного охлаждения GPU, от Kafka в k8s до мок-собеседований
Мои ребята, которым я помогал в подготовке, будут рассказывать про Kafka в Kubernetes со Strimzi: от хаоса к контролю, Сломаться или стать сильнее? Зарисовки инцидентов c K8s в инфре MWS Cloud , Каскадный деплой в GitOps: два подхода на FluxCD
Привет, Ваня, Дима, Кирилл =)
А еще мы с Серегой проведем Fails Talks, который в прошлом сезоне всем ооочень понравился =)
Приходите, будет интересно =)
Enjoy =)
ЗЫ — за билетами по специальным условиям можно прийти в лс к @cherry_tok =) | 558 |
| 6 | Обновление k8s 1.33⇒1.34
Коллеги, всем привет! =)
По старой доброй традиции раз в квартал мы с коллегами обновляем наши k8s-кластеры.
Третий квартал не стал исключением. Обновлялись мы с версии 1.33 до 1.34.1.
Проверили совместимость при помощи Pluto, проблем не обнаружили.
К слову, обновление прошло гладко.
Правда, через небольшое количество времени заметили, что метрики PV испарились.
Оооочень неприятная история, так как у нас есть некоторое количество stateful-сервисов.
Пошли разбираться и нашли вот такое issue на GitHub
Если вкратце — ну пропало и пропало, метрики в альфа-версии =)
Метрики вернули в версии 1.34.2.
НО, когда мы обратились в саппорт с вопросом: «Как бы нам обновиться до 1.34.2, потому что метрики PV нам важны?»
Ответ был в духе: «Обновляйтесь до 1.35, там всё работает».
Решили не рисковать и перед обновлением проверили issues для 1.35.
И нашли очередной прикол, связанный с exec-пробами.
Проблема в том, что когда pod завершается, его пробы с типом exec перестают работать, и это напрямую влияет на graceful shutdown.
Мы решили перестраховаться и накидали простенький bash-скрипт для поиска сервисов с exec-пробами.
По итогу получили список, который почти полностью состоял из вспомогательных сервисов, напрямую не оказывающих влияния на бизнес.
Решили обновиться, так как метрики PV нам важнее.
Обновились также без проблем.
И за месяц на 1.35 проблем не обнаружили =)
Мораль сей басни — перед обновлением уточняйте, на какую конкретно версию вы обновляетесь, в том числе патч-версию.
Глазами или при помощи ИИ-агента проверьте открытые issues для этой версии — это определённо будет не лишним =)
Enjoy =)
PS — Ииии нас уже более 500, чему я очень рад! Пора придумать какую-нибудь активность =) | 538 |
| 7 | Коллеги, всем привет! =)
На подходе очередной выпуск DevOops Podcast, к слову, пятый по счёту =)
Подкаст пройдет 28.08.2026 в 18-00 МСК
На подкасте мы встретимся с Дмитрием Баскаковым и обсудим его прошлогодний доклад «Kafka в K8s — это просто!»
Также к нам присоединится Кирилл Протопопов и немного поспойлерит свой доклад в этом сезоне — «Kafka в Kubernetes со Strimzi: от хаоса к контролю».
О чём будет подкаст, или чуть больше деталей:
– Просто ли «катать» сотни Kafka-кластеров в K8s
– Самые большие вызовы, с которыми столкнулись команда и компания
– Kafka в Kubernetes — зачем вообще? Где профит, а где дополнительная боль?
– Как стандартизировать сотни кластеров и при этом не превратить платформу в монстра
– Strimzi: что он действительно упрощает, а что всё равно приходится делать самим
– Обновление Kafka-кластеров без боли и страданий
– ZooKeeper → KRaft: насколько страшна миграция в реальной жизни
– Как жить с разными размерами и профилями нагрузки Kafka-кластеров
– Как мониторить Kafka и понимать, что с ней действительно всё хорошо
– Факапы, грабли и ситуации из серии «на стенде всё работало» =)
Трансляция будет доступна по ссылке: Youtube
Добавляйте событие себе в календарь, будет интересно =) | 603 |
| 8 | Коллеги, всем привет! =)
В продолжение темы про обновление Harbor и про хранение артефактов в целом.
Бороздя просторы GitHub, наткнулся на два весьма интересных проекта.
Nora — минималистичная хранилка артефактов: поддержка кучи форматов пакетов, проксирование/кеширование пакетов из удалённых хранилок, развёртывается одним бинарём. Неплохой вариант, если инсталляция небольшая.
Artifact Keeper — а вот тут уже заявка на полноценный энтерпрайз со всеми вытекающими. Модульная архитектура, хранение артефактов в S3, поддержка множества форматов, резервирование из коробки иии нативный механизм миграции из JFrog Artifactory =)
Выглядит вкусно, если нужно большое и масштабируемое хранилище =)
Коллеги, !!!заранее обратите внимание!!!: проекты достаточно молодые. О крупных инсталляциях или конкретных кейсах эксплуатации я не слышал, поэтому, если решите стать первопроходцами, учитывайте риски.
Enjoy =) | 647 |
| 9 | Коллеги, всем привет! =)
6 мая 2026 случилось поистине великое событие (да-да, пишу очень вовремя) — вышел релиз Harbor 2.15.1.
Ну обновился Harbor и обновился, а прикол-то в чем? Как будто бы вполне ризонный вопрос — а что такого великого в этом релизе?
Как по мне, всю историю существования Harbor в нем была одна серьезная проблема.
А именно: если образ в проксируемом реджестри по какой-то причине становился недоступен или сам реджестри становился недоступным — проксируемый образ из Harbor мы получить уже не могли.
Даже если Harbor его до этого успешно скачал и он физически лежал в кеше.
Был хак, когда образ из Harbor можно было получить по его хэш-сумме, но это долго и неудобно.
В 2.15.1, а если точнее — тут, эту проблему наконец-то пофиксили.
Теперь, если образ или сам реджестри недоступны, но образ уже есть в кеше — его можно получить из Harbor.
Ииии это ровно то поведение, которого лично я ждал от Proxy Cache =)
Свой Harbor мы обновляли с версии 2.12.XX, с проверками на каждом этапе.
Обновляться стоит по порядку и точно не забывать про резервное копирование PostgreSQL, потому что с каждым обновлением проходят новые миграции БД.
Enjoy =) | 768 |
| 10 | Коллеги, всем привет! =)
Ранее я рассказывал про BSA-модель, к которой я часто обращаюсь в своих докладах.
Оригинальный пост вы можете найти по ссылке.
Иии 13 марта мы с коллегами из Flant провели вебинар, на котором подробно разобрали, как устроена модель, её плюсы и как она ложится на инфраструктуру.
Не забыли подсветить особенности и корнер-кейсы =)
Запись вебинара доступна тут: Youtube, Rutube, Dzen, VKvideo
Enjoy =)
ЗЫ1 — про DevOops Podcast: отдельный пост про то, где можно посмотреть запись, делать не буду — запись доступна по тем же ссылкам =)
ЗЫ2 — про DevOops Podcast: готовим следующие выпуски, stay tuned =) | 611 |
| 11 | Коллеги, всем привет! =)
Пришло время прервать молчание и начать писать посты регулярно. Как и обещал… ага-ага =)
За прошедшие 6–7 месяцев много чего произошло, и, кажется, пришло время обо всём этом рассказать.
Возможно, вы знаете, что я являюсь членом программного комитета DevOops Conf.
Ииии… мы с коллегами запустили небольшой подкаст =)
В подкаст мы приглашаем спикеров конференции, обсуждаем их доклады с DevOops Conf 2025, задаём неудобные вопросы, смотрим, что изменилось почти за год, и думаем, куда движемся дальше.
Мы уже провели три подкаста:
* DevOops Podcast #1 // «Битва кодовых ассистентов»
* DevOops Podcast #2 // Инженер: куда уж дальше? Есть ли жизнь после сеньора?
* DevOops Podcast #3 // Смерть классического IDP и восстание машин
Тема следующего подкаста:
Day 2 Operations: Как ломалась и крепла архитектура MWS Cloud на базе K8s и SaltStack
О чём поговорим?
* 💀 Смерть Immutable Infrastructure? (Боль идеалиста)
* 🔨 K8s как молоток, а весь мир — гвоздь (Истинная цена «дешёвой» инфраструктуры)
* ⚡ Некромантия или прагматизм: почему SaltStack?
* 💥 Blast Radius (радиус поражения) и ночные кошмары
* 🏗️ Platform Engineering и внутренний заказчик
* 🐤 Факапы и мёртвые канарейки
Подкаст состоится уже в эту пятницу, 07.08.2026, начало в 18:00 МСК.
В онлайне вы сможете пообщаться с членами ПК и спикером =)
Трансляция будет доступна здесь: Youtube, VK Видео
Добавляйте в свои календари =)
Ссылку на запись выложу немного позже ^_^ | 767 |
| 12 |  Коллеги, всех с прошедшими праздниками! ^_^
Хотел написать данный пост ещё в понедельник, но руки дошли только сейчас.
Начало года — всегда самая любимая пора,
потому что это всегда обновление каких-нибудь сертификатов и всякое такое, регулярно, но нечасто.
Самое весёлое в этом сезоне — это то, что EdgeCDN перестаёт предоставлять услуги CDN для Yandex Cloud, и всех просят мигрировать на Yandex CDN, коим мы сейчас и занимаемся.
Инструкция облака в целом исчерпывающая, а если у вас инфраструктура как код, то проблем возникнуть не должно.
Единственный момент — это как проверить работоспособность нового CDN?
А сделать можно это следующим образом.
Если вы шли строго по инструкции, клонировали ранее созданный CDN для своего доменного имени, вы получили CNAME нового CDN.
Там будет что-то вида 123123abcd.topology.gslb.yccdn.ru
После этого вам нужно узнать IP-адрес этого CDN, в этом нам поможет dig.
dig +short 123123abcd.topology.gslb.yccdn.ru
После того как мы получим IP-адрес (представим, что это 1.2.3.4), мы сможем собрать примерно вот такой curl:
curl -vvv --resolve my-awesome-service.ololo.ru:443:1.2.3.4 https://my-awesome-service.ololo.ru/
После его выполнения вы сможете проверить работоспособность нового CDN.
Enjoy и всем лёгкой первой трудовой недели ^_^
PS - а зачем проверять то? Инструкция от облака описывает чуть-ли не автомиграцию
"прЕкол" заключается в том, что замена CDN подразумевает замена CNAME для основого домена ради которого CDN и поднимается/настраивается
Любые работы с DNS, особенно в проде, несут ряд рисков и определенно стоит проверить все заранее
PPS - новый CDN будет "не прогретый", то есть в нем не будет кэша, по этому в моменте вы получите увеличение нагрузки на сервис за CDN до момента пока кэш "не прогреется" | 1 132 |
| 13 |  BSA-модель
Коллеги, всем привет! =)
В своих докладах я довольно часто делаю отсылку к модели BSA (base-service-app), и порой меня спрашивают: «Откуда она вообще взялась?»
Впервые я познакомился с этой моделью в 2019 или 2020 году, когда трудился в E42 (кто знает — тот знает).
Модель BSA хороша тем, что она достаточно явно описывает связь «условного» бизнес-сервиса с необходимыми зависимостями (БД, кэши, очереди и т. д.) и инфраструктурой.
Как говорил классик: «Всё переплетено».
Давайте по порядку.
Базовый слой — это слой инфраструктуры, и именно тут разворачивается наше приложение. Это не просто условная ВМ или кластер Kubernetes — это ещё и необходимая инфраструктура: мониторинг, логирование, трейсинг и дополнительные компоненты.
Сервисный слой — это необходимые вспомогательные сервисы. Наше бизнес-приложение наверняка хранит какие-то данные, ему нужны кэши, а возможно, и очереди.
Слой приложения — это уже само бизнес-приложение.
Благодаря такому разделению удобно работать с зависимостями. Например, мы так выставляли priority class для базового слоя.
Enjoy! =) | 1 076 |
| 14 | Коллеги, всем привет!=)
У DevOps Conf 2026 идет call for papers
А это значит, что если у вас есть о чем рассказать - самое время подать заявку
Ссылка на CFP - https://cfp.devopsconf.io/
Прием заявок до 24 ноября 2025!!!
Ключевые темы:
— Эксплуатация LLM
— AI-Driven Engineering: практики, риски и трансформация разработки
— Как сократить косты на инфраструктуру?
— Цифровые иммунные системы и инженерия надёжности (это SRE и новый термин оттуда)
— Про разработку для системных инженеров
— Требования регуляторов на простом русском
— Базовые практики работы и про то, почему они по-прежнему важны
Буду ли я подаваться с докладом? Да еще не решил, надо бы подумать, вдруг в закромах найдется что-то интересное =) | 916 |
| 15 | Как я стал фронтендером vol.2
Коллеги, всем привет! =)
Ранее я писал о том, как при помощи ИИ «заводил» техрадар (ссылка на первый пост: https://t.me/devops_not_burn/111).
Чем мне помог ИИ???
Начнём с того, что я ни разу не фронтендер, и иногда мне бывает сложновато сформулировать запрос.
Задача была достаточно простой — используя какое-то мейнстримовое решение, завести свой техрадар.
Первый ИИ — ChatGPT 5 с платной подпиской.
В целом, он помог всё базово запустить. На всё про всё ушло порядка часа.
Плюсы:
— быстрые ответы;
— хорошие базовые рекомендации.
Минусы:
— половина рекомендаций — мимо;
— ChatGPT 5 «не видит», что происходит на фронте.
Далее я воспользовался Claude Sonnet 4 в режиме агента — и вот тут стало гораздо интереснее.
Claude Sonnet 4 в режиме агента самостоятельно всё верстал и проверял.
Плюсы:
— всё сделано более-менее (всё-таки есть некоторое количество вопросов к решениям).
Минусы:
— сразу держите в голове, что вы общаетесь с джуном.
Если с фронтом ИИ-агент всё накручивал, то с инфрой я несколько раз его останавливал, потому что он творил откровенную дичь.
Какие выводы я могу сделать?
Для быстрого старта — вполне ок.
НО, как я уже не раз говорил в кулуарах:
«Если вы совершенно не шарите в теме, в которой просите помощи у ИИ — скорее всего, вам стоит приготовиться к страданиям и дебагу».
Я не противник ИИ. Я человек, который относится к нему как к помогатору, а не как к замене «кожаных мешков».
Enjoy =) | 959 |
| 16 | Как “сломать” всю команду в пятницу?
Коллеги, всем хорошей пятнички! =)
Как сломать всю команду в пятничку?
Достаточно скинуть во внутренний чатик вот эту ссылку https://floor796.com/ 😂😂😂
Этаж 796 - здоровнннннная гифка с каким то невероятным количеством отсылок к фильмам, играм, мемам и всякое такое
Enjoy, а найденные отсылки вы можете скидывать в чатик =)
ЗЫ - уже встречал эту гифку давно, и не давно накнулс в канале Макса и заностальгировал | 1 224 |
| 17 | Коллеги, всем привет! =)
Поговорим про 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 вы можете почитать тут
Надеюсь мой пост поможет вам стать более надежными ^_^ | 160 |
| 18 |  Вижу что мои слайды вам нравятся🤣
Подкину еще один
Знаете что за мем, ставите - 🔥
Не знаете, но вам понравилась картинка - 👍 | 200 |
| 19 | Коллеги, привет! =)
Готовлюсь к внутреннему митапчику и буду рассказывать как мы считаем DORA-метрики
Есть у меня такой слайд
Как вам?=)
Если понравился и ты понял о чем он, ставь - 🔥
Если не понял, ставь - 👍
Ну и всем хорошего понедельника ^_^ | 206 |
| 20 | Что там с 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 и я об этом точно напишу =) | 345 |
