Zenn
🖼️

Kubernetesの主要コンポーネントを図解したい

2024/12/09に公開
Kubernetes
Kubernetes
tech

TR;TD

図解はこれ

はじめに

Kubernetesのクラスタは「Control Plane」と「Worker Node」の2つから構成されています。

  • Control Plane: クラスタ全体に関わる制御・管理を担う司令塔。
  • Woker Node[1]: 実際の稼働場所。Control Planeと連動してコンテナ起動などを実行しています。

本記事では、k8sのControl Planeを構成する複数のコンポーネントについて図を用いながらざっくりまとめます。

Control Plane上で動作しているもの

長くて読めないという人向けに、それぞれ最初の1行で重要なことをまとめました。

kube-apiserver

  • 全てのAPIリクエストを受け付け、処理を他のコンポーネントに委譲します。
  • Control Planeのフロントエンドサーバ。k8sへのAPIリクエストをRESTで受け付けます。
  • 全コンポーネントと繋がっており、ここを通じて各コンポーネント達がやりとりします。
  • 各オブジェクトに対する実際の処理を行っているわけではありません。
  • k8sAPIサーバーへのリクエストを評価し、そのリクエストを許可するかどうかを決定するAdmission Control (リソースの作成や変更がポリシーに従っているかを確認する仕組み)もあり、認証認可の処理なども行なっています。

kube-scheduler

  • Podを適切なNodeに配置します。
  • 作成先のNodeが決まっていないPodがないか監視します。迷子のPodが存在した場合は、リソース状況を踏まえて適切なNodeを1つ選択し、迷子のPodを選択したNodeと紐付けます。
  • 実際にPod作成をしているわけではありません。Pod作成の流れは以下のイメージです。
    • kube-schedulerがPodの作成場所を判断します。
    • kube-schedulerは判断結果をkube-apiserverに伝え、kube-apiserverがその結果をetcdという場所に記録します(etcdについては後述します)。
    • 他のコンポーネントがetcdの記録をもとにPodを作成します。

cloud-controller-manager

  • Cloud Providerの機能と連携し、ロードバランサやディスクボリュームなどのリソースを管理しています。
  • k8s v1.15まで本体に組み込まれていたCloud Providerとの連携機能をv1.6から段階的に外部化し、クラウド環境との柔軟な統合を可能にしています[2]。
  • API server経由でリソース差分をチェックし、必要なリソースを作成するためにCloud Provider APIを呼んでいます。

kube-controller-manager

  • k8sクラスタのリソース状態を管理して、要求される各リソースの状態（あるべき姿）を維持します。
  • Controller[3]を管理するプロセスです。
  • 例としてdeployment, replicaset, cronjob, service等のControllerが実行されています。

etcd

  • k8sクラスタに登録される全ての情報を保存するデータストアです。
  • あるべき状態、作成されたPodとNodeのアサイン、api-serverから受信した情報などを保存します。
  • キー・バリュー形式でデータを保存し、キーは階層的に構造化されています(KVS)。

Woker Node上で動作しているもの

kubelet

  • kube-apiserからの指示を受けて動作し、Worker Node上で動いている全てのPodと関連リソースのヘルスチェックや、ライフサイクル管理全般を行います。
  • Container Runtimeを利用しPodの生成・更新・破棄などを行うのが大きな役目です。Podがダメになっていたら再起動したりします。
  • kubeletはイベント駆動型で、リソースの変更に応じて素早く処理を実行します。

kube-proxy

  • クラスター内外からPodの通信を管理するネットワークプロキシの役割を持ちます。
  • kube-proxyが各Worker Node上で動作し、Serviceオブジェクトの設定に基づいてネットワーク設定を行います。
  • 実体はiptablesのルールを発行し、パケットの制御をしています。
  • 実装は（Linux Nodeで利用可能な）iptables, ipvs, nftables[4], および（Windows Nodeで利用可能な）kernelspace の中から選ぶことができます。デフォルトはiptablesです[5]。

Container Runtime

  • ここでコンテナが実行され、kubeletによるコンテナイメージの取得・コンテナの作成・更新・破棄などを実行します。
  • 現代のk8sクラスタでは、containerd がデフォルトのContainer Runtimeとなっています。
  • k8sはContainer Runtimeの取替が可能なため CRI-O, gVisor などに変更することも可能です。
  • 以前はContainer Runtimeの1つとしてDocker（dockershim）も選択肢にありましたが、v1.20 からDockerを選択することは非推奨になりました[6]。その後、1.24で正式にサポートが終了しています[7]。

