摘要：換句話說(shuō)，親和性選擇節(jié)點(diǎn)僅在調(diào)度時(shí)起作用。先創(chuàng)建集群反親和性打散各個(gè)副本再部署服務(wù)，需要打散并且與服務(wù)共存，配置如下注意需要進(jìn)行大量處理，所以會(huì)明顯減慢大型集群的調(diào)度時(shí)間，不建議在大于幾百個(gè)節(jié)點(diǎn)的集群中使用該功能。

前一篇文章 Kubernetes 調(diào)度器淺析，大致講述了調(diào)度器的工作原理及相關(guān)調(diào)度策略。這一章會(huì)繼續(xù)深入調(diào)度器，介紹下“親和性調(diào)度”。

Kubernetes 支持限制 Pod 在指定的 Node 上運(yùn)行，或者指定更傾向于在某些特定 Node 上運(yùn)行。
有幾種方式可以實(shí)現(xiàn)這個(gè)功能：

NodeName: 最簡(jiǎn)單的節(jié)點(diǎn)選擇方式，直接指定節(jié)點(diǎn)，跳過(guò)調(diào)度器。

NodeSelector: 早期的簡(jiǎn)單控制方式，直接通過(guò)鍵—值對(duì)將 Pod 調(diào)度到具有特定 label 的 Node 上。

NodeAffinity: NodeSelector 的升級(jí)版，支持更豐富的配置規(guī)則，使用更靈活。(NodeSelector 將被淘汰.)

PodAffinity: 根據(jù)已在節(jié)點(diǎn)上運(yùn)行的 Pod 標(biāo)簽來(lái)約束 Pod 可以調(diào)度到哪些節(jié)點(diǎn)，而不是根據(jù) node label。

nodeName 是 PodSpec 的一個(gè)字段，用于直接指定調(diào)度節(jié)點(diǎn)，并運(yùn)行該 pod。調(diào)度器在工作時(shí)，實(shí)際選擇的是 nodeName 為空的 pod 并進(jìn)行調(diào)度然后再回填該 nodeName，所以直接指定 nodeName 實(shí)際是直接跳過(guò)了調(diào)度器。換句話說(shuō)，指定 nodeName 的方式是優(yōu)于其他節(jié)點(diǎn)選擇方法。

方法很簡(jiǎn)單，直接來(lái)個(gè)官方示例：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeName: kube-01

當(dāng)然如果選擇的節(jié)點(diǎn)不存在，或者資源不足，那該 pod 必然就會(huì)運(yùn)行失敗。

nodeSelector 也是 PodSpec 中的一個(gè)字段，指定鍵—值對(duì)的映射。
如果想要將 pod 運(yùn)行到對(duì)應(yīng)的 node 上，需要先給這些 node 打上 label，然后在 podSpec.NodeSelector 指定對(duì)應(yīng) node labels 即可。

步驟如下：

設(shè)置標(biāo)簽到 node 上：

kubectl label nodes kubernetes-node type=gpu

pod 配置添加 nodeSelector 字段：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
  nodeSelector:
    type: gpu

Kubernetes 內(nèi)置了一些節(jié)點(diǎn)標(biāo)簽：

kubernetes.io/hostname

beta.kubernetes.io/instance-type

beta.kubernetes.io/os

beta.kubernetes.io/arch

failure-domain.beta.kubernetes.io/zone

failure-domain.beta.kubernetes.io/region

有些標(biāo)簽是對(duì)云提供商使用。

還有些表示 node role 的 labels（可以指定 master、lb 等）:

kubernetes.io/role

node-role.kubernetes.io

nodeSelector 通過(guò) k-v 的方式非常簡(jiǎn)單的支持了 pod 調(diào)度限制到具有特定標(biāo)簽的節(jié)點(diǎn)上。而 nodeAffinity 根據(jù)親和力 & 反親和力極大地?cái)U(kuò)展了能夠表達(dá)的約束信息。

nodeAffinity 特性的設(shè)計(jì)初衷就是為了替代 nodeSelector。

