まず全体像
Kubernetes は、複数のサーバー上でコンテナを自動で動かすための管理システムです。
クラスタは大きく分けると、考えて指示を出す側の control plane と、実際にコンテナを動かす側の worker node でできています。公式ドキュメントでも、クラスタは「control plane と 1台以上の worker node で構成される」と説明されています。 (Kubernetes)
いちばん大事な専門用語
クラスタ
Kubernetes でまとめて管理するサーバー群のことです。
1台だけでも作れますが、ふつうは複数ノードで使います。 (Kubernetes)
ノード
クラスタを構成する1台1台のマシンです。
役割で分けると、control plane node と worker node があります。 (Kubernetes)
Pod
Kubernetes がアプリを動かすときの最小単位です。
実際には、コンテナはたいてい Pod の中で動きます。Scheduler は「Pod をどの Node に置くか」を決めます。 (Kubernetes)
API Server
Kubernetes の受付窓口です。
人間、kubectl、Scheduler、Controller、kubelet、外部ツールは、基本的にみんな API Server を通じて Kubernetes とやり取りします。API Server は HTTP API を公開していて、クラスタの共通状態への入口になっています。 (Kubernetes)
etcd
クラスタの状態を保存するデータベースです。
たとえば「どんな Pod が欲しいか」「今どの Node があるか」などの情報がここに保存されます。 (Kubernetes)
kubelet
各 Node で動く現場監督です。
「この Pod を動かせ」という指示を受けて、実際にコンテナを起動・監視します。 (Kubernetes)
Container Runtime
実際にコンテナを起動するソフトです。
containerd や CRI-O などがこれに当たり、kubelet と runtime は CRI という仕組みで通信します。 (Kubernetes)
CRI 対応コンテナランタイムとは、
Kubernetes と決められた話し方（CRI = Container Runtime Interface）で会話できる、コンテナ実行ソフトのことです。
kube-proxy
各 Node 上で、Service に届く通信を正しい Pod に流すためのネットワークルールを維持します。 (Kubernetes)
API は「どこからどこへ」「何のために」使うのか
結論から言うと、Kubernetes ではほぼ全部が API Server 経由です。
公式ドキュメントでも、Kubernetes API はオブジェクト状態を問い合わせたり操作したりするためのもので、ユーザー、クラスタ内部の各部品、外部コンポーネントが API Server 経由で通信すると説明されています。さらに、ノード側から control plane への通信は hub-and-spoke 型で、ノードや Pod からの API 利用はすべて API Server で終端するとされています。 (Kubernetes)
1. あなた → API Server
あなたが kubectl apply -f xxx.yaml を打つと、kubectl は Kubernetes API を使って API Server に要求を送ります。(yamlにやりたいことを書く)
kubectl は control plane と通信するためのコマンドで、設定ファイル kubeconfig を使って接続先や認証情報を知ります。 (Kubernetes)
自分のPCからkubectlを使うには
xxx.yamlの書き方
2. API Server → etcd
API Server は受け取った内容を検証し、クラスタの状態として保存します。
この保存先が etcd です。つまり、「こうしたい」という希望状態をまず記録する役目です。 (Kubernetes)
3. Scheduler → API Server
Scheduler は、まだどの Node に置くか決まっていない Podを見つけて、置き場所を決めます。
直接コンテナを起動するのではなく、API Server 上の情報を見て判断し、割り当て結果も API 経由で反映します。 (Kubernetes)
4. Controller Manager → API Server
Controller Manager は、「希望状態」と「実際の状態」のズレを埋める係です。
たとえば「Pod は3個必要」と書いてあるのに2個しかなければ、API Server を通じて不足を埋めようとします。公式ドキュメントでも、controller は API Server 越しに共有状態を監視し、現在状態を望む状態へ近づけると説明されています。 (Kubernetes)
5. Worker 上の kubelet → API Server
各 worker node の kubelet も、API Server を見て自分の Node で何を動かすべきかを把握します。
そして、その情報をもとに container runtime に依頼してコンテナを起動します。ノードから control plane への API 利用は API Server に集約されます。 (Kubernetes)
6. API Server → kubelet
逆方向の通信もあります。
たとえば kubectl logs、kubectl exec、port-forward のような操作では、API Server から各 Node の kubelet に接続して処理します。 (Kubernetes)
マスター(Control Plane)は何をしているのか
Control Plane は、ひとことで言うとクラスタ全体の管理者です。
主な部品は kube-apiserver、etcd、kube-scheduler、kube-controller-manager です。 (Kubernetes)
kube-apiserver
全員の受付窓口です。
kubectl も、Scheduler も、Controller Manager も、kubelet も、まずここに話しかけます。REST 操作の入口であり、クラスタ共有状態のフロントエンドです。 (Kubernetes)
etcd
クラスタ情報の保管庫です。
API Server のデータがここに入ります。 (Kubernetes)
kube-scheduler
どの worker に Pod を置くか決める係です。
CPU やメモリ、制約条件を見て、まだ Node 未割り当ての Pod に置き場所を決めます。 (Kubernetes)
kube-controller-manager
状態を自動で整える係です。
「3個あるべき」「Node が消えた」「Service 用の関連情報が必要」などを監視して、API を通じて調整します。 (Kubernetes)
ワーカー(Worker Node)は何をしているのか
Worker Node は、ひとことで言うと実行担当です。
アプリの Pod は基本的に worker node 上で動きます。公式ドキュメントでも「worker nodes are where your workloads run」と説明されています。 (Kubernetes)
kubelet
Node 上の現場監督です。
API Server を見て、自分の Node に割り当てられた Pod を実際に動かし続けます。 (Kubernetes)
container runtime
実際にコンテナを起動する実働部隊です。
kubelet から CRI 経由で命令を受けます。 (Kubernetes)
kube-proxy
通信の交通整理です。
Service 宛ての通信が、正しい Pod に届くよう Node 上のネットワークルールを保ちます。 (Kubernetes)
「マスターとワーカーで何が違うのか」を一発で言うと
マスター(Control Plane) は
「どこで何を何個動かすかを決め、全体状態を管理する側」です。 (Kubernetes)
ワーカー(Worker) は
「決められた内容どおりに、実際に Pod とコンテナを動かす側」です。 (Kubernetes)
それぞれでどんなコマンドが使えるか
ここは少し大事です。
kubectl は“マスター専用コマンド”ではありません。
kubectl は kubeconfig があって API Server に届く場所なら、control plane node でも、worker node でも、手元PCでも使えます。 公式ドキュメントでも、kubectl は Kubernetes API を使って control plane と通信するツールであり、control plane 以外のマシンからでも admin.conf をコピーすれば操作できると説明されています。 (Kubernetes)
1) Control Plane でよく使うコマンド
クラスタ構築・管理の中心です。
# クラスタ初期化
kubeadm init
# ノード一覧
kubectl get nodes
# Pod一覧
kubectl get pods -A
# YAMLを適用
kubectl apply -f app.yaml
# 状態確認
kubectl describe pod <pod名>
# ログ確認
kubectl logs <pod名>
# API Serverへローカルプロキシ
kubectl proxy
kubeadm init は control-plane node の初期化に使い、kubectl はクラスタ操作に使います。control plane node 上で kubectl apply -f <add-on.yaml> を実行してネットワーク add-on を入れる例も公式にあります。 (Kubernetes)
2) Worker Node でよく使うコマンド
worker をクラスタに参加させたり、Node 上の実行状況を調べたりします。
# クラスタ参加
kubeadm join <control-plane-host>:<port> --token ... --discovery-token-ca-cert-hash sha256:...
# kubeletログ確認（systemd環境）
journalctl -u kubelet
# CRIランタイムの中身を見る
crictl pods
crictl ps
crictl images
crictl logs <container_id>
kubeadm join は node をクラスタに参加させるコマンドです。journalctl -u kubelet は systemd 環境で kubelet ログを見る公式例です。crictl は CRI 対応 runtime を調べるための公式ツールで、Node 上のコンテナや Pod を直接確認できます。 (Kubernetes)
3) どこでも使えるが、意味を理解して使うコマンド
kubectl get nodes
Kubernetesクラスタに参加しているノード一覧（サーバ一覧）を見るコマンドです。control plane や worker が今どういう状態か確認できます。
kubectl get pods -A
クラスタ内のすべてのNamespaceにあるPod一覧を見るコマンドです。-A は --all-namespaces の意味で、「全部の名前空間を対象にする」です。
kubectl describe node <node名>
指定したノード1台について、かなり詳しい情報を表示するコマンドです。IPアドレス、役割、割り当てられているPod、イベント、リソース状況などを見られます。
kubectl logs <pod名>
指定したPodのログ（コンテナの標準出力・標準エラー出力）を見るコマンドです。アプリが何を出しているか、エラーが出ていないか確認するときに使います。
kubectl exec -it <pod名> -- sh
指定したPodの中にシェルで入って操作するコマンドです。-i は入力をつないだままにする、-t はターミナル風に操作する、sh はPod内で起動するシェルです。
少し補足すると、
-
get= 一覧を見る -
describe= 詳細を見る -
logs= ログを見る -
exec= 中に入ってコマンド実行する
という使い分けです。
たとえば kubectl logs <pod名> や kubectl exec -it <pod名> -- sh は、Podの中にコンテナが複数あると -c <コンテナ名> が必要になることもあります。
これらは API Server に届いて認証できれば、control plane node でも、worker node でも、あなたのノートPCでも実行できます。 kubectl logs などの裏では API Server から kubelet への通信が使われます。 (Kubernetes)
APIの流れを、実際の操作で例えるとこうなる
例1: kubectl apply -f nginx.yaml
- あなたが
kubectlを打つ -
kubectlが API Server に「nginx Pod を作りたい」と送る - API Server が内容を受け付けて保存する
- Scheduler が「どの worker に置くか」を決める
- その worker の kubelet が気づく
- kubelet が runtime に頼んでコンテナを起動する (Kubernetes)
例2: kubectl logs <pod名>
- あなたが
kubectl logsを打つ -
kubectlが API Server に依頼する - API Server がその Pod のある Node の kubelet に取りに行く
- kubelet がログファイルを読んで返す (Kubernetes)
初心者向けに超ざっくり覚えるなら
Control Plane = 頭脳
- 受け付ける: API Server
- 保存する: etcd
- 配置を決める: Scheduler
- ズレを直す: Controller Manager (Kubernetes)
Worker Node = 手足
- 指示を見る: kubelet
- コンテナを動かす: runtime
- 通信を流す: kube-proxy (Kubernetes)
勘違いしがちな点
Kubernetes は 「コンテナイメージを使って、デプロイ・スケーリング・自己修復・更新管理などを行うオーケストレーション基盤」 です。
なので、Podman や Docker で“作った”イメージを使うことは多いですが、Kubernetes 自体が必ずしも Podman/Docker 前提 というわけではありません。Kubernetes は Pod や Deployment などの設定を受け取り、各ノード上の CRI 対応コンテナランタイム にコンテナ起動を依頼します。各ノードには実際にコンテナを動かすランタイムが必要で、kubelet はそのために CRI を使います。
つまり、「コンテナイメージさえあれば、Kubernetes はそのイメージを使ってデプロイ・スケーリング・管理を自動化できる。ただし、実際にコンテナを動かすには、各ノードに containerd や CRI-O などのコンテナランタイムが必要」
最後に、最初の理解としてはこれで十分
最初はこう覚えるとかなり整理しやすいです。
- Kubernetes は API Server 中心
- 人も部品も API Server に話しかける
- Control Plane は決める側
- Worker は動かす側
kubectlは API をたたく道具kubeadmはクラスタを作る・参加する道具-
kubeletは各 Node の現場監督 (Kubernetes)