ブログ一覧

図でわかるKubernetes入門：Pod・Deployment・Serviceの違いとつながり

2026年10月26日 · 約14分で読めます

Kubernetesの用語を、本の一覧APIを動かす一つの例でつなげます。8つの図と配置の見取り図で、クラスタとNode、Podの作成と復旧、Serviceへの通信、ヘルスチェック、設定・ストレージ、スケールと更新を順に解説します。

1. Kubernetesとは？「APIを3個動かしたい」を維持する仕組み

コンテナイメージは、アプリと実行に必要なファイルをまとめたものです。コンテナは、そのイメージから起動した実行環境。1台で起動するだけならコンテナランタイムを使えますが、複数のマシンで動かすと、配置・障害時の補充・接続先・更新も管理する必要が出てきます。Kubernetes（略称K8s）は、その管理を担います。

本の一覧を返す架空のAPIを考えます。宣言するのは「books-apiのv1を3 Pod動かす」という望ましい状態です。コントローラーは現在の状態を観察し、足りないPodを作るなどして差を埋めます。この繰り返しを調整ループ、reconciliationと呼びます。

作成には時間がかかり、配置できる容量や権限がなければ望ましい状態に届きません。3個と書くだけで即座に3個が正常稼働するわけではなく、Kubernetesは目標へ近づける動作を続けます。以降は一般的なDeploymentと、セレクターを持つClusterIP Serviceを使う例です。

2. Cluster・Node・Pod・Container：どこで何が動くのか

クラスタ（Cluster）は、管理を行うコントロールプレーンと、アプリを動かすNodeから構成されます。Nodeは仮想マシンまたは物理マシンです。Podは1つのNode上に配置され、1個以上のコンテナが同じネットワーク環境を共有し、必要に応じてボリュームも共有します。API本体と補助プロキシのように密接に連携する構成もあります。

Cluster
├─ Control plane（クラスタを管理）
└─ Worker Nodes（アプリを実行）
   ├─ Node A
   │  ├─ Pod A [API container]
   │  └─ Pod B [API container]
   └─ Node B
      └─ Pod C [API container]

3個のAPIを動かすなら、通常は1つのPodにAPIコンテナを3個入れるのではなく、APIを入れたPodを3個に複製します。Podは配置と複製の単位だからです。同じPodのコンテナは別々のNodeに分散できません。Node障害へ備えて分散したい場合は、topology spread constraintsなどで配置条件も設計します。

Node側ではkubeletがPodの実行状態を管理し、containerdなどのコンテナランタイムを通じてコンテナを起動します。宣言を受け付ける人、置き場所を決める人、実際に動かす人が分担していると考えると、構成を追いやすくなります。

3. Deployment・ReplicaSet・Pod：誰が数を保ち、誰が置き換えるのか

Podだけを作っても、削除後の補充を管理する仕組みは付きません。ステートレスなAPIならDeploymentを使い、Podのひな型、必要な個数、更新方法を宣言します。DeploymentはReplicaSetを管理し、ReplicaSetが対象Podの数を維持します。

代わりのPod Dは、削除されたPod Bとは別のオブジェクトで、IPも同じとは限りません。対して、Pod内のコンテナが異常終了した場合は、kubeletがrestartPolicyに従って同じPod内で再起動することがあります。コンテナの再起動とPodの置き換えを区別しましょう。障害検知から補充までは時間がかかるため、処理中の要求やメモリ内のデータまで自動復元されるわけではありません。

4. Service・Label・Ingress：利用者の通信はどこへ届くのか

PodのIPを呼び出し側に直接設定すると、置き換わるたびに接続先が変わります。Serviceは、入れ替わるPod群に対して安定した接続先を提供します。この例のClusterIP Serviceにはクラスタ内の仮想IPが割り当てられ、クラスタDNSがあれば同じNamespaceのアプリはbooks-apiという名前で接続できます。

LabelはPodなどに付ける名札です。Podにapp=books-apiを付け、Serviceのselectorにもapp=books-apiを指定します。通常のセレクター付きServiceでは、対象Podのアドレスと準備状態がEndpointSliceへ反映され、通信経路の実装が転送先を更新します。ServiceがDeployment名を見て対象を選ぶわけではありません。

