Kubernetes を触り始めると、用語が一気に出てきます。自分も最初は、画面にもドキュメントにも知らない単語が並んでいて、入口で少しひるみました。
ただ、あとから振り返ると、しんどかったのは単に「用語が多いから」ではありませんでした。それぞれの用語が、どの階層の話なのか分からなかったのが一番の混乱ポイントでした。
自分が最初に詰まった K8s 用語は、大きく 3 つありました。
1 つ目は「Pod = コンテナだと思っていた」こと。2 つ目は「Namespace = 環境分離の壁だと思っていた」こと。3 つ目は「Service = ロードバランサーだと思い込んでいた」ことです。
この記事では、まず Cluster、Node、Pod、Deployment、Service までを扱います。Namespace と kubectl、manifest の話は Namespace と kubectl を、分離境界ではなく操作単位で見る に分けました。
まず全体像を見る
用語を階層で分ける
最初は全部を横並びで覚えようとしていました。でも、Kubernetes の用語は「どの階層の責務か」で分けるとかなり読みやすくなります。
Cluster は全体の単位
Control Plane と Worker Node に分けて見る
Kubernetes Cluster は、大きく見ると Kubernetes として動く全体の単位です。まずは細かいコンポーネント名よりも、「ここが全体なんだな」と見るくらいで十分です。
公式ドキュメントでは、Cluster は Control Plane と1つ以上の Worker Node で構成されると説明されています。Control Plane が全体の状態を管理し、Worker Node が実際に Pod を動かします。
EKS でも設計は残る
EKS を使う場合、この Cluster 部分の多くを AWS 側に任せられます。ただし、運用を任せられることと、設計を考えなくていいことは別です。
ここを誤解すると、「EKS を作れば、おおむね整った構成になる」と思ってしまいます。自分も最初は少しそう見えていました。でも実際には、Node をどう持つか、Namespace をどう分けるか、Pod をどこに置くか、運用側で考えることが残ります。
Node は Pod を置く場所
Pod は具体的なマシン上で動く
Node は、Pod を動かすためのマシンです。物理マシンの場合もあれば、仮想マシンの場合もあります。EKS では、多くの場合 EC2 インスタンスとして考えるのが分かりやすいです。
ここで大事なのは、Pod は Cluster の中にふわっと存在するわけではなく、最終的にはどこかの Node にスケジュールされて動く、という点です。これを忘れると、あとでリソースや配置の話が急に分からなくなります。
配置設計の話に切り替わる
EKS の Managed Node Group を使うと、Node になる EC2 インスタンスのプロビジョニングやライフサイクル管理を AWS 側に寄せられます。さらに Node Group にラベルを付け、nodeSelector や Node affinity で Pod を特定の Node 群に寄せる設計もできます。
このあたりから、Kubernetes は急に「アプリケーションの話」だけではなく、「どこに置くか」というインフラの配置設計の話になってきます。自分はここで一回、話の階層が切り替わったことに気づけず混乱しました。
Pod はコンテナを包む単位
Pod とコンテナの違い
Pod は、Kubernetes で作成・管理できる最小のデプロイ単位です。ここも最初に誤解しやすいところです。
最初は「Pod = コンテナ」と思いがちですが、正確には少し違います。Pod は1つ以上のコンテナをまとめて動かす単位です。ネットワークやストレージなど、一部の実行環境を共有します。
多くのケースでは 1 Pod に 1 コンテナなので、普段は「だいたいコンテナっぽいもの」と見ても困らない場面はあります。ただ、運用で詰まり始めると、この粗い理解がじわじわ効いてきます。
リソース制約に目を向ける
たとえば、Pod 数には Node 側のリソースやネットワークの制約が絡みます。サービスを増やすたびに Pod が増え、監視 Agent や補助コンポーネントも Pod を使います。
EC2 や ECS の感覚だけでインスタンスタイプを小さく見積もると、思ったより早く上限や余力の問題に当たります。ここではまず、Pod はコンテナではなく、コンテナを動かすための単位だと押さえておけば十分です。
Deployment は Pod をどう保つか
Pod 単体ではなく望む状態を保つ
Pod は直接作れます。ただ、実運用では Pod を単体で直接管理することは多くありません。
Deployment は、アプリケーション用の Pod 群をどう維持するかを宣言するリソースです。たとえば「この Pod を3つ動かしておきたい」と書くと、Deployment Controller が ReplicaSet を介して、実際の状態をそこに近づけます。
宣言型に慣れる
Kubernetes では、手順を1つずつ実行するというより、「こういう状態であってほしい」と宣言し、Control Plane や Controller がそこへ寄せていきます。
この宣言型の考え方に慣れると、Kubernetes の見通しが少し良くなります。あれこれ操作しているというより、希望する状態を書いて、あとは Controller が近づけてくれる、という感覚です。
Service は Pod への入口
Pod IP は変わる前提で見る
Pod は作り直される前提のリソースです。再作成されれば IP も変わります。なので、他の Pod や外部の利用者が特定の Pod を直接見に行く設計は安定しません。
そこで Service が出てきます。Service は、作り直される Pod 群への安定した入口を作るリソースです。
Deployment と Service の責務を分ける
Deployment は Pod をどう保つか、Service は Pod へどう到達するかを扱います。どちらもアプリケーションを動かすために出てきますが、見ている問題が違います。
ここが分かると、マニフェストを読むときの目線がかなり楽になります。次は Namespace と kubectl を、分離境界ではなく操作単位で見る で、Namespace、kubectl、manifest の見方を整理します。