From 6b261c7611c192b326ca8e92416ee04b88b31f75 Mon Sep 17 00:00:00 2001 From: Jin Hase Date: Tue, 5 Nov 2019 13:52:38 +0900 Subject: [PATCH] modify terminated-pod-gc-threshold explanation (#15272) (#17183) * modify terminated-pod-gc-threshold explanation (#15272) * modify terminated-pod-gc-threshold explanation (#15272) --- content/en/docs/concepts/workloads/pods/pod-lifecycle.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md index 65815c5bc0..a55378ba3c 100644 --- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md @@ -276,10 +276,11 @@ once bound to a node, a Pod will never be rebound to another node. ## Pod lifetime -In general, Pods do not disappear until someone destroys them. This might be a -human or a controller. The only exception to -this rule is that Pods with a `phase` of Succeeded or Failed for more than some -duration (determined by `terminated-pod-gc-threshold` in the master) will expire and be automatically destroyed. +In general, Pods remain until a human or controller process explicitly removes them. +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. Three types of controllers are available: