IP-адреса за 6 минут

👉 DevOps Portal

Пойми, как работает firewall, за 45 секунд

👉 DevOps Portal

Почему важно менять версии Helm Chart?

Когда вы пакуете и публикуете Helm chart, именно версия чарта отслеживается репозиториями.

Не теги образов.
Не версия вашего приложения.

Если вы изменили шаблоны, но не увеличили версию чарта:

- Репозиторий будет считать это тем же самым релизом.
- Ваш CI/CD-пайплайн будет использовать закэшированные артефакты.
- Кластер не обнаружит изменений при выполнении upgrade.

В итоге всё выглядит так, будто обновилось, но на самом деле ничего не изменилось.

Поле appVersion — это всего лишь метаданные о версии вашего приложения. Оно не влияет на упаковку чарта и индексацию в репозитории.

Поэтому если вы просто обновили тег образа в values.yaml и забыли увеличить версию чарта, инструменты, которые на неё опираются, не распознают новый релиз.

Всегда увеличивайте поле version в Chart.yaml, когда меняете любой файл внутри чарта.

Подробный блог:
https://devopscube.com/create-helm-chart/

👉 DevOps Portal

Один из ключевых трюков, лежащих в основе Service Mesh — это прозрачный перехват трафика. Такой прокси, как Envoy, можно разместить на сетевом пути между двумя сервисами, даже не давая им понять, что он вообще существует.

eBPF — одна из тех "магических" технологий, с помощью которых можно реализовать такой прозрачный перехват трафика.

Узнайте, как реализовать перехват исходящего трафика, а заодно прокачать навыки программирования на eBPF, в свежем туториале Теодора Подобника:
https://labs.iximiuz.com/tutorials/ebpf-envoy-egress-dc77ccd7

👉 DevOps Portal

Узнайте, как с помощью GPT и Claude построить полноценную мульти-средовую платформу Kubernetes.

От k3s до продакшн-кластеров, с использованием GitHub Actions, Traefik, Helm и PostgreSQL – полностью автоматизированная DevOps-архитектура, собранная с помощью AI.

Читайте тут

👉 DevOps Portal

Уменьшил Docker-образ с 1.37 GB → 168 MB.

Всего лишь за счёт использования multi-stage сборок, slim-базовых образов и очистки неиспользуемых зависимостей.

Небольшие оптимизации = более быстрый CI/CD и более безопасные контейнеры 👍

👉 DevOps Portal

Terraform за 60 секунд!

Не пропусти.

👉 DevOps Portal

Настройка NVIDIA GPU Operator в Kubernetes

Базовый процесс настройки выглядит так:

- Проставить labels и taints для GPU-нод
- Добавить Helm-репозиторий Nvidia GPU Operator
- Установить Nvidia GPU Operator
- Проверить обнаружение GPU

Подробное руководство:
https://devopscube.com/setup-gpu-operator-kubernetes/

👉 DevOps Portal

Объединение слоёв контейнерного образа в «плоскую» файловую систему с помощью OverlayFS

Тема, о которой я слишком давно хотел рассказать — как контейнерные рантаймы превращают многослойные образы в «плоский» rootfs контейнера.

Разберёмся на практике в новом челлендже iximiuz Labs:
https://labs.iximiuz.com/challenges/union-mount-container-image-layers-using-overlayfs

👉 DevOps Portal

Разбираемся в архитектуре Istio за 12 минут (иллюстрированный гайд)

Если вы хотите лучше понять Istio,

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

В cтатье подробно разбираем это с помощью наглядных диаграмм и простых объяснений.

Вот что вы узнаете

- Почему Istio понадобилась новая архитектура
- Обзор архитектуры Istio
- Подробный разбор ключевых компонентов: Istiod, Ztunnel, Waypoint Proxy и CNI
- Является ли Ztunnel единой точкой отказа?
- Бизнес-кейсы использования Ambient Mesh, включая преимущества по стоимости
- Практическое руководство по настройке Istio Ambient Mesh

Читать здесь: https://newsletter.devopscube.com/p/istio-ambient-mesh

Примечание: для лучшего понимания сначала разверните Ambient Mesh, а затем изучайте архитектуру. Так вам будет гораздо проще связать все концепции между собой.

👉 DevOps Portal

Минимальные требования для получения работы DevOps-инженером в 2026 году

👉 DevOps Portal

Сетевое взаимодействие в Kubernetes - штука сложная.

Но это не значит, что в ней невозможно разобраться. Если разложить всё на более мелкие части, станет понятно, как они между собой связаны.

Следующий урок курса Kubernetes the Very Hard Way посвящён именно этой теме:
https://labs.iximiuz.com/courses/kubernetes-the-very-hard-way-0cbfd997/cluster/network

👉 DevOps Portal

DevOps-инженеры, превращающие простое приложение в Kubernetes-кластер

👉 DevOps Portal

Контейнерный образ — это база любого релиза ❤️

Но когда версии, доступы и безопасность пущены на самотек, команда увязает в «починке доставки» и отвлекается от развития продукта.

