You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
networking: new space pods get ECONNREFUSED to marketplace databases for ~15-20s after start (kube-router source sync lag) #135
New pods in space namespaces get ECONNREFUSED when connecting to marketplace CNPG databases (and other in-namespace services) for roughly 15-20 s after pod start: the new pod's source IP is not yet in the destination node's kube-router KUBE-SRC ipsets, so the destination's default-deny ingress rejects it.
Measured on 2026-09-30 with a fresh pod TCP-probing a marketplace Postgres every ~1.5 s:
t after start
TCP connect to Postgres pod IP
t+0 … t+8 s
FAIL (connection refused)
t+20 s onwards
OK
Reproduced from three different spaces (same-namespace client → CNPG -rw service and direct pod IP). Pods started earlier connect fine, so the failure only hits apps that deploy/start with short retry loops — a real user app failed to connect this way on 2026-09-29 and kept failing until it was restarted the next day.
Same underlying kube-router sync window from the other side: #123 covers the new pod being unprotected during the window; this issue covers the new pod being rejected as a source during it. Policy state for a new pod only propagates after kube-router's sync, currently 15-40 s across nodes. The scale (4,576 NetworkPolicies / 1,124 namespaces) and etcd raft latency (see the etcd quorum issue) amplify it.
Real-world case confirmed (2026-09-29/30): a user app in space-pmartinezd-myspace started at 09:19:34Z while its marketplace Postgres was NotReady (background in the etcd quorum issue), logged connection failed after 5 attempts, and stayed running but disconnected for >24h — Next.js kept serving with no working DB connection.
Two operational notes while the initContainer fix lands:
Redeploying the pod re-rolls the dice. A fresh pod gets a fresh IP and hits this same 15-20s window; a short-retry app can fail again on the next deploy. The wait-for-db initContainer gate is what makes deploys deterministic — it remains the real fix.
Operational workaround for single-container apps: restarting the container in place (kubectl exec <pod> -- kill 1, kubelet restarts it) keeps the pod IP, which is already in the destination node's ipsets — the app reconnects on the first attempt. Used today: container restart at 20:04Z → connection ok (attempt 1/5) immediately after boot.
Activity
sre-helmcode commentedon Sep 30, 2026
Real-world case confirmed (2026-09-29/30): a user app in
space-pmartinezd-myspacestarted at 09:19:34Z while its marketplace Postgres was NotReady (background in the etcd quorum issue), loggedconnection failed after 5 attempts, and stayed running but disconnected for >24h — Next.js kept serving with no working DB connection.Two operational notes while the initContainer fix lands:
wait-for-dbinitContainer gate is what makes deploys deterministic — it remains the real fix.kubectl exec <pod> -- kill 1, kubelet restarts it) keeps the pod IP, which is already in the destination node's ipsets — the app reconnects on the first attempt. Used today: container restart at 20:04Z →connection ok (attempt 1/5)immediately after boot.