Podman — альтернатива Docker без демона

Podman – это container runtime, который имитирует Docker на уровне основных команд (run, exec, kill и т.д.), но при этом под капотом использует daemonless-архитектуру. У такого подхода есть свои плюсы (например, меньше moving parts, более простой rootless-сетап) и минусы (например, без демона некоторые операции с контейнерами требуют дополнительной интеграции с systemd).

Вот несколько практических челленджей, если хотите попробовать Podman и сравнить его с Docker:

- Запуск и инспектирование контейнера в Podman
https://labs.iximiuz.com/challenges/start-container-with-podman
- Автоматический рестарт контейнера Podman после перезагрузки хоста
https://labs.iximiuz.com/challenges/podman-101-container-restart-on-host-reboot
- Запуск и инспектирование контейнера в Docker (для сравнения)
https://labs.iximiuz.com/challenges/start-container-with-docker

👉 DevOps Portal

Настройка Kubernetes-кластера на Kubeadm 1.36 (пошагово)

Вот почему стоит развернуть собственный self-hosted Kubernetes-кластер.

Когда вы поднимаете кластер с нуля,

вы начинаете гораздо лучше понимать, как устроены control plane-компоненты и worker-ноды Kubernetes.

Кроме того, если вы готовитесь к экзаменам CKA или CKS, управление кластером через Kubeadm входит в официальный syllabus этих сертификаций.

Вот обновлённый гайд по настройке Kubeadm 1.36, где весь процесс разобран пошагово.

https://devopscube.com/setup-kubernetes-cluster-kubeadm/

Для DevOps-инженера крайне важно глубоко понимать все компоненты, из которых состоит Kubernetes-кластер.

Рекомендую в процессе обучения использовать именно self-hosted Kubernetes-кластер, а не готовые managed-решения, которые легко доступны "из коробки".

👉 DevOps Portal

Stakpak — это опенсос AI-агент для терминала, заточенный под DevOps: генерирует инфраструктурный код, дебажит Kubernetes и автоматизирует деплои. При этом использует подстановку секретов, чтобы LLM никогда не получала доступ к вашим реальным данным

https://github.com/stakpak/agent

👉 DevOps Portal

Apache Airflow на Kubernetes (MLOps)

Если вы хотите работать с проектами в области MLOps, Data Engineering или AI-инфраструктуры,
знание Apache Airflow может дать вам серьёзное преимущество.

Apache Airflow — это open-source платформа для построения и управления сложными воркфлоу и пайплайнами.

В этом блоге разобрали:

- Что такое Apache Airflow
- Как работают DAG’и
- Как устроены executors в Airflow
- Развёртывание Airflow в Kubernetes
- Настройку GitSync для управления DAG’ами
- Важные Day 2 operational insights и многое другое...

Читайте здесь: https://devopscube.com/apache-airflow-on-kubernetes/

Изучение Airflow значительно упрощает понимание таких платформ, как Kubeflow, потому что их ключевые концепции очень похожи:
- DAG’и
- Оркестрация задач
- Выполнение пайплайнов и т.д.

👉 DevOps Portal

Когда FROM scratch-образа уже недостаточно 🤔

Тебе дали падающий контейнер – простой Go-сервер, который при получении запроса ходит в HTTPS API и проксирует ответ обратно клиенту.

Сможешь починить?
https://labs.iximiuz.com/challenges/when-from-scratch-image-is-not-good-enough

👉 DevOps Portal

Этот туториал показывает, как добавить observability в EKS-кластер: перейти на паттерн App of Apps в ArgoCD и развернуть kube-prometheus-stack с корректно настроенным EBS CSI driver и конфигурацией kubelet cAdvisor

Читайте тут

👉 DevOps Portal

Helm _helpers.tpl file – что это такое?

Если вы работаете с Helm чартами, то наверняка видели файл _helpers.tpl внутри директории /templates.

Многие просто игнорируют его, не понимая, зачем он нужен при деплое чарта.

В этом гайде разобрали:
- что такое _helpers.tpl и как он работает;
- что такое named templates / partial templates;
- практический пример использования;
- в каких случаях его лучше не использовать.

Читайте здесь: https://devopscube.com/_helpers-tpl-file-in-helm-charts/

👉 DevOps Portal

Чеклист готовности Kubernetes к продакшену для команд, которые подготавливают workloads к запуску в production.

В него входят: интерактивный чеклист, подробные пояснения к каждому пункту проверки и PDF-воркшит для скачивания.

https://learnkube.com/production-best-practices

👉 DevOps Portal

Развёртывание Kubernetes-кластера с помощью kubeadm

Этот туториал от Márk Sági-Kazár не просто пошагово объясняет процесс, но и даёт возможность выполнить каждую команду в изолированной песочнице, чтобы убедиться в её корректности.

Изучай Kubernetes на практике:
https://labs.iximiuz.com/tutorials/provision-k8s-kubeadm-900d1e53

👉 DevOps Portal

Новая серия практических челленджей от Kaloyan Preslavski, полностью сфокусированная на том, как работает планирование подов в Kubernetes

