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]>
3.3 KiB
k8s — reference, not deployment
deploy/ is authoritative. Nothing in this directory is applied by anything.
The lux-fleet ApplicationSet generates one Application per
deploy/<namespace>/<app>.yaml and reads no other path in this repository, so a
manifest here reaches a cluster only if a person types kubectl apply. For a
service that also has a values file, that apply is a second, competing
description of one workload — and the values files were generated from what is
RUNNING while these were hand-applied over a long period, so when the two
disagree it is this tree that is stale.
Twelve services were declared in both. Each carried something the values file did not — an IngressRoute, a ConfigMap, a claim, a Role — so deleting them outright would have dropped the half of a service users reach. Those objects moved into the values files first, verified by rendering the chart and diffing it against the manifest, and only then were the manifests removed.
Two objects stayed, because the chart cannot express either:
lux-mainnet/luxd-rpc.yaml— a Service selecting onlux.network/rpc: fresh, one key more than luxd's own labels. rpc-tip-gate patches that key on and off.lux-testnet/exchange-api-ingress.yaml— moving it renames it, and an Ingress name is a cert-manager Certificate name.
lux-testnet/explorer.yaml also stayed, deliberately: this directory's own
kustomization records it as "a mix of aspirational + stale" that "would clobber
the live explorer pod", so its ConfigMap is not content to promote into the tree
CD reconciles from.
What legitimately lives here: chain CRs (LuxChain, LuxNetwork, LuxIndexer,
LuxGateway, LuxMPC), which are not services and have their own controllers;
NetworkPolicies; DNS zone files; and the historical record. Some aggregate roots
do not build — lux-k8s/kustomization.yaml lists a kms directory that does not
exist — and are kept for that history rather than for use.
Clusters
| Cluster | Environment | Domain | Nodes |
|---|---|---|---|
lux-k8s |
mainnet + testnet + devnet + storm (namespaces) | *.lux.network |
lux-nodes, lux-runners-amd64 |
hanzo-k8s |
prod | cloud.hanzo.network |
worker-pool, runner-pool-32g |
lux-dev-k8s and lux-test-k8s no longer exist. Devnet and testnet are the
lux-devnet / lux-testnet namespaces on do-sfo3-lux-k8s. Node workloads
are not defined under k8s/: the only luxd source is the three CD values files
under deploy/, preventing stale manifests from downgrading a network.
Tracked Chains
The runtime automation in Makefile + scripts/ensure-tracked-chains.sh enforces:
lux(C-Chain)zoohanzospcpars
Testnet aliases are used automatically: zootest, hanzotest, spctest, parstest.
Apply
A supporting resource here — a NetworkPolicy, a chain CR — is still applied by hand, and diffed first:
kubectl --context do-sfo3-hanzo-k8s diff -k k8s/hanzo-k8s
kubectl --context do-sfo3-hanzo-k8s apply -k k8s/hanzo-k8s
Never apply a workload from here. If a service has a values file, the values
file is what runs it; if it does not, give it one. Never add a luxd StatefulSet
or Network resource back to these roots — the only luxd source is the three
values files under deploy/.