From 964a24d7591276e9bea6b0c2f3f3d4b8e67f4625 Mon Sep 17 00:00:00 2001 From: Michal Wozniak Date: Thu, 24 Nov 2022 11:00:20 +0100 Subject: [PATCH] Extend documentation on PodGC focusing on PodDisruptionConditions enabled Co-authored-by: divya-mohan0209 --- .../en/docs/concepts/workloads/pods/disruptions.md | 4 ++++ .../docs/concepts/workloads/pods/pod-lifecycle.md | 14 ++++++++++++-- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index 48e239506b..66d05ef92a 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -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). diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index 06734ee51d..852f965530 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -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" %}}