Repository navigation
Deleted sidecar pods leave rows in the shared eBPF maps #773
Description
Summary
When an ingress sidecar pod is deleted, the rows it registered in the node's shared eBPF maps stay behind, because garbage collection keeps every sidecar row unconditionally and nothing else removes them.
A leftover row is overwritten only when a new sidecar pod reuses the same VPC slot. Until then it holds a map slot and can be mistaken for live sidecar state, for example by the host's egress route refresh sweep.
Acceptance criteria
- After a sidecar pod is deleted, its routing, VRF and interface rows are gone from the node's maps within one sweep
- Rows of a running sidecar pod survive every sweep
Related to #716
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
None yet
Activity
privateip commentedon Oct 7, 2026
The same leak also covers the sidecar's
BGPAdvertisements, not only its map rows. On one staging edge node, 11 of the sidecar's ingress advertisements, created in late September with no owner references, still record a host-side interface that no longer exists. The live sidecar's advertisements record its current interface.None of their gateway addresses overlap the live sidecar's, so traffic is unaffected. The node still advertises those addresses over EVPN, and the installer logs "Could not install the ingress sidecar's return path" for all 11 every 30 seconds.
A fix for this issue should delete a gone sidecar's advertisements along with its rows, since they share the same lifetime.
fix: Remove a deleted sidecar pod's map rows and ads
fix: Restore sidecar rows removed by another writer