Using Zeropod for Passive Disaster Recovery (DR) Cost Optimization

[Aym3nTN]

Hey folks, I am currently evaluating architecture strategies for a Disaster Recovery (DR) cluster. Traditionally, maintaining a passive DR cluster is relatively expensive (even with HPA and VPA) because resources are provisioned but sit idle 99% of the time, only receiving traffic during a primary region failover.

The Use Case: I am investigating if zeropod is a suitable solution for a passive DR architecture.

• Scenario: A secondary Kubernetes cluster acts as a failover target.

• Normal State: No user traffic is routed to this cluster.

• Failover State: Traffic is redirected via DNS Load Balancer to the DR cluster.

• Goal: Use zeropod to scale the DR workloads down to zero during the "Normal State" to minimize infrastructure costs, while relying on it to scale up immediately during a failover event.

Has zeropod been tested in DR scenarios where a service scales from zero to full load rapidly? Do you believe this effort is worth pursuing, or are there architectural limitations that would make it unsuitable for high-stakes DR failovers?

[ctrox]

I'm not too sure about this use case. Scaled down zeropods are still scheduled pods and need a running node. Sure, you can pack more than would normally fit on a single node in running state but if they are all restored at the same time that node will just run out of resources at which point you will need to provision new nodes regardless. So the first response to some of the services will be quick in case of a failover but after that it will stall and the cluster will need to scale out regardless.

[Aym3nTN]

I'd add this to my backlog to test it with my kind of workload. I'll update this thread or start a new discussion around this. Feel free to whether keep this open or close it.

[ctrox]

Sounds good, I'm fine with keeping this open in the meantime.