DB apps fail on bare k3s: app-ns NetworkPolicy blocks CNPG initdb→apiserver egress (gate only runs on k3d) #89

New issue

Open

opened 2026-07-06 18:40:35 +00:00 by plat · 0 comments

plat commented

2026-07-06 18:40:35 +00:00

Owner

Summary

Database-backed apps fail to bootstrap on bare single-VPS k3s platforms: CNPG initdb can't reach the kube-apiserver because the generated app-namespace NetworkPolicies assume the apiserver is in 172.16.0.0/12 (true on the k3d gate rig, false on a real VPS where the apiserver is the node IP on :6443). Every app with a DB hangs at "Setting up primary".

Root-caused and fixed in plat/gitops (generate-allow-egress now allows the apiserver ClusterIP :443 + 0.0.0.0/0:6443), validated live on the product-garden.com granddaughter (crew-built app reached preview 200). This issue tracks the durable lesson + the gate gap.

Why the gate missed it

The coldstart/GATE harness germinates only on k3d (vxrail), where the apiserver container IP falls inside the 172.16/12 allow. The bug is invisible there and only appears on a bare-k3s substrate (HYB path). This is the exact category HYB-2 (#35) exists to catch.

Follow-up

Germinate at least one bare-k3s target in CI (or a k3d cluster whose apiserver is outside 172.16/12) so substrate-divergent networking regressions are caught automatically.
Consider moving allow-egress-postgres's apiserver intent out of the renderer's hardcoded 172.16/12 and into the same substrate-agnostic rule.

Fix commit: plat/gitops fix/apiserver-egress-bare-k3s.

## Summary Database-backed apps fail to bootstrap on **bare single-VPS k3s** platforms: CNPG `initdb` can't reach the kube-apiserver because the generated app-namespace NetworkPolicies assume the apiserver is in `172.16.0.0/12` (true on the k3d gate rig, false on a real VPS where the apiserver is the node IP on `:6443`). Every app with a DB hangs at "Setting up primary". Root-caused and **fixed** in plat/gitops (`generate-allow-egress` now allows the apiserver ClusterIP `:443` + `0.0.0.0/0:6443`), validated live on the `product-garden.com` granddaughter (crew-built app reached preview 200). This issue tracks the durable lesson + the gate gap. ## Why the gate missed it The coldstart/GATE harness germinates only on **k3d** (vxrail), where the apiserver container IP falls inside the `172.16/12` allow. The bug is invisible there and only appears on a bare-k3s substrate (HYB path). This is the exact category HYB-2 (#35) exists to catch. ## Follow-up - [ ] Germinate at least one bare-k3s target in CI (or a k3d cluster whose apiserver is outside 172.16/12) so substrate-divergent networking regressions are caught automatically. - [ ] Consider moving `allow-egress-postgres`'s apiserver intent out of the renderer's hardcoded `172.16/12` and into the same substrate-agnostic rule. Fix commit: plat/gitops `fix/apiserver-egress-bare-k3s`.

plat referenced this issue

2026-07-06 19:10:32 +00:00

Enforce flip breaks ALL app TLS: disallow-unmanaged-secrets blocks cert-managers issuance temp secrets (wildcard-plat-tls-<rand>) #91

plat referenced this issue

2026-07-06 19:24:09 +00:00

/goal /ultracode-workflows [HYB-2] validate a granddaughter on a real VPS over the public internet (production TLS + edge) #35