The consumer needs the cluster's CA and Secrets do not cross namespaces, so
ca.crt has to be copied into peach's namespace. A copied certificate deserves
suspicion — k3s-fleet's own history records an incident where the expired
central SDLC wildcard was copied manually and never renewed into its consumer
namespaces — so the numbers are written down rather than assumed:
tidaldb-cluster-ca 87600h (10y), renewBefore 8760h (1y), isCA
tidaldb-cluster-tls 2160h (90d), renewBefore 720h (30d)
The 90-day LEAF is what rotates, roughly every 60 days, and it rotates under
this same root, so the copied CA keeps verifying it with no attention. The
fleet incident was an expiring leaf; this is a decade-lived root.
The coupling that actually bites is recreation, not expiry: the root is
self-signed and minted fresh on first apply, so destroying and re-applying the
namespace invalidates every copy at once and every consumer request then fails
TLS with nothing visibly wrong on either side. Recorded as a mandatory step of
any recreate.
thepeach's discover corpus should run the CLUSTER, not the standalone, and it
should run on GKE. Both halves are now evidenced rather than assumed.
Cluster, because the reason for the standalone is gone. The standalone was
chosen to work around cluster-mode `POST /signals` silently discarding
user_id/creator_id behind a 204 — fixed at the source in 6ad8c51. Inheriting a
workaround whose defect is fixed is how a temporary choice becomes permanent.
GKE, because that is where the consumer is. k3s-fleet's own history records the
fleet instance holding 1,720m of CPU requests — 17% of fleet allocatable —
while serving NOTHING, with tidaldb-staging at `items: 0` after 53 days,
because "the only in-source consumers ... run on GKE". Cluster-local DNS does
not cross clusters, so the consumer's
`tidaldb.tidaldb-cluster.svc.cluster.local:9500` can only resolve here.
An overlay, not a fork — precedent is ../cluster-local-kind, which patches the
same storage field. Two GKE facts the base cannot know:
1. `storageClassName: local-path` is the k3s provisioner. GKE has no such
class, so the volumeClaimTemplate would leave every pod Pending
indefinitely with nothing wrong on the StatefulSet itself. Patched to
`standard-rwo` (pd.csi, WaitForFirstConsumer — the binding mode a
StatefulSet wants).
2. The base publishes `tidaldb.threesix.ai`. That is a FLEET hostname with no
DNS record here that must not get one, and the base's own comment says
"Remove for internal-only". Deleted rather than left inert, which keeps DNS,
certificates and load-balancer topology entirely out of this change. Peach
reaches the service over cluster-local DNS; nothing needs exposing.
Worth recording because it nearly shipped: my first delete patch targeted a
`traefik.io` IngressRoute. The base publishes a plain `networking.k8s.io/v1`
Ingress carrying Traefik ANNOTATIONS, so the patch matched nothing, kustomize
rendered happily, and the Ingress survived — GKE would have published that
hostname. Rendering the overlay and reading the object inventory is what caught
it, so that check is now preflight step 1 with its expected output written
down, not left to memory.
The NetworkPolicy is kept verbatim and needs no widening: its `:9500` rule
carries no `from` selector (deliberate in the base, because kubelet probes come
from the node), which is exactly what lets thepeach-staging reach this
namespace with no cross-namespace rule. I had earlier claimed cross-namespace
was BLOCKED here; that was wrong, from reading a grep-filtered view instead of
the file.
Validated clean against GKE 2026-09-16: all 12 objects pass server dry-run,
warnings only. NOT applied — the base's image pin predates the signal-context
fix, so applying now would deploy the buggy binary. Preflight step 3 is the pin.
