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 /vendor/github.com/client9 | |
| 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
Diffstat (limited to 'vendor/github.com/client9')
0 files changed, 0 insertions, 0 deletions
