Skip to content

networking: new space pods get ECONNREFUSED to marketplace databases for ~15-20s after start (kube-router source sync lag) #135

Open

Description

@sre-helmcode

Summary

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.

Root cause (shared with #123)

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.

Proposal

  1. Cheap, robust fix in platform-api: add a wait-for-db initContainer to the marketplace app templates (loop nc -z $DB_HOST 5432 up to 90 s) so app containers only start after the policy window closes — the availability-side mirror of the wait-network-isolation gate from security: member-*/space-* pods run ~40s without NetworkPolicy enforcement at start (kube-router sync window) #123. Needs its own tests (init gate timeout, DB down behavior).
  2. Re-measure after the etcd topology fix: target window < 2 s, tracked with the same timing probe.
  3. If still > 5 s: evaluate the CNI-level options already listed in security: member-*/space-* pods run ~40s without NetworkPolicy enforcement at start (kube-router sync window) #123 (pre-programmed per-namespace default-deny or CNI migration).

Review before rolling out: the initContainer change affects every marketplace deployment.

Activity

  1. sre-helmcode commented on Sep 30, 2026

    @sre-helmcode
    ContributorAuthor

    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:

    1. 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.
    2. 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions