摘要：的調(diào)度機(jī)制組件調(diào)度器會將調(diào)度到資源滿足要求并且評分最高的上。這個特性的設(shè)計初衷是為了替代，并擴(kuò)展更強(qiáng)大的調(diào)度策略。和完全相同，以進(jìn)行強(qiáng)制的約束。軟規(guī)則除了，，還有一條軟規(guī)則配置后，沒有相關(guān)污點策略的會盡量避免調(diào)度到該上。

k8s調(diào)度器會將pod調(diào)度到資源滿足要求并且評分最高的node上。我們可以使用多種規(guī)則比如：1.設(shè)置cpu、內(nèi)存的使用要求；2.增加node的label，并通過pod.Spec.NodeSelector進(jìn)行強(qiáng)匹配；3.直接設(shè)置pod的nodeName，跳過調(diào)度直接下發(fā)。

k8s 1.2加入了一個實驗性的功能：affinity。意為親和性。這個特性的設(shè)計初衷是為了替代nodeSelector，并擴(kuò)展更強(qiáng)大的調(diào)度策略。

調(diào)度器的工作機(jī)制是這樣的：
一、預(yù)備工作
1、緩存所有的node節(jié)點，記錄他們的規(guī)格：cpu、內(nèi)存、磁盤空間、gpu顯卡數(shù)等；
2、緩存所有運行中的pod，按照pod所在的node進(jìn)行區(qū)分，統(tǒng)計每個node上的pod request了多少資源。request是pod的QoS配置，可以參考之前的文章。
3、list & watch pod資源，當(dāng)檢查到有新的Pending狀態(tài)的pod出現(xiàn)，就將它加入到調(diào)度隊列中。
4、調(diào)度器的worker組件從隊列中取出pod進(jìn)行調(diào)度。

二、調(diào)度過程
1、先將當(dāng)前所有的node放入隊列；
2、執(zhí)行predicates算法，對隊列中的node進(jìn)行篩選。這里算法檢查了一些pod運行的必要條件，包括port不沖突、cpu和內(nèi)存資源QoS（如果有的話）必須滿足、掛載volume（如果有的話）類型必須匹配、nodeSelector規(guī)則必須匹配、硬性的affinity規(guī)則（下文會提到）必須匹配、node的狀態(tài)（condition）必須正常，taint_toleration硬規(guī)則（下文會提到）等等。
2、執(zhí)行priorities算法，對隊列中剩余的node進(jìn)行評分，這里有許多評分項，各個項目有各自的權(quán)重：整體cpu，內(nèi)存資源的平衡性、node上是否有存在要求的鏡像、同rs的pod是否有調(diào)度、node affinity的軟規(guī)則、taint_toleration軟規(guī)則（下文會提到）等等。
3、最終評分最高的node會被選出。即代碼中suggestedHost, err := sched.schedule(pod)一句（plugin/pkg/scheduler/scheduler.go）的返回值。
4、調(diào)度器執(zhí)行assume方法，該方法在pod調(diào)度到node之前，就以“該pod運行在目標(biāo)node上” 為場景更新調(diào)度器緩存中的node 信息，也即預(yù)備工作中的1、2兩點。這么做是為了讓pod在真正調(diào)度到node上時，調(diào)度器也可以同時做后續(xù)其他pod的調(diào)度工作。
5、調(diào)度器執(zhí)行bind方法，該方法創(chuàng)建一個Binding資源，apiserver檢查到創(chuàng)建該資源時，會主動更新pod的nodeName字段。完成調(diào)度。

舉例：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    disktype: ssd

上面這個pod會且僅會被調(diào)度到帶有disktype: ssd這個label的node上。這是一種強(qiáng)規(guī)則，沒有妥協(xié)，必須遵守。

有親和性規(guī)則，那么反親和性規(guī)則肯定也要有。

親和性規(guī)則實現(xiàn)了更豐富的規(guī)則表達(dá)方式。并且包含了nodeSelector的硬規(guī)則和另一種軟規(guī)則。

軟規(guī)則是一種優(yōu)先規(guī)則，如果沒有符合這個優(yōu)先規(guī)則的節(jié)點，它仍然會被進(jìn)行調(diào)度。

node親和性和nodeSelector類似，通過label進(jìn)行可調(diào)度node的過濾，現(xiàn)在有兩種node親和性：requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution：

強(qiáng)規(guī)則。和nodeSelector完全相同，以label進(jìn)行強(qiáng)制的約束。需要指出的是：目前，如果一個node在運行時label發(fā)生了變化，變化后和其上運行的pod的requiredDuringSchedulingIgnoredDuringExecution 不再匹配，這個node上的pod也不會被驅(qū)逐，這個功能會在以后被改進(jìn)，屆時會增加一種類型RequiredDuringSchedulingRequiredDuringExecution 。

軟規(guī)則。舉例來說：我們要將某個容器盡可能地調(diào)度到可用域X中，但如果不存在這個可用域或者可用域無法再運行pod，調(diào)度器也允許這個pod被調(diào)度到其他可用域。

以下是一個包含了強(qiáng)規(guī)則和軟規(guī)則的案例:

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: gcr.io/google_containers/pause:2.0

