😊
コントールプレーン(Control Plane)について理解する
コントロールプレーンとは
- Kubernetesクラスタ全体を「宣言的に制御」する中枢部分
- 「ユーザーが望む状態」を受け取り、それを「実際の状態」に近づけるように調整をする
- 常に状態を監視し続け、差分があれば自動的に修正

コントロールプレーンのコンポーネント詳細
全体像

①kube-apiserver
- 全てのコンポーネント・ユーザーがやり取りする「唯一の入り口」
- REST APIを提供し、CRUD操作は全てここを通る
- 認証・認可・Admission Controlを担い、セキュリティの中心

②etcd
- kubernetesクラスタの全ての情報を記憶・管理しているKey-Valueストア。
- kubernetesが何かを決める時、例えば新しいアプリケーションをどこで動かすかといった判断をする際には、必ずEtcdに問い合わせて現在の状況を確認する。
- これによりクラスタ全体が同じ情報を共有し、一貫性のある動作を保つことができる。
- apiserverだけが唯一etcdと直接やり取りが可能

③kube-scheduler
- 新しく作成されたPodをどのノードに割り当てるかを決定。
- スケジューリングの流れ
-
フィルタリング
利用可能なノードを条件で絞り込み(リソース不足・ノードセレクタポリシー違反は除外) -
スコアリング
候補ノードにスコアをつけ、最適なノードを選択。
スコアは各ノードに対してプラグインが複数走り、それぞれが0~100点のスコアを出し、その合計や重み付けによって最終スコアが決まる。
-
フィルタリング

④kube-controller-manager
- コントローラとは、監視対象リソースの変更や一定時間経過などのイベントをトリガーとして調整ループを実行するもの。(調整ループとは、YAMLなどで宣言されたあるべき状態と現在の状態を比較して、変更や調整を行う制御ループのこと)
- kube-controller-managerとは、複数の「コントローラ」が集まったプロセス
- コントローラの例
- Deplotment Controller:Pod数を指定通りに維持
- Node Controller:ノードの死活監視
- Replication Controller:レプリカ数の維持
- Service Controller:ServiceとクラウドLBを同期

⑤cloud-controller-manager
- クラウドプロバイダのAPIと連携する専用のコンポーネント
- 例:
- Node管理(クラウドVMが削除されたらKubernetesノードからも削除)
- Serviceタイプ=LoadBalancerの作成時にクラウドLBを自動構築
- ボリューム(EBSなど)の動的プロビジョニング
動作フローの例:Podの作成
- ユーザーが
kubectl apply -f pod.yamlを実行 -
kubectl-> kube-apiserverにリクエスト送信 - kube-apiserverがリクエストを検証し、etcdに「望まれる状態」を保存
- SchedulerがPodを割り当てるノードを決定
- Controller Managerがその状態を監視し、必要に応じて再スケジューリングや再作成
- 選ばれたノードのkubeletがPodを起動
まとめ
- コントロールプレーン = Kubernetesの「中枢部分」
- API Serverを中心に、etcdが記録、Schedulerが配置、Controllerが調整する仕組みで成り立つ
- 理解することで「なぜKubernetesが自動でうまく動くのか」が見える
Discussion