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

Изучаем 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

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

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

👉 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

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

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

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

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

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

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

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

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

👉 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

Локальный сервис, например дев-сервер, можно выставить в публичный интернет через простой 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

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

Если вы 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

Если вы знаете 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

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

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

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

Чем MLOps отличается от привычных DevOps-процессов?

MLOps отличается от классических DevOps-процессов так же, как машинное обучение отличается от традиционной разработки ПО.

Например:

В SDLC мы управляем жизненным циклом кода.

MDLC добавляет ещё два измерения — данные и модели.

Поэтому в MLOps приходится отслеживать уже три компонента: код, данные и модели.

В классическом DevOps вы работаете только с кодом.

Именно поэтому MLOps-системы сложнее деплоить и сопровождать.

Если вы DevOps-инженер и хотите прокачаться в MLOps, вот подробный гайд, в котором собрали практические рекомендации и опыт по развитию MLOps-навыков для DevOps-инженеров.

Подробный роадмап: https://devopscube.com/devops-to-mlops/

Кроме того, понимание основ MLOps закладывает прочную базу, если в дальнейшем вы хотите перейти к LLMOps и AI Infrastructure.

👉 DevOps Portal

Linux для контейнеров: network namespaces

Network namespaces позволяют Docker и Kubernetes создавать для приложений иллюзию, что они работают в отдельном сетевом окружении: с изолированным набором сетевых устройств, IP-адресов, правил роутинга и т.д.

Разберитесь, как работают netns: https://labs.iximiuz.com/challenges/linux-network-namespace

👉 DevOps Portal

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

Нужен только один столбец из файла?

Выполните:

cut -d',' -f2 ~/Desktop/members.csv

Команда cut извлекает из текстовых файлов указанные поля или символы.

👉 DevOps Portal

zeropod — это инструмент, который автоматически сохраняет состояние контейнеров на диск через заданное время после последнего TCP-подключения, позволяя быстро и бесшовно масштабировать их до нуля.

https://github.com/ctrox/zeropod

👉 DevOps Portal

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

При работе с Kubernetes возможности eBPF позволяют видеть каждый системный вызов (syscall) и каждый сетевой пакет на уровне ядра Linux. Но сама по себе эта информация не отвечает на главный вопрос: какому Pod, контейнеру или Namespace принадлежит событие?

Именно эту проблему решает Inspektor Gadget — open-source инструмент для диагностики и отладки Kubernetes-кластеров и Linux-хостов на базе eBPF.

Он автоматически связывает события ядра с объектами Kubernetes, что значительно упрощает поиск проблем. Что умеет Inspektor Gadget?

В режиме реального времени отслеживает:
• DNS-запросы;
• TCP-соединения;
• открытие файлов;
• запуск процессов внутри контейнеров.

Захватывает сетевые пакеты внутри любого контейнера с использованием фильтров в стиле tcpdump (pcap).

Позволяет мгновенно обнаруживать:
• OOM Kill;
• потерю TCP-пакетов;
• TCP Retransmissions;
• другие проблемы на уровне ядра.

Фильтрует события по имени Pod или контейнера, причём фильтрация выполняется непосредственно в ядре, что минимизирует накладные расходы.

Помогает автоматически генерировать:
• Seccomp Profiles;
• Kubernetes NetworkPolicies
• на основе реального поведения приложений во время выполнения.

Важно: Inspektor Gadget запускается как privileged DaemonSet, поскольку eBPF требует доступа к ядру Linux. Для многопользовательских кластеров рекомендуется использовать встроенные механизмы ограничения запуска отдельных gadgets.

GitHub: https://github.com/inspektor-gadget/inspektor-gadget

👉 DevOps Portal

У небольших команд GPU-запросы очень прикладные:

прогнать модель, ускорить рендер, обработать тяжелые данные. Дальше DevOps раскладывает задачу на рабочие параметры — модель GPU, количество карт на сервер, срок запуска, питание, SLA, формат доступа к ресурсу.

Крупные игроки резервируют GPU заранее и надолго, а под небольшую, но нагруженную задачу мощности надо искать.

Из свежего, и пока мало кто в курсе — Московский кластер видеоигр и анимации начал сдавать в аренду выделенные GPU. Посмотрел, что там по конфигурации 👇

Из карт — H100 и RTX Ada 5000/6000, от 1 до 8 GPU на сервер, ресурс закрепляется за арендатором. Закрывает AI/ML, LLM, inference, 3D/Render, VDI.

Если нужен не отдельный GPU-сервер, а колокейшн — там же от 1U до полной стойки 42U на 10 кВт (можно расширить до 20), два независимых ввода питания на стойку.

Цены конкурируют с коммерческими ЦОДами — площадку субсидирует город.

👉 DevOps Portal

Нативные sidecar-контейнеры в Kubernetes

Sidecar — это вспомогательный процесс, который запускается рядом с основным приложением. Такой паттерн удобен, когда дополнительную функциональность лучше подключить отдельно: например, сетевой прокси, сборщик и отправщик логов, коллектор метрик или агент, который загружает секреты.

Основная сложность - правильно управлять жизненным циклом sidecar-контейнера: он должен запускаться раньше приложения, продолжать работать вместе с ним, перезапускаться при неожиданном завершении и останавливаться только после завершения самого приложения.

Раньше для реализации паттерна sidecar приходилось писать собственные скрипты, но нативная поддержка sidecar-контейнеров в Kubernetes через init-контейнеры с restartPolicy: Always заметно упростила этот процесс.

В этом практическом туториале рассказывают, как работают нативные sidecar-контейнеры в Kubernetes, чем они отличаются от обычных и init-контейнеров, а также как попрактиковаться в их использовании на нескольких реалистичных сценариях:
https://labs.iximiuz.com/tutorials/kubernetes-native-sidecars

👉 DevOps Portal