該案例表明，這個pod只允許被調(diào)度到帶有kubernetes.io/e2e-az-name=e2e-az1或e2e-az2的label的node上，也即只允許被調(diào)度到e2e-az1或者e2e-az2兩個可用域中；另外，pod要盡量調(diào)度到包含another-node-label-key的值為another-node-label-value的node上。

matchExpressions結(jié)構(gòu)記錄各種表達(dá)式，一個表達(dá)式包含key,operator,values，分別表示關(guān)鍵字、關(guān)鍵字匹配關(guān)系、關(guān)鍵字匹配值。匹配關(guān)系包括：In,NotIn,Exists,DoesNotExist,Gt,Lt。NotIn和DoesNotExist是node anti-affinity的一種表現(xiàn)。

如果一個pod的描述信息中同時包含了nodeSelector和nodeAffinity,那么調(diào)度時兩個規(guī)則都要滿足。

如果一個nodeAffinity中包含了多條nodeSelectorTerms， 調(diào)度器只需要滿足其中一條； 如果一個 nodeSelectorTerms中記錄了多條matchExpressions，那么調(diào)度器要滿足所有的matchExpressions

這兩個特性都包含在1.4版本中，上面的親和性是node親和性，這個就是pod親和性，簡而言之，要把pod調(diào)度到某個node上，這個node上已有的pod能滿足、或盡量滿足某些條件。這個特性用pod.spec.affinity.podAffinity和pod.spec.affinity.podAntiAffinity來表示。

pod親和性的規(guī)則可以這么表示：
這個pod應(yīng)該（或者不應(yīng)該）運行在節(jié)點X上，X上必須已經(jīng)運行了一個或多個滿足規(guī)則Y的pod。規(guī)則Y的表達(dá)方式類似于一個labelSelector并關(guān)聯(lián)了一個namespace列表:namespaces（若沒有則表示“allnamespaces”）,X可能是node或一個az，我們通過字段topologyKey來規(guī)劃X，即所有的X都要滿足topologyKey相同，一般topologyKey是一個label的key。

為什么要有namespace列表？因為和node不同，pod是有分namespace的，因此pod的label也是有分namespace的。在這種情況下，規(guī)則Y必須要指明自己這個規(guī)則要適用于哪些namespace。比如node上運行的是hy這個namespace下的pod，即便pod的label和規(guī)則Y的nodeSelector都相同，我們也視為不符合規(guī)則。

和node親和性一樣，pod親和性也包含兩個（硬規(guī)則和軟規(guī)則）：

requiredDuringSchedulingIgnoredDuringExecution: 硬規(guī)則。

preferredDuringSchedulingIgnoredDuringExecution：

舉個例子：

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: kubernetes.io/hostname
  containers:
  - name: with-pod-affinity
    image: gcr.io/google_containers/pause:2.0

上面的pod模板使用了podAffinity的硬規(guī)則和podAntiAffinity的軟規(guī)則。

podAffinity規(guī)則中topologyKey是zone，也就是可用域，說明這條規(guī)則可以規(guī)劃處調(diào)度到的域，首先，node上必須至少有一個running狀態(tài)的pod包含key為security，value為S1的label。只要滿足這個條件，那么這個node和其同一個域（擁有相同的failure-domain.beta.kubernetes.io/zone 為key，且值相同的label）的node均會被調(diào)度。

podAntiAffinity規(guī)則中topologyKey是hostname，表明該規(guī)則約定了某種node盡量不會被調(diào)度到，這種node上已經(jīng)運行了包含key為security，value為S2的label的pod。

假如現(xiàn)在有node a，b，c，其中a和b擁有相同的zone，且b上運行了一個pod，這個pod有一個label,key為security，value為S1。那么我們創(chuàng)建如上的一個親和性規(guī)則的3副本時，三個副本都會被調(diào)度到a或者b上。假如b上同時運行了一個pod，這個pod有一個label,key為security，value為S2,那么所有的副本都會調(diào)度到node a上。

node 可以被打上污點標(biāo)記，并配置污點容忍策略。而pod的描述信息中如果包含了相同的污點容忍策略，就可以被調(diào)度到這個node上，反之則不可、或盡量不允許。

給node a 打上污點 name=huang, 策略為不可調(diào)度：
kubectl taint nodes a name=huang:NoSchedule
若我創(chuàng)建的pod中包含如下描述：

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

則這個pod可以容忍有這類污點的node，即可以調(diào)度到node a，當(dāng)然，也可以用如下的描述：

tolerations:
- key: "name"
  operator: "Exist"
  effect: "NoSchedule"

類似的硬性規(guī)則體現(xiàn)在effect字段中，還有NoExecute,它比NoSchedule更嚴(yán)格，不止pod不能調(diào)度上去，node上原有的pod如果不能容忍污點，就會被驅(qū)逐（eviction），配合字段tolerationSeconds可以規(guī)定這些會被驅(qū)逐的pod能在node上呆多久。

除了NoExecute，NoSchedule，還有一條軟規(guī)則：PreferNoSchedule.配置effect=PreferNoSchedule后，沒有相關(guān)污點策略的pod會盡量避免調(diào)度到該node上。