Environment
- Controller version: 1.1.15
- Deployment: GKE (Google Kubernetes Engine)
- Topology: single (non-HA) controller
- Client fleet: 35+ clients total, including 17+ Linux edge-tunnel (ZET) IoT devices
Summary
We want to build a DR/standby controller using a restored DB snapshot + PKI from our production 1.1.15 controller, hosted under a different domain. Rather than standing this up purely for failover, we'd like to also use it as our upgrade test environment: restore prod data into the DR copy, upgrade that instance to the current release, validate our real client fleet against it, then apply the same steps to production.
Combining these into one topic because the two are related — the DR pattern and the upgrade validation pattern both start from the same "restore a snapshot onto a new host under a different domain" step.
Questions — DR + restore
- When restoring a DB snapshot + PKI onto a controller under a different DNS hostname than the original, do leaf certs need SANs covering both hostnames, or is there a supported way to reissue only server certs from the same intermediate CA?
- Any known issues restoring a 1.1.15 (pre-HA) snapshot onto a host that isn't reachable under the original ctrl/edge advertised addresses?
Questions — using that restore as an upgrade test bed
- Is upgrading a restored controller (rather than the live one) fully representative of what happens to prod — does the restore process itself do anything (schema state, migration flags) that could make the DR copy behave differently during upgrade than the original would?
- From 1.1.15, do we need to land on the latest 1.x release first before testing 2.0, or can we upgrade the DR copy directly to 2.0?
- What's the minimum ZET (edge tunnel) version needed on client devices to authenticate against a 2.0 controller, so we can point a few real IoT devices at the DR copy during testing?
- For GKE/Helm, is there a documented rolling-upgrade order (controller → router → client) with specific chart/image version pins validated at a fleet size in the tens of clients?
- Once validated on the DR copy, is there anything about promoting that upgraded config back to production (vs. just repeating the same upgrade steps on the live controller) we should be aware of, or are the two entirely independent once the DR copy has served its testing purpose?
Why this matters
This lets us validate an upgrade against production-representative data and a subset of our real IoT fleet without risking the live network, while also giving us a working DR pattern afterward. A documented "restore-then-upgrade-test" workflow would likely help others running pre-HA controllers in production.