Merge pull request #4145 from vishh/document-storage-allocatable

Adding storage as a supported resource to node allocatable

docs/tasks/administer-cluster/reserve-compute-resources.md

@@ -45,8 +45,7 @@ on each node.
 
 `Allocatable` on a Kubernetes node is defined as the amount of compute resources
 that are available for pods. The scheduler does not over-subscribe
-`Allocatable`. `CPU` and `memory` are supported as of now. Support for `storage`
-is expected to be added in the future.
+`Allocatable`. `CPU`, `memory` and `storage` are supported as of now.
 
 Node Allocatable is exposed as part of `v1.Node` object in the API and as part
 of `kubectl describe node` in the CLI.
@@ -81,7 +80,7 @@ be configured to use the `systemd` cgroup driver.
 
 ### Kube Reserved
 
-- **Kubelet Flag**: `--kube-reserved=[cpu=100m][,][memory=100Mi]`
+- **Kubelet Flag**: `--kube-reserved=[cpu=100m][,][memory=100Mi][,][storage=1Gi]`
 - **Kubelet Flag**: `--kube-reserved-cgroup=`
 
 `kube-reserved` is meant to capture resource reservation for kubernetes system
@@ -111,7 +110,7 @@ exist. Kubelet will fail if an invalid cgroup is specified.
 
 ### System Reserved
 
-- **Kubelet Flag**: `--system-reserved=[cpu=100mi][,][memory=100Mi]`
+- **Kubelet Flag**: `--system-reserved=[cpu=100mi][,][memory=100Mi][,][storage=1Gi]`
 - **Kubelet Flag**: `--system-reserved-cgroup=`
 
 
@@ -194,20 +193,22 @@ So expect a drop in `Allocatable` capacity in future releases.
 
 Here is an example to illustrate Node Allocatable computation:
 
-* Node has `32Gi` of `memory` and `16 CPUs`
-* `--kube-reserved` is set to `cpu=1,memory=2Gi`
-* `--system-reserved` is set to `cpu=500m,memory=1Gi`
-* `--eviction-hard` is set to `memory.available<500Mi`
+* Node has `32Gi` of `memory`, `16 CPUs` and `100Gi` of `Storage`
+* `--kube-reserved` is set to `cpu=1,memory=2Gi,storage=1Gi`
+* `--system-reserved` is set to `cpu=500m,memory=1Gi,storage=1Gi`
+* `--eviction-hard` is set to `memory.available<500Mi,nodefs.available<10%`
 
-Under this scenario, `Allocatable` will be `14.5 CPUs` & `28.5Gi` of memory.
-Scheduler ensures that the total `requests` across all pods on this node does
-not exceed `28.5Gi`. Kubelet evicts pods whenever the overall memory usage
-exceeds across pods exceed `28.5Gi`. If all processes on the node consume as
+Under this scenario, `Allocatable` will be `14.5 CPUs`, `28.5Gi` of memory and
+`98Gi` of local storage.
+Scheduler ensures that the total memory `requests` across all pods on this node does
+not exceed `28.5Gi` and storage doesn't exceed `88Gi`.
+Kubelet evicts pods whenever the overall memory usage exceeds across pods exceed `28.5Gi`,
+or if overall disk usage exceeds `88Gi` If all processes on the node consume as
 much CPU as they can, pods together cannot consume more than `14.5 CPUs`.
 
 If `kube-reserved` and/or `system-reserved` is not enforced and system daemons
 exceed their reservation, `kubelet` evicts pods whenever the overall node memory
-usage is higher than `31.5Gi`.
+usage is higher than `31.5Gi` or `storage` is greater than `90Gi`
 
 ## Feature Availability
 
@@ -231,3 +232,5 @@ required to drain their nodes prior to upgrade of the `kubelet` from prior
 versions in order to ensure pods and their associated containers are launched in
 the proper part of the cgroup hierarchy.
 
+As of Kubernetes version 1.7, `kubelet` supports specifying `storage` as a resource
+for `kube-reserved` and `system-reserved`.