nodeAffinity 當(dāng)前支持的匹配符號(hào)包括：In、NotIn、Exists、DoesNotExists、Gt、Lt 。

nodeAffinity 當(dāng)前支持兩種調(diào)度模式:

requiredDuringSchedulingIgnoredDuringExecution: 一定要滿足的條件，如果沒(méi)有找到滿足條件的節(jié)點(diǎn)，則 Pod 創(chuàng)建失敗。所有也稱為hard 模式。

preferredDuringSchedulingIgnoredDuringExecution: 優(yōu)先選擇滿足條件的節(jié)點(diǎn)，如果沒(méi)有找到滿足條件的節(jié)點(diǎn)，則在其他節(jié)點(diǎn)中擇優(yōu)創(chuàng)建 Pod。所有也稱為 soft 模式。

兩種模式的名字特長(zhǎng)，這是 k8s 的命名風(fēng)格。其中IgnoredDuringExecution的意義就跟 nodeSelector 的實(shí)現(xiàn)一樣，即使 node label 發(fā)生變更，也不會(huì)影響之前已經(jīng)部署且又不滿足 affinity rules 的 pods，這些 pods 還會(huì)繼續(xù)在該 node 上運(yùn)行。換句話說(shuō)，親和性選擇節(jié)點(diǎn)僅在調(diào)度 Pod 時(shí)起作用。

k8s 社區(qū)正在計(jì)劃提供 requiredDuringSchedulingRequiredDuringExecution  模式，便于驅(qū)逐 node 上不滿足 affinity rules 的 pods。

來(lái)個(gè)官方示例，看下怎么玩:

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      # 必須選擇 node label key 為 kubernetes.io/e2e-az-name,
      # value 為 e2e-az1 或 e2e-az2.
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/e2e-az-name
            operator: In
            values:
            - e2e-az1
            - e2e-az2
      # 過(guò)濾掉上面的必選項(xiàng)后，再優(yōu)先選擇 node label key 為 another-node-label-key
      # value 為 another-node-label-value.
      preferredDuringSchedulingIgnoredDuringExecution:
      # 如果滿足節(jié)點(diǎn)親和，積分加權(quán)重(優(yōu)選算法，會(huì)對(duì) nodes 打分)
      # weight: 0 - 100
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: k8s.gcr.io/pause:2.0

簡(jiǎn)單看下 NodeAffinity 的結(jié)構(gòu)體，下面介紹注意事項(xiàng)時(shí)會(huì)涉及：

type NodeAffinity struct {
    RequiredDuringSchedulingIgnoredDuringExecution *NodeSelector
    PreferredDuringSchedulingIgnoredDuringExecution []PreferredSchedulingTerm
}

type NodeSelector struct {
    NodeSelectorTerms []NodeSelectorTerm
}

type NodeSelectorTerm struct {
    MatchExpressions []NodeSelectorRequirement
    MatchFields []NodeSelectorRequirement
}

配置相關(guān)的注意點(diǎn)：

如果 nodeSelector 和 nodeAffinity 兩者都指定，那 node 需要兩個(gè)條件都滿足，pod 才能調(diào)度。

如果指定了多個(gè) NodeSelectorTerms，那 node 只要滿足其中一個(gè)條件，pod 就可以進(jìn)行調(diào)度。

如果指定了多個(gè) MatchExpressions，那必須要滿足所有條件，才能將 pod 調(diào)度到該 node。

nodeSelector & nodeAffinity 都是基于 node label 進(jìn)行調(diào)度。而有時(shí)候我們希望調(diào)度的時(shí)候能考慮 pod 之間的關(guān)系，而不只是 pod 和 node 的關(guān)系。

