AI-агенты в Kubernetes: деплой, масштабирование, мониторинг

AI-агенты в Kubernetes: полный гайд по развёртыванию и оркестрации

☸️

AI-агенты в Kubernetes: оркестрация интеллектуальных рабочих нагрузок

Полное руководство по развёртыванию AI-агентов в Kubernetes-кластере. От настройки GPU-нод и автомасштабирования до продакшен-мониторинга LangChain-агентов с Prometheus и Grafana.

advanced ⏱ 25 мин

# 1. Почему Kubernetes для AI-агентов

AI-агенты требуют надёжной оркестрации. Kubernetes предоставляет автомасштабирование, самоисцеление подов, управление GPU-ресурсами и интеграцию с CI/CD. В отличие от ручного запуска скриптов, K8s гарантирует, что ваш агент переживёт сбой ноды, автоматически перезапустится и масштабируется под нагрузку запросов к LLM. Современные фреймворки — LangChain, CrewAI, AutoGen — отлично упаковываются в Docker-контейнеры и работают как stateless-сервисы внутри кластера.

Ключевые преимущества: нативная поддержка GPU через device plugins NVIDIA, автомасштабирование по кастомным метрикам (например, latency p95), rolling updates без даунтайма, и интеграция с service mesh для безопасного межсервисного взаимодействия агентов.

# Проверяем доступные GPU-ресурсы в кластере
kubectl describe nodes | grep nvidia.com/gpu

# Деплоим NVIDIA device plugin
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.15.0/deployments/static/nvidia-device-plugin.yml

# Проверяем, что GPU видны внутри пода
kubectl run gpu-test --rm -ti --restart=Never \
  --image=nvidia/cuda:12.1-base-ubuntu22.04 \
  --limits=nvidia.com/gpu:1 -- nvidia-smi

# 2. Docker-образ AI-агента

Первый шаг — упаковка агента в Docker. Используйте multi-stage build для минимизации размера образа. LangChain-агент с CrewAI может весить под 2 ГБ из-за зависимостей torch и transformers. Оптимизируйте: ставьте только нужные бэкенды (CUDA или CPU), используйте python:3.11-slim как базовый образ.

Ключевой момент — health check. Агент должен отвечать на HTTP-запросы, даже если его основная работа — обработка очереди сообщений. Добавьте эндпоинт /healthz, который проверяет подключение к LLM API и векторной базе данных.

# Dockerfile для AI-агента
FROM python:3.11-slim-bookworm AS builder
WORKDIR /app
RUN pip install --no-cache-dir \
  langchain==0.3.7 \
  langchain-openai==0.2.9 \
  qdrant-client==1.11.0 \
  httpx==0.28.1 \
  pydantic==2.10.3

FROM python:3.11-slim-bookworm
WORKDIR /app
COPY --from=builder /usr/local/lib/python3.11/site-packages \
     /usr/local/lib/python3.11/site-packages
COPY agent/ ./agent/
COPY main.py .
EXPOSE 8080
HEALTHCHECK --interval=15s --timeout=5s \
  CMD curl -f http://localhost:8080/healthz || exit 1
CMD ["python", "main.py"]

# 3. Kubernetes-манифесты: Deployment, Service, HPA

Создаём Deployment с запросом GPU, Service для внутреннего доступа и HorizontalPodAutoscaler для масштабирования по CPU и кастомным метрикам. Для AI-нагрузок критично настроить resource requests/limits: GPU-память легко утекает, а OOMKill пода агента приведёт к потере контекста диалога.

Используйте topologySpreadConstraints для распределения подов по разным нодам и зонам доступности. Это критично для отказоустойчивости: если упадёт одна GPU-нода, остальные поды продолжат обслуживать запросы.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-agent-deployment
  labels:
    app: ai-agent
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ai-agent
  template:
    metadata:
      labels:
        app: ai-agent
    spec:
      containers:
      - name: agent
        image: registry.example.com/ai-agent:v1.2.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "4Gi"
            cpu: "2"
            nvidia.com/gpu: "1"
          limits:
            memory: "8Gi"
            cpu: "4"
            nvidia.com/gpu: "1"
        env:
        - name: OPENAI_API_KEY
          valueFrom:
            secretKeyRef:
              name: ai-agent-secrets
              key: openai-api-key
        - name: QDRANT_URL
          value: "http://qdrant-service:6333"
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 30
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: ai-agent

# 4. HPA: автомасштабирование по latency и кастомным метрикам

Стандартного HPA по CPU недостаточно. AI-агенты упираются в latency LLM-вызовов и occupancy GPU. Настройте кастомные метрики через Prometheus Adapter: экспортируйте p95 latency, количество активных диалогов, utilisation GPU-памяти. HPA будет масштабировать поды до того, как пользователи заметят деградацию.

На практике хорошо работает масштабирование по двум метрикам одновременно: CPU > 70% ИЛИ кастомная метрика agent_latency_p95 > 5000ms. Используйте stabilizationWindowSeconds чтобы избежать флаппинга при кратковременных всплесках.

