github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-08-10 04:27:54 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #18646 from mesosphere/sur-690-docs

Browse Source 
Auto commit by PR queue bot
This commit is contained in:
k8s-merge-robot 2015-12-14 13:58:07 -08:00
commit 47aece40dd
1 changed files with 46 additions and 39 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

85
contrib/mesos/docs/scheduler.md
View File

@ -35,53 +35,60 @@ is restarted.
A Mesos cluster can be statically partitioned using [resources roles][2]. Each A Mesos cluster can be statically partitioned using [resources roles][2]. Each
resource is assigned such a role (`*` is the default role, if none is explicitly resource is assigned such a role (`*` is the default role, if none is explicitly
assigned in the mesos-slave command line). The Mesos master will send offers to assigned in the mesos-slave command line). The Mesos master will send offers to
frameworks for `*` resources and – optionally – for one extra role that a frameworks for `*` resources and – optionally – one additional role that a
framework is assigned to. Right now only one such extra role for a framework is framework is assigned to. Right now only one such additional role for a framework is
supported. supported.
### Configuring Roles for the Scheduler ### Configuring Roles for the Scheduler
Every Mesos framework scheduler can choose among the offered `*` resources and Every Mesos framework scheduler can choose among offered `*` resources and
those of the extra role. The Kubernetes-Mesos scheduler supports this by setting optionally one additional role. The Kubernetes-Mesos scheduler supports this by setting
the framework roles in the scheduler command line, e.g. the framework roles in the scheduler command line, e.g.
```bash ```bash
$ km scheduler ... --mesos-roles="*,role1" ... $ km scheduler ... --mesos-framework-roles="*,role1" ...
``` ```
This will tell the Kubernetes-Mesos scheduler to default to using `*` resources This permits the Kubernetes-Mesos scheduler to accept offered resources for the `*` and `role1` roles.
if a pod is not specially assigned to another role. Moreover, the extra role By default pods may be assigned any combination of resources for the roles accepted by the scheduler.
`role1` is allowed, i.e. the Mesos master will send resources or role `role1` This default role assignment behavior may be overridden using the `--mesos-default-pod-roles` flag or
to the Kubernetes scheduler. else by annotating the pod (as described later).
Note the following restrictions and possibilities: One can configure default pod roles, e.g.
- Due to the restrictions of Mesos, only one extra role may be provided on the
command line. ```bash
- It is allowed to only pass an extra role without the `*`, e.g. `--mesos-roles=role1`. $ km scheduler ... --mesos-default-pod-roles="role1" ...
This means that no `*` resources should be considered by the scheduler at all. ```
- It is allowed to pass the extra role first, e.g. `--mesos-roles=role1,*`.
This means that `role1` is the default role for pods without special role This will tell the Kubernetes-Mesos scheduler to default to `role1` resource offers.
assignment (see below). But `*` resources would be considered for pods with a special `*` The configured default pod roles must be a subset of the configured framework roles.
assignment.
The order of configured default pod roles is relevant,
`--mesos-default-pod-roles=role1,*` will first try to consume `role1` resources
from an offer and, once depleted, fall back to `*` resources.
The configuration `--mesos-default-pod-roles=*,role1` has the reverse behavior.
It first tries to consume `*` resources from an offer and, once depleted, falls
back to `role1` resources.
Due to restrictions of Mesos, currently only one additional role next to `*` can be configured
for both framework and default pod roles.
### Specifying Roles for Pods ### Specifying Roles for Pods
By default a pod is scheduled using resources of the role which comes first in By default a pod is scheduled using resources as specified using the
the list of scheduler roles. `--mesos-default-pod-roles` configuration.
A pod can opt-out of this default behaviour using the `k8s.mesosphere.io/roles` A pod can override of this default behaviour using a `k8s.mesosphere.io/roles`
label: annotation:
```yaml ```yaml
k8s.mesosphere.io/roles: role1,role2,role3 k8s.mesosphere.io/roles: "*,role1"
``` ```
The format is a comma separated list of allowed resource roles. The scheduler The format is a comma separated list of allowed resource roles. The scheduler
will try to schedule the pod with `role1` resources first, using `role2` will try to schedule the pod with `*` resources first, using `role1`
resources if the former are not available and finally falling back to `role3` resources if the former are not available or are depleted.
resources.
The `*` role may be specified as well in this list.
**Note:** An empty list will mean that no resource roles are allowed which is **Note:** An empty list will mean that no resource roles are allowed which is
equivalent to a pod which is unschedulable. equivalent to a pod which is unschedulable.
@ -93,29 +100,29 @@ apiVersion: v1
kind: Pod kind: Pod
metadata: metadata:
name: backend name: backend
labels: annotations:
k8s.mesosphere.io/roles: *,prod,test,dev k8s.mesosphere.io/roles: "*,public"
namespace: prod namespace: prod
spec: spec:
... ...
``` ```
This `prod/backend` pod will be scheduled using resources from all four roles, This `*/public` pod will be scheduled using resources from both roles,
preferably using `*` resources, followed by `prod`, `test` and `dev`. If none preferably using `*` resources, followed by `public`. If none
of those for roles provides enough resources, the scheduling fails. of those roles provides enough resources, the scheduling fails.
**Note:** The scheduler will also allow to mix different roles in the following **Note:** The scheduler will also allow to mix different roles in the following
sense: if a node provides `cpu` resources for the `*` role, but `mem` resources sense: if a node provides `cpu` resources for the `*` role, but `mem` resources
only for the `prod` role, the upper pod will be schedule using `cpu(*)` and only for the `public` role, the above pod will be scheduled using `cpu(*)` and
`mem(prod)` resources. `mem(public)` resources.
**Note:** The scheduler might also mix within one resource type, i.e. it will **Note:** The scheduler might also mix within one resource type, i.e. it will
use as many `cpu`s of the `*` role as possible. If a pod requires even more use as many `cpu`s of the `*` role as possible. If a pod requires even more
`cpu` resources (defined using the `pod.spec.resources.limits` property) for successful `cpu` resources (defined using the `pod.spec.resources.limits` property) for successful
scheduling, the scheduler will add resources from the `prod`, `test` and `dev` scheduling, the scheduler will add resources from the `public`
roles, in this order until the pod resource requirements are satisfied. E.g. a role until the pod resource requirements are satisfied. E.g. a
pod might be scheduled with 0.5 `cpu(*)`, 1.5 `cpu(prod)` and 1 `cpu(test)` pod might be scheduled with 0.5 `cpu(*)`, 1.5 `cpu(public)`
resources plus e.g. 2 GB `mem(prod)` resources. resources plus e.g. 2 GB `mem(public)` resources.
## Tuning ## Tuning