Merge pull request #41108 from Zhuzhenghao/clean
Cleanup page garbage-collection and nodespull/41111/head
Kubernetes Prow Robot
GitHub
commit
c6ff7b40db
|
|
@ -8,17 +8,17 @@ weight: 70
|
|||
{{<glossary_definition term_id="garbage-collection" length="short">}} This
|
||||
allows the clean up of resources like the following:
|
||||
|
||||
* [Terminated pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
|
||||
* [Completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
* [Objects without owner references](#owners-dependents)
|
||||
* [Unused containers and container images](#containers-images)
|
||||
* [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete)
|
||||
* [Stale or expired CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
|
||||
* {{<glossary_tooltip text="Nodes" term_id="node">}} deleted in the following scenarios:
|
||||
* [Terminated pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
|
||||
* [Completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
* [Objects without owner references](#owners-dependents)
|
||||
* [Unused containers and container images](#containers-images)
|
||||
* [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete)
|
||||
* [Stale or expired CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
|
||||
* {{<glossary_tooltip text="Nodes" term_id="node">}} deleted in the following scenarios:
|
||||
* On a cloud when the cluster uses a [cloud controller manager](/docs/concepts/architecture/cloud-controller/)
|
||||
* On-premises when the cluster uses an addon similar to a cloud controller
|
||||
manager
|
||||
* [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats)
|
||||
* [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats)
|
||||
|
||||
## Owners and dependents {#owners-dependents}
|
||||
|
||||
|
|
@ -63,8 +63,8 @@ delete an object, you can control whether Kubernetes deletes the object's
|
|||
dependents automatically, in a process called *cascading deletion*. There are
|
||||
two types of cascading deletion, as follows:
|
||||
|
||||
* Foreground cascading deletion
|
||||
* Background cascading deletion
|
||||
* Foreground cascading deletion
|
||||
* Background cascading deletion
|
||||
|
||||
You can also control how and when garbage collection deletes resources that have
|
||||
owner references using Kubernetes {{<glossary_tooltip text="finalizers" term_id="finalizer">}}.
|
||||
|
|
@ -75,11 +75,11 @@ In foreground cascading deletion, the owner object you're deleting first enters
|
|||
a *deletion in progress* state. In this state, the following happens to the
|
||||
owner object:
|
||||
|
||||
* The Kubernetes API server sets the object's `metadata.deletionTimestamp`
|
||||
* The Kubernetes API server sets the object's `metadata.deletionTimestamp`
|
||||
field to the time the object was marked for deletion.
|
||||
* The Kubernetes API server also sets the `metadata.finalizers` field to
|
||||
* The Kubernetes API server also sets the `metadata.finalizers` field to
|
||||
`foregroundDeletion`.
|
||||
* The object remains visible through the Kubernetes API until the deletion
|
||||
* The object remains visible through the Kubernetes API until the deletion
|
||||
process is complete.
|
||||
|
||||
After the owner object enters the deletion in progress state, the controller
|
||||
|
|
@ -129,8 +129,8 @@ which is part of the kubelet, with the cooperation of
|
|||
considers the following disk usage limits when making garbage collection
|
||||
decisions:
|
||||
|
||||
* `HighThresholdPercent`
|
||||
* `LowThresholdPercent`
|
||||
* `HighThresholdPercent`
|
||||
* `LowThresholdPercent`
|
||||
|
||||
Disk usage above the configured `HighThresholdPercent` value triggers garbage
|
||||
collection, which deletes images in order based on the last time they were used,
|
||||
|
|
@ -142,11 +142,11 @@ until disk usage reaches the `LowThresholdPercent` value.
|
|||
The kubelet garbage collects unused containers based on the following variables,
|
||||
which you can define:
|
||||
|
||||
* `MinAge`: the minimum age at which the kubelet can garbage collect a
|
||||
* `MinAge`: the minimum age at which the kubelet can garbage collect a
|
||||
container. Disable by setting to `0`.
|
||||
* `MaxPerPodContainer`: the maximum number of dead containers each Pod
|
||||
* `MaxPerPodContainer`: the maximum number of dead containers each Pod
|
||||
can have. Disable by setting to less than `0`.
|
||||
* `MaxContainers`: the maximum number of dead containers the cluster can have.
|
||||
* `MaxContainers`: the maximum number of dead containers the cluster can have.
|
||||
Disable by setting to less than `0`.
|
||||
|
||||
In addition to these variables, the kubelet garbage collects unidentified and
|
||||
|
|
@ -171,8 +171,8 @@ You can tune garbage collection of resources by configuring options specific to
|
|||
the controllers managing those resources. The following pages show you how to
|
||||
configure garbage collection:
|
||||
|
||||
* [Configuring cascading deletion of Kubernetes objects](/docs/tasks/administer-cluster/use-cascading-deletion/)
|
||||
* [Configuring cleanup of finished Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
* [Configuring cascading deletion of Kubernetes objects](/docs/tasks/administer-cluster/use-cascading-deletion/)
|
||||
* [Configuring cleanup of finished Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
|
||||
<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
|
||||
|
||||
|
|
|
|||
|
|
@ -321,7 +321,7 @@ This period can be configured using the `--node-monitor-period` flag on the
|
|||
|
||||
### Rate limits on eviction
|
||||
|
||||
In most cases, the node controller limits the eviction rate to
|
||||
In most cases, the node controller limits the eviction rate to
|
||||
`--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods
|
||||
from more than 1 node per 10 seconds.
|
||||
|
||||
|
|
@ -641,10 +641,9 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
Learn more about the following:
|
||||
* [Components](/docs/concepts/overview/components/#node-components) that make up a node.
|
||||
* [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
* [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) section of the architecture design document.
|
||||
* [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
|
||||
* [Node Resource Managers](/docs/concepts/policy/node-resource-managers/).
|
||||
* [Resource Management for Windows nodes](/docs/concepts/configuration/windows-resource-management/).
|
||||
|
||||
* [Components](/docs/concepts/overview/components/#node-components) that make up a node.
|
||||
* [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core).
|
||||
* [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) section of the architecture design document.
|
||||
* [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
|
||||
* [Node Resource Managers](/docs/concepts/policy/node-resource-managers/).
|
||||
* [Resource Management for Windows nodes](/docs/concepts/configuration/windows-resource-management/).
|
||||
|
|
|
|||
Loading…
Reference in New Issue