Customer-Facing Applications on Kubernetes: Keep the Service Available, Not Just the Pods

A customer-facing service may have healthy Pods while users still experience failed logins, slow API responses, broken sessions, database timeouts, certificate failures, or partial releases. Kubernetes can manage replicas, networking, placement, health signals and scaling — it does not automatically guarantee correct application behavior, database availability, external dependency resilience, or disaster recovery.

A production design connects Kubernetes controls to measurable user outcomes, not just cluster health.

A common architecture: client → DNS → CDN/DDoS protection → external load balancer → Gateway or Ingress → Kubernetes Service → application Pods → database/cache/object storage/external APIs. Every layer can become the actual availability limit — three healthy application replicas don't help when the only load balancer, database or identity provider is unavailable.

A single replica creates an application-level single point of failure. Multiple replicas only improve availability when they run on independent nodes, sessions are portable, and sufficient capacity remains during failure. Topology spread constraints can distribute Pods across nodes and zones — but a strict spread rule can leave Pods Pending when the required failure domains or capacity aren't available.

A PodDisruptionBudget limits concurrent voluntary disruption and can help during node maintenance — it does not prevent involuntary failures and does not itself create capacity. A cluster running at full requested capacity cannot replace a failed replica or create rollout surge Pods.

A rolling update is not automatically zero downtime — it also requires multiple healthy replicas, correct readiness, graceful shutdown, backward-compatible APIs, compatible database schema, and sufficient surge capacity.

Database schema changes are one of the largest release risks — use a backward-compatible expand-and-contract pattern: add compatible schema, deploy dual-compatible code, migrate data, then remove obsolete schema in a later release.

Session models range from stateless signed tokens to database- or Redis-backed sessions to load-balancer affinity. Sticky sessions can support a transition but don't make local session state durable — they fail when the Pod disappears, the client IP changes, or traffic moves regions.

API design

The HorizontalPodAutoscaler can adjust replica count using resource, custom or external metrics. CPU may be appropriate when it correlates with load — it's weak when the application is limited by database, queue, external API, or connection pool. Consider requests per second, queue depth, or concurrent requests instead.

Node autoscaling can create Pending Pods when no node has sufficient capacity — do not depend on emergency node creation for traffic spikes shorter than node startup time. Pre-scale before predictable demand such as launches or marketing campaigns.

The application availability cannot exceed its database availability when every request depends on it — a Kubernetes application with ten replicas and one unprotected database remains a single-point service. Inventory every external dependency (identity, payment, email, search, CRM) with timeout, retry, rate limit and fallback behaviour.

Healthy infrastructure does not prove a healthy business service — track p95/p99 tail latency rather than only the average, since a small group of extremely slow requests may represent your most valuable or complex operations.

Protect Kubernetes resources, application configuration, persistent files, database, object storage, Secrets and keys, container images, and Gateway/DNS configuration. A recovery cluster may require a Gateway implementation, TLS certificates, database recovery, object-storage access, Secret rotation and a DNS switch — recovery is complete only when critical customer journeys succeed in the recovery environment, not merely when Pods report Running. See the disaster recovery plan guide for the broader planning framework.