Налаштування Kubernetes-оркестрації бекенду мобільного додатку

Зазначимо: коли ми беремося за налаштування Kubernetes для мобільного бекенду, перша проблема — різкі стрибки навантаження. Наприклад, додаток з 50 000 активних користувачів зазнає 10–15-кратних коливань трафіку: ранковий пік, обід, вечір. На одному сервері це означає або перевитрату ресурсів вночі, або деградацію в пік. Одного разу до нас звернувся клієнт з 100 000 DAU: його Node.js API падав при пікових 10k RPS, а ECS не справлявся з автомасштабуванням. Kubernetes вирішує це через горизонтальне автомасштабування, rolling update без даунтайму та ізоляцію сервісів. Досвід — 5 років в DevOps для мобільних проєктів, понад 20 успішних впроваджень, сертифіковані інженери (CKA, CKAD). Гарантуємо SLA 99.9% та підтримку після запуску. Завдяки оркестрації економія на хмарних ресурсах може сягати 50 000–200 000 гривень на місяць. Замовте консультацію — ми підберемо оптимальну конфігурацію.

Як виглядає базова архітектура Kubernetes-оркестрації для мобільного бекенду?

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

Deployment і HPA — налаштування kubernetes оркестрації

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 до того, як він почне завершувати з'єднання. Як рекомендує preStop hook, цей крок гарантує zero-downtime при rolling update.

Що робити, якщо HPA не масштабується?

Часта проблема — метрики не доходять до HPA. Перевірте, чи запущений metrics-server, та правильність target averageUtilization. Для custom метрик (наприклад, по RPS) використовуйте Prometheus Adapter з конфігурацією для збору метрик з кожного пода. Ми закладаємо 2 дні на налагодження HPA при першому впровадженні.

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 (норма: до 10 000 на под)
• push_notification_delivery_rate (цільовий рівень: 99.9%)
• database_pool_size та database_query_duration

Алерти на p99 latency > 500ms, error rate > 0.5%, pod restart count > 3 за 5 хвилин. Налаштування алертів входить у вартість — зв'яжіться для деталей.

Чому 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 бачить коміт і синхронізує кластер. GitOps гарантує, що кластер завжди відповідає стану в репозиторії. Це підвищує прозорість, спрощує аудит та знижує ризик людської помилки при деплої. Наші інженери мають сертифікати CKA та CKAD, тому впровадження GitOps проходить без збоїв.

Процес роботи та що входить

Етапи:

1. Аудит поточної інфраструктури
2. Проєктування namespace/RBAC структури
3. Написання маніфестів (Deployment, Service, Ingress, HPA)
4. Налаштування Secrets management
5. Налаштування моніторингу (Prometheus, Grafana, алерти)
6. Інтеграція з CI/CD (GitOps, ArgoCD/Flux)
7. Навантажувальне тестування автомасштабування з 200% пікового навантаження
8. Документація та навчання команди (2 сесії)
9. Підтримка після запуску (1 місяць)

Зазначимо: що входить у результат:

• Helm-чарти або Kustomize-оверлеї для всіх компонентів
• Документація з архітектури та runbook
• Доступи до моніторингу та алертів
• Доступ до Git-репозиторію з історією
• Навчання команди (2 сесії по 2 години)
• Гарантія коректної роботи HPA та rolling update

Термін: 5 днів для типового бекенду на GKE/EKS/AKS. Вартість розраховується індивідуально після аналізу архітектури та вимог по SLA.

Замовте консультацію, і ми підготуємо індивідуальний план.