Kubernetes Orchestration Setup for Mobile App Backend

Let's note: when we take on Kubernetes setup for a mobile backend, the first problem is sharp load spikes. For example, an app with 50,000 active users experiences 10–15x traffic fluctuations: morning peak, lunch, evening. On a single server, this means either overprovisioning resources at night or degradation at peak. Once a client with 100,000 DAU approached us: their Node.js API crashed at peak 10k RPS, and ECS couldn't handle auto-scaling. Kubernetes solves this through horizontal auto-scaling, rolling updates with zero downtime, and service isolation. We have 5 years of DevOps experience for mobile projects, over 20 successful deployments, and certified engineers (CKA, CKAD). We guarantee SLA 99.9% and post-launch support. Thanks to orchestration, cloud resource savings can reach 50,000–200,000 rubles per month. Request a consultation — we'll select the optimal configuration.

What does a basic Kubernetes orchestration architecture for a mobile backend look like?

Typical component set:

Deployment and HPA — kubernetes orchestration setup

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 

The preStop sleep of 5 seconds is needed so that the Ingress can remove the Pod from rotation before it starts terminating connections. As recommended by preStop hook, this step guarantees zero-downtime during rolling updates.

What to do if HPA does not scale?

A frequent issue is that metrics do not reach HPA. Check if metrics-server is running and the target averageUtilization is correct. For custom metrics (e.g., based on RPS), use Prometheus Adapter with a configuration to collect metrics from each pod. We allocate 2 days for HPA debugging during the first deployment.

Secrets and confidential data

APNs .p8 keys, FCM server key, JWT secrets — in Kubernetes Secrets:

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

For production, use External Secrets Operator with AWS Secrets Manager or HashiCorp Vault — this allows rotating secrets without manually recreating Kubernetes Secrets.

WebSocket and sticky sessions

WebSocket is a stateful connection. During a rolling update, the old Pod must wait for all active connections to finish. nginx-ingress configuration:

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" 

It is better to make the WebSocket service stateless via Redis Pub/Sub: the client connects to any pod, messages are routed through a Redis channel. Then rolling updates are transparent.

Monitoring and observability

Prometheus + Grafana is the standard for Kubernetes. For a mobile backend, key metrics:

• http_request_duration_seconds with percentiles p50/p95/p99
• websocket_connections_active (normal: up to 10,000 per pod)
• push_notification_delivery_rate (target: 99.9%)
• database_pool_size and database_query_duration

Alerts on p99 latency > 500ms, error rate > 0.5%, pod restart count > 3 in 5 minutes. Setting up alerts is included in the cost — contact us for details.

Why is GitOps the standard for infrastructure management?

ArgoCD or Flux track changes in a Git repository with manifests and apply them to the cluster. CI only builds the image and updates the tag in the manifest via kustomize edit set image or 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 sees the commit and syncs the cluster. GitOps guarantees that the cluster always matches the state in the repository. This increases transparency, simplifies auditing, and reduces the risk of human error during deployment. Our engineers hold CKA and CKAD certifications, so GitOps implementation runs smoothly.

Work process and what's included

Stages:

1. Audit of current infrastructure
2. Design of namespace/RBAC structure
3. Writing manifests (Deployment, Service, Ingress, HPA)
4. Secrets management setup
5. Monitoring setup (Prometheus, Grafana, alerts)
6. CI/CD integration (GitOps, ArgoCD/Flux)
7. Load testing of auto-scaling with 200% peak load
8. Documentation and team training (2 sessions)
9. Post-launch support (1 month)

Note: what is included in the result:

• Helm charts or Kustomize overlays for all components
• Architecture documentation and runbook
• Access to monitoring and alerts
• Access to Git repository with history
• Team training (2 sessions of 2 hours)
• Guarantee of correct HPA and rolling update operation

Timeline: 5 days for a typical backend on GKE/EKS/AKS. Cost is calculated individually after analysis of architecture and SLA requirements.