😊

コントールプレーン(Control Plane)について理解する

に公開

コントロールプレーンとは

  • Kubernetesクラスタ全体を「宣言的に制御」する中枢部分
  • 「ユーザーが望む状態」を受け取り、それを「実際の状態」に近づけるように調整をする
  • 常に状態を監視し続け、差分があれば自動的に修正

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

全体像

①kube-apiserver

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

②etcd

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

③kube-scheduler

  • 新しく作成されたPodをどのノードに割り当てるかを決定
  • スケジューリングの流れ
    1. フィルタリング
      利用可能なノードを条件で絞り込み(リソース不足・ノードセレクタポリシー違反は除外)
    2. スコアリング
      候補ノードにスコアをつけ、最適なノードを選択。
      スコアは各ノードに対してプラグインが複数走り、それぞれが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の作成

  1. ユーザーがkubectl apply -f pod.yamlを実行
  2. kubectl -> kube-apiserverにリクエスト送信
  3. kube-apiserverがリクエストを検証し、etcdに「望まれる状態」を保存
  4. SchedulerがPodを割り当てるノードを決定
  5. Controller Managerがその状態を監視し、必要に応じて再スケジューリングや再作成
  6. 選ばれたノードのkubeletがPodを起動

まとめ

  • コントロールプレーン = Kubernetesの「中枢部分」
  • API Serverを中心に、etcdが記録、Schedulerが配置、Controllerが調整する仕組みで成り立つ
  • 理解することで「なぜKubernetesが自動でうまく動くのか」が見える

Discussion