Extend documentation on PodGC focusing on PodDisruptionConditions enabled
Co-authored-by: divya-mohan0209 <divya.mohan0209@gmail.com>pull/38042/head
parent
5dc9273803
commit
964a24d759
|
@ -270,6 +270,10 @@ deleted. In such a situation, after some time, the
|
|||
Pod disruption condition will be cleared.
|
||||
{{< /note >}}
|
||||
|
||||
When the `PodDisruptionConditions` feature gate is enabled,
|
||||
along with cleaning up the pods, the Pod garbage collector (PodGC) will also mark them as failed if they are in a non-terminal
|
||||
phase (see also [Pod garbage collection](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)).
|
||||
|
||||
When using a Job (or CronJob), you may want to use these Pod disruption conditions as part of your Job's
|
||||
[Pod failure policy](/docs/concepts/workloads/controllers/job#pod-failure-policy).
|
||||
|
||||
|
|
|
@ -507,17 +507,27 @@ If you need to force-delete Pods that are part of a StatefulSet, refer to the ta
|
|||
documentation for
|
||||
[deleting Pods from a StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
|
||||
|
||||
### Garbage collection of terminated Pods {#pod-garbage-collection}
|
||||
### Garbage collection of Pods {#pod-garbage-collection}
|
||||
|
||||
For failed Pods, the API objects remain in the cluster's API until a human or
|
||||
{{< glossary_tooltip term_id="controller" text="controller" >}} process
|
||||
explicitly removes them.
|
||||
|
||||
The control plane cleans up terminated Pods (with a phase of `Succeeded` or
|
||||
The Pod garbage collector (PodGC), which is a controller in the control plane, cleans up terminated Pods (with a phase of `Succeeded` or
|
||||
`Failed`), when the number of Pods exceeds the configured threshold
|
||||
(determined by `terminated-pod-gc-threshold` in the kube-controller-manager).
|
||||
This avoids a resource leak as Pods are created and terminated over time.
|
||||
|
||||
Additionally, PodGC cleans up any Pods which satisfy any of the following conditions:
|
||||
1. are orphan pods - bound to a node which no longer exists,
|
||||
2. are unscheduled terminating pods,
|
||||
3. are terminating pods, bound to a non-ready node tainted with [`node.kubernetes.io/out-of-service`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service), when the `NodeOutOfServiceVolumeDetach` feature gate is enabled.
|
||||
|
||||
When the `PodDisruptionConditions` feature gate is enabled, along with
|
||||
cleaning up the pods, PodGC will also mark them as failed if they are in a non-terminal
|
||||
phase. Also, PodGC adds a pod disruption condition when cleaning up an orphan
|
||||
pod (see also:
|
||||
[Pod disruption conditions](/docs/concepts/workloads/pods/disruptions#pod-disruption-conditions)).
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
Loading…
Reference in New Issue