DevOps Portal | Linux

Когда начинаешь разбираться в архитектуре Istio,

часто всплывает такой вопрос про SPOF 👇

Является ли ztunnel единой точкой отказа (single point of failure)?

Что произойдёт, если ztunnel упадёт на ноде?

Вот ответ.

Поскольку ztunnel запускается как один pod на каждую ноду, может показаться, что это SPOF.

Если ztunnel падает, трафик к pod’ам на конкретной ноде будет затронут.

Однако pod’ы на других нодах не пострадают.

На каждой ноде есть свой здоровый экземпляр ztunnel.

Поскольку ztunnel развёрнут как DaemonSet, Kubernetes автоматически перезапустит его — так же, как и любой другой pod из daemonset.

Так является ли ztunnel SPOF? Конечно, нет.

Архитектура изначально предполагает, что ноды могут падать — это нормально для распределённых систем.

Восстановление обрабатывается автоматически самим Kubernetes.

Понимание таких архитектурных паттернов помогает проектировать более надёжные системы и уверенно отвечать на подобные вопросы во время внедрения

👉 DevOps Portal

Этот исследование показывает, как авторы использовали динамическое разбиение MIG для разделения крупных GPU, таких как NVIDIA A100/H100, на несколько изолированных слайсов, чтобы множество небольших задач могли эффективно шарить один GPU

Читать тут

👉 DevOps Portal

Разработчики часто разворачивают приложения вроде NGINX в Kubernetes.

Но при этом им приходится писать множество YAML-манифестов, таких как:

Deployments, Services, Ingress и ConfigMaps.

Управлять всем этим бывает довольно сложно.

KRO (Kubernetes Resource Orchestrator) решает эту проблему с помощью переиспользуемых шаблонов, называемых ResourceGroups.

Разработчику достаточно указать простые параметры — например, имя приложения, количество реплик или тег образа — и KRO автоматически создаст все необходимые ресурсы Kubernetes.

Вот как это работает:

- Вы создаёте определение ResourceGroup, которое объединяет несколько Kubernetes-ресурсов в один шаблон.
- Контроллер KRO отслеживает такие инстансы и автоматически провиженит все связанные ресурсы в правильном порядке.
- Он управляет зависимостями между ресурсами, гарантируя корректную последовательность их создания.

В отличие от Helm или Kustomize, KRO работает напрямую на уровне Kubernetes API, что упрощает управление ресурсами и интеграцию с GitOps-пайплайнами.

Репозиторий GitHub: https://github.com/kubernetes-sigs/kro

👉 DevOps Portal

Docker 101: Как извлечь файловую систему образа контейнера?

Образы состоят из слоёв, и каждый слой содержит diff изменений файловой системы. Однако, когда вы запускаете контейнер из образа, он получает обычную «плоскую» rootfs (корневую файловую систему).

Разберитесь с несколькими способами её инспекции:
https://labs.iximiuz.com/challenges/extract-container-image-filesystem

👉 DevOps Portal

Linux 101: Защити открытый порт с помощью правил фаервола

HTTP-сервис уже запущен на сервере и слушает 0.0.0.0:8080. Твоя задача – защитить этот порт, не перезапуская и не перенастраивая сервис.

Сможешь решить задачу? https://labs.iximiuz.com/challenges/linux-protect-ports

👉 DevOps Portal

Эта статья рассказывает, как в Dream11 собрали собственную observability-платформу на базе SigNoz, ClickHouse и OpenTelemetry, чтобы обрабатывать миллионы метрик и трейсов с тысяч EC2-инстансов и при этом сэкономить миллионы на коммерческих инструментах.

Читайте тут

👉 DevOps Portal

База по сетевым технологиям для разрабов, девопсов и платформенных инженеров

Мини-курс с кучей наглядных схем по уровням Ethernet и IP (L2/L3) в компьютерных сетях. В комплекте — богатый набор практических лабораторных работ

Забираем здесь 🍯

👉 DevOps Portal

HTTP (HyperText Transfer Protocol)