На вебинаре вместе с экспертом Cloud․ru вы:

▶️рассмотрите контур артефактов и разберёте, где он чаще всего ломается;

▶️научитесь загружать Docker-образы, версионировать и управлять ими в Evolution Artifact Registry;

▶️настроите приватный доступ к репозиториям и разграничение прав;

▶️включите сканирование на уязвимости и примените политики безопасности;

▶️разберете, как поддерживать порядок в реестре: политики удаления и жизненный цикл.

Вебинар будет полезен backend-разработчикам, DevOps-инженерам (сборка/доставка), архитекторам (инфраструктура/безопасность), техлидам и руководителям команд для ускорения релизов и снижения рисков ошибок.

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

Kubernetes CNI vs Istio CNI

Вот ключевой момент, который нужно понять

Когда ты разворачиваешь Istio, тебе нужно запускать Istio CNI. Это не означает, что ты заменяешь CNI своего Kubernetes-кластера.

Он работает вместе с уже существующим CNI (например, Calico или Cilium) как chaining-плагин.

Вот в чём основное отличие.

Когда под стартует, Kubernetes вызывает CNI-плагин, чтобы настроить сеть: выдать IP, создать сетевые интерфейсы, прописать маршруты и т.д.

То есть именно он делает всю «реальную» сетевую работу.

Вот что делает Istio CNI:

- Работает только с подами, которые входят в mesh (неймспейсы с лейблом dataplane-mode=ambient)
- Когда он обнаруживает новые поды, входящие в mesh, он уведомляет Istio CNI node agent
- Node agent добавляет правила iptables в сетевой namespace пода, чтобы перенаправить трафик пода в прокси Ztunnel

В целом, Istio CNI - это chaining plugin. Это значит, что несколько CNI-плагинов выполняются последовательно для одного и того же пода, и каждый добавляет свою часть сетевой логики.

Например:

- Под стартует
- Calico (назначает IP, настраивает маршруты)
- Istio CNI (добавляет правила iptables для редиректа трафика)

👉 DevOps Portal

Helm — это один из базовых инструментов, который обязательно нужно знать при работе с Kubernetes. Практические примеры, проходящие через полный жизненный цикл: добавление репозиториев, просмотр чартов, деплой NGINX ingress и настройка реальных override’ов – сильно помогают в обучении.

В этом гайде показан не только "счастливый путь": автор специально пушит некорректный тег образа, показывает, как падают поды, и затем демонстрирует, как с помощью rollback в Helm можно аккуратно восстановиться. Это максимально приближено к реальному опыту работы с Helm (и другими инструментами), поэтому материал лучше усваивается.

Shivam Soni даёт чёткий разбор команд без лишней абстракции. Если вы только начинаете работать с Helm или хотите освежить знания по версионированию релизов и механике rollback – это чистый, хорошо структурированный материал, на который стоит обратить внимание.

Читайте здесь

👉 DevOps Portal

Kubernetes v1.36 официально выходит 22 апреля 2026 года

Вот 6 ключевых изменений, к которым нужно подготовить свои кластеры:

1️⃣ HPA Scale-to-Zero (включено по умолчанию):
→ Фича HPAScaleToZero выходит из alpha (была там с версии v1.16).
→ Теперь можно стабильно использовать minReplicas: 0.
→ Существенная экономия затрат для простаивающих staging-окружений и batch-пайплайнов.

2️⃣ Эфемерные SA-токены для pull образов:
→ Заменяют долгоживущие статические секреты для аутентификации в приватных registry.
→ Используются краткоживущие, автоматически ротируемые токены Service Account.
→ Доступ теперь привязан к identity конкретного pod’а, что значительно снижает риск утечек.

3️⃣ Более умный выбор pod’ов в HPA:
→ Исправлена проблема, когда HPA учитывал метрики orphaned или устаревших pod’ов.
→ Новая логика гарантирует, что HPA читает метрики только с pod’ов, управляемых целевым workload’ом.
→ Поведение автоскейлинга становится гораздо более предсказуемым и стабильным.

4️⃣ Удаление режима IPVS в kube-proxy:
→ Режим IPVS был deprecated в v1.35 и теперь полностью удаляется.
→ Пора мигрировать кластеры на iptables (backend на nftables) или eBPF-прокси (например, Cilium).
→ Запланируйте миграцию заранее, чтобы patch-апдейт не сломал сетевой стек.

5️⃣ Отказ от Ingress NGINX и переход на Gateway API:
→ Сообщество активно отказывается от Ingress NGINX.
→ Gateway API становится новым стандартом для управления трафиком.
→ Предоставляет нативный cross-namespace routing без необходимости городить кастомные аннотации.

6️⃣ Переход на containerd 2.x:
→ v1.36, вероятно, станет последним релизом с поддержкой старых версий containerd (например, 1.6.x).
→ Экосистема Kubernetes полностью выравнивается под containerd 2.x.
→ Обновите container runtime заранее, чтобы избежать ломающих изменений в следующем цикле.

👉 DevOps Portal