Налаштування 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 проходить прозоро.

Моніторинг та 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.