Summary
DisableSockmap() is never called anywhere in the codebase. When pods are removed or the mesh manager shuts down, SOCKMAP entries are never cleaned up, leaving stale entries in the kernel eBPF map.
Current State
EnableSockmap() is called in reconcileNovaNetSockMap() but there's no tracking of previously enabled podsShutdown() in manager.go:394-414 does not clean up SOCKMAP entries (comment says "NovaNet client lifecycle is managed by the caller")shutdownAgent() in main.go closes the NovaNet client without disabling any SOCKMAP entries
What's Needed
- Track which pods have SOCKMAP enabled (set of namespace/name pairs)
- In
reconcileNovaNetSockMap(), compare desired vs current and call DisableSockmap() for removed endpoints
- In
Shutdown(), call DisableSockmap() for all currently enabled pods before closing
Impact
Stale SOCKMAP entries could redirect traffic to dead sockets after pod restart, causing connection failures until NovaNet's own cleanup runs.
Acceptance Criteria
Summary
DisableSockmap()is never called anywhere in the codebase. When pods are removed or the mesh manager shuts down, SOCKMAP entries are never cleaned up, leaving stale entries in the kernel eBPF map.Current State
EnableSockmap()is called inreconcileNovaNetSockMap()but there's no tracking of previously enabled podsShutdown()inmanager.go:394-414does not clean up SOCKMAP entries (comment says "NovaNet client lifecycle is managed by the caller")shutdownAgent()inmain.gocloses the NovaNet client without disabling any SOCKMAP entriesWhat's Needed
reconcileNovaNetSockMap(), compare desired vs current and callDisableSockmap()for removed endpointsShutdown(), callDisableSockmap()for all currently enabled pods before closingImpact
Stale SOCKMAP entries could redirect traffic to dead sockets after pod restart, causing connection failures until NovaNet's own cleanup runs.
Acceptance Criteria
DisableSockmap()for removed endpoints during reconciliationDisableSockmap()for all pods during shutdown