DevOps Portal | Linux

Нужно заглянуть внутрь образа контейнера, не запуская его?

Один из самых практичных способов:

docker create --name tmp my-image
docker export tmp | tar -C rootfs -xf -

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

Но если вам нужно извлечь образ контейнера в полноценный rootfs, который корректно сохранит все права доступа, владельцев файлов и расширенные атрибуты (xattrs), например, capabilities, sticky bits и т. д. — всё быстро становится гораздо сложнее.

Вот несколько практических способов и описал все подводные камни здесь: https://labs.iximiuz.com/tutorials/extracting-container-image-filesystem

👉 DevOps Portal

Если вы знаете Terraform,

значит, вы уже работали с DAG, даже если сами этого не осознавали.

Когда дело доходит до MLOps, AI/ML или сложных пайплайнов,

вам неизбежно придется работать с cloud-native инструментами, которые используют DAG в своих пайплайнах.

Так что же такое Directed Acyclic Graph (DAG)?

По сути, это описание всего вашего пайплайна, в котором определены все задачи, порядок их выполнения и зависимости между ними.

Terraform уже использует эту концепцию.

Перед выполнением terraform apply он автоматически строит граф зависимостей ресурсов (тот самый DAG). Именно благодаря этому Terraform знает, что сначала нужно создать VPC, а уже потом подсеть.

Argo Workflows тоже использует DAG для построения сложных воркфлоу.

Мы впервые познакомились с DAG в Airflow во время работы над MLOps-проектом.

Сегодня такие инструменты, как Kubeflow, используют DAG на Python для оркестрации AI/ML-пайплайнов.

Нужно ли DevOps-инженеру разбираться в этом?

Да. Времена, когда можно было сказать: «Разработка - не моя зона ответственности», уже прошли.

С современными AI-инструментами вы без труда сможете писать пайплайны на Python.

Если хотите на практике разобраться с DAG,

прочитайте материал про пайплайн Airflow + DVC в Kubernetes, где подробно объясняют, как работают Airflow и DAG с точки зрения DevOps-инженера.

Подробнее: https://newsletter.devopscube.com/p/mlops-airflow-dvc-pipeline

👉 DevOps Portal

Если вы DevOps-инженер,

не игнорируйте изучение AI-инфраструктуры в 2026 году 👇

На протяжении многих лет Kubernetes был основной платформой для запуска микросервисов.

Но сегодня на той же основе Kubernetes работает уже новое поколение ворклоадов.

* AI-пайплайны
* сервинг моделей
* распределённое обучение моделей
* GPU-ворклоады
* приложения на базе LLM

И один из ключевых проектов в этой области — Kubeflow.

Сегодня это cloud-native AI-платформа для разработки и эксплуатации GenAI, LLMOps, агентных AI-систем, распределённого обучения моделей и файнтюнинга foundation-моделей.

В нашем недавнем дайджесте мы разобрали:

* из чего состоит стек Kubeflow;
* как работают Kubeflow Pipelines;
* архитектуру KFP и процесс выполнения пайплайнов;
* создание KFP-пайплайна с нуля в Kubernetes;
* внутреннюю MLOps-платформу Cloudflare;

и многое другое.

Читать: https://newsletter.devopscube.com/p/kubeflow-pipelines

👉 DevOps Portal

CRI vs CNI vs CSI vs CDI в Kubernetes

CRI (Container Runtime Interface) — интерфейс, через который kubelet взаимодействует с контейнерными рантаймами.
CNI (Container Network Interface) — интерфейс, через который поды получают сетевое подключение.
CSI (Container Storage Interface) — интерфейс, через который поды получают постоянное (persistent) хранилище.
CDI (Container Device Interface) — интерфейс, через который поды получают доступ к аппаратным устройствам (NVIDIA, AMD, Intel).

Главная идея здесь проста:
Kubernetes определяет интерфейс, а вендоры реализуют плагины для него.

👉 DevOps Portal

Локальный сервис, например дев-сервер, можно выставить в публичный интернет через простой reverse SSH-туннель (ssh -R).

Но если вы хотите контролировать, кто может открывать такой туннель и кто может получать доступ к опубликованному сервису, можно использовать Pomerium — опенсорсный инструмент, который будет терминировать ssh -R-сессии. Pomerium ставит OIDC-аутентификацию перед получившимся HTTPS-роутом и применяет access policies.

