zeekayandHanzo Dev
425b96f66e
Every provenance line and manifest still named a DigitalOcean context, and the ARC values described a pool that died with it. A cluster gets a name here; the address it answers on belongs to the private record. Co-authored-by: Hanzo Dev <[email protected]>
1.6 KiB
Lux production topology
The live Lux validator estate is one Kubernetes cluster with three isolated namespaces and five validators per network.
| Network | Namespace | Network ID | C-Chain ID | HTTP | Staking |
|---|---|---|---|---|---|
| Mainnet | lux-mainnet |
1 | 96369 | 9630 | 9631 |
| Testnet | lux-testnet |
2 | 96368 | 9640 | 9641 |
| Devnet | lux-devnet |
3 | 96367 | 9650 | 9651 |
Cluster context: do-sfo3-lux-k8s.
Ownership
The validator StatefulSets are owned by these CD Applications:
lux-mainnet-luxdlux-testnet-luxdlux-devnet-luxd
Their sole values sources are the matching files under deploy/. Supporting
manifests under k8s/ do not own luxd. Historical snapshots under backups/
and migrations/ are records, not deployable production sources.
Each active node image is pinned as tag plus sha256 digest. Init containers
that run luxd tooling use the same immutable image. Mutable tags such as
latest, hand-edited StatefulSets, and direct kubectl set image changes are
not supported.
Operations
Use the validator release runbook for every node upgrade. Its single entry point resolves the published release digest, commits all three pins, syncs and rolls devnet → testnet → mainnet, preserves four-of-five quorum, and verifies version, digest, bootstrap state, health and block production.
Mainnet data is never wiped. The StatefulSets retain PVCs on deletion and scale-down. Genesis, staking keys and chain upgrades are independent of a node image release and must never be changed as part of a routine roll.