Данные передаются в открытом виде, и любой в сети может их перехватить или прочитать – протокол небезопасен.
Пример: http://example.com

Шифрование отсутствует, поэтому соединение уязвимо для атак.

HTTPS (HTTP Secure)

Данные передаются в зашифрованном виде, и злоумышленники не могут их прочитать или изменить – соединение считается безопасным.
Пример: https://example.com

Данные защищены.

👉 DevOps Portal

Как Kubernetes вообще понимает, что в вашем кластере есть GPU?

Kubernetes сам по себе не умеет обнаруживать GPU.

Он полагается на device plugin’ы, которые запускаются как DaemonSet’ы на нодах с GPU.

Когда вы устанавливаете NVIDIA GPU Operator или соответствующий device plugin, он регистрирует GPU-ресурсы в kubelet на каждой ноде.

Плагин объявляет доступные GPU как расширенные ресурсы (например, nvidia.com/gpu: 1).

После регистрации kubelet репортит эти ресурсы в API server, и они становятся доступными для планировщика (schedulable).

После этого ваши поды могут запрашивать GPU через resource limits в своих спецификациях.

Без device plugin’а Kubernetes вообще не знает, что на нодах есть GPU, даже если железо физически присутствует.


Читайте здесь: https://newsletter.devopscube.com/p/gpu-scheduling-kubernetes

Примечание: в Kubernetes 1.32 появился Dynamic Resource Allocation (DRA) — следующий этап эволюции управления аппаратными ресурсами.

Он предоставляет более гибкое и детализированное распределение ресурсов, которое невозможно реализовать с помощью device plugin’ов.

Тем не менее, device plugin’ы по-прежнему широко используются в продакшене, и на данный момент оба подхода сосуществуют.

👉 DevOps Portal

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

Ключевая идея (просто):

В отличие от Deployment (где поды считаются взаимозаменяемыми), StatefulSet даёт каждому поду:
- Стабильное имя → app-0, app-1, app-2
- Персистентное хранилище → каждый под сохраняет свои данные
- Упорядоченный запуск/остановку → поды стартуют и завершаются последовательно

Используй StatefulSet, когда приложение:
- Требует сохранения данных (например, базы данных)
- Нуждается в уникальной идентичности для каждого пода
- Требует упорядоченного масштабирования

Примеры:
- MySQL кластер
- MongoDB
- Kafka
- Redis (в режиме кластера)

👉 DevOps Portal

Этот туториал объясняет, как создавать и деплоить production-ready микрофронтенды в Kubernetes.

Также в нём рассматривается настройка ingress-роутинга для module federation и реализация CI/CD пайплайнов для изолированных команд микрофронтенда.

Читайте тут

👉 DevOps Portal

Как работают мультиплатформенные container images

Когда вы делаете docker pull nginx:1.29 на AMD64-сервере и на ARM64-ноутбуке, Docker подтягивает совершенно разные сборки образа. Но как это возможно, если в обоих случаях используется одно и то же имя образа?

Чтобы представить несколько сборок через одну ссылку на образ (например, nginx:1.29), container registry использует специальный файл — Image Index, в котором перечислены манифесты для отдельных платформенных сборок. Поэтому при pull появляется дополнительный шаг:

- Сначала запрашивается index по адресу https://registry.example[.]com/v2/REPO/manifests/TAG

- Затем в index находится манифест образа для нужной платформы, после чего он запрашивается по digest: https://registry.example[.]com/v2/REPO/blobs/DIGEST

- И уже после этого по digest’ам из манифеста подтягиваются config образа и blobs слоёв файловой системы

Для single-platform image ссылка https://registry.example[.]com/v2/REPO/manifests/TAG указывает сразу на его manifest. То есть здесь на один уровень косвенности меньше.

Подробнее о внутреннем устройстве container images:
https://labs.iximiuz.com/tutorials/container-image-from-scratch

👉 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

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

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

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

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

👉 DevOps Portal

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

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

👉 DevOps Portal

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

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

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

👉 DevOps Portal

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

👉 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

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

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

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

👉 DevOps Portal