Зачем это нужно
Не каждый сервис в k8s одинаковый. Stateless inference API масштабируется копиями; база метаданных требует стабильных имён томов; batch-пересчёт признаков — разовая Job; агент сбора метрик на каждой node — DaemonSet. Выбор неправильного workload — типичная ошибка: StatefulSet для stateless API или Deployment для задачи «прогнать ETL один раз».
Основные идеи
Deployment — stateless приложения. Основной тип для ML inference, REST API, workers без локального state. Управляет ReplicaSet → Pod'ы. Поддерживает rolling update и rollback. Поля: replicas, template.spec.containers[].image, probes.
apiVersion: apps/v1 kind: Deployment metadata: name: scorer spec: replicas: 3 selector: matchLabels: app: scorer template: metadata: labels: app: scorer spec: containers: - name: api image: registry.example.com/ml/scorer:128 ports: - containerPort: 8080
StatefulSet — стабильная идентичность. У Pod'ов предсказуемые имена (scorer-0, scorer-1) и persistent volume claim template. Используйте для баз данных, Kafka-брокеров, не для обычного FastAPI.
DaemonSet — по Pod на node. Логи (fluent-bit), мониторинг (node-exporter), GPU device plugin. На каждой (или выбранной) node ровно один экземпляр.
Job / CronJob — batch. Job завершается после успеха: nightly retrain, backfill фич, export датасета. CronJob — расписание cron. Не держите бесконечный цикл в Job — для сервисов Deployment.
ReplicaSet. Низкоуровневый контроллер количества Pod; обычно управляется Deployment, напрямую редко создаёте.
Probes. livenessProbe — перезапуск при зависании; readinessProbe — Pod получает трафик только когда готов (модель загружена в память). Для ML inference readiness критичен: большой .onnx грузится секунды.
Resource requests/limits. resources.requests.cpu/memory — для scheduler; limits — потолок. Без requests Pod может «съесть» node; GPU — отдельный ресурс (nvidia.com/gpu).
Как это выглядит на практике
| Задача | Workload |
|---|---|
| Online scoring API | Deployment + HPA |
| PostgreSQL для feature metadata | StatefulSet + PVC |
| Ежедневный batch predict | CronJob |
| Сбор логов с node | DaemonSet |
| Разовый migration script | Job |
Практикум модуля 3.3: Deployment + Service + PVC + HPA — inference с конфигом на диске и автомасштабированием по CPU (или custom metrics позже).
Rolling update: kubectl set image deployment/scorer api=...:129 или через Helm. Старые Pod'ы гасят по одному, если readiness зелёный — zero-downtime.
Anti-pattern: хранить обученную модель только inside Pod без volume — при restart модель теряется, если не baked in image.
Что сделать после занятия
Создайте Deployment с 2 replicas и проверьте
kubectl get pods -o wide— на каких nodes они сели.Добавьте readinessProbe HTTP GET
/healthи убедитесь, что Service не шлёт трафик до ready.Опишите, какой workload вы бы выбрали для nightly batch scoring — обоснуйте.