KubernetesのTolerationを徹底解説:例・ユースケース・ベストプラクティス

KubernetesのTaintの効果

Tolerationで上書きできる、Kubernetesが提供するTaintの効果を見ていきましょう。

NoSchedule

NoScheduleは、合致するTolerationを持たない新規Podがノードにスケジュールされるのを防ぎます。Taintが追加された時点ですでにノード上で実行されているPodは退避されません。そのため、NoScheduleは、既存のPodに影響を与えずに特定のワークロード向けにノードを確保する場合に有効です。

たとえば、hardware=gpu:NoScheduleのTaintを追加すると、合致するTolerationを持たないPodはGPUノードに新たにスケジュールされなくなります。すでに実行中のPodは、そのまま実行を継続できます。

PreferNoSchedule

PreferNoScheduleは、緩やかなスケジューリング制限です。Kubernetesは、合致するTolerationを持たないPodをTaint付きノードに配置しないよう試みますが、必要な場合はそこにスケジュールすることもあります。NoScheduleとは異なり、スケジューリングを厳密にブロックするわけではありません。

この効果は、特定のワークロード向けにノードを確保したいものの、他の配置先が限られる場合にはスケジューラーにそれらのノードを使わせたい、という場面で有効です。PreferNoScheduleのTaintを追加しても、既存のPodは退避されません。

NoExecute

NoExecuteは、スケジューリングだけでなく、ノード上で実行中のPodにも影響します。合致するTolerationを持たない新規Podはそのノードにスケジュールできず、Taintを許容しない既存のPodは退避されます。

TolerationにtolerationSecondsを含めることで、合致するNoExecuteのTaintが付与された後も、Podが一時的にノードに留まることを許可できます。その期間が経過してもTaintが残っている場合、Podは退避されます。tolerationSecondsを省略した場合、合致するTolerationがあれば、Taintが存在する間はPodが留まり続けられます。

KubernetesのTolerationの設定例

例1:基本的なNoScheduleのToleration

あるノードにworkload=analytics:NoScheduleのTaintが付与されているとします。そのノードにスケジュール可能になるには、Podに合致するTolerationが必要です。次のPodは、この特定のTaintを許容します:

apiVersion: v1
kind: Pod
metadata:
  name: analytics-pod
spec:
  containers:
    - name: web
      image: nginx:latest
  tolerations:
    - key: "workload"
      operator: "Equal"
      value: "analytics"
      effect: "NoSchedule"

Equal演算子では、keyとvalueの両方がTaintと一致する必要があります。このTolerationは、指定されたTaintを持つノードへのPod配置を許可しますが、スケジューラーにそれらのノードへの配置を強制するものではありません。

例2:Taintの値を問わず許容する

値にかかわらずTaintのkeyをPodに許容させたい場合は、Exists演算子を使えます。たとえば、次の設定は、keyがworkloadであるあらゆるNoScheduleのTaintを許容します:

apiVersion: v1
kind: Pod
metadata:
  name: compute-pod
spec:
  containers:
    - name: worker
      image: busybox:latest
  tolerations:
    - key: "workload"
      operator: "Exists"
      effect: "NoSchedule"

Existsを使う場合、valueは指定しません。その結果、このPodはworkload=database:NoScheduleやworkload=batch:NoScheduleといったTaintを許容できます。他のTaintのkeyやeffectについては、引き続き個別に合致するTolerationが必要です。

例3:tolerationSecondsを使ったNoExecute

NoExecuteのTolerationにtolerationSecondsを含めることで、合致するTaintが適用された後にPodがノードに留まる時間を制御できます。次のPodは、maintenance-window=active:NoExecuteのTaintを100秒間許容します:

apiVersion: v1
kind: Pod
metadata:
  name: maintenance-worker
spec:
  containers:
    - name: worker
      image: busybox:latest
  tolerations:
    - key: "maintenance-window"
      operator: "Equal"
      value: "active"
      effect: "NoExecute"
      tolerationSeconds: 100

Podの実行中にTaintが追加された場合、Podは最大100秒間ノードに留まれます。その期間を過ぎてもTaintが残っていれば、KubernetesはPodを退避させます。期間が終わる前にTaintが削除されれば、Podは実行を継続できます。

KubernetesのTolerationのベストプラクティス

必要なワークロードにだけTolerationを設定する

