kube-scheduler（キューブスケジューラー）

2025年11月6日

kube-scheduler（キューブスケジューラー）

英語表記: kube-scheduler

概要

kube-schedulerは、Kubernetesのコントロールプレーン（制御部）を構成する非常に重要なコンポーネントの一つです。その主たる役割は、新しく作成されたPod（コンテナの集合体）を、実行可能な最適なNode（物理または仮想マシン）に割り当てることです。これは、Kubernetes アーキテクチャにおける「コンポーネント」の中でも、システム全体の効率と安定性を担保する心臓部と言えるでしょう。リソースの要求、制約、ノードの空き状況などを総合的に判断し、どのNodeでPodを実行すべきかを決定する、まさに「采配役」を担っています。

詳細解説

kube-schedulerは、Kubernetesがオーケストレーションシステムとして機能するために不可欠な判断を下すエンジンです。このコンポーネントが存在するおかげで、ユーザーは「どこで動かすか」を意識することなく、「何を動かすか」に集中できるのですから、非常にありがたい存在ですね。

目的とアーキテクチャ内の位置づけ

Kubernetesは、多数のNodeからなるクラスタ全体のリソースを最大限に活用し、かつ耐障害性を維持しながらワークロード（Pod）を実行する必要があります。kube-schedulerの目的は、この複雑な要求を満たすために、以下の二点を考慮して最適なNodeを選び出すことです。

リソース効率: CPUやメモリなどのリソースを最も効率よく使えるNodeを選ぶ。
制約遵守: 特定のNodeでのみ実行したい、あるいは特定のNodeでは実行したくないといったユーザー定義の制約（テイント、アフィニティなど）を厳守する。

kube-schedulerは、APIサーバーから新規作成されたPodの情報を監視しています。Nodeが決定されると、その決定情報（バインディング情報）は再びAPIサーバーを通じてetcd（分散KVS）に書き込まれます。これにより、選定されたNode上のKubelet（エージェント）が、Podの実行を開始できるようになるのです。

スケジューリングの動作原理（二段階プロセス）

kube-schedulerがNodeを選定するプロセスは、主に「フィルタリング」と「スコアリング」という二つの段階に分かれています。これは非常に論理的で分かりやすい仕組みです。

1. フィルタリング（Filtering）

この段階では、まず「このPodを実行できるNodeはどれか？」という観点で、実行不可能なNodeをリストから除外します。

例: Podが「メモリ8GB」を要求している場合、現在利用可能なメモリが8GB未満のNodeはすべてフィルタリングされます。
このステップで、Taints（汚染）やTolerations（容認）といった高度な制約も考慮されます。Podの要求を満たせないNodeは容赦なく候補から外されるわけです。

2. スコアリング（Scoring）

フィルタリングを通過した「実行可能なNode」に対して、今度は「どのNodeが最も最適か？」という観点で点数付け（スコアリング）を行います。

スコアリングは、リソースの利用効率、Nodeの負荷分散、Pod間のアフィニティ（近接性）など、様々な要素に基づいて行われます。
例: 可能な限りNode間の負荷を均等にするために、現在最も利用率の低いNodeに高いスコアを与える、といったロジックが働きます。
最終的に、最も高いスコアを獲得したNodeが、そのPodの実行場所として決定されます。

この二段階のプロセスによって、kube-schedulerはKubernetesクラスタの健全性と効率を維持しているのです。この機能こそが、Kubernetes アーキテクチャの強靭さを支える「コンポーネント」の真髄だと感じます。

具体例・活用シーン

kube-schedulerの働きを理解するためには、その実用的な側面や、具体的な類推を用いるのが一番です。

類推：優秀な不動産エージェント

kube-schedulerの役割は、まるで非常に優秀で、かつ公平な不動産エージェントのようです。

顧客（Pod）の登場: 新しくPod（顧客）が「アプリケーションを実行したい」という依頼を持ってやってきます。
要望のヒアリング（リソース要求）: 顧客は「CPU 2コア、メモリ 4GBは必須。できれば高速なストレージがある場所がいい」といった要望（リソース要求や制約）を出します。
物件の選定（フィルタリング）: エージェント（kube-scheduler）は、まず顧客の必須条件（フィルタリング）を満たさない物件（Node）を全て除外します。「メモリが足りない物件」「指定された地域外の物件」は候補から外します。
最適な物件の評価（スコアリング）: 残った物件（Node）に対して、エージェントは「この顧客にとっての利便性」「現在入居している他の顧客との相性（Pod間のアフィニティ）」「家賃対効果（リソース効率）」などを総合的に評価し、点数をつけます。
契約の決定（バインディング）: 最も点数の高かった物件に顧客を案内し、契約を決定します。

このエージェントは、クラスタ内のすべてのNodeの状態を把握し、常に全体最適を目指してPodを配置します。もしこのエージェントがいなければ、Podはどこに配置されるか分からず、特定のリソースが枯渇したり、Node間の負荷が極端に偏ったりしてしまうでしょう。

活用シーン

高可用性の確保: 重要なPodを意図的に異なるアベイラビリティゾーン（AZ）にあるNodeに分散配置するよう制約（Pod Anti-Affinity）を設定できます。kube-schedulerはこの制約を厳密に守り、自動的に分散配置を実現します。
リソース最適化: 開発環境のPodは低スペックNodeに、本番環境のPodは高スペックNodeに割り当てる、といったポリシーをカスタマイズすることで、クラスタ全体のコスト効率を向上させます。kube-schedulerはこれらのカスタムポリシーに基づいてNode選定を行います。

資格試験向けチェックポイント

kube-schedulerは、Kubernetesの根幹をなす概念であるため、基本情報技術者試験や応用情報技術者試験の応用分野、あるいは専門的な認定資格（CKA/CKADなど）では頻出のトピックです。特に「Kubernetes アーキテクチャ」の「コンポーネント」として、その役割と連携について問われることが多いです。

コントロールプレーンの構成要素: kube-schedulerが、API Server、Controller Manager、etcdなどと共に「コントロールプレーン」を構成する要素であることを確実に覚えておきましょう。特に、ワーカーノード上のKubeletとは役割が明確に分離されています。
処理の二段階: スケジューリング処理が「フィルタリング（候補絞り込み）」と「スコアリング（最適度評価）」の二段階で行われることを理解することが重要です。この用語自体が選択肢として登場することがあります。
連携先: kube-schedulerがPodの情報を取得し、選定結果を書き込む先のコンポーネントを問う問題が出ます。
- Podの監視・情報取得元：API Server
- 選定結果の書き込み先：API Server経由でetcd
スケジューリングの目的: 単にNodeにPodを配置するだけでなく、「リソースの効率的な利用」と「ユーザー定義の制約の遵守」が主目的であることを理解しておくと、応用的な問題に対応できます。
Podのステータス: スケジューリングが完了し、Nodeが決定したPodは、そのNode上でKubeletによって実行に移されます。この一連の流れを理解しておくことで、Kubernetesのライフサイクル全体像が把握できます。