# TaintとToleration
LLMS index: [llms.txt](/llms.txt)
---
[_ノードアフィニティ_](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)は
Podの属性であり、あるノード群を*引きつけます*（優先条件または必須条件）。反対に _taint_ はノードがある種のPodを排除できるようにします。
_toleration_ はPodに適用され、一致するtaintが付与されたノードへPodがスケジューリングされることを認めるものです。ただしそのノードへ必ずスケジューリングされるとは限りません。
taintとtolerationは組になって機能し、Podが不適切なノードへスケジューリングされないことを保証します。taintはノードに一つまたは複数個付与することができます。これはそのノードがtaintを許容しないPodを受け入れるべきではないことを示します。
## コンセプト
ノードにtaintを付与するには[kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)コマンドを使用します。
例えば、次のコマンドは
```shell
kubectl taint nodes node1 key1=value1:NoSchedule
```
`node1`にtaintを設定します。このtaintのキーは`key1`、値は`value1`、taintの効果は`NoSchedule`です。
これは`node1`にはPodに合致するtolerationがなければスケジューリングされないことを意味します。
上記のコマンドで付与したtaintを外すには、下記のコマンドを使います。
```shell
kubectl taint nodes node1 key1=value1:NoSchedule-
```
PodのtolerationはPodSpecの中に指定します。下記のtolerationはどちらも、上記の`kubectl taint`コマンドで追加したtaintと合致するため、どちらのtolerationが設定されたPodも`node1`へスケジューリングされることができます。
```yaml
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
```
```yaml
tolerations:
- key: "key1"
operator: "Exists"
effect: "NoSchedule"
```
tolerationを設定したPodの例を示します。
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
tolerations:
- key: "example-key"
operator: "Exists"
effect: "NoSchedule"
`operator`のデフォルトは`Equal`です。
tolerationがtaintと合致するのは、`key`と`effect`が同一であり、さらに下記の条件のいずれかを満たす場合です。
* `operator`が`Exists`（`value`を指定すべきでない場合）
* `operator`が`Equal`であり、かつ`value`が同一である場合
備考:
2つ特殊な場合があります。
空のkeyと演算子Existsは全てのkey、value、effectと一致するため、すべてのtaintと合致します。
空のeffectはkey1が一致する全てのeffectと合致します。
FEATURE STATE:
Kubernetes v1.18 [stable]
上述したように、effect `NoExecute`のtaintはノードで実行中のPodに次のような影響を与えます。
* 対応するtolerationのないPodは即座に除外される
* 対応するtolerationがあり、それに`tolerationSeconds`が指定されていないPodは残り続ける
* 対応するtolerationがあり、それに`tolerationSeconds`が指定されているPodは指定された間、残される
Nodeコントローラーは特定の条件を満たす場合に自動的にtaintを追加します。
組み込まれているtaintは下記の通りです。
* `node.kubernetes.io/not-ready`: ノードの準備ができていない場合。これはNodeCondition `Ready`が`False`である場合に対応します。
* `node.kubernetes.io/unreachable`: ノードがノードコントローラーから到達できない場合。これはNodeCondition`Ready`が`Unknown`の場合に対応します。
* `node.kubernetes.io/out-of-disk`: ノードのディスクの空きがない場合。
* `node.kubernetes.io/memory-pressure`: ノードのメモリーが不足している場合。
* `node.kubernetes.io/disk-pressure`: ノードのディスクが不足している場合。
* `node.kubernetes.io/network-unavailable`: ノードのネットワークが利用できない場合。
* `node.kubernetes.io/unschedulable`: ノードがスケジューリングできない場合。
* `node.cloudprovider.kubernetes.io/uninitialized`: kubeletが外部のクラウド事業者により起動されたときに設定されるtaintで、このノードは利用不可能であることを示します。cloud-controller-managerによるコントローラーがこのノードを初期化した後にkubeletはこのtaintを外します。
ノードから追い出すときには、ノードコントローラーまたはkubeletは関連するtaintを`NoExecute`効果の状態で追加します。
不具合のある状態から通常の状態へ復帰した場合は、kubeletまたはノードコントローラーは関連するtaintを外すことができます。
備考:
コントロールプレーンは新しいtaintをノードに加えるレートを制限しています。
このレート制限は一度に多くのノードが到達不可能になった場合（例えばネットワークの断絶）に、退役させられるノードの数を制御します。
Podに`tolerationSeconds`を指定することで不具合があるか応答のないノードに残る時間を指定することができます。
例えば、ローカルの状態を多数持つアプリケーションとネットワークが分断された場合を考えます。ネットワークが復旧して、Podを排除しなくて済むことを見込んで、長時間ノードから排除されないようにしたいこともあるでしょう。
この場合Podに設定するtolerationは次のようになります。
```yaml
tolerations:
- key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 6000
```
備考:
Kubernetesはユーザーまたはコントローラーが明示的に指定しない限り、自動的にnode.kubernetes.io/not-readyとnode.kubernetes.io/unreachableに対するtolerationをtolerationSeconds=300にて設定します。
自動的に設定されるtolerationは、taintに対応する問題がノードで検知されても5分間はそのノードにPodが残されることを意味します。
