en
Feedback
DevOps для ДевоПсов

DevOps для ДевоПсов

Open in Telegram

Самые актуальные материалы по DevOps на русском и английском языке Разместить рекламу: @tproger_sales_bot Правила общения: https://tprg.ru/rules Другие каналы: @tproger_channels Другие наши проекты: https://tprg.ru/media

Show more
3 220
Subscribers
No data24 hours
-17 days
-1530 days
Posts Archive
Kubernetes 2026: что стоит внедрить За год немало функций дошло до стабильной версии, и часть привычных подходов пора обновит
Kubernetes 2026: что стоит внедрить За год немало функций дошло до стабильной версии, и часть привычных подходов пора обновить. Теперь ресурсы пода можно менять на ходу: с версии 1.35 процессор и память настраиваются без перезапуска, что сильно упрощает настройку под нагрузку. Изменился и способ выделения оборудования — под может просто описать, какой GPU нужен, а планировщик сам подберёт подходящий, что особенно удобно для AI-задач. Вспомогательные контейнеры получили понятный жизненный цикл, так что обходные решения для service mesh и агентов Vault больше не нужны. В релизе 1.36 усилили безопасность: root внутри контейнера теперь сопоставляется с обычным пользователем на узле, а правила изменения объектов можно задавать прямо в кластере, без отдельного сервиса. И о чём стоит помнить перед обновлением: Ingress NGINX закрыт с марта 2026 — присмотритесь к Gateway API; поле externalIPs в Service устарело и будет удалено в версии 1.43; на смену Endpoints API приходит EndpointSlices.

Продолжим о Deckhouse Kubernetes Platform (DKP). Недавно в Community Edition стал доступен полный веб-интерфейс! Начиная с ве
+3
Продолжим о Deckhouse Kubernetes Platform (DKP). Недавно в Community Edition стал доступен полный веб-интерфейс! Начиная с версии 1.46 модуля console интерфейс в DKP CE стал полноценным: теперь можно управлять узлами, модулями, доступом, сертификатами, виртуализацией и мониторингом через веб-интерфейс без ограничений. Больше подробностей об этом обновлении читайте на Хабре.

Развернуть Kubernetes-кластер относительно просто. Настоящая жизнь начинается потом: обновления, мониторинг, логи, сеть, безо
Развернуть Kubernetes-кластер относительно просто. Настоящая жизнь начинается потом: обновления, мониторинг, логи, сеть, безопасность, автоскейлинг. И на всё это довольно быстро уходит время целой команды, а не одного человека. Deckhouse Kubernetes Platform как раз о том, чтобы этой рутины было меньше. Это Kubernetes, который уже собран и упакован вместе с нужными модулями — мониторингом, логами, ingress, сетевыми политиками, веб-интерфейсом и другими функциями. Платформа разворачивается практически где угодно, сама следит за состоянием кластера и обновляет его, а не просто отдаёт вам набор деталей, которые нужно собирать и чинить вручную. У платформы несколько редакций: Community Edition (CE) — бесплатная и полностью открытая, распространяется под лицензией Apache 2.0. В ней достаточно функциональности, чтобы поднять рабочий кластер и разобраться, как устроена платформа. Дальше идут коммерческие редакции с более широким набором функций, поддержкой от вендора и статусом отечественного ПО в реестре, включая Certified Security Edition, сертифицированную ФСТЭК России. Вокруг платформы сложилось инженерное сообщество, которое помогает разобраться с нюансами. Обсуждения на русском идут в чате @deckhouse_ru, а анонсы релизов и материалы для инженеров публикуются в канале @deckhouse_news.

Агенты перешли от Stateless API к сессиям — проверьте их изоляцию AWS, Microsoft, Google и Anthropic строят runtime вокруг se
Агенты перешли от Stateless API к сессиям — проверьте их изоляцию AWS, Microsoft, Google и Anthropic строят runtime вокруг session-aware execution. AWS изолирует сессию в microVM, Google — код в dedicated sandbox, Microsoft Foundry использует per-session isolation, Anthropic разделяет агента на session, harness и sandbox. Для DevOps это меняет модель угроз: агент теперь долгоживущий, stateful и выполняет код от имени пользователя. При слабой изоляции одна сессия увидит state другой, утечёт за пределы хоста или скомпрометирует данные. Авторы материала называют такой runtime control plane для состояния, идентичности, изоляции и жизненного цикла. Что делать: проверьте, как сессии ваших агентов отделены друг от друга и от хоста, где лежит state и кто контролирует их жизненный цикл.

