kubernetes高级调度特性

Kubernetes的调度在大部分场景下工作良好-例如，它能够确保Pod运行在具有足够空闲资源的节点上，它试图在跨节点的在传播同一集合的Pod（ReplicaSet,StatefulSet,etc），试图平衡节点的资源使用等。

但是有些时候你想过要去控制你的Pods怎么去调度，比如你可能想要保证一些Pod只会在一些特定的硬件的节点上去进行调度，或者你想过要通信频繁的的服务放在一起（co-locate）。或者你想要将一组节点用于一组的特定用户。最终，你能够知道的更多关于你的应用是怎么调度以及部署的。所以Kubernetes1.6提供了四个高级的调度特性：节点的亲和性和反亲和性，taints和tolerations, Pod的亲和性以及反亲和性。这些特性当前在Kubernetes1.6中是Beta状态.

节点的亲和性以及反亲和性

Node Affinity/Anti-Affinity是通过在调度器设置规则来确定哪些节点将会被调用。这个特性是nodeSelector特性的泛化，nodeSelector特性从Kubernetes 1.0版本就已经出现，这些规则的定义采用类似的概念：通过在节点上自定义标签和在pods上定义selector，它们可以使必选或者首选的，这取决于你希望调度程序强制执行它们的严格程序。
特定的规则必须满足Pod被调度到特定的节点上。如果没有节点满足该约束（加上所有其他正常的约束，比如有足够的空闲资源来处理该pod对资源的请求），否则该Pod将不会被调度，需要的规则通过nodeAffinity中的requiredDuringSchedulingIgnoredDuringExecution字段来指定需要的规则。

比如，如果你想要调度Pod到使用us-centrall-a的GCE zone的节点上，你可以再Pod的规格中指定如下的亲合性规则。

affinity:
 nodeAffinity:
   requiredDuringScheduling IgnoredDuringExecution:
     nodeSelectorTerms:
       - matchExpressions:
         - key: "failure-domain.beta.kubernetes.io/zone"
           operator: In
           values: ["us-central1-a"]

IgnoredDuringExecution字段表示如果node上的标签改变或者亲和性规则永远不可能满足的时候，仍然能够运行Pod.有未来的计划将会提供requiredDuringSchedulingRequiredDuringExecution，他将会从节点中驱赶（evict）pod，一旦它们不能满足node的亲和性规则的时候。
更好的规则是如果有节点匹配这些规则，他们将会首先被选中，如果没有更合适的节点可以使用的情况下，非最合适的节点被选择。你如果是更希望而不是必须pod部署到us-central1-a，可以通过稍微修改pod的规则中使用preferredDuringSchedulingIgnoredDuringExecution来达到目的。

affinity:
 nodeAffinity:
   preferredDuringSchedulingIgnoredDuringExecution:
     nodeSelectorTerms:
       - matchExpressions:
         - key: "failure-domain.beta.kubernetes.io/zone"
           operator: In
           values: ["us-central1-a"]

节点的反亲和性是通过使用相反的操作来实现，比如你想要我们的 Pod 创建的时候避免使用 us-centroal1-a 中的节点，我们可以通过如下来实现：

affinity:
 nodeAffinity:
   requiredDuringSchedulingIgnoredDuringExecution:
     nodeSelectorTerms:
       - matchExpressions:
         - key: "failure-domain.beta.kubernetes.io/zone"
           operator: NotIn
           values: ["us-central1-a"]

同样的操作我们可以使用 In, NotIn, Exists ， DoesNotExist ，以及 Gt 和 Lt.

其它的用户使用场景是根据节点的硬件架构，操作系统版本或者专用硬件来限制调度。在Kubernetes1.6版本中节点的亲和性以及反亲和性处于Beta版本。

Taints and Tolerations（污点以及容忍）

“taints and tolerations”的相关功能是允许你标注（taint）节点，那样没有Pods可以调度到这个节点上，除非pod明确的”tolerates”这个”taint”。在节点上标注而不是pos(as innode affinity/anti-affinity)是一些场景下有特殊的使用，比如希望集群中的大部分pods不要调度到某些节点上。比如，你可能想要标注你的master节点值调度运行Kubernetes的系统组件，或者贡献一部分节点给特定的用户组，或者是保持一般的Pods不要调度到特定硬件功能的节点上，这样就能够将这些特定硬件的节点预留空间分配给需要这些硬件的Pods来使用

kubectl命令行允许你在节点上设置taints,比如如下所示：

kubectl taint nodes node1 key=value:NoSchedule

创建一个污点（taint），通过key,value,effect=NoSchedule来标注节点不要被无法容忍污点的pod来调度。其他污点的effect=preferNoSchedule,它可能是NoSchedule更好的选择，NoExecute意味着在节点上运行的任何pods将会被驱逐，除非它们容忍污点。容忍污点你可以再Pod的规格中添加对于的容忍污点的说明，就像下面代码一样:

tolerations:
- key: "key"
 operator: "Equal"
 value: "value"
 effect: "NoSchedule"

