-
Notifications
You must be signed in to change notification settings - Fork 14.9k
Add pod Observed Generation docs for 1.34 #51371
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.
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
base: main
Are you sure you want to change the base?
Add pod Observed Generation docs for 1.34 #51371
Conversation
Welcome @jonathancecilj! |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
/assign |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good! I have a few small suggestions. Thanks for taking this on
@@ -260,6 +255,19 @@ The above update rules apply to regular pod updates, but other pod fields can be | |||
- **Binding:** The `binding` subresource allows setting the pod's `spec.nodeName` via a `Binding` request. | |||
This is typically only used by the {{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}}. | |||
|
|||
### Pod generation | |||
|
|||
- The `generation` field is unique. It will be automatically set by the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The `generation` field is unique. It will be automatically set by the | |
- The `metadata.generation` field is unique. It will be automatically set by the |
Previously this was in a section that was talking about metadata, but since we are moving it to its own section, we should make it expicit
|
||
{{< feature-state for_k8s_version="v1.34" state="beta" >}} | ||
|
||
- `observedGeneration` is an optional field that is captured in the `status` section of the Pod |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: remove the word "optional". Optional usually implies that it is optional for the user, but in this case the field is set by the system (and is always set when the feature gate is on)
- `observedGeneration` is an optional field that is captured in the `status` section of the Pod | |
- `observedGeneration` is a field that is captured in the `status` section of the Pod |
{{< feature-state for_k8s_version="v1.34" state="beta" >}} | ||
|
||
- `observedGeneration` is an optional field that is captured in the `status` section of the Pod | ||
object. Kubelet will set `status.observedGeneration` to track the pod state to the current pod status. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
object. Kubelet will set `status.observedGeneration` to track the pod state to the current pod status. | |
object. If the feature gate `PodObservedGenerationTracking` is set, the Kubelet will set `status.observedGeneration` to track the pod state to the current pod status. |
object. Kubelet will set `status.observedGeneration` to track the pod state to the current pod status. | ||
The pod's `status.observedGeneration` will reflect the `metadata.generation` of the pod at the point | ||
that the pod status is being reported. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a great high-level description of what generation / observedGeneration is, thank you!
Just one thing I want us to add here. #51195 states that we have to carefully document the nuanced meaning of observedGeneration. That "nuance" I think is captured well in summary section of the mutable fields analysis doc:
If allocated spec is reflected directly in the pod status, it makes sense for the observed generation to be the generation observed in the current sync loop. This is the case for: allocated resources, resize status, ephemeral containers.
If the status is an indirect result of running the spec, then the generation associated is the generation from the previous sync loop. This is the case for: actual resources, container image, activeDeadlineSeconds/terminationGracePeriodSeconds
Can we add something to this effect here?
/cc @SergeyKanzhelev |
/retest |
@jonathancecilj: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
/ok-to-test |
/retest |
Description
Add pod ObservedGeneration info to pod docs as part of beta promotion.
Observed Pod Generation KEP: kubernetes/enhancements#2377
Issue
Closes: #51195