3.3.2 · блок 3

Workloads: Deployment, StatefulSet, Job и другие

Зачем это нужно

Не каждый сервис в 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 — обоснуйте.

Официальные материалы

Открыть интерактивную версию