Kubernetes networking или «сеть в кубернетесе»

Несу вам полезную статью моего коллеги Георга Гаала, основателя и CTO AEnix.

🛡 В ней он рассказывает про сетевую подсистему Kubernetes и как разобраться, какой CNI-плагин выбрать для production-кластера. Глубоко разбирает лидеров рынка Calico и Cilium и делится опытом, как решить типовые проблемы с CNI.

➡️ Познакомиться со статьёй — по ссылке.

Готовы результаты исследования State of DevOps Russia 2025

Это крупнейший ежегодный срез состояния DevOps-индустрии в России, который показывает, как изменились команды, инструменты и практики за последний год.

Главные выводы:

➡️ Эффективность команд выросла

Для продуктивных команд характерны: обратная связь, удобный инструментарий и бОльшая автономия.

➡️ Роль информационной безопасности усиливается (кто б сомневался 😌)

77 % специалистов применяют инструменты ИБ, у 2/3 они уже встроены в пайплайны. Почти 3/4 используют решения на базе искусственного интеллекта, чаще всего для генерации кода.

➡️ Продолжается переход на российское программное обеспечение

Растёт доля пользователей отечественных дистрибутивов Kubernetes и операционных систем.

🛡 В документе — конкретные данные о том, как работает индустрия сегодня. Можно сравнить практики своей команды с рынком, определить направления развития и понять, какие навыки наиболее востребованы.

▶️ Скачать полное исследование можно на сайте Экспресс 42.

Самый ожидаемый вывод 😌

Давно с коллегами говорим о том, что навыки безопасности нужны всем, кому есть, что защищать. А это не только ИБ-специалисты, это и DevOps, и SRE, и руководители.

15 ноября стартует интенсив «DevSecOps Bootcamp», на котором эксперты из Лаборатории Касперского и Positive Technologies расскажут, как внедрять безопасность во все этапы разработки, чтобы снижать риски и ускорять релизы. Все подробности — на сайте.

Зачем шатать инфраструктуру

Тема управляемой деградации критически важна для современных систем. Проведение учений по отказу инфраструктуры позволяет не просто тестировать отказоустойчивость, а проактивно выявлять слабые места.

🟠Компания Netflix — самый известный пример в этой области. Вместо того, чтобы ждать реального сбоя, они решили намеренно инициировать проблемы. Для этого они создали инструменты:

➡️ Chaos Monkey — случайным образом отключает виртуальные машины. Его цель — привить инженерам культуру проектирования, при которой выход из строя любого отдельного узла не влияет на пользовательский опыт.

➡️ Chaos Kong — симулирует отказ уже целого региона. Это позволяет отработать механизмы автоматического переключения трафика на другие регионы и подтвердить общую устойчивость системы.

Неочевидные проблемы, выявляемые такими учениями⬇️

▶️ Каскадные сбои и скрытые зависимости
Наиболее опасная категория проблем. Отказ одного сервиса может инициировать цепочку сбоев из-за межсервисных зависимостей.

▶️ Тестирование алертов
Имитация сбоя — это, прежде всего, проверка систем мониторинга. Зачастую выясняется, что алерты настроены неверно, критические метрики непонятно где смотреть или дашборды не позволяют быстро определить root cause в условиях реального инцидента.

▶️ Проверка взаимодействия людей
Внезапное падение части системы — лучший тест на эффективность общения между разными командами. Учения показывают, насколько быстро и корректно команда:
— определяет владельца проблемы;
— начинает применять ранбуки и проверяет их актуальность.

▶️ Ошибки конфигурации и неверные лимиты
Сбой может привести к резкому росту запросов на другие сервисы. Это, в свою очередь, может вызвать их штатное отключение из-за рейт лимитов, circuit breakers, outlier detection и прочих механизмов, призванных снизить влияние отказов на систему. Учения помогают выяснить, корректно ли настроены эти механизмы.

Помимо постоянного внедрения проблем (chaos engineering), как практикует Netflix, есть и другой подход: выполнять учения вручную. К ним абсолютно нормально готовиться 1-2 месяца, собирая все детали сервисов, что будут зааффекчены, и планируя сценарии отката.

Сталкивались с такими подходами в своей практике?

Амстердам в тумане, очертания домов теряются в дымке.

Так же неопределённо выглядит сейчас будущее многих IT-специалистов. Рынок меняется. По словам HR-экспертов, рекрутёры захлёбываются в волне откликов: 200+ резюме на вакансию за сутки стали нормой.

