@@ -232,7 +232,7 @@ have some limitations:
232
232
` metadata.finalizers ` list.
233
233
- Pod updates may not change fields other than ` spec.containers[*].image ` ,
234
234
` spec.initContainers[*].image ` , ` spec.activeDeadlineSeconds ` , ` spec.terminationGracePeriodSeconds ` or
235
- ` spec.tolerations ` . For ` spec.tolerations ` , you can only add new entries.
235
+ ` spec.tolerations ` or ` spec.schedulingGates ` . For ` spec.tolerations ` , you can only add new entries.
236
236
- When updating the ` spec.activeDeadlineSeconds ` field, two types of updates
237
237
are allowed:
238
238
@@ -261,20 +261,21 @@ The above update rules apply to regular pod updates, but other pod fields can be
261
261
system such that new pods have a ` metadata.generation ` of 1, and every update to
262
262
mutable fields in the pod's spec will increment the ` metadata.generation ` by 1.
263
263
264
- {{< feature-state for_k8s_version="v1.34" state="beta " >}}
264
+ {{< feature-state feature_gate_name="PodObservedGenerationTracking " >}}
265
265
266
266
- ` observedGeneration ` is a field that is captured in the ` status ` section of the Pod
267
267
object. If the feature gate ` PodObservedGenerationTracking ` is set, the Kubelet will set ` status.observedGeneration `
268
268
to track the pod state to the current pod status. The pod's ` status.observedGeneration ` will reflect the
269
269
` metadata.generation ` of the pod at the point that the pod status is being reported.
270
270
271
- The key distinction is whether a change in the ` spec ` is reflected directly in the ` status ` or is an indirect result
272
- of a running process.
271
+ Different status fields may either be associated with the ` metadata.generation ` of the current sync loop, or with the
272
+ ` metadata.generation ` of the previous sync loop. The key distinction is whether a change in the ` spec ` is reflected
273
+ directly in the ` status ` or is an indirect result of a running process.
273
274
274
275
#### Direct Status Updates
275
276
276
- For fields where a change can be directly observed and reflected in the Pod's status , the ` observedGeneration ` will
277
- match the current ` spec ` generation (Generation N) during the same sync loop .
277
+ For status fields where the allocated spec is directly reflected, the ` observedGeneration ` will
278
+ be associated with the current ` metadata.generation ` (Generation N).
278
279
279
280
This behavior applies to:
280
281
@@ -284,9 +285,8 @@ This behavior applies to:
284
285
285
286
#### Indirect Status Updates
286
287
287
- For changes that require a process to run before the result is visible the status will reflect the outcome of the previous
288
- ` spec ` generation (Generation N-1) during the current sync loop. The ` observedGeneration ` will update in a subsequent loop
289
- after the process completes.
288
+ For status fields that are an indirect result of running the spec, the ` observedGeneration ` will be associated
289
+ with the ` metadata.generation ` of the previous sync loop (Generation N-1).
290
290
291
291
This behavior applies to:
292
292
0 commit comments