summaryrefslogtreecommitdiff
path: root/scheduler_algorithm.md
diff options
context:
space:
mode:
authork8s-merge-robot <k8s.production.user@gmail.com>2016-05-21 19:37:15 -0700
committerk8s-merge-robot <k8s.production.user@gmail.com>2016-05-21 19:37:15 -0700
commitbbc5a56dc3692f58fcdd3c4a89380bfda72a9e15 (patch)
tree482ab70352a4e4ed6bd63f9771d55cd6af077327 /scheduler_algorithm.md
parenta9712c656007b24d7aa504c947cda164fd56221b (diff)
parentc3d5cfb6c45213fd9645115f25322a26ecdcbc1e (diff)
Merge pull request #25531 from ingvagabund/introduce-memory-pressure-to-scheduler
Automatic merge from submit-queue Introduce node memory pressure condition to scheduler Following the work done by @derekwaynecarr at https://github.com/kubernetes/kubernetes/pull/21274, introducing memory pressure predicate for scheduler. Missing: * write down unit-test * test the implementation At the moment this is a heads up for further discussion how the new node's memory pressure condition should be handled in the generic scheduler. **Additional info** * Based on [1], only best effort pods are subject to filtering. * Based on [2], best effort pods are those pods "iff requests & limits are not specified for any resource across all containers". [1] https://github.com/derekwaynecarr/kubernetes/blob/542668cc7998fe0acb315a43731e1f45ecdcc85b/docs/proposals/kubelet-eviction.md#scheduler [2] https://github.com/kubernetes/kubernetes/pull/14943
Diffstat (limited to 'scheduler_algorithm.md')
-rwxr-xr-xscheduler_algorithm.md1
1 files changed, 1 insertions, 0 deletions
diff --git a/scheduler_algorithm.md b/scheduler_algorithm.md
index b6c7ea01..807f0600 100755
--- a/scheduler_algorithm.md
+++ b/scheduler_algorithm.md
@@ -48,6 +48,7 @@ The purpose of filtering the nodes is to filter out the nodes that do not meet c
- `MatchNodeSelector`: Check if the labels of the node match the labels specified in the Pod's `nodeSelector` field and, as of Kubernetes v1.2, also match the `scheduler.alpha.kubernetes.io/affinity` pod annotation if present. See [here](../user-guide/node-selection/) for more details on both.
- `MaxEBSVolumeCount`: Ensure that the number of attached ElasticBlockStore volumes does not exceed a maximum value (by default, 39, since Amazon recommends a maximum of 40 with one of those 40 reserved for the root volume -- see [Amazon's documentation](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_limits.html#linux-specific-volume-limits)). The maximum value can be controlled by setting the `KUBE_MAX_PD_VOLS` environment variable.
- `MaxGCEPDVolumeCount`: Ensure that the number of attached GCE PersistentDisk volumes does not exceed a maximum value (by default, 16, which is the maximum GCE allows -- see [GCE's documentation](https://cloud.google.com/compute/docs/disks/persistent-disks#limits_for_predefined_machine_types)). The maximum value can be controlled by setting the `KUBE_MAX_PD_VOLS` environment variable.
+- `CheckNodeMemoryPressure`: Check if a pod can be scheduled on a node reporting memory pressure condition. Currently, no ``BestEffort`` should be placed on a node under memory pressure as it gets automatically evicted by kubelet.
The details of the above predicates can be found in [plugin/pkg/scheduler/algorithm/predicates/predicates.go](http://releases.k8s.io/HEAD/plugin/pkg/scheduler/algorithm/predicates/predicates.go). All predicates mentioned above can be used in combination to perform a sophisticated filtering policy. Kubernetes uses some, but not all, of these predicates by default. You can see which ones are used by default in [plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go](http://releases.k8s.io/HEAD/plugin/pkg/scheduler/algorithmprovider/defaults/defaults.go).