Model Server — одно из ключевых понятий в MLOps.

Если говорить проще:

* Nginx-сервер обслуживает веб-приложения
* Model Server обрабатывает inference-запросы к ML-модели

Работает это следующим образом.

Model Server загружает артефакты обученной модели в оперативную память или память GPU, чтобы не загружать модель заново при каждом запросе.

Он предоставляет inference-эндпоинты по HTTP и gRPC.

Также он экспортирует метрики и трейсы – например, через Prometheus и OpenTelemetry (OTEL).

Среди часто используемых Model Server – MLServer, TensorFlow Serving, NVIDIA Triton Inference Server и другие.

Теперь важный момент.

Model Server сам по себе не умеет горизонтально масштабироваться.

Для масштабирования и обеспечения высокой доступности поверх него используется оркестрация Kubernetes.

Когда речь идёт о model serving, KServe – один из ключевых serving-фреймворков для Kubernetes.

Model Server отвечает за обработку inference-запросов, а KServe выступает в роли слоя оркестрации.

👉 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

Многие ли знают, что Helm хранит информацию о релизах в Kubernetes Secrets?

Когда вы запускаете helm install или helm upgrade, Helm сохраняет данные о релизе в K8s Secrets в том же namespace.

В Secret хранится, например:
- имя релиза;
- статус деплоя;
- применённые манифесты;
- использованные values;
- информация о chart и другие данные.

Данные в Secret сжимаются с помощью gzip, а затем кодируются в base64.

Имя Secret создаётся по следующему шаблону:
sh.helm.release.v1.[release-name].v[revision]

Когда вы запускаете helm rollback, Helm читает эти Secrets, чтобы восстановить приложение до предыдущей версии.
Helm не нужна внешняя база данных.

Вся информация хранится прямо в вашем кластере в виде нативных Kubernetes Secrets.

Примечание: также можно настроить внешнюю SQL-базу данных для хранения релизов, но эта возможность пока находится в beta

👉 DevOps Portal

Hubble — полностью распределённая платформа для observability сетевого взаимодействия и безопасности cloud-native workloads.

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

➜ https://github.com/cilium/hubble

👉 DevOps Portal

Паттерн проектирования sidecar – удобный способ вынести прокси, агенты доставки логов, агенты для provisioning секретов и другие вспомогательные процессы за пределы основного контейнера приложения.

Начиная с Kubernetes 1.28, поддержка sidecar-контейнеров стала нативной – и реализована довольно элегантно: никакого нового типа контейнеров, просто initContainer с restartPolicy: Always.

Попрактиковаться в работе с нативными sidecar-контейнерами Kubernetes можно здесь:
https://labs.iximiuz.com/tutorials/kubernetes-native-sidecars

👉 DevOps Portal

С Kubernetes-сетями довольно быстро становится сложно, как только выходишь за рамки базовых Service.

В этом туториале Ayobami разбирает, как работают сеть между Pod’ами, ClusterIP, Ingress-контроллеры, NetworkPolicy и CNI-плагины.

Также сравниваются разные CNI и показывается, как Cilium использует eBPF для сетевого взаимодействия, observability и возможностей service mesh.

https://freecodecamp.org/news/kubernetes-networking-explained-from-clusterip-to-cilium-service-mesh/

👉 DevOps Portal

SSH-туннели, или как стать магом сетевой связности

10 практических челленджей, чтобы прокачать port forwarding через SSH-туннели — от простого локального/удалённого проброса портов до продвинутых сценариев с bastion- и jump-хостами:

- Получить доступ к внутреннему debug-порту через SSH-туннель
https://labs.iximiuz.com/challenges/ssh-local-port-forwarding
- Достучаться до приватного сервиса в VPC через SSH-бастион
https://labs.iximiuz.com/challenges/ssh-local-port-forwarding-bastion
- Получить доступ к удалённому loopback-порту через SSH jump host
https://labs.iximiuz.com/challenges/ssh-local-port-forwarding-jump-host
- Ограничить доступ к SSH-бастиону в зависимости от роли пользователя
https://labs.iximiuz.com/challenges/ssh-local-port-forwarding-bastion-hardened
- Получить доступ к внутренним серверам через SSH-бастион без shell-доступа
https://labs.iximiuz.com/challenges/ssh-jump-host-internal-servers
- Получить доступ ко всей VPC через SSH SOCKS-прокси
https://labs.iximiuz.com/challenges/ssh-socks-proxy
- Пробросить локальный сервис наружу через обратный SSH-туннель
https://labs.iximiuz.com/challenges/ssh-remote-port-forwarding
- Пробросить устройство из домашней сети через обратный SSH-туннель
https://labs.iximiuz.com/challenges/ssh-remote-port-forwarding-home-network
- Пробросить всю домашнюю сеть через обратный SSH SOCKS-прокси
https://labs.iximiuz.com/challenges/ssh-reverse-socks-proxy
- Заменить root-доступ по паролю на админский логин по SSH-ключу
https://labs.iximiuz.com/challenges/ssh-harden-new-server

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

👉 DevOps Portal

Kubernetes HPA не ограничивается только CPU и памятью

Ворклоады можно скейлить и по кастомным метрикам, например

- количество запросов в секунду (RPS)
- длина очереди
- количество активных соединений
- latency приложения

Для этого можно использовать связку HPA + Prometheus + Prometheus Adapter.

Prometheus Adapter прокидывает метрики через Kubernetes Custom Metrics API, после чего HPA использует их для автоскейлинга.

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

В этой рассылке разобрали, как работает HPA tolerance.

Читать здесь:
https://newsletter.devopscube.com/p/kubernetes-hpa-tolerance-levels

👉 DevOps Portal

Большинство инженеров каждый день работают с 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