➡️ Как остаться конкурентоспособным на IT-рынке в этих условиях? Развивать навыки, которые будут критически важны завтра. Например, добавить в свой CV DevSecOps — один из самых востребованных и дефицитных скиллов 2025 года.

DevSecOps — это возможность за счёт грамотного подхода к безопасности ускорить релизы и снизить риски до 70%.

🟣 На интенсиве «DevSecOps Bootcamp» вы узнаете, как встраивать безопасность в каждый этап, чтобы она стала не препятствием, а вашим конкурентным преимуществом.

Старт 15 ноября. Подробнее про интенсив — здесь.

P.s. Качая софты, не забываем про харды 😉

Вебинар «Container Storage Interface (CSI): как Kubernetes работает с томами»

Базы данных, кэши, брокеры сообщений — сегодня в Kubernetes запускают всё. Но за возможность работать со state приходится платить сложностью управления томами и системами хранения.

Без CSI мы бы до сих пор заливали кастомные плагины в ядро кубера и молились, чтобы ничего не сломалось при обновлении. А CSI превратил работу с персистентными томами в предсказуемый инженерный процесс.

13 ноября, в 20:00 мск мы с Константином Неумоиным, разработчиком Go в компании «Флант», встретимся на вебинаре, чтобы обсудить:

➡️ зачем Kubernetes понадобился CSI и какие боли старых плагинов он закрыл;
➡️ как устроена архитектура CSI: основные и sidecar-компоненты;
➡️ какой жизненный цикл тома: от создания PVC до его удаления;
➡️ как происходит выбор узла для создания тома и зачем нужны ресурсы вроде CSINode.

Будет особенно полезно разработчикам 👌

🟠 Занять место в первом ряду — по ссылке

Котятки, у меня потрясающая новость — сегодня в 11:00 в Слёрме запустится распродажа со скидками 50%!

🔥 На моей памяти это первая акция с таким размахом, не воспользоваться ею просто преступление. Механика простая: каждые 3 часа открывается новое окно скидок.

Промокод на курсы по Kubernetes будет действовать с 14:00 до 17:00.

➡️ Если вы не успели/не смогли принять участие в прошлых потоках, сейчас это можно сделать за полцены.

Кроме этого, на сайте можно выбрать курсы по DevOps, SRE и другим направлениям — также сэкономив половину стоимости обучения. Ну мёд же? 😌

Распродажа будет идти 11 часов — в 22:00 все промокоды автоматически сгорят.

🟠 Все подробности — тут.

Как говорить с бизнесом о безопасности на языке денег?

Донести руководству необходимость внедрения нового инструмента/подхода/технологии не всегда легко. Особенно когда речь идет о безопасности — сфере, где угрозы кажутся неочевидными до первого инцидента.

Запугивание рисками не работает. Бизнес живет в условиях неопределённости и постоянно чем-то рискует. Здесь нужен другой подход: считайте стоимость простоя и потери данных. Говорите на языке избежания убытков и оптимизации затрат.

Простой пример:
✅ Внедрение автоматического сканера в CI/CD стоит X руб./мес.
✅ Один час простоя нашего сервиса из-за инцидента стоит Y руб.
✅ В прошлом квартале было 3 инцидента, на устранение которых ушло Z часов.
✅ Инвестиция в сканер окупится за N месяцев за счёт сокращения времени на исправление.

➡️ Всё это — часть философии DevSecOps, где безопасность становится драйвером эффективности, а не тормозом.
Интенсив по 😏😏😏, где вы на практике научитесь встраивать безопасность в процессы, стартует через 3 дня.

Забрать его за полцены можно сегодня, с 17:00 до 20:00
Промокод на скидку: SMART_ENGER

🔥 Занять место с выгодой

Поздние алерты и тормоза API

Вижу, вам интересно решать задачки с подвохом. Приготовил следующую.

🟣Ситуация:

Команда payment-service столкнулась с жалобами пользователей: API при оплате заказа стал отвечать с заметной задержкой. Раньше платежи проходили «мгновенно» (100-200 мс), а сейчас выполняются по 2-3 секунды.

В это же время алерты сработали только через 15 минут после первых пользовательских жалоб.

Изучаем дашборды:

➡️ метрика http_request_duration_seconds_p95 показывает рост только спустя ~10 минут после начала проблемы;
➡️ CPU и memory на pods выглядят стабильными;
➡️ логов с ошибками (5xx) нет, но видно рост количества queue_wait_time_seconds . Сервис обрабатывает платежи через очередь, поэтому метрика важна для понимания длительности нахождения сообщения в очереди.

Алерт на latency был построен на базе p95 без усреднения по лейблу endpoint и с окном 10m, из-за чего срабатывание сильно запоздало.

Фрагмент метрик:

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{service="payment-service"}[10m])) by (le)) = 2.9
queue_wait_time_seconds_avg{service="payment-service"} = 4.1

Внимание, вопрос: почему алерт сработал слишком поздно, хотя тормоза начались сразу?

💯 Проблема в prometheus — scrape-интервал слишком длинный (60s).
👍 Сервис payment-service не экспортирует корректные метрики latency через OpenTelemetry.
🔥 Метрика latency агрегируется с большим окном (10m), и алерт основан на p95 без разбивки по endpoint, из-за чего сглаживаются всплески.
❤️ Alertmanager задерживает доставку уведомлений из-за неудачной конфигурации.

Ставьте смайл, который соответствует правильному варианту ответа или пишите в комментариях свой вариант, если не подходит ничего. Вечером приду с пояснениями.

🟠Пояснение:

Алерт был основан на сильно усреднённой метрике (p95 с окном 10 минут), что сгладило краткие всплески latency. Из-за отсутствия label-агрегации по endpoint отдельные проблемные ручки «растворились» в общей статистике.

Корректный подход:

➡️ использовать более чувствительные правила (например, окно в 2–3 минуты, p99 latency вместо p95);
➡️ разделять latency по endpoint;
➡️ добавить алерт на рост queue_wait_time_seconds.

Что добавите к этому?

5-часовая готовность к вебинару!

Серым ноябрьским днём лучше всего делать что? Правильно, спать.

🐈С вами Маркус, и сплю я лучше всего, когда мой человек ведёт вебинары и учит студентов.

Сегодня вечером планирую отлично выспаться — мой человек встретится с Константином Неумоиным, разработчиком Go в компании «Флант» на вебинаре «Container Storage Interface (CSI): как Kubernetes работает с томами».

Они будут обсуждать интересные вопросы для разработчиков и не только:
▶️ почему в Kubernetes решили отказаться от старого подхода и что именно улучшил CSI;
▶️ из каких компонентов состоит система и как они взаимодействуют;
▶️ путь тома от создания до удаления;
▶️ как происходит выбор узла для создания тома и какую роль в этом играет CSINode.
Я готов, а вы? Готовьте печеньки и кофе, начнём в 20:00

🛡 Ссылка для входа тут.

😄😄😄 Три, два, один… Поехали!

Подключайтесь, мы начинаем вебинар по CSI.

⚡️ Ссылка ждёт в боте.

Готова запись вебинара по CSI

Котятки, если не успели вчера на эфир, то можно посмотреть на площадках. Обсудили с Константином архитектуру CSI, жизненный цикл тома в Kubernetes, механизмы связывания с подом, топологии и ключевые сценарии.

Посмотреть вебинар в записи можно по ссылкам:
☺️Youtube
☺️ВК
☺️Rutube

Прощаемся с Kubernetes Ingress NGINX

Поддержка самого популярного ингресс контроллера прекращается в следующем году.
Если вы ждали миграции на gateway API, то это тот самый знак, что пора.

➡️Что делать?

Как можно скорее мигрировать на:
🟣Gateway API Controller
🟣Envoy
🟣Istio
🟣Traefik Gateway API
🟣HAProxy Kubernetes Gateway
🟣F5 NGINX Kubernetes Gateway

Я бы отдал предпочтение haproxy — cтаричок, что многие годы крутится в мире балансировщиков.

Как вам новости? Что выберете для миграции?

Чем занимается SRE в компании

🟣Определение SLA?
🟣Помощь с алёртами?
🟣А чем ещё ▶️ в видео

Осторожно🟣 На видео присутствуют реальные виды Амстердама, а не бездушный zoom бэкграунд, потому что в эпоху AI должно оставаться что-то настоящее.

Прочитал пост на канале Евгения Сулейманова про противников базовых знаний и понял, что мне есть, что сказать