Tolerationは、ワークロードがTaint付きノードで実行される明確な理由がある場合にのみ追加しましょう。広すぎる、あるいは不要なTolerationは、Taintが本来提供する分離を弱め、他の用途に確保されたノードへのワークロード配置を許してしまいます。その結果、リソース競合が発生し、ノード配置の予測可能性が低下する恐れがあります。

ワークロードの要件が変わったら、Tolerationを見直しましょう。Podが本当に幅広いTaintを許容する必要がある場合を除き、汎用的なExistsのTolerationは避けてください。各ワークロードが必要なスケジューリング権限だけを持つように、key、value、effectのスコープは狭く設定することをおすすめします。

また、DeploymentやStatefulSet、DaemonSetなど、ワークロードコントローラーのレベルでTolerationを管理するのも有効です。これにより、Podの再作成やスケール時にもスケジューリング動作の一貫性が保たれます。

Tolerationとノードアフィニティを組み合わせる

Tolerationは、PodをTaint付きノードで実行可能にするだけで、そのノードへPodを誘導するわけではありません。ワークロードを特定のノードプールで確実に実行したい場合は、Tolerationとノードアフィニティまたはノードセレクターを組み合わせましょう。

たとえば、GPUワークロードは、GPUノードのTaintを許容しつつ、ノードアフィニティで適切なGPUタイプのラベルを持つノードを必須にできます。Taintが一般のワークロードを遠ざけ、アフィニティがGPUワークロードを互換性のあるノードへ導きます。

配置の厳密さに応じて、必須(required)のノードアフィニティと優先(preferred)のノードアフィニティを使い分けましょう。必須のアフィニティは条件に合わないノードへのスケジュールを防ぎ、優先のアフィニティは適切なノードがない場合にスケジューラーへより多くの柔軟性を与えます。

ノードプール間でTaintとTolerationの一貫性を保つ

ノードプール間で、Taintのkeyとvalueに一貫した命名規則を使いましょう。同じ目的にworkload=gpu、type=gpu、node=gpuといった一貫性のない値を使うと、Pod設定の保守が難しくなり、スケジューリングエラーのリスクが高まります。

一般的なノードロールに対して標準のTaintを定義し、クラスターまたはインフラの自動化を通じて適用しましょう。これにより、ワークロードマニフェストは開発、ステージング、本番の各環境で、不要な設定差分なしに予測可能なTolerationを使えるようになります。

一貫性は、クラスターオートスケーリングシステムによってノードが自動的に作成・置換される場合に特に重要です。どのノードインスタンスが稼働していてもワークロードが同じように動作するよう、新規ノードにはプロビジョニング時に想定どおりのTaintとラベルを付与すべきです。

特殊で高価なノードを保護する

GPU、大容量メモリインスタンス、その他の高価なハードウェアといった特殊リソースを汎用Podが消費しないように、Taintを活用しましょう。これらのリソースを使うように設計されたワークロードにだけ、対応するTolerationを付与すべきです。

Tolerationだけでは、Podが実際に特殊リソースを要求していることは保証されません。たとえばGPUワークロードの場合は、Tolerationに加えて、適切なリソース要求や制限も設定してください。複数のハードウェアタイプが利用できる場合は、ノードアフィニティでさらに細かく配置を制御できます。

このアプローチにより、優先度の低いワークロードが、特殊なアプリケーションに必要なキャパシティを占有するのを防げます。また、高価なノードを、そのハードウェアを活かせるワークロード向けに確保しておくことで、インフラコストの削減にもつながります。

設定だけでなくスケジューリングの結果を監視する

Tolerationが正しくても、Podが正常にスケジュールされることは保証されません。リソースの空き状況、ノードアフィニティ、トポロジー制約、Podアフィニティ・アンチアフィニティなど、他のスケジューラールールによって配置が妨げられることがあります。

保留中のPod、スケジューラーのイベント、ノードのTaint、実際のPod配置を監視し、スケジューリングポリシーが意図どおりに機能していることを確認しましょう。kubectl describe podやkubectl describe nodeといったコマンドは、Taintの不一致やその他のスケジューリング制約の特定に役立ちます。

監視では、保留のまま残るPodだけでなく、想定外の配置も検知すべきです。ワークロードが誤ったノードプールで問題なく稼働している場合、Tolerationが広すぎるか、アフィニティルールが不足している可能性があります。定期的なチェックにより、クラスターとワークロードの変化に合わせてスケジューリングポリシーが機能し続けることを確認できます。

