zeekayandHanzo Dev
c9e1987ab4
k8s/ and deploy/ both described lux-build, lux-market, explorer, lux-indexer,
explore-fe-spc, rpc-tip-gate, exchange-api, lux-exchange, zoo-bot, zoo-build,
zoo-industries and hanzo's lux-market. Only deploy/ is read by anything: the
ApplicationSet generates one Application per deploy/<ns>/<app>.yaml. So a
kubectl apply from k8s/ moved the cluster to a description CD would then heal
back, and the values files were generated from what is RUNNING while these
manifests were hand-applied over a long period.
Not one of them was a plain duplicate, which is why this took a lift rather than
a delete. Every k8s manifest carried an object the values file did not:
lux-build, lux-market, zoo-* IngressRoute + Middleware — the hosts users
actually reach, entirely outside CD
lux-indexer (x2) the chain table and the 100Gi claim, both
MOUNTED BY NAME in the values file and
declared nowhere in it
explorer (mainnet) the 50Gi claim, likewise mounted, likewise
undeclared
explore-fe-spc the ConfigMap its envFrom names, so the
values file described a pod that would start
with none of its NEXT_PUBLIC_* set
rpc-tip-gate the ServiceAccount, Role and binding its
serviceAccountName names
lux-exchange the rate-limit Middleware and the annotation
that binds it
Each moved into the values file and was verified by rendering the chart against
the manifest object by object: the routes, ConfigMaps, claims and RBAC now come
out identical. All 134 values files render.
Two objects could not move, and are split into manifests of their own rather
than left inside a duplicate:
luxd-rpc.yaml luxd's Service, selecting one label MORE
than luxd's pods carry — the key the gate
patches on and off. A chart-rendered Service
selects the release's own pods, which is
every luxd node, current or not.
exchange-api-ingress.yaml renaming it re-issues a certificate, and
with prune off the old object would keep
serving beside the new one.
k8s/lux-testnet/explorer.yaml stays whole. Its own kustomization records it as
aspirational and stale and says applying it would clobber the live explorer pod,
so its ConfigMap is not something to promote into the tree CD reconciles from.
Co-authored-by: Hanzo Dev <[email protected]>
34 lines
1.2 KiB
YAML
34 lines
1.2 KiB
YAML
# The Service that answers only from luxd pods whose tip is current.
|
|
#
|
|
# It is luxd's, not rpc-tip-gate's: it selects luxd's pods, and it lived in
|
|
# k8s/lux-mainnet/rpc-tip-gate.yaml only because the gate is what maintains the
|
|
# third selector key. rpc-tip-gate itself is declared in
|
|
# deploy/lux-mainnet/rpc-tip-gate.yaml and the rest of that manifest went with
|
|
# it; this object stayed because the app chart cannot express it. `service:`
|
|
# there emits a Service selecting the release's OWN pods, and the whole point
|
|
# here is a selector with one key MORE than the workload carries —
|
|
# lux.network/rpc: fresh, which the gate patches on and off as a node falls
|
|
# behind. A Service the chart rendered would select every luxd pod, current or
|
|
# not, which is the failure this exists to prevent.
|
|
apiVersion: v1
|
|
kind: Service
|
|
metadata:
|
|
name: luxd-rpc
|
|
namespace: lux-mainnet
|
|
labels:
|
|
app.kubernetes.io/name: luxd
|
|
app.kubernetes.io/part-of: lux
|
|
app.kubernetes.io/component: rpc
|
|
spec:
|
|
type: ClusterIP
|
|
publishNotReadyAddresses: false
|
|
selector:
|
|
app.kubernetes.io/name: luxd
|
|
app.kubernetes.io/instance: luxd
|
|
lux.network/rpc: fresh
|
|
ports:
|
|
- name: http
|
|
port: 9630
|
|
targetPort: 9630
|
|
protocol: TCP
|