Ingressは、ホスト名やパスからServiceへ振り分けるHTTP(S)のルールです。ルールを反映するIngress controllerとロードバランサー等の実体が必要です。図は論理的な対応であり、実装によってはServiceの仮想IPを経由せず、プロキシがPodへ直接転送します。実際の経路は採用した実装で確認します。Gateway APIも入口を構成する選択肢です。

5. RunningとReady：起動したPodへすぐ通信してよいか

Runningはアプリが要求を処理できる保証ではありません。設定やキャッシュを読み込む途中でもコンテナは動いています。そこでprobe（ヘルスチェック）を使い、起動できたか、要求を受けてよいか、再起動が必要かを分けて判断します。

livenessに共有DBへの問い合わせを入れると、DBの一時的な遅延で全コンテナが再起動し、起動時の接続集中で悪化することがあります。再起動で直るプロセス自身の異常と、依存先の障害を分けます。readinessにも共有依存先を入れるなら、全Podを同時に外す影響を評価します。検査と転送先の更新には遅れがあり、切り替えは瞬時ではありません。

6. YAMLを読む：Deploymentのひな型とServiceの名札を結ぶ

ここまでの関係をYAMLで表すと次のようになります。既存のbooks Namespaceを想定した概念説明用の例です。イメージURLはダミーで、実行確認した構成ではありません。実際に試すには取得可能なイメージと、8080番で本の一覧および/readyzを返すアプリが必要です。リソース値は仮定で、推奨値ではありません。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: books-api
  namespace: books
spec:
  replicas: 3
  selector:
    matchLabels:
      app: books-api
  template:
    metadata:
      labels:
        app: books-api
    spec:
      containers:
        - name: api
          image: registry.example.invalid/books-api:v1
          ports:
            - name: http
              containerPort: 8080
          readinessProbe:
            httpGet:
              path: /readyz
              port: http
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: books-api
  namespace: books
spec:
  type: ClusterIP
  selector:
    app: books-api
  ports:
    - port: 80
      targetPort: http

• replicas: 3は希望するPod数。template以下がPodのひな型で、そのlabelsが作成されるPodへ付く。
• Deploymentのselectorとtemplateのlabelsを一致させる。Serviceのselectorも同じ名札を選ぶが、Podの個数は管理しない。
• Serviceは80番で受けた通信を、Podのhttpという名前のポート、つまり8080番へ転送する。containerPortを書くだけでアプリが待ち受けたり、外部公開されたりはしない。
• readinessProbeはアプリが実装した/readyzを検査する。YAMLにパスを書くだけでは、そのエンドポイントは作られない。

7. Namespace・ConfigMap・Secret：所属と設定を分ける

Namespaceは、クラスタ内で名前やリソースを区切る単位です。booksのServiceと、別Namespaceにある同名Serviceは別物です。ただしNodeやPersistentVolumeのようにNamespaceへ属さないリソースもあります。Namespaceを分けただけで通信や権限がすべて分離されるわけではなく、RBACや実装に対応したNetworkPolicy等も必要です。

ConfigMapやSecretを環境変数で渡した場合、オブジェクトを更新しても実行中コンテナの環境変数は変わりません。新しい値を取り込むためにコンテナを再起動する必要があります。通常のボリュームマウントでは更新が後から反映されますが、subPathには自動反映されず、アプリ側にもファイルを読み直す仕組みが必要です。SecretをPodへマウントできる権限も、機密値を読む権限として扱います。

8. Volume・PVC・PV：Podが消えても残したいデータ

コンテナの書き込み領域やPodの一時ボリュームを、永続データの保存先と考えてはいけません。例えばemptyDirは同じPod内のコンテナ再起動では残りますが、Podが削除されると失われます。Podの寿命と分けて保存したいときに、PersistentVolumeClaim（PVC）とPersistentVolume（PV）を使います。