Вы бы доверили управление кластером ИИ-агенту? Эдгар Сипки, основатель EasyP && Sipki Tech, однажды не просто кивнул в ответ,
Вы бы доверили управление кластером ИИ-агенту? Эдгар Сипки, основатель EasyP && Sipki Tech, однажды не просто кивнул в ответ, а дал агенту возможность настраивать кластер и работать в K8s. Правда, потом агент слегка уронил прод, но это уже нюансы. Своим кейсом Эдгар поделится на DUC meetup /5. Митап состоится 8 июля, в Москве. Регистрируйтесь заранее, мест осталось совсем немного!

Генерируйте SBOM на этапе сборки: сканирование готового образа даст декларацию вместо фактов 86% организаций в отчёте Omdia 2
Генерируйте SBOM на этапе сборки: сканирование готового образа даст декларацию вместо фактов 86% организаций в отчёте Omdia 2026 называют генерацию SBOM сложной. Причина в том, что разрозненные сканеры дают несогласованный результат, и приходится сводить его вручную. Для DevOps проблема в том, что если SBOM собран после сборки, он фиксирует задекларированные версии, а не фактически установленные. Пропущенные транзитивные зависимости или устаревший слой базового образа превращают аудит на compliance в формальность. Выход — генерация на этапе сборки: генератор видит разрешённое дерево зависимостей, файлы пакетного менеджера и полный контекст сборки. Сканирование готового образа такой видимости не даёт. Для воспроизводимости фиксируйте генератор по неизменяемой ссылке и выбирайте базовые образы с предсобранным SBOM. Детали в обзоре Docker.

От ноутбука до кластера Говорят, у мужчины должны быть «Жигули» «четвёрка» в гараже. У инженера Фланта Василия Олейникова вме
От ноутбука до кластера Говорят, у мужчины должны быть «Жигули» «четвёрка» в гараже. У инженера Фланта Василия Олейникова вместо них — домашняя инфраструктура. Как так вышло, что из одного ноутбука Toshiba вырос геораспределённый кластер на несколько квартир, Василий расскажет на юбилейном Deckhouse User Community meetup /5. Митап пройдёт 8 июля в People Loft. Встреча гостей с 18:15, доклады стартуют в 19:05. ➡️ Регистрация

Kubernetes-кластер на несколько квартир, ИИ-агент, который уронил продакшен, и программа для контрибьюторов — всё это на мита
Kubernetes-кластер на несколько квартир, ИИ-агент, который уронил продакшен, и программа для контрибьюторов — всё это на митапе Deckhouse User Community 8 июля в Москве. В программе три доклада: — история домашней геораспределённой инфраструктуры длиной в 13 лет — от ноутбука до кластера, охватывающего несколько квартир; — рассказ об ИИ-агенте, который управляет инфрой (и однажды уронил прод); — питч о веб-интерфейсе Deckhouse Kubernetes Platform. Отдельная тема митапа — участие в жизни сообщества. На встрече объявят о запуске программы поддержки контрибьюторов Deckhouse User Community. Митап пройдёт только офлайн, места ограничены. Регистрация — по ссылке, ждём вас!

Поднимите S3-совместимое хранилище для staging на том же VPS Если staging загружает аватары, отчёты и тестовые файлы в облачн
Поднимите S3-совместимое хранилище для staging на том же VPS Если staging загружает аватары, отчёты и тестовые файлы в облачный S3, вы платите за хранилище и трафик, которые на самом деле не нужны. MinIO, open-source сервер объектного хранилища на Go, реализующий API Amazon S3, можно развернуть в Docker на VPS за 10–15 минут и платить только за диск сервера. Код приложения не меняется: те же SDK, PutObjectCommand, presigned URL и те же ошибки SignatureDoesNotMatch. Меняются только переменные окружения: endpoint, ключи и флаг forcePathStyle, который нужен большинству S3-совместимых сервисов, включая MinIO и R2. Не отдавайте приложению root-ключи. Создайте отдельного пользователя с IAM-политикой только на нужный бакет, а HTTPS и домен отдайте reverse proxy, Traefik или NGINX, с Let’s Encrypt. Пошаговый разбор — с Docker, бэкапом в холодное хранилище и деталями настройки.

