【Day6】PodとDeploymentの関係を解き明かす！
Kubernetesを学んでいると、ふとこんな疑問が浮かびませんか？
「Podって結局、Deploymentと何が違うの？」
▶ Podとは？
Podは、Kubernetesが管理する最小単位の実行環境。
1つ以上のコンテナ（多くの場合は1つ）を含みます。
とてもシンプルですが、壊れやすい存在でもあります。
Podは落ちたら自動復旧しない
→スケーリングやロールアウトの機能がない
つまり、Pod単体では実運用にはちょっと心許ないのです。
▶ Deploymentとは？
Deploymentは、Podを管理・監視・更新してくれる司令塔です。
- Podの数を管理（スケーリング）
- コンテナの更新（ロールアウト・ロールバック）
- ヘルスチェック
という重要な機能を担っています。
🧠 たとえるなら…
Podが「侍」なら、Deploymentは「侍を束ねる大名」。
一人ひとりを気にせず、大名に命令すれば、部隊全体が動きます。
🌐 Deploymentだけでは外部に公開できない？
Pod（Deployment）を作成しても、外部の世界からアクセスする方法がありません。
そこで必要になるのが Service や Ingress の存在です。
▶ Serviceとは？
Serviceは、Deploymentが管理するPodたちの前に立つ、出入り口の門番のような存在です。
- Podが増減しても、常に同じDNS名でアクセスできる
- 負荷分散（ラウンドロビン）もしてくれる
たとえば grafana-service を通じて、背後のPodたちにリクエストを届けてくれます。
▶ Ingressとは？
Ingressは、Serviceをさらに外部へ公開する「玄関」のような存在です。
HTTP/HTTPSリクエストを特定のServiceにルーティング
- パスベース・ホストベースのルーティングが可能
- セキュリティ強化（HTTPSや認証）にも対応
- 玄関（Ingress）→ 門番（Service）→ 侍たち（Pod）
🧭 全体像を図でイメージしよう！
ユーザーのアクセス
↓
Ingress（例: ALB）
↓
Service（例: grafana-service）
↓
Deployment（例: grafana-deployment）
↓
Pod（grafana本体が動作）
🚪 まとめ：アプリを世に解き放つ三種の神器
| コンポーネント | 役割 |
|---|---|
| Pod | 実際に動作するコンテナ |
| Deployment | Podの数や更新を管理する司令塔 |
| Service | Podへの安定した入口（内部的なアクセス） |
| Ingress | 世界への公開ゲート（外部的なアクセス） |
この理解があれば、EKS × IAMの話でも「どこにアクセス制御を仕込むべきか」がだんだん見えてきますね！
次回予告 📢：EKSの門を開け！～RBACでユーザーに正しい力を授けよ～
次はいよいよ、KubernetesとAWSの権限をつかさどるRBACの出番です。
Kubernetesの世界とAWSの世界が交差する、本当に面白いゾーンに突入します！
よければフォロー＆いいねお願いします🙏
続きが気になる方は、フォロー＆いいね👍
コメントで「詰まったところ」「もっと知りたいこと」もお待ちしています！