Удобно для дев-боксов, CI-раннеров, on-call ноутбуков и хоумлабов, которые сидят за NAT.

Посмотрите полный туториал от Nick Taylor, чтобы увидеть, насколько просто поднять рабочий пример: https://labs.iximiuz.com/tutorials/native-reverse-ssh-tunneling-with-pomerium-005bfe2a

👉 DevOps Portal

В DevOps мы много говорим про масштабирование, аптайм и пайплайны.

Но в большинстве случаев безопасность всегда обсуждают в последнюю очередь.

В клауд-нейтив мире приложения должны воспринимать аутентификацию и авторизацию как базовые принципы дизайна.

Kubernetes — отличный реальный пример такого подхода.

* Каждый Pod получает JWT — токен сервис-аккаунта.
* Когда Pod обращается к Kubernetes API, он прикладывает этот токен.
* API-сервер проверяет токен и применяет RBAC-правила, чтобы определить, что этому Pod разрешено делать.

Это 15-Factor security на практике.

* Каждый запрос проходит проверку.
* Система следует zero-trust модели: по умолчанию никому и ничему нет доверия.
* Identity и permissions закладываются в архитектуру с самого начала.

Если хотите больше узнать про 15-Factor Apps, вот разбор дополнительных факторов

Читайте здесь: https://newsletter.devopscube.com/p/12-factor-to-15-factor-apps

👉 DevOps Portal

Случайные сбои DNS в Kubernetes?

Возможно, проблема вовсе не в CoreDNS.

Причиной может быть переполненная таблица conntrack.

Эту настройку Kubernetes полезно знать, если вы:

- изучаете сетевую архитектуру Kubernetes;
- готовитесь к экзамену CKA;
- администрируете production-кластеры, развернутые с помощью kubeadm.

Если вы используете kubeadm, размер таблицы conntrack можно настроить через KubeProxyConfiguration.

Вот пошаговое руководство, в котором подробно показано, как это сделать.

Подробный гайд: https://devopscube.com/setup-kubernetes-cluster-kubeadm/

👉 DevOps Portal

Новая подборка практических Kubernetes-челленджей от Omkar Shelke уже доступна. Learning by doing в лучшем виде

- Добавьте ephemeral container в distroless Pod и проверьте HTTP-запрос между namespace’ами
https://labs.iximiuz.com/challenges/inject-debug-container-into-distroless-pod-confirm-cross-namespace-http-8040ab18
- Запустите короткую задачу как отдельный Pod без Job-контроллера
https://labs.iximiuz.com/challenges/run-short-task-as-a-standalone-pod-without-a-job-controller-f6655185
- Приложение Puzzle Block Game пропало — восстановите его из etcd
https://labs.iximiuz.com/challenges/puzzle-block-game-application-is-gone-recover-it-from-etcd-28e61727
- Создайте и восстановите snapshot etcd в Kubernetes-кластере
https://labs.iximiuz.com/challenges/take-and-restore-etcd-snapshot-on-a-kubernetes-cluster-7ae31fbc

👉 DevOps Portal

В этом гайде разбирается, как опубликовать Kubernetes-кластер на Proxmox через связку из двух HAProxy: внешний HAProxy работает на хосте как edge-прокси, а внутренний в кластере в качестве ingress-контроллера.

➜ https://ruzhnikov.substack.com/p/exposing-kubernetes-dual-haproxy

👉 DevOps Portal

Изучаем Linux на практике: локальный проброс портов через SSH

- Получите доступ к внутреннему порту для отладки через SSH-туннель: https://labs.iximiuz.com/challenges/ssh-local-port-forwarding
- Подключитесь к приватному сервису в VPC через bastion-хост: https://labs.iximiuz.com/challenges/ssh-local-port-forwarding-bastion
- Получите доступ ко всей VPC через SSH SOCKS-прокси: https://labs.iximiuz.com/challenges/ssh-socks-proxy

👉 DevOps Portal

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

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

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

$ which ssh

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

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

👉 DevOps Portal

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

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

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

👉 DevOps Portal

Если вы работаете в 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

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

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

👉 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

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

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

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

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

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

👉 DevOps Portal

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

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

- Слишком медленная последовательность остановки приложения: 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