База - она никуда не делась. Даже в эпоху AI и вайб-кодинга. Несмотря на то, что стало гораздо сложнее получать приглашения на собеседования. Несмотря на то, что фильтры в IT стали жестче, чем когда-либо. И учитывая правила игры "давай порешаем литкод", которые практикуются в процессах найма и, кажется, никуда не денутся.

Как вы честно проверите знания и опыт 100 кандидатов, не поставив всех в одинаковые условия?
А сколько часов ваших инженеров потребуется, чтобы провести эти 100+ собеседований? И в это время они не будут пилить фичи и оптимизировать косты.

↘️Подсказка: один часовой собес стоит ~ 1.5-2 часа времени. Потому что нужно еще и сформировать отчет по результатам, принять решение, идет ли кандидат дальше или нет, сделать честную оценку, порефлексировать над ответами. Да и пресловутое вырывание из состояния потока тоже много стоит в терминах рабочего времени.

А что делать, когда наняли кандидата, который ответил на всю теорию, но не может разобраться в сложной логике или не тянет работу со сложной архитектурой?

Так как же "база" помогает решить проблемы?
Разработчики, обладающие знаниями об устройстве БД, могут дать более оптимальные структуры и менее тяжелые запросы. И речь не только про выбор правильных индексов.
Понимание concurrency позволяет применять его там, где это применимо, и не пихать горутины/корутины/треды везде, где кажется, что оно ускорит работу (закон Амдала против этого).
Знание работы сети, понимание проблем TCP для low latency и т.д. позволяет строить более правильные предположения об оптимизации межсервисных взаимодействий.

Жду в комментариях jsonоукладчиков, которые будут бухтеть на то, что все это нужно только в очень тяжелых проектах с огромными нагрузками, а у них это не применимо🙂

Но они будут по своему правы, потому что получить такой опыт можно только на практике. Или активно учиться и читать много статей от больших компаний, но не факт, что это будет когда-нибудь применимо. Зато позволит развивать навык насмотренности и видеть за пределами тех инструментов, с которыми привыкли работать. Зачем? Потому что приходится осваивать все новые и новые технологии, чтобы понимать, что происходит в сложной гетерогенной инфраструктуре.

А понимать все это помогает та самая база, потому что почти любая технология базируется на этих основах: сеть, многопоточность, взаимодействие с ОС и использование syscalls и т.д. В основе всегда лежат базовые концепции и объяснить, как работает технология, часто можно именно на основе базовых вещей, не погружаясь в детали, и этого может хватать для понимания архитектуры системы целиком.

А точно ли вы разбираетесь в Kubernetes?

Приготовил вам задачку, интересно, сможете ли ответить?⬇️

В Kubernetes у вас есть Deployment с приложением, которое использует ConfigMap для конфигурации. После обновления значения в ConfigMap приложение не подхватывает изменения автоматически.

Какой рекомендуемый способ гарантировать, что приложение будет получать обновленные значения конфигурации при каждом изменении ConfigMap?

Варианты:

1. Использовать kubectl rollout restart deployment, чтобы пересоздать поды и они смонтировали новую версию ConfigMap.

2. Добавить hash-сумму содержимого ConfigMap как аннотацию в Pod template, чтобы при изменении конфигурации автоматически запускался новый rollout.

3. Включить параметр --reload-config=true в манифесте ConfigMap, чтобы kubelet сам обновлял монтированные файлы без рестарта подов.

4. Установить в Deployment стратегию обновления type: Recreate, чтобы поды всегда уничтожались и пересоздавались при изменении ConfigMap.

Cloudflare сломал пол-интернета. Опять.

А случилось это 18 ноября 2025 года из-за одной строки Rust-кода, использовавшей "unwrap()" – тот самый метод, который в мире Rust считается опасным, если не обрабатывать ошибки правильно.

➡️Из-за изменения прав доступа в БД, из которой читается конфигурация, размер конфигурационного "feature" файла взял и удвоился, превысив лимит памяти, который был жестко зашит в эту часть системы. Вместо аккуратного реагирования на ошибку, unwrap вызвал мини апокалипсис.

В итоге пришлось вручную откатить конфигурацию и перезапускать службы, с простым уроком ▶️ каким бы безопасным не был язык, найдется способ этой безопасностью пожертвовать.

P.S. У Сloudflare очень хорошие постмортемы. Всем SRE рекомендую😉

Вопрос на засыпку (попробуйте ответить без поиска в гугле или других системах):

Cloudflare обслуживает трафик половины интернета. Строит ли компания для этого свои ДЦ и где?