- Kubernetes Pod Scheduling: Requests ресурсов
https://labs.iximiuz.com/challenges/resource-requests-scheduling-e607f0d4
- Kubernetes Pod Scheduling: QoS-классы (Quality of Service Classes)
https://labs.iximiuz.com/challenges/qos-classes-ed21d34c
- Kubernetes Pod Scheduling: Priority и Preemption
https://labs.iximiuz.com/challenges/priority-preemption-9c62482f
- Kubernetes Pod Scheduling: LimitRange и ResourceQuota
https://labs.iximiuz.com/challenges/limitrange-resourcequota-7d992c42
- Kubernetes Pod Scheduling: Pod Affinity и Anti-Affinity
https://labs.iximiuz.com/challenges/pod-scheduling-affinity-8733a9e2
- Kubernetes Pod Scheduling: nodeSelector и Node Affinity
https://labs.iximiuz.com/challenges/nodeselector-node-affinity-e80db96a
- Kubernetes Pod Scheduling: Topology Spread Constraints
https://labs.iximiuz.com/challenges/topology-spread-constraints-a806af86
- Kubernetes Pod Scheduling: Taints, Tolerations и Node Affinity — почему иногда нужны сразу оба механизма
https://labs.iximiuz.com/challenges/taints-tolerations-node-affinity-3cd4d1de
- Kubernetes Pod Scaling: Horizontal Pod Autoscaler (HPA)
https://labs.iximiuz.com/challenges/hpa-scaling-5f978f78

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

👉 DevOps Portal

Этот инструмент предоставляет доступ к операциям Kubernetes-кластера через Model Context Protocol, позволяя AI-агентам и инструментам безопасно читать состояние кластера и выполнять контролируемые действия, такие как команды kubectl

https://github.com/containers/kubernetes-mcp-server

👉 DevOps Portal

Kubernetes начинался как слой планировщика поверх набора однохостовых Docker-демонов. Это значит, что долгое время Kubernetes-поды были всего лишь "полусклеенными" группами Docker-контейнеров.

Со временем появился Container Runtime Interface (CRI), который дал возможность подменять и настраивать container runtime’ы. Большинство кластеров перешло с тяжеловесного Docker на более специализированный containerd в качестве «высокоуровневого» runtime’а, при этом низкоуровневый OCI runtime (runc) остался без изменений.

Однако потребность в более изолированных подах продолжала расти, и вслед за этим появились "альтернативные" реализации – альтернативные по отношению к Docker-style контейнерам. Самые заметные из них – gVisor и Kata Containers.

gVisor запускает контейнеры поверх урезанного user-land kernel, написанного на Go, а Kata Containers оборачивает обычные Linux-контейнеры в microVM’ы для дополнительной изоляции.

Естественно, возникла необходимость указывать container runtime на уровне пода. Так и появился ресурс RuntimeClass.

С помощью RuntimeClass можно сообщить Kubernetes, какие container runtime’ы поддерживают ноды кластера. Это позволяет кластеру запускать как традиционные поды на базе Linux-контейнеров, так и более изолированные поды на gVisor или Kata Containers.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: nginx-kata-qemu
spec:
  runtimeClassName: kata-qemu
  containers:
    - name: nginx
      image: nginx:alpine
EOF

Узнайте, как регистрировать новые RuntimeClass’ы и запускать поды с произвольными именами runtime class, в практическом туториале от Márk Sági-Kazár: https://labs.iximiuz.com/tutorials/kubernetes-runtime-class-61506808

👉 DevOps Portal

Новая фича Kubernetes 1.36: Image Volumes

Контейнерные образы уже давно используют не только для упаковки приложений, но и для хранения произвольных артефактов: статических ассетов, весов моделей, конфигов и т.д. Во многом потому, что контейнерные registry есть практически везде, а такой «хак» сильно упрощает доставку крупных наборов данных.

Но чтобы использовать такой image-артефакт, раньше приходилось сначала pull’ить образ, а затем распаковывать его содержимое в директорию, доступную приложению. В Kubernetes это обычно означало дополнительный init container с набором кастомных скриптов.

К счастью, в Kubernetes v1.36 появился более чистый подход — image volumes. Теперь можно напрямую монтировать файловую систему OCI-образа в Pod как read-only volume.

Небольшой hands-on челлендж, чтобы попробовать это в деле: https://labs.iximiuz.com/challenges/kubernetes-pod-image-volume

👉 DevOps Portal

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

Запускать Kafka в проде – это здорово, ровно до того момента, когда нужно залезть внутрь и посмотреть, что там происходит

Kafbat UI — бесплатный open-source веб-интерфейс для мониторинга и управления кластерами Apache Kafka.
Он даёт единое окно управления всеми вашими Kafka-кластерами.

Брокеры, топики, партиции, consumer groups, schema registry, Kafka Connect – всё собрано в одном дашборде.

