Kubernetes and high availability

Goal

Understand how the stateless and stateful parts of ShieldGate map to Kubernetes, and how appliance clustering provides network-plane HA.

What scales and what doesn't

• Proxy — stateless; scale horizontally behind a Service/LoadBalancer. This is where you add replicas first.
• API and console — stateless; a couple of replicas each for availability.
• Worker — scale by job volume; jobs coordinate so replicas don't duplicate work.
• PostgreSQL and Redis — stateful; use managed services or dedicated operators, not casual in-cluster pods.

Configuration still flows the same way: publish → snapshot → nodes pull. New proxy pods fetch the current snapshot at startup, which is what makes horizontal scaling safe.

Appliance clusters

The network appliance is tied to the hosts whose traffic it controls, so its HA model is clustering, not pod replicas:

• Nodes join a named cluster and send heartbeats.
• The cluster view in the console shows each node's health and applied version.
• When a node dies, its peers continue enforcing the same published configuration.

Steps (high level)

1. Deploy PostgreSQL and Redis (managed or operator-backed).
2. Deploy API, console, worker, then proxy with an external LoadBalancer.
3. Register appliance nodes into a cluster and verify heartbeats.

Verify

• Killing a proxy pod causes no user-visible errors; the replacement pod serves the current snapshot.
• Cluster view shows all appliance nodes heartbeating on the same version.

Pitfalls

• Scaling the proxy without checking PostgreSQL/Redis capacity moves the bottleneck instead of removing it.