Большинство инженеров каждый день работают с Kubernetes, но не могут объяснить, что происходит после запуска kubectl apply.

Разберём по шагам.

Когда вы применяете манифест, на самом деле происходит следующее:
- kubectl отправляет YAML в kube-apiserver
- API Server валидирует манифест, аутентифицирует запрос и записывает желаемое состояние в etcd
- Scheduler отслеживает Pod'ы, которые ещё не назначены ни на одну ноду. Он оценивает доступные ноды, выбирает наиболее подходящую и привязывает к ней Pod
- kubelet на выбранной ноде видит новое назначение Pod'а. Он скачивает образ, запускает контейнер и отправляет статус обратно
- kube-proxy следит за изменениями Service'ов и Endpoint'ов. Он обновляет правила iptables или IPVS, чтобы трафик мог доходить до вашего Pod'а

А теперь самое интересное.
- Вся система работает по событийной модели — event-driven. Компоненты не опрашивают друг друга
- Каждый компонент следит за изменениями через API Server и реагирует только тогда, когда это необходимо

Именно поэтому Kubernetes называют системой desired state — «желаемого состояния».

Вы декларативно описываете, что хотите получить. А Kubernetes сам приводит систему к этому состоянию.

В материале подробно разбирается архитектура Kubernetes и показывается, что на самом деле происходит под капотом после запуска kubectl apply.

Читать здесь:
https://devopscube.com/kubernetes-architecture-explained/

👉 DevOps Portal

KubeTable — это local-first десктопное приложение для работы с базами данных внутри Kubernetes-кластеров.

Оно находит базы через ваш kubeconfig, само поднимает port-forward и позволяет напрямую выполнять запросы к PostgreSQL, MySQL, Redis или MongoDB.

➜ https://github.com/kubetable/kubetable

👉 DevOps Portal

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

Запуск AI-моделей в Kubernetes часто означает необходимость управлять vLLM, автоскейлингом, Knative и кучей YAML-файлов, которые со временем становится сложно поддерживать.

KubeAI заменяет весь этот стек одним оператором.

KubeAI — это open-source Kubernetes-оператор, который деплоит и масштабирует AI-модели через простую конфигурацию на базе CRD.

Что он умеет 👇

* Деплоит и масштабирует AI-модели через простую CRD-конфигурацию.
* Направляет связанные запросы на одну и ту же реплику, чтобы vLLM переиспользовал закэшированный контекст вместо того, чтобы пересобирать его каждый раз.
* Деплоит модели из встроенного каталога, уже настроенного под распространённые типы GPU, поэтому не приходится вручную подбирать большую часть флагов vLLM.
* Автоматически скачивает и монтирует модели, поддерживая кеширование через AWS EFS и GCP Filestore.

https://github.com/kubeai-project/kubeai

👉 DevOps Portal

Ballast — это Kubernetes-оператор, который анализирует историю реального потребления ресурсов и сам корректирует CPU- и memory requests – либо на этапе admission, либо прямо у уже запущенных Pod’ов.

➜ https://github.com/Tight-Line/ballast

👉 DevOps Portal

Как собирать компактные образы контейнеров

Подробный разбор того, из-за чего production-образы обычно раздуваются и как этого избежать с помощью multi-stage builds и грамотного выбора базовых образов.

С практическими примерами для Node.js, Go, Rust, Java и PHP:
https://labs.iximiuz.com/tutorials/docker-multi-stage-builds

👉 DevOps Portal

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

Собрать RAG-пайплайн с нуля - непростая задача.

Нужно самостоятельно реализовать:
• Парсинг документов
• Чанкинг и создание эмбеддингов
• Хранение в векторной базе
• Логику поиска и re-ranking

При этом большинство документов - это далеко не чистый текст: в них есть таблицы, изображения, отсканированные страницы и сложное форматирование.

Для базового RAG-пайплайна корректно обрабатывать всё это может быть сложно.

Здесь и помогает RAGFlow.

RAGFlow — open-source RAG-движок, который умеет работать со сложными и плохо структурированными документами, отвечать на вопросы по их содержимому и показывать, из каких источников были взяты данные.

