前回 は、Cluster、Node、Pod、Deployment、Service を階層と責務で分けて見ました。

この回では、最初に誤解しやすかった Namespace と、Kubernetes を手元から操作するときの kubectl / manifest の流れを整理します。

自分にとって大事だったのは、Namespace を「環境分離の壁」として見すぎないことと、kubectl を「手順を実行するCLI」ではなく「宣言を API Server へ渡す窓口」として見ることでした。

Namespace は分類であって万能な分離境界ではない

Namespace で分けられるもの

Namespace は、1つの Cluster 内でリソースのグループを分ける仕組みです。名前だけ見ると完全に分離できそうですが、実際に分かれるのは主に名前と管理単位です。

Deployment、Service、ConfigMap などは Namespace の中に置けます。同じ名前の ConfigMap でも、Namespace が違えば別物として扱えます。これは環境や用途ごとにリソースを整理するときに便利です。

一方で、Namespace は万能な分離境界ではありません。Node や PersistentVolume など、Namespace に属さないリソースもあります。Namespace を分けたからといって、Node やコストが自動で適切に分離されるわけでもありません。

ここが自分にとって最初の大きな落とし穴でした。

分離には追加設計が必要

「Namespace で分ける」と聞くと、強い分離ができるように見えます。でも実際には、何を分けたいのかによって、NetworkPolicy、ResourceQuota、NodeSelector、Node Group、NAT Gateway など、別の設計要素も絡んできます。

Namespace は入口としては分かりやすいですが、コストやネットワークまで含めると、話は一段深くなります。まずは「名前と管理単位を分ける箱」として見ておくと混乱しにくいです。万能な分離境界だと思わない、くらいがちょうどよさそうです。

kubectl は宣言をクラスタへ渡す窓口

kubectl は API Server への入口

Cluster / Node / Pod / Deployment / Service / Namespace は、すべて Kubernetes のリソースです。

これらを実際に作ったり書き換えたりするとき、最初の窓口になるのが kubectl という CLI ツールです。kubectl から API Server に対して操作を投げ、Control Plane が状態を更新します。Kubernetes を手元から触るときの入口ですね。

ここで大事なのは、kubectl は単に「作業コマンドを順番に実行する道具」ではないということです。Kubernetes の API に対して、今ほしい状態や確認したい状態を伝える窓口として見ると、後の説明がつながりやすくなります。

マニフェストを apply する

操作の中心になるのは「マニフェスト」と呼ばれる YAML ファイルです。Deployment や Service の「望む状態」をマニフェストに書き、kubectl apply -f manifest.yaml で適用すると、Control Plane がその状態へ寄せていきます。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-api
  namespace: dev
spec:
  replicas: 3

Kubernetes の宣言型の考え方は、ここで初めて手が動きます。手順を1つずつ実行するのではなく、「こうあってほしい」とマニフェストに書いて適用する。あとは Control Plane がその状態へ寄せていきます。

ここが分かると、Deployment や Service の話が線でつながりました。

迷ったら階層に戻る

用語を階層で見直す

ここまでを少し荒く整理すると、こうです。

  • Cluster: Kubernetes 全体
  • Control Plane: 全体の状態を管理する側
  • Node: Pod を動かすマシン
  • Pod: コンテナを動かす最小単位
  • Deployment: Pod 群を望む状態に保つ宣言
  • Service: Pod 群への安定した入口
  • Namespace: リソース名や管理単位を分ける箱
  • kubectl: クラスタへの操作窓口
  • マニフェスト: リソースの「望む状態」を書く YAML ファイル

自分は最初、この階層をだいぶ混ぜていました。Namespace の話をしているつもりで Node の話をしていたり、Pod の数を見ているつもりで実際には Node Group やインスタンスタイプの制約を踏んでいたりしました。

Kubernetes は、用語を単体で覚えるよりも、「これはどの階層の責務か」を分けたほうが理解しやすいです。最初は全部を覚えようとせず、この整理を見直すくらいで十分かなと思います。

次に扱うこと

次は Managed Node Group とリソース制約の話に進みます。Node ごとの capacity、Pod のリソースリクエスト、実際の配置がどう影響するのかを整理します。その先には、ConfigMap / Secret といった設定管理の話も見えてきます。

参考