Новая подборка практических 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

Большинство инструментов безопасности для Kubernetes лишь уведомляют о проблеме уже после того, как она произошла.

KubeArmor работает иначе.

Это опенсорсный инструмент безопасности, который на уровне ядра контролирует, какие процессы могут запускаться, к каким файлам можно обращаться и какие сетевые запросы разрешены внутри ворклоадов.

Вместо простого алерта он блокирует действие ещё до его выполнения.

Что умеет KubeArmor

— Блокирует неожиданный запуск процессов или доступ к файлам внутри пода ещё до того, как это произойдёт.
— Применяет принцип минимально необходимых прав с помощью вайтлистинга процессов и сетевых подключений для каждого ворклоада.
— Ограничивает доступ к чувствительным путям, например к бандлам сертификатов и секретам, чтобы их нельзя было прочитать или изменить.
— Применяет политики харденинга, сопоставленные с MITRE, CIS и STIG, без необходимости писать их самостоятельно.
— Обеспечивает детальную видимость происходящего в рантайме с помощью eBPF, включая информацию о подах, контейнерах и неймспейсах.

https://github.com/kubearmor/KubeArmor

👉 DevOps Portal

Создаём контейнер наподобие Docker с нуля

Освойте ключевые пространства имён Linux, собрав небольшой, но реалистичный контейнер, используя только штатные команды Linux: unshare, mount и pivot_root. Никакой магии рантайма и (почти) никаких упрощений.

Изучаем здесь

👉 DevOps Portal

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

Инструмент распространяется в виде одного бинарника, напрямую подключается к Kubernetes API и не требует установки компонентов внутри кластера.

➜ https://github.com/skyhook-io/radar

👉 DevOps Portal

Большинство пользователей Kubernetes до сих пор не знают о существовании этого типа томов

Он называется ImageVolume.

Вот как он работает

Функция Image Volume позволяет использовать OCI-образы в качестве томов непосредственно внутри Pod’ов Kubernetes.

Что такое OCI-образы?

Это стандартизированный формат, который определяет структуру контейнерных образов.

С помощью ImageVolume можно хранить в образах файлы моделей, бинарные файлы, конфигурации и другие данные, а затем монтировать их в Pod’ы.

Вот практическое руководство, в котором показано, как работает эта функция и как её использовать.

Полезная возможность, о которой стоит знать.

https://devopscube.com/oci-image-volume-kubernetes-pods/

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

👉 DevOps Portal

Как работает сетевая подсистема контейнеров

Большинство Docker-инсталляций и Kubernetes-кластеров используют одинаковую схему сетей на основе мостов. Как лучше всего разобраться, как это устроено?

Попробуйте воссоздать такую сетевую конфигурацию с нуля, используя только стандартные Linux-команды: https://labs.iximiuz.com/tutorials/container-networking-from-scratch

👉 DevOps Portal

В этом руководстве показано, как построить SaaS-архитектуру с отдельным окружением для каждого пользователя в EKS Auto Mode: один pod, один поддомен и один persistent volume на пользователя, wildcard TLS и общий ALB.

➜ Читайте тут

👉 DevOps Portal