Kubernetesは「コンテナを起動するコマンド」ではなく、宣言された望ましい状態へクラスタを近づけ続ける制御システムです。その中心がControl plane、実際にPodを動かす側がdata planeです。
Control planeとdata plane
| 区分 | 役割 | 主な構成要素 |
|---|---|---|
| Control plane | 状態を受け付け、判断し、調整を指示する | API server、scheduler、controller manager、状態ストア |
| Data plane | 指示を受けて実際のワークロードを動かす | Node、kubelet、コンテナランタイム、ネットワーク |
一般的なKubernetesではdata planeを「worker node」と呼ぶこともあります。GKE AutopilotではノードをGoogleが管理するため、利用者から見える管理範囲は小さくなります。
kubectl applyからPod起動まで
Deploymentを適用したとき、裏側ではおおむね次の流れが起きます。
kubectlがマニフェストをKubernetes API serverへ送る- API serverが認証・認可・検証を行い、状態を保存する
- Deployment controllerが必要なReplicaSetを作る
- ReplicaSet controllerが不足分のPodを作る
- schedulerが未配置Podに適したNodeを割り当てる
- Node上のkubeletがコンテナランタイムへ起動を指示する
- 各コントローラーが状態差を監視し続ける
このように、kubectl がNodeへ直接SSHしてコンテナを起動するわけではありません。APIへ望ましい状態を登録し、複数のコントローラーが分担して実現します。
Control planeの主な構成要素
kube-apiserver
クラスタ操作の入口です。kubectl、コントローラー、外部ツールは原則としてAPI serverを通じて状態を読み書きします。認証、認可、Admission Control、API検証もここを通ります。
kube-scheduler
まだNodeが決まっていないPodに対し、CPU・メモリ要求、制約、親和性、汚染と許容などを見て配置先を決めます。第13回で扱う requests はこの判断材料です。
kube-controller-manager
DeploymentやReplicaSetなど、複数のコントローラーを実行します。それぞれが「望ましい状態」と「現在状態」の差を監視し、必要なAPI操作を行います。この繰り返しを**調整ループ（reconciliation loop）**と呼びます。
状態ストアとetcd
etcd は、Kubernetes APIオブジェクトを保存する強整合な分散キーバリューストアです。SecretもAPIオブジェクトなので、アクセス制御と保存時暗号化が重要です。
ただしGKEの内部実装について「必ず物理的なetcdクラスタに保存される」と断定してはいけません。GKEの制御プレーン状態バックエンドはetcdまたはSpannerの場合があり、どちらでもAPI serverにはetcd互換の保存インターフェースとして提供されます。利用者は内部ストアを直接操作せず、Kubernetes APIを使います。
Data planeの主な構成要素
Node
Podが配置される計算資源です。GKE Standardではノードプール、マシンタイプ、更新などを利用者がより細かく管理します。AutopilotではGoogleがノード基盤を管理し、利用者は主にワークロードを宣言します。
kubelet
各Node上のエージェントです。API serverで割り当てられたPod仕様を監視し、コンテナが期待どおり動くようコンテナランタイムと連携します。Probe結果やNode状態もControl planeへ報告します。
コンテナランタイムとネットワーク
コンテナランタイムはイメージ取得とコンテナ実行を担います。Kubernetesは現在、CRIというインターフェースを介してcontainerdなどを利用します。KubernetesがDockerfileを読むのではなく、レジストリにある完成済みイメージをランタイムが取得します。
GKEが管理してくれる範囲
GKEではControl planeの可用性、更新、状態ストアなどをGoogleが管理します。しかし利用者側にも責任が残ります。
- DeploymentやServiceなどの設計
- IAMとKubernetes RBACの最小権限
- コンテナイメージと脆弱性管理
- requests、limits、Probeの設定
- Secretの参照方法
- ログ、メトリクス、予算の監視
マネージドサービスは「運用がゼロ」ではなく、責任境界が変わるサービスです。
AutopilotとStandard
初めてGKEを使う多くのワークロードでは、GoogleはAutopilotを推奨しています。ノード運用を減らせる一方、特殊な権限、ハードウェア、DaemonSet、細かなノード構成などでStandardが必要になる場合があります。
どちらを選んでもKubernetes APIと基本オブジェクトは共通です。まずワークロード要件を書き出し、必要な制御範囲で選びます。
次回
この調整ループへ望ましい状態を渡す方法を、kubectl applyと宣言的管理で実践します。