Rule Resync and minSyncPeriod
How long after a Pod dies do the rules sending traffic to it disappear? Every Node runs a kube-proxy unless you replaced it, and it watches Services and EndpointSlices, not Pods, batching changes behind minSyncPeriod instead of rewriting the kernel per event, so deleting a 100-Pod Deployment costs about five updates, not a hundred. Staleness is the price, because one change can wait a full minSyncPeriod, while syncPeriod drives the cleanup no single change triggers.
Play the animation 6 steps, animated, best on a wide screen
Rule Resync and minSyncPeriod, step by step
-
A Pod that dies reaches this loop only as a change to the EndpointSlice that listed its endpoint. The change rewrites nothing by itself: it marks the rules stale and asks for a resync, and the resync is what touches the kernel. How soon that resync runs is a question about the floor between them rather than about the change.
Play from step 1 -
Delete the Deployment behind this Service and all 100 of its Pods go. The slice loses 100 endpoints, so 100 separate changes reach kube-proxy inside a very short window, and every one of them on its own is a reason to rewrite the rules in the kernel.
Play from step 2 -
With minSyncPeriod set to 0s kube-proxy resyncs immediately on every Service or EndpointSlice change. Those 100 deletions come out as 100 separate updates, removing the endpoints from the rules one at a time. That is a great deal of redundant work whenever many things change in a small period.
Play from step 3 -
The floor is minSyncPeriod, and it is a floor rather than a delay: at the default 1s no resync starts sooner than a second after the last one ends, so the changes waiting behind it are aggregated. The same 100 deletions might come out as about 5 updates of 20 endpoints each, cheaper in CPU, and the full set of changes lands faster.
Play from step 4 -
The floor is paid for in staleness. A change that arrives just after a resync waits for the next one, up to a full minSyncPeriod, and until then the rules still carry an endpoint the API server has already dropped. A larger floor aggregates more work and widens that window.
Play from step 5 -
The other clock is syncPeriod, and it is not tied to any individual change. It paces the re-synchronizing and cleanup work no single change triggers: every syncPeriod kube-proxy checks whether an external component has interfered with its rules, and resyncs them if one has.
Play from step 6