Web App on Kubernetes

When to use it

• Several services — web, API, background workers, scheduled jobs — that you deploy together.
• You need Kubernetes features: sidecars, custom autoscaling, network policies or operators.
• Your team already runs Kubernetes and wants the same tooling here.

For a single web service, Web App on Containers is much less work.

Diagram

  Browser
     │ HTTPS
     ▼
  CDN & WAAP ──────────────────────────────► Object storage (static assets, uploads)
     │
     ▼
  Load balancer  (TLS certificate from Secrets, firewall: 443 only)
     │
  ┌──┴───────────── private network ─────────────────────────────┐
  │  Kubernetes cluster (Cilium)                                  │
  │   ├─ pool "web"     2–6 nodes, anti-affinity   → web, API pods │
  │   └─ pool "workers" 1–4 nodes                  → queues, cron  │
  │                          │                                     │
  │                          ▼  TCP 5432                           │
  │               Managed PostgreSQL (private interface, HA)       │
  └───────────────────────────────────────────────────────────────┘

Components

Component	Velerion service	Configuration
Network	Networking	A private network for the cluster and the database, so internal traffic never crosses the internet. A router gives nodes outbound access.
Cluster	Kubernetes	Attach the private network, choose a CNI (Cilium supports network policies well), and turn on cluster auto-healing.
Node pools	Kubernetes node pools	Separate pools for web traffic and background work, so a runaway job cannot starve the website. Use Anti-affinity placement for the web pool, and turn on autohealing nodes.
Ingress	Load balancer	Terminates HTTPS with a certificate stored in Secrets, in the same region. A firewall allows only port 443 from the internet.
Edge	CDN & WAAP	Caches static content and filters attacks before traffic reaches the load balancer.
Database	Managed PostgreSQL	A private network interface, high availability and the connection pooler.
Files	Object storage	Static build and user uploads, accessed with per-service access keys.

Failure modes

Failure	Effect	Mitigation
Node failure	Pods on that node restart elsewhere.	Anti-affinity placement spreads web nodes across hosts; node autohealing replaces the failed node.
Pool reaches its maximum	New pods stay pending.	Set realistic maximums, check Limits for vCPU and RAM quota, and request an increase before launch.
Certificate expires	Browsers reject the site.	Track expiry dates and replace the certificate in Secrets ahead of time.
Background job overloads the cluster	The website slows down.	Keep workers on their own node pool.
Volume quota exhausted	New nodes cannot start.	Each node gets its own volume, and each counts against volume quota; size pools with that in mind.

Trade-offs

• Control vs effort: you own upgrades, manifests and capacity planning. In return you can run anything Kubernetes can run.
• Private network vs simplicity: without a private network, every node needs a public address. The private network takes a few extra steps to set up but closes the database and nodes off from the internet.
• Anti-affinity soft vs strict: strict anti-affinity guarantees spreading but can block scheduling when hosts are scarce; soft (the default) prefers spreading without blocking.