Files
zeekayandHanzo Dev 7a0f6ac65e feat(k8s): land pars/osage consolidation target namespaces on lux-k8s
WHY. DigitalOcean carries 8 DOKS clusters (doctl kubernetes cluster list),
one per org/chain. Per-network separation is ALREADY namespaces everywhere
that matters — lux-{mainnet,testnet,devnet}, zoo-{mainnet,testnet,devnet},
pars-{mainnet,testnet,devnet} — and the old per-network CLUSTERS
(lux-dev-k8s, lux-test-k8s) are already gone from DO; only their stale
k8s/ dirs remain. So the remaining waste is not network splits, it is
one-chain-per-cluster: osage-k8s burns 3x s-4vcpu-8gb to run a single
StatefulSet (osaged-mv 5/5) and pars-k8s burns 3x s-4vcpu-8gb for
parsd-mv 5/5 plus 4 app deployments. Both run ghcr.io/luxfi/node:v1.36.2 —
they are Lux-ecosystem sovereign L1s, so lux-k8s is their org cluster and
a namespace is the right boundary (an L1 stays sovereign at the network
layer regardless of which cluster its validators are scheduled on).

This lands ONLY the destination namespaces, labelled on the existing
k8s/lux-mainnet/namespace.yaml convention (part-of / lux.network~1network /
lux.network~1cluster) so they participate in the same taxonomy. No workload
is moved and no cluster is deleted here: deleting a DOKS cluster is
effectively irreversible, so the migration + teardown is a reviewed plan,
not a side effect of this commit.

pars-testnet / pars-devnet are deliberately NOT created — both are empty on
pars-k8s (0 deploy, 0 sts, 0 pods), and an empty namespace is not a
destination.

Co-authored-by: Hanzo Dev <[email protected]>
2026-07-27 21:01:32 -07:00
..