Вот что он умеет
• Парсит сложные документы: PDF с таблицами, сканы, Word, Excel, изображения и веб-страницы
• Использует шаблонный чанкинг, позволяя контролировать, как именно документы разбиваются на части
• Показывает, какие именно чанки использовались для каждого ответа, чтобы можно было отследить источники
• Синхронизирует данные из S3, Notion, Confluence, Google Drive и Discord
• Поддерживает агентные workflows и MCP
• Работает с любыми LLM и моделями эмбеддингов

https://github.com/infiniflow/ragflow.git

👉 DevOps Portal

Kubernetes In-Place Pod Resize

Раньше в Kubernetes нельзя было изменить CPU или memory для уже запущенного Pod без его перезапуска.

Но функция In-Place Pod Resize решает эту проблему.

Вот подробный материал, в котором разобрали:

* Что такое In-Place Pod Resize
* Как это работает под капотом
* Зачем нужен VPA для изменения ресурсов Pod без перезапуска
* Что происходит, если на ноде не хватает ресурсов
* Когда стоит использовать Resize Policy
* С какими проблемами можно столкнуться при уменьшении ресурсов и многое другое

https://devopscube.com/vpa-in-place-pod-resize

👉 DevOps Portal

Подборка всегда актуальных DevOps-песочниц

В каждой песочнице можно запустить до 5 Linux VM и использовать окружение до 24 часов:

* Ubuntu 26.04, Debian Trixie, Fedora 44
* Kubernetes 1.37, Docker и Podman
* Go 1.27, Python 3.14, Node 26

Практикуйтесь как профи: https://labs.iximiuz.com/playgrounds

👉 DevOps Portal

В этой статье рассказывается, как спроектировать AI-агента для SRE-задач, который анализирует алерты, логи, данные Kubernetes, ранбуки, деплои и сигналы observability, чтобы диагностировать инциденты и предлагать безопасные действия.

https://blog.stackademic.com/building-an-ai-agent-that-runs-your-sre-operations-what-i-learned-what-works-and-how-you-can-do-8a3801124bdc

👉 DevOps Portal

Все мониторят поды, но почти никто не следит за этим критически важным компонентом

А потом в Kubernetes-кластере что-то ломается – и внезапно etcd становится самым важным компонентом всей инфраструктуры.

Потому что etcd – это мозг Kubernetes.

Каждый Deployment, Secret, ConfigMap и Node хранится в etcd в виде данных.

И вот что многие понимают неправильно:

Только API Server взаимодействует с etcd напрямую.

Поэтому если с etcd возникают проблемы, кластер перестаёт принимать любые новые изменения. Вы не сможете ничего задеплоить, масштабировать или обновить.

Даже сейчас многие инженеры допускают базовые ошибки при работе с etcd.

Не делают регулярные бэкапы. Запускают etcd на том же диске, где находится ОС. Или игнорируют проблемы с latency в распределённых конфигурациях.

В продакшене etcd должен работать на быстрых SSD и быть изолирован от других workloads. Бэкапы должны выполняться автоматически.

В подробном гайде разобрали бэкап и восстановление etcd

Читать: https://devopscube.com/backup-etcd-restore-kubernetes/

👉 DevOps Portal

Разворачиваем Llama 3 с Docker и vLLM

Запуск LLM – это не просто поднять контейнер.

Здесь важны производительность, память и эффективное использование GPU.

В этом гайде разберём:
- Настройку GPU-окружения: Docker + NVIDIA Runtime
- Деплой модели с Llama и vLLM
- Оптимизацию памяти с помощью флага --gpu-memory-utilization, чтобы сбалансировать VRAM между весами модели и KV Cache
- Техники квантизации, которые позволяют увеличить throughput более чем в 2 раза — с 1,62 до 3,64 req/s — и вдвое сократить потребление VRAM
- Как работает Continuous Batching

Подробный гайд:
https://devopscube.com/deploying-llama-with-docker-and-vllm/

Следуя экспериментам по оптимизации из гайда, можно получить:
- рост общего throughput в 2,2 раза
- Time to First Token (TTFT) в 3 раза быстрее
- от 5 до 20+ одновременных пользователей на том же железе — NVIDIA RTX 4000

Примечание: этот гайд предназначен для обучения и экспериментов. Используйте его, чтобы разобраться в основных концепциях.

👉 DevOps Portal

keda-gpu-scaler — это внешний scaler для KEDA, который считывает GPU-метрики через NVML на каждом узле. Благодаря этому deployments с vLLM и Triton масштабируются по реальной нагрузке на GPU, а не по CPU, включая scale-to-zero

