Как обученная AI-модель превращается в production API в Kubernetes?

KServe — это проект CNCF на стадии Incubating для развёртывания и обслуживания AI-моделей в Kubernetes.

Проще говоря, KServe берёт обученную модель и превращает её в масштабируемый inference-сервис в Kubernetes.

Он берёт на себя деплой, сеть, автоскейлинг и health checks модели.

Важно понимать, что KServe уже давно работает не только с классическими ML-моделями.

Как inference-платформа, он поддерживает две категории AI/ML-нагрузок:

- Predictive AI (классический ML): например, модели на scikit-learn, XGBoost, модели, упакованные через MLflow, и другие.
- Generative AI (LLM): например, запуск и обслуживание LLM через backend vLLM с поддержкой GPU.

Если хотите разобраться, как устроена inference-платформа KServe, можно прочитать свежий выпуск MLOps-рассылки.

В нём разбираются:
- Model Servers и runtimes в KServe
- Как KServe разворачивает AI-модели в Kubernetes
- Деплой MLflow-модели в KServe на практике
- Как выкатывать новые версии моделей
- Rolling Updates, Canary, A/B Testing и Shadow Deployments

И многое другое.

Читать здесь: https://newsletter.devopscube.com/p/kserve

Многие ли знают, что 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

VPN, который просто работает.

RuSolv — подключение за несколько минут, 50+ серверов и современные протоколы для стабильного доступа к интернету.

✓ 10 ГБ каждый месяц бесплатно
✓ Без привязки карты
✓ Без логов
✓ Телефон, компьютер и другие устройства

Попробуйте бесплатно → https://rusolv.com

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

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

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

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

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

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

Участвуй в КосмоХакатоне 4–6 сентября, решай реальные космические кейсы, поборись за 1,2 млн ₽ и шанс попасть в финал в Москве!

С 4 по 6 сентября в Ростове-на-Дону пройдёт КосмоХакатон Южного и Северо-Кавказского федеральных округов — масштабное соревнование для тех, кто готов превратить данные о нашей планете в реальные технологические решения.

Один хакатон — два формата: участвовать можно очно в Ростове-на-Дону или онлайн из любой точки России. Все команды работают над едиными кейсами, оцениваются по одинаковым критериям и участвуют в общем рейтинге.

В рамках хакатона также пройдёт открытая лекция «Применение космических технологий для решения экологических задач» от Игоря Кожелина, CEO SR Data.
Призовой фонд — 1 200 000₽

Даты проведения: 4–6 сентября
Формат: онлайн и офлайн
Очная площадка: Центр развития предпринимательства «Новый Ростов», ул. Максима Горького, 151, 4 этаж.
🔗 Зарегистрироваться: https://космохакатон.рф

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

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

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

Popeye — опенсорсный инструмент от создателя k9s, который проверяет ресурсы работающего Kubernetes-кластера на ошибки конфигурации и наличие неиспользуемых ресурсов.

Что умеет 👇
- Находит неиспользуемые ConfigMaps, Secrets, ServiceAccounts, PV, PVC и RBAC-роли.
- Выявляет Services без endpoints или соответствующих Pods.
- Проверяет Pods на отсутствие проб, лимитов ресурсов и использование тега latest у образов.
- Показывает распределение CPU и памяти при наличии metrics-server.
- Оценивает состояние кластера по шкале от 0 до 100.
- Экспортирует отчёты в форматах HTML, JSON, YAML, JUnit и Prometheus.
- Может запускаться как CronJob и отправлять отчёты в S3.

Начать работу: github.com/derailed/popeye

Примечание: Popeye работает в режиме read-only, поэтому ничего не изменяет в кластере.

Kubernetes: Client-Side Apply vs Server-Side Apply

При выполнении команды kubectl apply по умолчанию используется Client-Side Apply (CSA).

При использовании Client-Side Apply утилита kubectl анализирует манифест, ранее применённую конфигурацию и текущее состояние объекта в кластере.

На основе этих данных kubectl определяет, что изменилось, и отправляет необходимый патч на API-сервер Kubernetes.

Server-Side Apply (SSA) работает иначе.

При выполнении команды kubectl apply --server-side операцию применения конфигурации выполняет сам API-сервер Kubernetes.

Главное отличие — владение полями.

В руководстве ниже подробно объясняется эта разница.

Подробное руководство: https://skills.devopscube.com/kubernetes-client-side-vs-server-side-apply/

Изучение Linux через устранение неполадок на серверах

Подборка практических сценариев по диагностике и устранению проблем, которые помогут прокачать навыки работы с Linux:

- Демон отправки логов, который не запускается — https://labs.iximiuz.com/challenges/linux-strace-failing-daemon
- Демон конвертации изображений с отсутствующими зависимостями — https://labs.iximiuz.com/challenges/linux-missing-shared-library
- Воркер-сервис, который постоянно исчезает — https://labs.iximiuz.com/challenges/linux-debug-vanishing-worker-service
- Несколько сервисов разработки, конфликтующих из-за одного порта — https://labs.iximiuz.com/challenges/linux-resolve-port-conflict
- Привилегированный демон с некорректно настроенным контролем доступа — https://labs.iximiuz.com/challenges/linux-restrict-unix-socket-access

Удачного хакинга!

В этом кейсе показано, как WSC Sports полностью перестроила модель деплоя: от пайплайнов с helm upgrade до полноценного GitOps на базе ArgoCD ApplicationSets.

Рассматриваются:
- Архитектура монорепозитория с единым Helm-чартом;
- Теневые деплои;
- AppProjects;
- Механизмы заморозки кода в CI.

➜ https://medium.com/@elad320011/gitops-at-enterprise-scale-inside-wsc-sports-deployment-platform-5ee373431309