全体構成図

これまでのコンポーネントを図示するとこのようになります。

処理の流れ（図に記載しているものと同じです）
  1. kube-apiserver → kube-scheduler
    新しいPodの情報をkube-schedulerに提供
  2. kube-scheduler → kube-apiserver
    Podの配置先Nodeを決定、その情報をkube-apiserverに報告
  3. kube-apiserver → etcd
    kube-apiserverを通じてetcdに保存されたクラスタの状態を間接的に参照
  4. etcd→kube-apiserver
    スケジューリングの結果をkube-apiserverを介し保存
  5. kube-apiserver → kube-controller-manager
    リソース状態をkube-controller-managerに通知する
  6. kube-controller-manager → kube-apiserver
    リソース状態をkube-controller-managerに通知
  7. kube-apiserver → kubelet
    Podの作成、更新、削除などの指示
  8. kubelet → Container Runtime
    コンテナの起動、停止、削除などの操作を指示
  9. kubelet → kube-apiserver
    Node上で実行中のPodやNode自体の状態をkube-apiserverに報告
  10. kube-apiserver → kube-proxy
    Serviceオブジェクトやエンドポイント情報を提供
  11. kube-apiserver → cloud-controller-manager
    リソース状態や関連するイベントをcloud-controller-managerに通知
  12. cloud-controller-manager → Cloud Provider
    Cloud Provider API呼び出しクラウドリソース管理
  13. cloud-controller-manager → kube-apiserver
    Cloud Provider APIを通したリソースの管理結果をkube-apiserverに反映

全体構成図

補足

  • ユーザーはCLIツール kubectl を使ってkube-apiserverと通信し、k8sクラスタにアクセスします。
  • Control Planeは冗長化を考慮してNodeが3台程度[8]で動くのに対し、Worker Nodeは規模によっては100台動かすこともあります。
  • それぞれのコンポーネントは疎結合であり、コンポーネントのカスタマイズは自由です。
    • 例: Cloud Providerを利用していないのでcloud-controller-managerは利用しない、kube-proxyを使わずにCiliumを導入するなど。

おわりに

勉強を兼ねて書いたので、間違っているところがあるかもしれません（認識がずれていたら教えていただけると幸いです）。
知見を共有してくださった先人たちへこの場を借りて御礼申し上げます。

参考にさせていただいたものたち

つくって、壊して、直して学ぶ Kubernetes入門
Kubernetes入門！主要コンポーネントを概要図で学ぼう
Kubernetes の コンテナランタイムについて、改めて見つめなおしてみた
CRI: the Container Runtime Interface
kubernetes公式ドキュメント
Comparing kube-proxy modes: iptables or IPVS?
Kubeletから読み解くKubernetesのコンテナ管理の裏側/Kubelet & Containers
kube-proxy入門
controller-runtime Deep Dive
kube-controller-manager入門
Kubernetes 超入門
Kubernetesの内部機構【中・上級者向け】
Kubernetesの各コンポーネントについて
Cloud Controller Manager 超入門 / Cloud Controller Manager 101

脚注

  1. Nodeと単純に書かれている場合には、基本的にWoker Nodeを指します。
    api-serverを構成するPodが動作するNodeは Control Plane Node と呼び、区別することもあります。 ↩︎

  2. design-proposals-archive - Refactor Cloud Provider out of Kubernetes Core ↩︎

  3. 管理対象を宣言された理想状態に自動で調整するループを実行するアプリケーションのことを指します。管理対象のリソース変更や一定時間経過などのイベントをきっかけに実行されます。 ↩︎

  4. KEP-3866: Add an nftables-based kube-proxy backendで提案された機能で、k8s v1.29 でα機能として入っています。 ↩︎

  5. 以前はuserspaceというモードもありましたが、長い非推奨期間を経てv1.26で削除されています（Remove kube-proxy userspace modes＃11213）。 ↩︎

  6. kubernetes/CHANGELOG-1.20.md#deprecation ↩︎

  7. kubernetes/CHANGELOG-1.24.md#dockershim-removed-from-kubelet ↩︎

  8. 「Control PlaneのNodeが3台程度」というのは、Control Planeのコンポーネント（例: kube-apiserverやetcd）が冗長化のために3つの専用Nodeに分散して動作していることを指します。これはWorker Nodeとは別のものです。 ↩︎

Discussion