➜ https://github.com/pmady/keda-gpu-scaler

👉 DevOps Portal

Что такое Distroless-образ контейнера? 🧐

Go известен своими статически слинкованными бинарниками. Можно взять исполняемый файл Go, положить его в контейнер с FROM scratch - и на этом закончить.

Но у такого подхода есть несколько проблем...

1. В контейнерах FROM scratch нет нормального управления пользователями

Базовый образ scratch — это буквально пустой образ. Поэтому файлов /etc/passwd и /etc/group там просто нет.

Из-за этого контейнеризированный процесс в большинстве случаев запускается от root.

2. В FROM scratch отсутствуют некоторые важные директории

/tmp, /root, /home, /var, /etc — ничего из этого в scratch-контейнере нет, если, конечно, вы не примонтируете нужные директории самостоятельно.

Из-за этого приложение может работать некорректно — попробуйте, например, создать временный файл и посмотрите, что произойдёт 😉

3. В FROM scratch нет CA-сертификатов и данных о часовых поясах

Нужно обратиться к HTTPS-эндпоинту? Не получится.

Нужно выполнить преобразование времени между часовыми поясами? Тоже не получится.

4. В FROM scratch нет runtime вашего языка

Если поддержка статической линковки в вашем языке не настолько хороша, как в Go, либо приложению нужен интерпретатор или runtime-окружение, использовать scratch-контейнеры становится практически невозможно.

Distroless-образы как раз решают эти проблемы, при этом оставаясь максимально близкими к подходу FROM scratch.

Хороший пример — проект GoogleContainerTools/distroless. В нём есть следующие базовые образы:
- distroless/static = scratch + структура директорий, похожая на обычный дистрибутив, /etc/{passwd,group}, CA-сертификаты и данные о часовых поясах
- distroless/base = distroless/static + glibc
- distroless/cc = distroless/base + libgcc

Также есть несколько специализированных под конкретные языки, но всё ещё distroless-образов:
- distroless/java — для Java 17, 21 и 25
- distroless/nodejs — для Node.js 22, 24 и 26
- distroless/python3 — соответственно, для Python 3

Но существуют и другие проекты и продукты.

Подробнее о distroless-образах - в туториале iximiuz Labs:
https://labs.iximiuz.com/tutorials/gcr-distroless-container-images

👉 DevOps Portal

Новый челлендж по Kubernetes на iximiuz Labs:

Получите доступ к приватному Kubernetes-кластеру через SSH SOCKS-прокси 🧙‍♂️

Попрактикуйтесь в удобном способе подключения к Kubernetes API Server без проброса конкретного порта и без необходимости менять адрес сервера в kubeconfig:
https://labs.iximiuz.com/challenges/access-kubernetes-api-through-ssh-socks-proxy

👉 DevOps Portal

Самый красивый сайт, который я сегодня видел:
https://kubernetes3d.com/rack

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

Обратите внимание: все кнопки и сцены здесь интерактивны, поэтому сайт отлично подходит ещё и для изучения концепций. Я уже довольно долго с ним играюсь

👉 DevOps Portal

GitLab Architecture: A Complete Guide

В этом вводном гайде вы узнаете:

- Основные компоненты GitLab
- Хранилище GitLab
- Высокая доступность и масштабируемость
- Аутентификация и авторизация
- Мониторинг GitLab с помощью Prometheus и Grafana

Подробное руководство: https://devopscube.com/gitlab-architecture/

👉 DevOps Portal

🤖 DevOps в эпоху AI трансформации: что работает уже сейчас!

17 сентября Сбер собирает DevOps-инженеров, SRE и платформенные команды на встречу о том, как AI меняет работу с инфраструктурой, релизами и безопасностью.

Обсудим:
🔘Platform Engineering и IDP: как строить внутренние платформы без лишней сложности
🔘Agentic engineering: каких агентов уже можно доверить пайплайнам
🔘Security на скорости: как закрывать уязвимости, когда счет идет на часы

Своим опытом поделятся практики из Авито, Сбера, Cloud․ru и Т-Банка.

Встречаемся 17 сентября в 17:00 в Сбер.Среде (Москва, Земляной Вал 9А) или онлайн. Мест всего 150 — успей занять своё по ссылке!