mhKubernetesは、「コンテナを効率的に管理するための分散システム」です。
あなたがアプリをコンテナで用意したとき、「どこに何個動かすか」「壊れたらどうするか」「外からアクセスできるようにするには？」といった運用上の課題が出てきます。Kubernetesはこれらを自動で制御してくれる仕組みです。
🧩 全体構成のイメージ：Kubernetesクラスタ
Kubernetesは、複数のマシン（仮想でも物理でも）をまとめて1つの「クラスタ」として扱うのが基本です。
このクラスタは、大きく次の2種類のノード（サーバ）から成り立っています：
| 役割 | 概要 |
|---|---|
| Control Plane（旧称: Master） | Kubernetes全体をコントロールする「司令塔」。 Podのスケジューリングや監視、再起動の指示などを担う |
| Node（旧称: Worker） | 実際にアプリケーションのコンテナが動く場所。 Control Planeの指示に従ってPodを動かす |
🧠 Control Planeの主な構成コンポーネント
Control Planeには、以下のようなプロセスが動いています：
kube-apiserver
→ Kubernetesの「受付窓口」。kubectl や他のサービスがAPIを通して操作を送る先。etcd
→ Kubernetesの設定や状態を保存する「鍵付きノート」。軽量な分散KVS（キーバリューストア）。kube-scheduler
→ 新しいPodをどのNodeに配置するか決める「スケジューラ」。kube-controller-manager
→ 望ましい状態（例: Podが常に3つ動いている）と実際の状態を比べて差分を解消する「調整役」。cloud-controller-manager（クラウド利用時）
→ GCPやAWSなどのクラウドインフラと連携するための制御役。
🖥️ Node（ワーカーノード）の主な構成コンポーネント
各Nodeでは、以下のコンポーネントが動いています：
kubelet
→ Node上で「Podを起動せよ」という命令を受け取り、コンテナを実際に動かす「現場監督」。kube-proxy
→ Pod間や外部とのネットワーク通信を制御する「交通整理役」。Container Runtime（例: containerd、CRI-O）
→ 実際にコンテナを実行するエンジン部分。昔はDockerだったが、現在はより軽量なcontainerd等が主流。
🔄 Kubernetesの動き方（ざっくり）
- あなたが
kubectl applyなどでYAMLを送ると、kube-apiserverがそれを受け取ります。 etcdにその情報が保存され、他のコンポーネントが監視し始めます。schedulerが「このPodはNode Aに置こう」と判断。kubeletがそのNode上でPodを起動。- Podが動き続けるように、
controller-managerが監視・自動修復。
💡補足：なぜこの構成なの？
このように役割ごとに分けることで、Kubernetesは大規模なクラスタでも安定して動くように設計されています。Control PlaneとNodeを分けるのは、スケーラビリティ（拡張性）と可用性（壊れにくさ）を両立させるためです。