Можно просматривать сообщения в форматах JSON, Avro и Protobuf, фильтровать live-потоки через CEL-выражения, смотреть consumer lag по каждой партиции, а также создавать и перенастраивать топики без необходимости лезть в CLI.

GitHub-репозиторий:
Kafbat UI GitHub Repository

👉 DevOps Portal

Эта фича Kubernetes меняет то, как контейнеры работают с root-привилегиями

User Namespaces — это механизм безопасности, который сопоставляет ID пользователей и групп внутри контейнера с другим набором ID на хосте. По сути, это rootless-изоляция.

Ключевая идея такая.

Процесс, который запускается от root внутри контейнера, на хосте выполняется от имени непривилегированного пользователя, например с UID 100000.

Без User Namespaces контейнер, запущенный от root, использует ту же root-идентичность, что и хост.

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

Вот практический гайд, в котором разобрали следующее:
- что такое User Namespaces;
- как ядро выполняет маппинг root-пользователя на non-root пользователя;
- что меняется при установке hostUsers: false;
- как ограничивать диапазоны UID на хосте с помощью файла /etc/subuid;
- практический деплоймент для понимания User Namespace;
- ограничения User Namespace.

Читать здесь: https://newsletter.devopscube.com/p/kubernetes-user-namespaces

👉 DevOps Portal

Это руководство показывает, как построить локальную data platform с использованием KinD для Kubernetes и Terraform для провижининга инфраструктуры, а также Argo CD в качестве GitOps-движка для деплоя и управления приложениями.

➤ Ссылка на руководство

👉 DevOps Portal

Наглядное руководство по основам Systemd

Статья подробно и наглядно раскрывает внутреннее устройство systemd, делая акцент на ключевых компонентах D-Bus и cgroups, и объясняет, как устроена их архитектура и взаимодействие на примерах и схемах

https://medium.com/@sebastiancarlos/systemds-nuts-and-bolts-0ae7995e45d3

👉 DevOps Portal

GitHub Actions + AWS без долгоживущих секретов?

Современные DevOps-пайплайны не должны зависеть от захардкоженных AWS access keys.

Потому что утекшие CI/CD-учётные данные всё ещё остаются одним из самых серьёзных рисков для безопасности в облаке.

Именно здесь помогает OIDC.

Вместо того чтобы хранить AWS-секреты в GitHub, ваш workflow во время выполнения получает краткоживущие временные credentials напрямую от AWS.

- Никаких статических ключей.
- Никакой головной боли с ротацией секретов.
- Меньший blast radius, если что-то пойдёт не так.

В этом блоге разберем интеграцию GitHub Actions OIDC с AWS на пошаговом примере, который помогает безопасно настроить доступ к AWS cloud.

К концу этого гайда вы поймёте:
- Почему OIDC — это безопасный способ подключить GitHub Actions к AWS
- Как интеграция GitHub OIDC работает с AWS
- Как пошагово настроить OIDC через IAM roles
- Как протестировать настройку через AWS CLI и задеплоить в EKS с помощью GitHub Actions workflows

Подробный блог: https://devopscube.com/github-actions-oidc-aws/

👉 DevOps Portal

Если вы изолируете своего coding-агента в sandbox-окружении, как дать ему возможность тестировать изменения в браузере?

Как и во многих Dev & Ops-задачах, ответ – пробросить порт

В этом воркфлоу используют Claude Code, запущенный в удалённой VM, вместе с локальным браузером: https://labs.iximiuz.com/docs/playground-recipes/coding-agent-with-browser-access

👉 DevOps Portal

Большинство DevOps-инженеров и SRE до сих пор плохо понимают, что на самом деле означают метрики P50, P95 и P99.

Объясню на примере пиццы.

Ты заказываешь пиццу в Dominos. Они обещают доставку за 30 минут. В день у них 5000 заказов.

P50 означает, что 2500 пицц приехали за 30 минут или быстрее. То есть половина клиентов получила сервис, который обещали. Вторая половина ждала дольше. Это и есть средний пользовательский опыт.

P95 означает, что 4750 заказов доставили за 45 минут или быстрее. Но для 250 клиентов всё было намного хуже. Пицца уже остыла, никто даже не отзвонился.

P99 означает, что 4950 заказов приехали максимум за 60 минут. Но оставшиеся 50 человек получили холодную пиццу, испорченный вечер и повод уйти к Pizza Hut.

Вот в чём проблема средних значений.

У тебя все графики зелёные. Average выглядит отлично. Но 50 реальных пользователей сегодня получили плохой опыт. И завтра получат. И послезавтра тоже.

В проде происходит ровно то же самое.

Среднее время ответа вашего API показывает 80 мс. Выглядит отлично. Но P99 для небольшой группы пользователей держится на уровне 3 секунд. Они не жалуются громко. Они просто тихо уходят.

При 1 миллионе запросов в день P99 означает, что 10 000 запросов получают "холодную пиццу". Каждый день. Тихо.

Именно поэтому опытные инженеры никогда не доверяют одним только средним значениям. Сначала они смотрят на P95 и P99.

👉 DevOps Portal