よくある質問

KubernetesのTolerationとは何ですか? Tolerationは、Podのspecに設定する項目で、合致するTaintを持つノードにPodをスケジュールできるようにします。あくまでスケジュールを許可するだけです。リソース要求やノードアフィニティも引き続き適用されるため、Taint付きノードへの配置を保証するものではありません。

TaintとTolerationの違いは何ですか? Taintはノードに付与され、合致するTolerationを持たないPodを遠ざけます。TolerationはPodに設定され、合致するTaintを持つノードへのスケジュールを許可しますが、強制はしません。

Equal演算子とExists演算子の違いは何ですか? Equalは、Tolerationのkey、value、effectがTaintと一致する必要があり、演算子を指定しない場合のデフォルトです。Existsはkeyのみで照合するため、valueは省略する必要があり、そのkeyの任意の値を許容します。

NoSchedule、PreferNoSchedule、NoExecuteの各効果はどのような動作をしますか? NoScheduleは、合致するTolerationを持たない新規Podをブロックしますが、実行中のPodには影響しません。PreferNoScheduleは強制力のない緩やかな制限で、スケジューラーはそのノードを避けようとします。NoExecuteはさらに、Taintを許容しない実行中のPodも退避させます。

tolerationSecondsは何をするものですか? NoExecuteのTolerationにおいて、tolerationSecondsは、合致するTaintが付与された後にPodがノードに留まれる時間を指定します。その時間が経過してもTaintが残っている場合、KubernetesはPodを退避させます。省略した場合、Taintが存在する間はPodが留まり続けます。

Tolerationを設定すれば、PodはTaint付きノードで実行されますか? いいえ。Tolerationは、Podをスケジュール可能にするだけです。特定のノードプールにPodを配置したい場合は、Tolerationとノードアフィニティまたはノードセレクターを組み合わせてください。

PerfectScaleでTolerationベースのスケジューリングをさらに効率化

TaintとTolerationは、Podが実行を許可される場所を決めますが、それらのノードが適切にサイジングされているか、そこに配置されるワークロードが適切な量のCPUとメモリを要求しているかについては何も教えてくれません。PerfectScaleは、Helmコマンド1つでデプロイできるKubernetesの最適化・ガバナンスプラットフォームです。ワークロード、ノード、オートスケーラーを含むK8sスタック全体にわたって、実用的なインサイトと自律的な最適化を提供し、専用・特殊・高価なノードプールが実際に効率よく活用されるようにします。

PerfectScaleの主な機能:

• ワークロードの自律的なライトサイジング: Podfitは、クラスターの健全性とコストをきめ細かく可視化し、無駄なリソースやレジリエンスの問題を浮き彫りにします。データドリブンなライトサイジングの推奨に基づいてワークロードを自律的に最適化し、推奨内容を自動適用することも可能です。
• ノードレベルの使用率インサイト: Infrafitは、アイドル状態のノードキャパシティを可視化し、ワークロードに最適なノードタイプを推奨します。専用ノード、GPUノード、その他のTaint付きノードプールが、未使用キャパシティへの支払いなしに最大のパフォーマンスを発揮できるようにします。
• オートスケーラーの最適化: PerfectScaleは、HPA、KEDA、Karpenter、Cluster Autoscaler、EKS Auto Mode、Fargate、Node Auto Provisioning、Google Autopilotと統合し、Taint付きノードをプロビジョニング・置換するシステムの効果を最大化します。
• 自動優先順位付けを備えたリアルタイムアラート: レジリエンスリスクやコストの異常を、影響度に基づいて優先順位付けして検出し、ユーザーやクラウド請求に影響が及ぶ前に、Slack、Datadog、MS Teams、PagerDutyへ直接通知します。
• トレンド、ガバナンス、予測: Trendsレポートは、クラスター、ノードグループ、名前空間、ワークロードを横断して、コスト・無駄・リスクの各指標の推移を詳細に可視化し、根本原因分析と正確な予算計画を支援します。
• あらゆるKubernetes環境に対応: PerfectScaleは、OpenShift、EKS、GKE、AKS、ハイブリッド構成を含むオンプレミスとクラウドの両方のクラスターで動作し、WindowsコンテナやAirflow・Sparkジョブなどのエフェメラル/MLワークロードもサポートします。

PerfectScaleプラットフォームの詳細はこちら