Сохраняйте causal-лог падений Kubernetes до перезаписи kubelet События подов в Kubernetes ротируются быстрее, чем вы успеваете открыть инцидент. Поле LastTerminationState перезаписывается после рестарта, а в crash-loop таких рестартов бывает несколько. Причина падения уходит за evidence horizon. Operational Memory Architecture (OMA) — открытый инструмент на Go, который отслеживает события кластера, строит цепочки причинно-следственных связей и складывает их в SQLite. В тестах на Minikube и AKS с 20 crash-loop подами средняя задержка на связь меньше 1 мс, коллектор потребляет менее 10 МБ памяти. Если отладка в вашем кластере упирается в пустой kubectl describe pod, посмотрите OMA — возможно, пора добавить operational memory layer.

Сохраняйте causal-лог падений Kubernetes до перезаписи kubelet События подов в Kubernetes ротируются быстрее, чем вы успевает
Сохраняйте causal-лог падений Kubernetes до перезаписи kubelet События подов в Kubernetes ротируются быстрее, чем вы успеваете открыть инцидент. Поле LastTerminationState перезаписывается после рестарта, а в crash-loop таких рестартов бывает несколько. Причина падения уходит за evidence horizon. Operational Memory Architecture (OMA) — открытый инструмент на Go, который отслеживает события кластера, строит цепочки причинно-следственных связей и складывает их в SQLite. В тестах на Minikube и AKS с 20 crash-loop подами средняя задержка на связь меньше 1 мс, коллектор потребляет менее 10 МБ памяти. Если отладка в вашем кластере упирается в пустой kubectl describe pod, посмотрите OMA — возможно, пора добавить operational memory layer.

Всем привет! Сегодня в канале стартует партнёрский месяц с Флантом 🦆 Флант развивает экосистему Deckhouse, продукты на базе
Всем привет! Сегодня в канале стартует партнёрский месяц с Флантом 🦆 Флант развивает экосистему Deckhouse, продукты на базе Kubernetes и Cloud Native-подходов. А уточка на аватарке — маскот экосистемы. В этом месяце расскажем о Deckhouse Kubernetes Platform и сообществе её пользователей, анонсируем пятый митап Deckhouse User Community (он посвящён Community Edition, бесплатной Open Source-редакции платформы) и поделимся полезным для DevOps-специалистов. Для нас это новый формат — надеемся, вам понравится!

Закрепите GitHub Actions и образы по хешу — Cilium ужесточает CI/CD Команда Cilium пинит все uses: в workflow по полному SHA:
Закрепите GitHub Actions и образы по хешу — Cilium ужесточает CI/CD Команда Cilium пинит все uses: в workflow по полному SHA: вместо тега @v6 указывается коммит-хеш. Образы тоже фиксируются через @sha256:..., а не по mutable-тегу. Если тег скомпрометируют, CI всё равно возьмёт проверенный код. Но пиннинг не покрывает транзитивные зависимости actions. Закреплённый checkout не спасёт от взлома вложенного action, который разрешается по тегу во время выполнения. GitHub обещает workflow-level dependency locking в roadmap 2026, аналогично go.mod + go.sum. Пока проверьте свои workflow: замените теги на SHA, закрепите образы по дайджесту и следите за дорожной картой GitHub.

Запустите o11y-bench, прежде чем доверить ИИ-агенту вашу Grafana Не доверяйте ИИ-агенту доступ к продовой Grafana, пока не пр
Запустите o11y-bench, прежде чем доверить ИИ-агенту вашу Grafana Не доверяйте ИИ-агенту доступ к продовой Grafana, пока не проверите его в o11y-bench. Grafana открыла код бенчмарка: он запускает агентов против реального стека с доступом к серверу Grafana MCP и оценивает их на observability-задачах. Внутри — запросы к метрикам, логам и трассировкам, расследование инцидентов и точечные правки дашбордов. Среда построена на фреймворке Harbor от авторов Terminal Bench. Перед доступом к проду прогоните свой сценарий через бенчмарк и убедитесь, что агент реально справляется, а не просто красиво отвечает.

K8s 1.35: почему под не рестартнулся после обновления конфига Обновили ConfigMap, Secret или Istio, а приложение всё ещё види
K8s 1.35: почему под не рестартнулся после обновления конфига Обновили ConfigMap, Secret или Istio, а приложение всё ещё видит старое? kubelet следит только за pod spec, и без смены spec'а контейнер не перезапустится. Проверяйте UID пода, а не только restart count: новый UID — под пересоздали и счётчик сбросился, старый UID с растущим restart count — CrashLoop в том же объекте. В K8s 1.35 CPU resize контейнер не трогает, память перезапускает только при политике RestartContainer; иначе JVM сохранит старый heap. envFrom из ConfigMap заморозит значения до kubectl rollout restart, volume mount обновится атомарно. Что делать: подключите Reloader с reloader.watchGlobally=true и аннотацией reloader.stakater.com/auto: "true", или вручную вызывайте kubectl rollout restart deployment/app. Матрица и команды в гайде.

