Корректное завершение работы контейнеризированных приложений может быть не таким простым, как кажется

Разберитесь с типичными подводными камнями на практике:

- Слишком медленная последовательность остановки приложения: https://labs.iximiuz.com/challenges/docker-graceful-container-shutdown
- Потеря сигналов при их передаче процессам: https://labs.iximiuz.com/challenges/graceful-termination-for-nodejs-container
- Некорректно работающий entrypoint-скрипт: https://labs.iximiuz.com/challenges/graceful-termination-for-container-with-entrypoint

Приятного хаккинга! 🚀

👉 DevOps Portal

Шпаргалка по SSH-туннелям

Забавный факт: с появлением ИИ-агентов и песочниц я стал пользоваться SSH даже чаще – это по-настоящему фундаментальная технология.

👉 DevOps Portal

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

25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками.

⚫️Развеем мифы, разберём лучшие современные подходы и инструменты.

⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов.

⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы.

Зарегистрируйтесь, чтобы не пропустить!

⏰ 25 июня в 14:00 (мск)

✅ Зарегистрироваться

Kubernetes NodeLocal DNSCache: как это работает

Когда речь заходит о производительности, в Kubernetes важен каждый DNS-запрос.

Без NodeLocal DNSCache поды отправляют DNS-запросы на Service IP kube-dns/CoreDNS.

Эти запросы проходят через kube-proxy, правила DNAT и conntrack, прежде чем попасть в CoreDNS.

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

NodeLocal DNSCache решает эту проблему, разворачивая локальный DNS-кеш на каждой ноде в виде DaemonSet.

В результате поды обращаются не напрямую к CoreDNS, а к локальному DNS-кешу на той же ноде.

Основные преимущества:
- Сокращает среднее время DNS-резолвинга, поскольку многие запросы обрабатываются локально из DNS-кеша.
- Снижает нагрузку на CoreDNS.
- Помогает избежать переполнения таблицы conntrack, так как соединения между подами и локальным DNS-кешем не создают записей в conntrack.
- DNS-запросы к внешним доменам могут форвардиться напрямую, без участия CoreDNS.

Примечание: NodeLocal DNSCache не включён в Kubernetes по умолчанию.

Для его использования необходимо вручную развернуть DaemonSet с NodeLocal DNSCache (за исключением некоторых managed-решений, например GKE Autopilot, где эта функциональность уже включена по умолчанию).

👉 DevOps Portal

Pod Affinity vs Pod Anti-Affinity

В Kubernetes

Pod Affinity и Pod Anti-Affinity помогают контролировать, где будут запускаться ваши поды, в зависимости от расположения других подов.

Вот самый простой способ запомнить
Pod Affinity = держать поды вместе
Pod Anti-Affinity = разносить поды друг от друга

Когда использовать Pod Affinity?

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

Когда использовать Pod Anti-Affinity?

Используйте, когда нужна высокая доступность.
Например, несколько реплик backend-сервиса распределяются по разным нодам, чтобы отказ одной ноды не положил всё приложение.

👉 DevOps Portal

Gateway API vs Ingress Controller

Вот ключевое различие, которое важно понимать

В Kubernetes объект Ingress лишь описывает правила маршрутизации.

Фактическая обработка и маршрутизация трафика выполняется Ingress Controller, который одновременно выступает и контроллером, и прокси-сервером.

С Gateway API процесс выглядит почти так же.

Вы создаёте такие ресурсы, как Gateway и HTTPRoute, чтобы управлять маршрутизацией и потоком трафика.

Затем контроллер Gateway API (NGINX Gateway Fabric) преобразует эти конфигурации в реальные правила маршрутизации и необходимую сетевую инфраструктуру.

Но здесь есть важное отличие в архитектуре NGINX Gateway Fabric.

У него control plane и data plane разделены.

Когда вы создаёте ресурс Gateway, контроллер автоматически разворачивает выделенный pod с NGINX (data plane), который непосредственно обрабатывает входящий трафик.

В случае с Ingress сам контроллер одновременно выполняет роль прокси и обрабатывает трафик.

👉 DevOps Portal

DevOps-инструмент недели: SpecKit

Инструменты для AI-кодинга часто упускают то, что вам действительно нужно.

Spec Kit — это open-source тулкит от GitHub, который ставит требования к проекту на первое место.

Вместо того чтобы сразу переходить к генерации кода, он помогает AI-агентам следовать понятному процессу: определить спецификацию, составить план, декомпозировать работу на задачи и только потом приступать к реализации.