除了在 kubernetes1.6 中将 taints 和 tolerations 功能升级到 beta 版本，引入了一个 alpha 功能，允许你使用 taints 和 tolerations 功能来定制当节点遭遇像网络分区这样的问题的时候来隔离 pod 到某个节点的时间，而不是使用默认的五分钟的时间，详细的内容可以参数 this sections.

Pod的亲和性和反亲和性

节点的亲和性和反亲和性允许我们通过node的标签来限制那些节点来运行Pod。但是如果你想要指定规则pods应该相对于其它的Pod来调度，比如比如你想要加速或者包装一个服务中的pods或者是其它服务中相关的pods？在这种场景下，你可以使用pod的亲和性和反亲和性，在kubernetes1.6中该特性处于beta阶段。

让我们来看一个例子，比如你在S1的服务中有一个front-ends，他们需要跟服务S2中的back-ends频繁的进行通信（一个南-北向的通信模式）。所以你想要两个服务协同co-located在通过一个云提供者的分区中，但是你不想要手动的去选择分区—如果这个分区失败，你想要pods可以被重新调度到其它的分区。你可以通过pod的亲和性规则来实现该功能，假如你给服务的Pods指定了标签service=S2和其它服务的Pods指定了标签”service=S1”:

affinity:
   podAffinity:
     requiredDuringSchedulingIgnoredDuringExecution:
     - labelSelector:
         matchExpressions:
         - key: service
           operator: In
           values: [“S1”]
       topologyKey: failure-domain.beta.kubernetes.io/zone

跟节点的亲和性/反亲和性一样，也存在一个requiredDuringSchedulingIgnoredDuringExecution变量

Pod的亲和性和反亲和性是很灵活的。想象一下，您已经分析了你的服务的性能，发现来自服务S1的容器在共享相同节点时会干扰来自服务S2的容器，这可能是由于缓存干扰效应或饱和网络链路。或者也许是由于安全性问题，您不想要容器S1和S2共享一个节点。要实现这些规则，只需对上述代码段进行两次更改即可更改podAffinity到podAntiAffinity并将topologyKey更改为kubernetes.io/hostname。

自定义调度器

如果Kubernetes调度程序的各种功能不能为您的工作负载调度提供足够的控制权，则可以委托将任意子集的pod调度到您自己的自定义调度程序，而不是默认Kubernetes调度程序。多个调度程序在Kubernetes1.6中是beta.

每个新的pod将会被默认的调度器所调用。但是如果我们提供自己的调度器，这个默认的调度器将会忽略这些pod,允许自定义的调度器来调取到节点上，如下面的例子一样.

这里我们创建pod的时候执行schedulerName字段：

apiVersion: v1
kind: Pod
metadata:
 name: nginx
 labels:
   app: nginx
spec:
 schedulerName: my-scheduler
 containers:
 - name: nginx
   image: nginx:1.10

如果我们在不部署自定义调度程序的情况下创建此Pod，则默认调度程序将忽略它，并且它将保持处于挂起状态。因此，我们需要一个自定义调度程序来查找和调度其schedulerName字段为my-scheduler的pod。

一个自定义的调度器可以使用任何语言来定义，可以根据你的需要来决定它的复杂度。这里一个通过bash来写的简单的调度器的例子，它随机的分配节点。注意到你需要运行kubectl proxy来配合它的工作。

#!/bin/bash
SERVER='localhost:8001'
while true;
do
   for PODNAME in $(kubectl --server $SERVER get pods -o json | jq '.items[] | select(.spec.schedulerName == "my-scheduler") | select(.spec.nodeName == null) | .metadata.name' | tr -d '"')
;
   do
       NODES=($(kubectl --server $SERVER get nodes -o json | jq '.items[].metadata.name' | tr -d '"'))
       NUMNODES=${#NODES[@]}
       CHOSEN=${NODES[$[ $RANDOM % $NUMNODES ]]}
       curl --header "Content-Type:application/json" --request POST --data '{"apiVersion":"v1", "kind": "Binding", "metadata": {"name": "'$PODNAME'"}, "target": {"apiVersion": "v1", "kind"
: "Node", "name": "'$CHOSEN'"}}' http://$SERVER/api/v1/namespaces/default/pods/$PODNAME/binding/
       echo "Assigned $PODNAME to $CHOSEN"
   done
   sleep 1
done

更多知识

Kubernetes 1.6发行说明有关于这些功能的更多信息，包括有关如何更改配置的详细信息，如果您已经使用Alpha版本的一个或多个这些功能（这是必需的，因为从alpha到beta的转变是一个突破更改这些功能）

致谢

这里描述的功能，包括Alpha和Beta版本，都是真正的社区努力，涉及Google，华为，IBM，Red Hat等的工程师。

参与其中

参与每周的 community meeting: 

·                    在Stack Overflow上发布问题 

·                    在Twitter @Kubernetesio 上关注最新的更新for latest updates

·                    在 Slack (room#sig-scheduling)上关注社区

非常感谢你的贡献。

--Ian Lewis, Developer Advocate, and David Oppenheimer, Software Engineer,Google

翻译于  http://blog.kubernetes.io/2017/03/advanced-scheduling-in-kubernetes.html