# hpa.yaml — масштабирование по кастомным метрикам
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ai-agent-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ai-agent-deployment
  minReplicas: 2
  maxReplicas: 12
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
      - type: Pods
        value: 2
        periodSeconds: 30
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: agent_latency_p95_ms
      target:
        type: AverageValue
        averageValue: "5000"

# 5. KEDA: событийно-ориентированное масштабирование

Для агентов, обрабатывающих очереди сообщений (RabbitMQ, Kafka, Redis), используйте KEDA — Kubernetes Event-Driven Autoscaling. KEDA может масштабировать поды до нуля, когда очередь пуста, экономя дорогие GPU-ресурсы. Это особенно актуально для агентов, работающих по расписанию или реагирующих на события из CRM/ERP-систем.

KEDA поддерживает десятки триггеров: Apache Kafka, NATS, Prometheus, AWS SQS, GCP Pub/Sub. Для AI-агента, принимающего задачи через Redis Streams, конфигурация занимает всего 30 строк YAML.

# keda-scaledobject.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: ai-agent-keda
spec:
  scaleTargetRef:
    name: ai-agent-deployment
  minReplicaCount: 0
  maxReplicaCount: 10
  cooldownPeriod: 300
  triggers:
  - type: redis
    metadata:
      address: redis-master:6379
      listName: agent-tasks
      listLength: "5"
      activationListLength: "1"

# Применяем
kubectl apply -f keda-scaledobject.yaml

# Проверяем статус
kubectl get scaledobject ai-agent-keda

# 6. Мониторинг с Prometheus и Grafana

Без observability вы летите вслепую. Инструментируйте агента с помощью prometheus_client (Python) или библиотеки для вашего языка. Ключевые метрики: общее количество запросов, latency по перцентилям (p50, p95, p99), количество ошибок по типам, utilisation GPU, количество активных сессий, размер контекстного окна.

Настройте алерты в Prometheus AlertManager: если p95 latency превышает 8 секунд в течение 5 минут, шлите уведомление в Slack/PagerDuty. Если количество ошибок LLM-вызовов (rate 5xx за 10 мин) превышает порог — алерт срочный.

# agent_metrics.py — instrumentation на Python
from prometheus_client import Histogram, Counter, Gauge, start_http_server

REQUEST_LATENCY = Histogram(
    'agent_request_latency_seconds',
    'Request latency',
    buckets=[0.5, 1.0, 2.5, 5.0, 10.0, 30.0, float("inf")]
)
LLM_CALLS = Counter(
    'agent_llm_calls_total',
    'Total LLM API calls',
    ['model', 'status']
)
ACTIVE_SESSIONS = Gauge(
    'agent_active_sessions',
    'Active conversation sessions'
)

def instrumented_agent_run(task: str) -> str:
    with REQUEST_LATENCY.time():
        ACTIVE_SESSIONS.inc()
        try:
            result = agent.invoke(task)
            LLM_CALLS.labels(model="gpt-4o", status="success").inc()
            return result
        except Exception as e:
            LLM_CALLS.labels(model="gpt-4o", status="error").inc()
            raise
        finally:
            ACTIVE_SESSIONS.dec()

start_http_server(9090)  # Prometheus будет скрейпить :9090

# 7. Продакшен-паттерны и best practices

В продакшене AI-агенты в Kubernetes требуют нескольких дополнительных паттернов: Graceful Shutdown (ловим SIGTERM, завершаем активные диалоги за 30 секунд), PodDisruptionBudget (minAvailable: 1 для защиты от одновременного выселения), NetworkPolicy для ограничения egress-трафика только к нужным API, и PersistentVolume для кеша эмбеддингов.

Не храните состояние агента в памяти пода — используйте Redis или PostgreSQL для сессионного контекста. Это позволит пережить рестарты и перебалансировку подов без потери данных пользователей. Для LLM-кеширования ответов используйте GPTCache с Redis-бэкендом — это сокращает затраты на API-вызовы на 40-60%.

# PodDisruptionBudget для защиты от выселения
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: ai-agent-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: ai-agent

# NetworkPolicy — разрешаем трафик только к OpenAI и Qdrant
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ai-agent-egress
spec:
  podSelector:
    matchLabels:
      app: ai-agent
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: qdrant
    ports:
    - port: 6333
      protocol: TCP
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.0.0.0/8
    ports:
    - port: 443
      protocol: TCP

📊 Итог: Kubernetes для AI-агентов

Развёртывание AI-агентов в Kubernetes превращает хрупкие скрипты в промышленные отказоустойчивые сервисы. Ключевые компоненты: GPU-aware scheduling, HPA/KEDA для автомасштабирования, Prometheus/Grafana для observability, и stateless-архитектура с внешним хранением сессий. При правильной настройке вы получаете платформу, способную обслуживать тысячи одновременных пользователей с p95 latency под 3 секунды и автоматическим восстановлением после сбоев. Начните с deployment из 3 реплик, настройте мониторинг и алерты, и только потом включайте автомасштабирование — это безопасный путь к продакшену.