StorageClassは、動的にストレージを作るときの種類や作成方法を表します。PVCがあっても、アクセス方式・ゾーン・実装によっては複数Nodeから同時利用できません。PVC削除後に実体が残るかはreclaimPolicy等に依存します。永続化はバックアップとは別で、削除や破損に備える復元の設計も必要です。今回のAPIは本のデータを外部DBに保存する前提なら、各API PodにPVCを付ける必要はありません。

9. requests・limits・HPA：Podを増やすこととNodeを増やすこと

requestsは配置判断に使う要求量、limitsは実行時の制約です。LinuxコンテナではCPUのlimitがスロットリング、メモリ不足がOOM終了につながることがあります。同じ「上限」でも挙動は違います。例の100mはCPU 1コアの10分の1、128Miは128メビバイトです。指定量がすべてアプリ専用に物理確保される、という意味ではありません。

Horizontal Pod Autoscaler（HPA）は、CPUなどのメトリクスを基に対象の希望Pod数を調整します。CPU使用率を使う設定では、分母はCPU requestsです。必要なメトリクス供給も別途必要です。HPAで管理する場合は、先ほどのYAMLのような固定のreplicasを継続して適用しないよう、管理をHPAへ移します。replicas: 3を再適用すると、HPAが増やした希望数を3へ戻してしまいます。一方、Nodeの増設は別の仕組みで、HPAだけではマシンは増えません。台数の判断から処理参加までに、収集・配置・イメージ取得・初期化の待ちがあります。予測できる集中には事前増設や通常時の余力も検討します。

Podを増やすと、DB接続や外部APIへの呼び出しも増え得ます。例えば仮定として1 Podの接続プール上限が10なら、3 Podで最大30、5 Podで最大50接続です。Kubernetesが外部DBの上限まで自動調整してくれるとは限りません。アプリ全体の予算からPod数と並列数を決めます。

10. ローリング更新：新しいPodを用意してから古いPodを終了する

DeploymentのPodひな型をv1からv2へ変更すると、ローリング更新では新しいReplicaSetを使い、旧Podと新Podの個数を段階的に調整します。次の図は、desired replicasが3、maxSurgeが1、maxUnavailableが0の例です。新Podが利用可能になるまで旧Podを減らさないため、一時的に追加の容量が必要です。

ローリング更新だけで無停止になるわけではありません。正しいreadiness、残るPodの処理能力、終了時のgraceful shutdownが必要です。経路から外れるまでの遅れと処理中の要求を考慮し、アプリが終了シグナルを受け、猶予内で後片付けできるようにします。固定秒数待つだけで安全とせず、実際の転送停止と終了時間を測ります。DBスキーマも旧版・新版の両方が動く形で移行します。

用語をつなげて読む：つまずいたらどの段階を見るか

確認問題です。Podを3個にしたいのはDeployment、入れ替わっても同じ名前で接続したいのはService、初期化中のPodへ要求を送らないための検査はreadinessProbeです。この3つの役割を図2・4・5で言い直せれば、基本のつながりをつかめています。次は下のTipで、ヘルスチェック、リソース、スケールの遅れ、機密設定、終了処理の設計を掘り下げられます。

参考資料：Kubernetes公式ドキュメント

2026年10月26日に確認した公式の概念ドキュメントです。図は本の一覧APIを使った独自の説明用モデルで、実環境の観測結果ではありません。機能の利用可否や実際の通信・ストレージの挙動は、利用するKubernetesのバージョンと実装で確認してください。

• Kubernetes — Components: control plane and Nodes
• Kubernetes — Pods: containers, replication, and replacement
• Kubernetes — Deployments: ReplicaSets and rolling updates
• Kubernetes — Service: selectors, ports, and EndpointSlices
• Kubernetes — Ingress: routing rules and controller prerequisites
• Kubernetes — Liveness, Readiness, and Startup Probes
• Kubernetes — ConfigMaps
• Kubernetes — Secrets: access, storage, and updates
• Kubernetes — Namespaces
• Kubernetes — Volumes: emptyDir lifetime
• Kubernetes — Persistent Volumes and claims
• Kubernetes — Resource management for Pods and containers
• Kubernetes — Horizontal Pod Autoscaling
• Kubernetes — Pod lifecycle and termination