Настройка Kubernetes-оркестрации бэкенда мобильного приложения

Настройка Kubernetes-оркестрации бэкенда мобильного приложения

Мобильное приложение с 50 000 активных пользователей создаёт нагрузку, которая меняется в 10–15 раз в течение дня: утренний пик, обед, вечер. На одном сервере это означает либо перерасход ресурсов ночью, либо деградацию в пике. Kubernetes решает это через горизонтальное автомасштабирование, rolling update без даунтайма и изоляцию сервисов.

Базовая архитектура для мобильного бэкенда

Типичный набор компонентов:

• API Deployment — stateless сервис, масштабируется горизонтально
• WebSocket Service — отдельный Deployment с sticky sessions или через Redis Pub/Sub
• Worker Deployment — обработка фоновых задач (ресайз изображений, отправка push)
• PostgreSQL — StatefulSet или managed (RDS, Cloud SQL)
• Redis — StatefulSet или managed (ElastiCache, Memorystore)
• Ingress — nginx-ingress или Traefik с TLS termination

Deployment и HPA

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mobile-api
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: mobile-api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0  # Zero-downtime
  template:
    metadata:
      labels:
        app: mobile-api
    spec:
      containers:
        - name: api
          image: ghcr.io/myorg/mobile-api:1.2.3
          ports:
            - containerPort: 3000
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url
            - name: REDIS_URL
              valueFrom:
                secretKeyRef:
                  name: redis-credentials
                  key: url
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          livenessProbe:
            httpGet:
              path: /health/live
              port: 3000
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 5
          lifecycle:
            preStop:
              exec:
                command: ["/bin/sh", "-c", "sleep 5"]

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mobile-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mobile-api
  minReplicas: 2
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

preStop sleep на 5 секунд нужен для того, чтобы Ingress успел убрать Pod из rotation до того, как он начнёт завершать соединения.

Secrets и конфиденциальные данные

APNs .p8 ключи, FCM server key, JWT secrets — в Kubernetes Secrets:

kubectl create secret generic apns-credentials \
  --from-file=AuthKey_XXXXXX.p8 \
  --from-literal=key_id=XXXXXXXXXX \
  --from-literal=team_id=YYYYYYYYYY

Для production рекомендуется External Secrets Operator с AWS Secrets Manager или HashiCorp Vault — тогда ротация секрета не требует пересоздания Kubernetes Secret вручную.

WebSocket и sticky sessions

WebSocket — stateful соединение. При rolling update старый Pod должен дождаться завершения всех активных соединений. Конфигурация nginx-ingress:

nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
nginx.ingress.kubernetes.io/upstream-hash-by: "$remote_addr"

Но лучше сделать WebSocket сервис stateless через Redis Pub/Sub: клиент подключается к любому поду, сообщения маршрутизируются через Redis channel. Тогда rolling update проходит прозрачно.

Monitoring и observability

Prometheus + Grafana — стандарт для Kubernetes. Для мобильного бэкенда ключевые метрики:

• http_request_duration_seconds с перцентилями p50/p95/p99
• websocket_connections_active
• push_notification_delivery_rate
• database_pool_size и database_query_duration

Алерты на p99 latency > 2s, error rate > 1%, pod restart count > 3 за 5 минут.

CI/CD с GitOps

ArgoCD или Flux отслеживают изменения в Git-репозитории с манифестами и применяют их в кластер. CI только собирает образ и обновляет тег в манифесте через kustomize edit set image или Helm values:

# .github/workflows/deploy.yml
- name: Update image tag
  run: |
    cd k8s/overlays/production
    kustomize edit set image ghcr.io/myorg/mobile-api=ghcr.io/myorg/mobile-api:${{ github.sha }}
    git commit -am "deploy: ${{ github.sha }}"
    git push

ArgoCD видит коммит и синхронизирует кластер.

Процесс

Аудит текущей инфраструктуры → проектирование namespace/RBAC структуры → написание манифестов (Deployment, Service, Ingress, HPA) → настройка Secrets management → настройка мониторинга → интеграция с CI/CD → нагрузочное тестирование автомасштабирования → документация.

Срок: 5 дней для типового бэкенда на GKE/EKS/AKS. Стоимость рассчитывается индивидуально после анализа архитектуры и требований по SLA.