diff options
| author | Kubernetes Submit Queue <k8s-merge-robot@users.noreply.github.com> | 2017-11-07 20:16:13 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2017-11-07 20:16:13 -0800 |
| commit | 4d82ba353964062efd16fd5504812c35d0bbeea5 (patch) | |
| tree | 11e50ee901c4f7a10a5b14f7d21d9750712fbcb0 | |
| parent | 98ddee45f093bc32fe14582fa43f4f2160afb580 (diff) | |
| parent | e54db4066a1b75858c306532a1c727d7e48e4d14 (diff) | |
Merge pull request #1275 from kubernetes/disk_allocatable
Automatic merge from submit-queue.
Remove Disk Allocatable Evictions
After https://github.com/kubernetes/kubernetes/issues/52336, which uncovered a bug in disk accounting, I have struggled to see why ephemeral-storage allocatable evictions are necessary.
For CPU and Memory allocatable, enforcing allocatable through cgroups provides protection from being starved of compute resources by user pods.
However, for ephemeral-storage it seems that the node-level enforcement mechanisms are able to prevent the node from running out of disk, and thus prevent impact to system daemons.
Additionally, memory usage metrics read from cgroups or statfs are far more reliable than an aggregation of `du` calls which may be collected at different times (as https://github.com/kubernetes/kubernetes/issues/52336 demonstrated).
(As a side note, we should read from the /kubepods cgroup to determine allocatable memory usage)
We should still keep the scheduling aspects of node allocatable for ephemeral storage, as this allows for proper accounting. But I would like to remove enforcement of node allocatable for ephemeral storage.
cc @dchen1107 @derekwaynecarr @jingxu97 @vishh @saad-ali
@kubernetes/sig-node-proposals
| -rw-r--r-- | contributors/design-proposals/node/kubelet-eviction.md | 9 |
1 files changed, 0 insertions, 9 deletions
diff --git a/contributors/design-proposals/node/kubelet-eviction.md b/contributors/design-proposals/node/kubelet-eviction.md index 0b627b97..ebc80458 100644 --- a/contributors/design-proposals/node/kubelet-eviction.md +++ b/contributors/design-proposals/node/kubelet-eviction.md @@ -440,15 +440,6 @@ from placing new best effort pods on the node since they will be rejected by the On the other hand, the `DiskPressure` condition if true should dissuade the scheduler from placing **any** new pods on the node since they will be rejected by the `kubelet` in admission. -## Enforcing Node Allocatable - -To enforce [Node Allocatable](./node-allocatable.md), Kubelet primarily uses cgroups. -However `storage` cannot be enforced using cgroups. - -Once Kubelet supports `storage` as an `Allocatable` resource, Kubelet will perform evictions whenever the total storage usage by pods exceed node allocatable. - -If a pod cannot tolerate evictions, then ensure that requests is set and it will not exceed `requests`. - ## Best Practices ### DaemonSet |