Cloudflare ускорила security-сканы с 10 до 120+ в секунду без новых партиций Security Insights сканировала аккаунты раз в 1–2
Cloudflare ускорила security-сканы с 10 до 120+ в секунду без новых партиций Security Insights сканировала аккаунты раз в 1–2 недели, а бесплатные часто не попадали в очередь. Цель — ~10→100 сканов/с, но консьюмеры лагали, API таймаутился и процессы падали. В разборе инженеры пишут, что распараллелили обработку сообщений внутри партиции, разделили «медленные» и «быстрые» потоки и убрали блокировку головы очереди. Вставки в Postgres по одной строке заменили на гибридный bulk-insert, API перевели в active-passive у основной БД. Шедулер — под adaptive rate limiter: зоны считают отдельно, стартовые временные метки размазали, лимит пересчитывается каждые полчаса. Итог: производительность выросла >10× и достигла 120+ сканов/с. Прежде чем добавлять партиции или железо, смотрите метрики, SQL, логи и код.

Severity во время инцидента может мешать больше, чем помогать Dan Slimmon в спорной заметке критикует SEV-шкалы. Не потому чт
Severity во время инцидента может мешать больше, чем помогать Dan Slimmon в спорной заметке критикует SEV-шкалы. Не потому что классификация совсем не нужна, а потому что в начале инцидента команда часто тратит силы на спор «это SEV-1 или SEV-2», когда важнее понять blast radius, назначить lead и двигать расследование. Для SRE-практики полезный угол такой: severity хороша для отчётности, коммуникации и post-incident анализа, но плохо заменяет operational questions. Что сломано? Кто координирует? Какой next action? Когда следующий update? Если ваш incident template начинается с выбора SEV, стоит проверить, не прячутся ли за ним реальные шаги управления инцидентом.

SELECT в Postgres тоже может выглядеть как запись Dan Slimmon разбирает странный инцидент: в Postgres появлялись пики WALWrit
SELECT в Postgres тоже может выглядеть как запись Dan Slimmon разбирает странный инцидент: в Postgres появлялись пики WALWrite, хотя нагрузка была read-only. Виновником оказался не внезапный write-запрос, а hint bits и full page writes. Для SRE это хороший пример, почему «чтения не пишут» в базах не всегда безопасное упрощение. Первый SELECT после изменений может пометить tuple metadata, а если страница ещё не была записана после checkpoint, Postgres отправит full page image в WAL. Практический вывод: когда видите write spikes на read-heavy workload, не останавливайтесь на поиске INSERT/UPDATE. Смотрите checkpoints, hint bits, buffer dirties и то, что реально происходит на уровне storage.

CoreDNS в Kubernetes можно патчить Terraform'ом, не через kubectl edit Jérôme Petazzoni разбирает практичную боль: кластер сам создал CoreDNS ConfigMap, но править Corefile руками не хочется, потому что потом это невозможно нормально повторить и проверить в IaC. Решение строится вокруг Terraform/OpenTofu: прочитать существующий ConfigMap, применить patch к нужному фрагменту и оставить изменение в коде, а не в истории команд администратора. Это особенно полезно, если нужно добавить upstream, rewrite, cache-настройки или внутренние DNS-правила. Материал стоит открыть тем, у кого в кластере ещё есть «один раз поправили руками». CoreDNS обычно как раз из таких мест, где ручная правка потом всплывает в самый неудобный момент.

Linux page cache для тех, кто смотрит на память в проде У Viacheslav Biriukov есть большой разбор page cache для SRE. Это материал про ту самую память, которая в top выглядит занятой, но не всегда означает утечку в приложении. Внутри: как Linux кэширует страницы файлов, что меняется с cgroup v2, как читать smaps, где помогают mincore, mmap, fsync, vmtouch, perf и strace. Практический фокус хороший: не «ядро сложное», а как не ошибиться при разборе memory pressure. Если у вас были алерты вида «RAM почти кончилась», а потом всё само проходило, этот текст стоит сохранить в runbook по Linux diagnostics.