一足遅れて Kubernetes を学び始める - 14. スケジューリング -

ストーリー

前回

一足遅れて Kubernetes を学び始める - 13. ヘルスチェックとコンテナライフサイクル -では、requests や limit といったヘルスチェックの仕方を学びました。今回は、Affinity などによるスケジューリングについて学習します。

スケジューリング

これから学ぶスケジューリングでは、大きく分けて２つに分類します。

Pod のスケジューリング時に特定の Node を選択する方法
- Affinity
- Anti-Affinity
Node に対して汚れをつけて、それを許容できる Pod のみスケジューリングを許可する方法
- 汚れ = Taints
- 許容 = Tolerations

Node のラベル確認

デフォルトで設定されている Node のラベルを見てみます。

pi@raspi001:~/tmp $ k get nodes -o json | jq ".items[] | .metadata.labels"
{
  "beta.kubernetes.io/arch": "arm",
  "beta.kubernetes.io/os": "linux",
  "kubernetes.io/arch": "arm",
  "kubernetes.io/hostname": "raspi001",
  "kubernetes.io/os": "linux",
  "node-role.kubernetes.io/master": ""
}
{
  "beta.kubernetes.io/arch": "arm",
  "beta.kubernetes.io/os": "linux",
  "kubernetes.io/arch": "arm",
  "kubernetes.io/hostname": "raspi002",
  "kubernetes.io/os": "linux",
  "node-role.kubernetes.io/worker": "worker"
}
{
  "beta.kubernetes.io/arch": "arm",
  "beta.kubernetes.io/os": "linux",
  "kubernetes.io/arch": "arm",
  "kubernetes.io/hostname": "raspi003",
  "kubernetes.io/os": "linux",
  "node-role.kubernetes.io/worker": "worker"
}

arch や os はデフォルトで設定されているみたいです。次以降の学習のため、ラベルをはります。

pi@raspi001:~/tmp $ k label node raspi002 cputype=low disksize=200
pi@raspi001:~/tmp $ k label node raspi003 cputype=low disksize=300

NodeSelector

最も簡単な NodeAffinity の設定です。指定するラベルに属する Node に Pod を割り当てるようスケジューリングします。簡易なので、equality-base のみしか指定できません。

では、disksize が 300 の Node(raspi003)に Pod を配置しましょう。

# sample-nodeselector.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sample-nodeselector
  labels:
    app: sample-app
spec:
  containers:
    - name: nginx-container
      image: nginx:1.12
  nodeSelector:
    disksize: "300"

pi@raspi001:~/tmp $ k apply -f sample-nodeselector.yaml
pi@raspi001:~/tmp $ k get pods sample-nodeselector -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP             NODE       NOMINATED NODE   READINESS GATES
sample-nodeselector   1/1     Running   0          21s   10.244.2.130   raspi003   <none>           <none>

期待通りですね。OK です。 nodeSelector はイコールでしか表現できないので、柔軟性に欠けます。

Affinity

Affinity は、NodeSelector よりも柔軟に設定できます。つまり、set-based の指定方法です。詳しくはこちらを参照下さい。今回は In オペレータを使います。

# sample-node-affinity.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sample-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
              - key: disktype
                operator: In
                values:
                  - hdd
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          preference:
            matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                  - raspi002
  containers:
    - name: nginx-container
      image: nginx:1.12

NodeAffinity では、required と preferred の 2 つ設定できます。

required
- 必須スケジューリングポリシー
preferred
- 優先的に考慮されるスケジューリングポリシー

必須条件が「cputype=low である Node(raspi002,raspi003)」で、優先条件が「hostname=raspi002 である Node」です。適用してみましょう。

pi@raspi001:~/tmp $ k apply -f sample-node-affinity.yaml
pi@raspi001:~/tmp $ k get pods sample-node-affinity -o wide
NAME                   READY   STATUS              RESTARTS   AGE   IP       NODE       NOMINATED NODE   READINESS GATES
sample-node-affinity   0/1     ContainerCreating   0          5s    <none>   raspi002   <none>           <none>

確かに raspi002 に配置されました。では、raspi002 をスケジューリングできなくするとどうなるのでしょうか。

pi@raspi001:~/tmp $ k delete -f sample-node-affinity.yaml
pi@raspi001:~/tmp $ k cordon raspi002
pi@raspi001:~/tmp $ k apply -f sample-node-affinity.yaml
pi@raspi001:~/tmp $ k get pods sample-node-affinity -o wide
NAME                   READY   STATUS              RESTARTS   AGE   IP       NODE       NOMINATED NODE   READINESS GATES
sample-node-affinity   0/1     ContainerCreating   0          11s   <none>   raspi003   <none>           <none>

今度は、raspi002 を cordon したので、raspi003 に移りました。優先なので、満たされなくても良いのですね。必須条件が満たされなかったら、Pending になります。

元に戻します。

pi@raspi001:~/tmp $ k delete -f sample-node-affinity.yaml
pi@raspi001:~/tmp $ k uncordon raspi002

AND と OR

nodeSelectorTerms や matchExpressions は配列なので複数指定できます。

# sample.yaml
nodeSelectorTerms:
  - matchExpressions:
      - A
      - B
  - matchExpressions:
      - C
      - D

上記の場合は、 (A and B) OR (C and D)という条件になります。

Anti-Affinity

Anti-Affinity は、Affinity の逆です。つまり、特定 Node 以外の Node に割り当てるようスケジューリングします。特別な指定はなく、単に Affinity の否定形式にするだけです。言葉だけですね。

Inter-Pod Affinity

特定の Pod が実行されているドメイン上へ Pod をスケジューリングするポリシーです。 Pod 間を近づけることができるので、レイテンシを下げることができます。