Что умеет Spec Kit
- Проводит агентов через структурированный workflow: Spec → Plan → Tasks → Implement
- Использует файл правил для определения проектных требований и ограничений, которым должен соответствовать каждый этап
- Выявляет пробелы и недостающие требования ещё до начала разработки
- Генерирует чек-листы требований для валидации результата
- Поддерживает более 30 AI-инструментов для разработки, включая Claude Code, Copilot, Cursor и Codex.

Начать можно здесь: https://github.com/github/spec-kit

👉 DevOps Portal

В этом туториале вы узнаете, как настроить событийное trace-based тестирование в Kubernetes с помощью Tracetest и Testkube

https://tracetest.io/blog/event-driven-kubernetes-testing-with-testkube-and-tracetest

👉 DevOps Portal

Зоопарк решений растёт, а команда — нет

Одни сервисы развёрнуты в облаке, другие — на своих серверах, а третьи – в изолированном контуре. Чем больше «зоопарк», тем сложнее управлять такой инфраструктурой. Вместо того, чтобы нанимать нового DevOps-инженера, можно автоматизировать рутинные операции.

30 июня на вебинаре мы представим сервис, который поможет автоматически управлять лоскутной инфраструктурой в режиме «одного окна».

Мы покажем, как с помощью MWS B2B Store:

1️⃣ Деплоить сервисы в VMware и K8s через Terraform as a Service
2️⃣ Автоматически «раскатывать» обновления в изолированные контуры
3️⃣ Контролировать, кто и как использует лицензии на серверное ПО
4️⃣ Управлять инстансами из разной инфраструктуры в едином окне

Вместо слайдов — живое демо. Вы сможете задать любые вопросы и разобрать ответы со спикерами.

⏰ 30 июня в 11:00

Будет полезно: CTO, директорам по инфраструктуре, DevOps-инженерам и тимлидам инфраструктурных команд.

Регистрируйтесь по ссылке

Если вы работаете в DevOps, то SLSA — это концепция безопасности, которую обязательно нужно знать.

Сегодня злоумышленники всё чаще атакуют CI/CD-пайплайны ещё до того, как код попадает в продакшен-кластеры.

Недавний компромисс цепочки поставок npm-пакетов TanStack в 2026 году – наглядный тому пример.

Когда ваш CI-пайплайн собирает контейнерный образ и публикует его в реестр,

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

Для большинства команд доказать это невозможно.

Фреймворк SLSA создан именно для решения этой проблемы.

В этой статье разобрали:

- Что такое SLSA Provenance и уровни доверия
- Как внедрить SLSA в ваш CI/CD-пайплайн
- Как проверять Provenance в Kubernetes с помощью Admission Policies
- Три инцидента в цепочке поставок ПО, о которых должен знать каждый DevOps-инженер

Читайте здесь: https://newsletter.devopscube.com/p/slsa-explained

👉 DevOps Portal

Изучите все основные концепции Prometheus за 8 минут

В этой статье вы узнаете:
- Что представляет собой архитектура Prometheus?
- Сервер Prometheus
- База данных временных рядов (TSDB)
- Таргеты в Prometheus
- Экспортеры Prometheus
- Механизм Service Discovery в Prometheus
- Prometheus Pushgateway
- Клиентские библиотеки Prometheus
- Alertmanager
- PromQL

Подробная статья: https://devopscube.com/prometheus-architecture/

👉 DevOps Portal

Быстрый совет по Linux

Хотите понять, что именно запустится, когда вы введёте команду?

Используйте:

$ which ssh

Эта команда покажет исполняемый файл или команду, которую использует ваш shell, а также её расположение в файловой системе.

Удобный способ проверить пути к командам, алиасы и разобраться с проблемами в окружении shell.

👉 DevOps Portal

Как ИИ меняет инфраструктуру дата-центров

Рост ИИ-нагрузок требует изменений не только на уровне разработки, но и на уровне всей инфраструктуры.

На infra.conf’26 Яндекс анонсировали, как адаптирует физическую и ML-инфраструктуру для дальнейшего масштабирования ИИ-сервисов.

Что меняется 👇
- Компания переходит к концепции кампусов дата-центров. Такой подход позволяет наращивать мощность до 180 МВт, что является рекордным показателем для России.
- В дата-центрах внедряется жидкостное охлаждение. Оно обеспечивает более эффективное терморегулирование вычислительного оборудования и помогает снижать энергопотребление.
- Для ML-разработчиков запущен внутренний сервис Dev Cluster. Он ускоряет проведение экспериментов и сокращает время разработки моделей.

Изменения затрагивают как физическую инфраструктуру, так и внутренние платформенные инструменты, необходимые для развития ИИ.

👉 DevOps Portal