Налаштування Canary Deployment для ML-моделей на Kubernetes

Зазначимо: коли нова версія ML-моделі потрапляє в продакшен, ми не знаємо, як вона поводитиметься під реальним навантаженням. Якось ми викотили модель, яка на тестових даних показувала відмінні метрики, але в production почала генерувати хибні спрацьовування на 30% запитів. Відкат зайняв 20 хвилин — хвилини, які коштували клієнту значної суми. Саме для таких ситуацій потрібен canary deployment — стратегія, що знижує MTTR у 3-5 разів і економить бюджет на інцидентах.

Ми практикуємо канаркове розгортання для ML-моделей на Kubernetes з використанням KServe, Seldon Core або Argo Rollouts, з автоматичним відкатом на основі метрик моніторингу. Наш досвід — 5+ років і 20+ проєктів у MLOps — підтверджує: canary з guardrails знижує MTTR до 45 секунд проти 22 хвилин при повному відкаті. В одному з проєктів економія на кожному інциденті склала близько $360–520.

Коли canary кращий за blue-green

Blue-green перемикає весь трафік одразу — підходить для сервісів з високою впевненістю в новій версії. Canary потрібен, коли:

• Модель навчена на нових даних, але реакція користувачів непередбачувана.
• Змінилася архітектура моделі (інший тип, інші вхідні ознаки).
• Критичний production-сервіс з високою ціною помилки.
• Немає повного набору інтеграційних тестів.

Порівняємо ключові характеристики:

Canary дає можливість контрольовано збільшувати трафік і автоматично відкочуватися на основі метрик, що критично для production-сервісів з високою ціною помилки.

Як canary знижує MTTR?

MTTR — ключова метрика при збоях. При повному відкаті доводиться перестворювати поди, перемикати трафік і перевіряти логи. Це займає 15-30 хвилин. Canary з автоматичним відкатом реагує за секунди: щойно error rate перевищив 1% або p99 latency перевалив за 500ms, скрипт відкочує канарейку без участі інженера. В одному з наших проєктів MTTR знизився з 22 хвилин до 45 секунд — у 30 разів швидше, що заощадило клієнту близько $360–520 на кожен інцидент.

Реалізація на Kubernetes з KServe

KServe (колишній KFServing) підтримує canary з коробки. Документація KServe рекомендує починати з 5-10% трафіку на канарейку.

---
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: fraud-detector
spec:
  predictor:
    canaryTrafficPercent: 10 # 10% на нову версію
    model:
      modelFormat:
        name: sklearn
      storageUri: s3://models/fraud-detector-v2/ # Попередня версія - canary baseline
---

Перемикання трафіку без даунтайму:

# Збільшення з 10% до 50%
kubectl patch inferenceservice fraud-detector \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/predictor/canaryTrafficPercent", "value": 50}]'

# Просування канарейки в production (100%)
kubectl patch inferenceservice fraud-detector \
  --type='json' \
  -p='[{"op": "remove", "path": "/spec/predictor/canaryTrafficPercent"}]'

Покрокове налаштування canary з KServe

1. Встановіть KServe та його залежності (Istio, Knative) в кластер Kubernetes.
2. Створіть InferenceService з canaryTrafficPercent: 10 і вкажіть URI нової моделі.
3. Налаштуйте моніторинг метрик (error rate, latency, drift) через Prometheus та алерти в Grafana.
4. Запустіть скрипт прогресивного збільшення трафіку, який перевіряє guardrails і автоматично відкочує при перевищенні порогів.
5. Після успішного досягнення 100% видаліть поле canaryTrafficPercent.

Реалізація на Seldon Core

---
apiVersion: machinelearning.seldon.io/v1
kind: SeldonDeployment
metadata:
  name: fraud-detector
spec:
  predictors:
    - name: main
      replicas: 3
      traffic: 90
      graph:
        name: fraud-v1
        implementation: SKLEARN_SERVER
        modelUri: s3://models/fraud-v1
    - name: canary
      replicas: 1
      traffic: 10
      graph:
        name: fraud-v2
        implementation: SKLEARN_SERVER
        modelUri: s3://models/fraud-v2

Автоматичний відкат налаштовується через PrometheusRule: при перевищенні error rate більше 1% або p99 latency вище 500ms спрацьовує алерт, який запускає зниження трафіку канарейки до 0.

Автоматичне управління трафіком

Прогресивне збільшення трафіку автоматично на основі метрик. Ми використовуємо скрипт, який перевіряє guardrail-метрики на кожному етапі:

def progressive_canary_rollout(service_name, metrics_client):
    stages = [5, 10, 25, 50, 100]
    for target_traffic in stages:
        set_canary_traffic(service_name, target_traffic)
        time.sleep(300) # 5 хвилин стабілізації
        metrics = metrics_client.get_metrics(window='5m')
        # Перевірка guardrail метрик
        if metrics['canary_error_rate'] > 0.01:
            rollback_canary(service_name)
            alert(f"Canary rollback: error rate {metrics['canary_error_rate']:.2%}")
            return False
        if metrics['canary_p99_latency_ms'] > 500:
            rollback_canary(service_name)
            alert("Canary rollback: latency SLA violated")
            return False
        if metrics['business_metric_delta'] < -0.02: # -2% деградація
            rollback_canary(service_name)
            alert("Canary rollback: business metric degraded")
            return False
    return True # Успішний повний деплой

Автоматичний відкат при перевищенні порогів помилок або затримок спрацьовує без участі інженера — це стандартна практика в наших проєктах.

Які метрики використовувати для автоматичного відкату?

Інтеграція з Argo Rollouts

Argo Rollouts — Kubernetes-контролер з підтримкою canary та blue-green для будь-яких workload, не тільки ML:

---
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: {duration: 5m}
        - setWeight: 25
        - pause: {duration: 10m}
        - setWeight: 50
        - pause: {duration: 10m}
        - analysis:
            templates:
              - templateName: ml-model-metrics

Обсяг робіт з налаштування canary deployment

Ми надаємо повний пакет під ключ:

• Проектування схеми canary під вашу інфраструктуру (Kubernetes, хмари, bare-metal).
• Налаштування KServe або Seldon Core (або будь-якого іншого ML-сервера).
• Інтеграція з CI/CD (GitLab CI, GitHub Actions, Argo Workflows).
• Моніторинг та алертинг на основі Prometheus/Grafana.
• Документація та навчання команди.

Терміни — від 3 до 10 днів залежно від складності. Вартість розраховується індивідуально. Замовте налаштування canary deployment прямо зараз — ми зв'яжемося з вами протягом дня.

Canary deployment для ML-моделей на Kubernetes значно знижує ризики при викочуванні нових моделей: 70% інцидентів у production пов'язані з новими версіями. Canary дозволяє виявити проблеми на ранній стадії, не зачіпаючи всіх користувачів. Автоматичний відкат на основі метрик — єдиний спосіб гарантувати, що погана модель не зашкодить бізнесу. Ми налаштовуємо guardrails за error rate, latency, drift та бізнес-метриками. Якщо хоча б один поріг перевищено — канарейка відкочується за секунди. Крім того, canary дає можливість A/B-тестування моделей у реальному трафіку: порівнюйте нову модель з поточною за ключовими показниками та приймайте зважене рішення. Отримайте консультацію інженера з MLOps — ми розповімо, як canary знизить ризики та зекономить бюджет.

Наші гарантії та досвід: ми виконали понад 20 проєктів з MLOps. Сертифіковані спеціалісти з Kubernetes та ML-інфраструктури. Гарантуємо зниження часу відкату до 1 хвилини при деградації моделі.