まず、特定の Pod は、先程の NodeSelector で使ったものとします。

pi@raspi001:~/tmp $ k apply -f sample-node-affinity.yaml
pi@raspi001:~/tmp $ k get pods sample-nodeselector -o wide
NAME                  READY   STATUS    RESTARTS   AGE   IP             NODE       NOMINATED NODE   READINESS GATES
sample-nodeselector   1/1     Running   0          36m   10.244.2.130   raspi003   <none>           <none>

# sample-pod-affinity-host.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sample-pod-affinity-host
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - sample-app
          topologyKey: kubernetes.io/hostname
  containers:
    - name: nginx-container
      image: nginx:1.12

これだと、sample-app がある Node で kubernetes.io/hostname(=raspi003)と同じ Node に Pod を割り振ります。つまり、raspi003 にできるはずです。

pi@raspi001:~/tmp $ k apply -f sample-pod-affinity-host.yaml
pi@raspi001:~/tmp $  k get pods sample-pod-affinity-host -o wide
NAME                       READY   STATUS              RESTARTS   AGE   IP       NODE       NOMINATED NODE   READINESS GATES
sample-pod-affinity-host   0/1     ContainerCreating   0          11s   <none>   raspi003   <none>           <none>

期待通り raspi003 にできています。また、required だけでなく、preferred も設定できます。

# sample-pod-affinity-arch.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sample-pod-affinity-arch
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
              - key: app
                operator: In
                values:
                  - sample-app
          topologyKey: kubernetes.io/arch
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          podAffinityTerm:
            labelSelector:
              matchExpressions:
                - key: app
                  operator: In
                  values:
                    - sample-app
            topologyKey: kubernetes.io/hostname
  containers:
    - name: nginx-container
      image: nginx:1.12

必須条件としては、下記のとおりです。

「label が app=sample-app である Pod が動いている Node(raspi003)で、kubernetes.io/arch が同じ Node(arm)」

これは raspi002(arm),raspi003(arm)どちらにも当てはまります。そして、優先条件として、下記のとおりです。

「label が app=sample-app である Pod が動いている Node(raspi003)で、kubernetes.io/hostname が同じ Node(raspi003)」

これにより、raspi003 が選ばれるはずです。

pi@raspi001:~/tmp $ k apply -f sample-pod-affinity-arch.yaml
pi@raspi001:~/tmp $ k get pods sample-pod-affinity-arch -o wide
NAME                       READY   STATUS              RESTARTS   AGE   IP       NODE       NOMINATED NODE   READINESS GATES
sample-pod-affinity-arch   0/1     ContainerCreating   0          13s   <none>   raspi003   <none>           <none>

期待通り raspi003 で動いていますね。

Inter-Pod Anti-Affinity

Inter-Pod Affinity の否定形です。以上。

今まで紹介した Affinity、AntiAffinity,Inter-Pod Affinity, Inter-Pod AntiAffinity は、組み合わせることができます。

Taints

Node に対して汚れをつけていきます。汚れた Node に対して、許容する Pod のみがスケジューリングできるようになります。

汚れの種類(Effect)は、３つあります。

PreferNoSchedule
- 可能な限りスケジューリングしない
NoSchedule
- スケジューリングしない（既にスケジューリングされている Pod はそのまま）
NoExecute
- 実行を許可しない（既にスケジューリングされている Pod は停止される）

それでは、まず Node を汚しましょう。

pi@raspi001:~/tmp $ k taint node raspi003 env=prd:NoSchedule
pi@raspi001:~/tmp $ k describe node raspi003 | grep Taints
Taints:             env=prd:NoSchedule

これで raspi003 に Pod をスケジューリングできなくなりました。

Tolerations

さきほど汚した Node に対して、許容(Tolerations)できる Pod を作成しましょう。

key と value(env=prd)と Effect(NoSchedule)が設定された Pod のみ許容されます。作ってみます。

# sample-tolerations.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sample-tolerations
spec:
  containers:
    - name: nginx-container
      image: nginx:1.12
  tolerations:
    - key: "env"
      operator: "Equal"
      value: "prd"
      effect: "NoSchedule"
  nodeSelector:
    disksize: "300"

※ nodeSelector で汚れた Node である raspi003 を指定するようにしています。

operator には、2 種類あります。

Equal
- key と value が等しい
Exists
- key が存在する

では、適用してみます。

pi@raspi001:~/tmp $ k apply -f sample-tolerations.yaml
pi@raspi001:~/tmp $ k get pod sample-tolerations -o=wide
NAME                 READY   STATUS    RESTARTS   AGE   IP             NODE       NOMINATED NODE   READINESS GATES
sample-tolerations   1/1     Running   0          27s   10.244.2.140   raspi003   <none>           <none>

汚れた Node に許容される Pod が適用されましたね。許容を一部変えてみる(env=stg)と、もちろん Pending になりました。

もとに戻しておきます。

pi@raspi001:~/tmp $ k taint node raspi003 env-

お片付け

pi@raspi001:~/tmp $ k delete -f sample-nodeselector.yaml -f sample-node-affinity.yaml -f sample-pod-affinity-host.yaml -f sample-pod-affinity-arch.yaml -f sample-tolerations.yaml
pi@raspi001:~/tmp $ k label node raspi002 cputype- disksize-
pi@raspi001:~/tmp $ k label node raspi003 cputype- disksize-

最後に

Pod をどの Node にスケジューリングするのか学習しました。汚れ(taint)と許容(tolerations)という考えは面白いなと思いました。ただ、あまり使いすぎると複雑に陥りやすそうなので、注意が必要ですね。次回は、こちらです。