舉個(gè)例子，會(huì)有需求希望服務(wù) A 和 B 部署在同一個(gè)機(jī)房、機(jī)架或機(jī)器上，因?yàn)檫@些服務(wù)可能會(huì)對(duì)網(wǎng)路延遲比較敏感，需要低延時(shí)；再比如，希望服務(wù) C 和 D 又希望盡量分開(kāi)部署，即使一臺(tái)主機(jī)甚至一個(gè)機(jī)房出了問(wèn)題，也不會(huì)導(dǎo)致兩個(gè)服務(wù)一起掛而影響服務(wù)可用性，提升故障容災(zāi)的能力。

podAffinity 會(huì)基于節(jié)點(diǎn)上已經(jīng)運(yùn)行的 pod label 來(lái)約束新 pod 的調(diào)度。
其規(guī)則就是“如果 X 已經(jīng)運(yùn)行了一個(gè)或者多個(gè)符合規(guī)則 Y 的 Pod，那么這個(gè) Pod 應(yīng)該（如果是反親和性，則是不應(yīng)該）調(diào)度到 X 上”。
這里的 Y 是關(guān)聯(lián) namespace 的 labelSelector，當(dāng)然 namespace 也可以是 all。和 node 不同，pod 是隸屬于 namespace 下的資源，所以基于 pod labelSelector 必須指定具體的 namespace；而 X 則可以理解為一個(gè)拓?fù)溆?，?lèi)似于 node、rack、zone、cloud region 等等，就是前面提到的 內(nèi)置 Node 標(biāo)簽 ，當(dāng)然也可以自定義。

看下 pod affinity 涉及的結(jié)構(gòu)體，便于進(jìn)行功能介紹：

type Affinity struct {
    // NodeAffinity 前面介紹了
    NodeAffinity *NodeAffinity
    // pod 親和性
    PodAffinity *PodAffinity
    // pod 反親和性
    PodAntiAffinity *PodAntiAffinity
}

type PodAffinity struct {
    // hard 模式, 必選項(xiàng)
    RequiredDuringSchedulingIgnoredDuringExecution []PodAffinityTerm
    // soft 模式, 進(jìn)行 node 優(yōu)先
    PreferredDuringSchedulingIgnoredDuringExecution []WeightedPodAffinityTerm
}

type PodAffinityTerm struct {
    LabelSelector *metav1.LabelSelector
    Namespaces []string
    TopologyKey string
}

type WeightedPodAffinityTerm struct {
    Weight int32
    PodAffinityTerm PodAffinityTerm
}

podAffinity 和 nodeAffinity 有相似的地方，使用了 labelSelector 進(jìn)行匹配，支持的匹配符號(hào)包括：In、NotIn、Exists、DoesNotExists；
也支持兩種調(diào)度模式 requiredDuringSchedulingIgnoredDuringExecution 和 preferredDuringSchedulingIgnoredDuringExecution, 功能和 nodeAffinity 一樣，這里就不在累述。

podAffinity 和 nodeAffinity 也有較大的差異，前面講了 pod 是 namespace 資源，所以必然會(huì)需要配置 namespaces，支持配置多個(gè) namespace。如果省略的話，默認(rèn)為待調(diào)度 pod 所屬的 namespace；如果定義了但是值為空，則表示使用 “all” namespaces。

還有一個(gè)較大的差別 TopologyKey, 便于理解進(jìn)行多帶帶介紹。

TopologyKey 用于定義 in the same place，前面也介紹了是拓?fù)溆?/b>的概念。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      app: store
  replicas: 3
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        // pod 反親和性, 打散 redis 各個(gè)副本
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: nginx:1.12-alpine

注意1: pod affinity 需要進(jìn)行大量處理，所以會(huì)明顯減慢大型集群的調(diào)度時(shí)間，不建議在大于幾百個(gè)節(jié)點(diǎn)的集群中使用該功能。
注意2: pod antiAffinity 要求對(duì)節(jié)點(diǎn)進(jìn)行一致標(biāo)志，即集群中的所有節(jié)點(diǎn)都必須具有適當(dāng)?shù)臉?biāo)簽用于配置給 topologyKey，如果節(jié)點(diǎn)缺少指定的 topologyKey 指定的標(biāo)簽，則可能會(huì)導(dǎo)致意外行為。