[BPF] Defer kube-proxy construction until first hostIPs and in-sync

[tomastigera]

Description

Felix restart on a node receiving NodePort traffic was breaking new TCP connections for ~500 ms — the bootstrap window between kube-proxy starting up and receiving the first hostIPs.

Root cause

In that window, kube-proxy.go:start() constructed the proxy with a stub Syncer (only podNPIP, no real host IPs). proxy.New() spins up the k8s informer goroutines synchronously; once they sync, an Apply runs against the stub Syncer. The cachingmap computes desired state without any (realHostIP, nodePort) FE entry and erases pre-existing real-host-IP NodePort FE entries left by the previous Felix run.

New external TCP connections to the NodePort during the gap miss the FE map, ascend to the host stack with no listener, and get RST by the kernel. The wildcard FE entry does not cover external→HEP NodePort traffic (nat_lookup.h:60-71 returns NULL on CALI_F_FROM_HEP without from_tun), so it provides no safety net.

The race window opened up in 3.31 because PR #11762 added enough setup work between scanner construction and Start() (channel allocation, the new WorkloadRemoveScannerTCP goroutine, extra EntryScanner wiring) to flip the apply-ordering relative to the kube-proxy bootstrap. Earlier versions had the same latent race but didn't trip it.

Fix

Defer proxy construction until both the first hostIPUpdates and the first hostMetadataUpdates have arrived, then construct the Syncer (with real host IPs) and the proxy in one shot via run(). The KubeProxy.Conntrack* callbacks already nil-check kp.syncer, so in-flight conntrack scans during the wait remain safe.

Test

New regression test in kube-proxy_test.go pre-populates the front map with a real-host-IP NodePort FE entry, fires only the host-metadata gate (mimicking the bootstrap window), and asserts via Consistently over 500 ms that the entry survives. The test fails on the buggy code (Consistently trips at ~125 ms) and passes with the fix.

Related issues/PRs

Closes #12192

Release Note

ebpf - Fix transient NodePort connection failures when Felix restarts on a node receiving external NodePort traffic.

Reminder for the reviewer

• release-note-required
• docs-not-required (no user-facing config change; bug fix)
• cherry-pick-candidate (bug fix; consider backport to active release branches)

[Copilot]

Pull request overview

This PR fixes a Felix/eBPF kube-proxy startup race that could briefly remove real-host-IP NodePort frontend (FE) entries during Felix restart, causing transient external NodePort connection failures until host IPs are known.

Changes:

• Defer kube-proxy/proxy construction until both the first hostIPUpdates and the first hostMetadataUpdates have been received.
• Update KubeProxy.run() to construct the proxy lazily on the first run() call (using real host IPs).
• Add a regression test that ensures pre-existing real-host-IP NodePort FE entries are not erased during the bootstrap window.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
felix/bpf/proxy/kube-proxy.go	Defers proxy construction until initial host IPs + host-metadata gate; adds nil-guard in Stop() and creates proxy in run() on first call.
felix/bpf/proxy/kube-proxy_test.go	Adds regression test reproducing bootstrap-window FE erasure and asserting marker FE entry persists until host IPs are delivered.

[Copilot]

Stop() holds kp.lock while it later waits on kp.wg.Wait(). If the update loop goroutine is in the middle of kp.run() (which also takes kp.lock) when Stop() is called, Stop can deadlock waiting for the goroutine to exit while the goroutine is blocked on the lock. Consider releasing kp.lock before waiting (e.g., take a local copy of kp.proxy under lock, unlock, then Stop proxy / waitgroup).

[Copilot]

The new nil-check avoids a panic when Stop() is called before start() constructs kp.proxy, but it also makes it possible for Stop() to return without ever stopping a proxy that gets created concurrently shortly after this check (e.g., start() has already received initial updates and is about to assign kp.proxy). Consider preventing proxy construction once exiting is closed, or include the start() goroutine in kp.wg so Stop() waits for it to finish, ensuring a constructed proxy is always stopped.