Skip to content

KEP-3386: Update milestone #5644

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 13, 2025
Merged

KEP-3386: Update milestone #5644

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion keps/sig-node/3386-kubelet-evented-pleg/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -141,7 +141,8 @@ This might be a good place to talk about core concepts and how they relate.
- Another risk is the CRI implementation could have a buggy event emitting system, and miss pod lifecycle events.
- A mitigation is a `kube_pod_missed_events` metric, which the Kubelet could report when a lifecycle event is registered that wasn't triggered by an event, but rather by changes of state between lists.
- While using the Evented implementation, the periodic relisting functionality would still be used with an increased interval which should work as a fallback mechanism for missed events in case of any disruptions.
- Evented PLEG will need to update global cache timestamp periodically in order to make sure pod workers don't get stuck at [GetNewerThan](https://github.com/kubernetes/kubernetes/blob/4a894be926adfe51fd8654dcceef4ece89a4259f/pkg/kubelet/pod_workers.go#L924) in case Evented PLEG misses the event for any unforeseen reason.
- During the state transition of a pod, the execution time of the podWorker code is slower than the event reporting speed of the container runtime. As a result, when calling `GetNewerThan()`, the timestamp in the PLEG cache is newer than `lastSyncTime`, ultimately causing the podWorker to enter a blocking state.
- We use real-time container events to determine the container's state, rather than relying on the cached timestamp to decide whether the container's state is up to date. This is because, in the case of `EventedPLEG`, real-time container events always represent the latest container state, which also aligns with the design where the container lifecycle is driven by container events.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section is implemented in kubernetes/kubernetes#129355.


## Design Details

Expand Down
2 changes: 1 addition & 1 deletion keps/sig-node/3386-kubelet-evented-pleg/kep.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ stage: alpha
# The most recent milestone for which work toward delivery of this KEP has been
# done. This can be the current (upcoming) milestone, if it is being actively
# worked on.
latest-milestone: "v1.30"
latest-milestone: "v1.35"

# The milestone at which this feature was, or is targeted to be, at each stage.
milestone:
Expand Down