I'm running Pi-hole with Unbound on k3s. It currently runs as a single-replica Deployment, but I'd like to move to a three-replica StatefulSet so I can perform staged upgrades. What migration strategy would avoid database or configuration conflicts while preserving persistent data and keeping DNS available during rollouts?
2 Answers
Pi-hole is not especially well suited to active-active replication in Kubernetes. If you want independently scalable replicas with predictable rollouts, consider a more declarative DNS stack such as CoreDNS with Blocky. CoreDNS can load zones from Git or OCI, while Blocky can refresh blocklists from a defined source. Each pod can start from the same configuration without sharing a writable database, and a separate Redis-compatible cache can be used if shared caching is useful.
You may not need a StatefulSet just to get rolling updates. A Deployment can run three replicas with a RollingUpdate strategy, for example with maxSurge set to 1 and maxUnavailable set to 1. That gradually replaces the pods. The important question is whether all replicas can safely use the same Pi-hole data and database.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures