「Dockerは使えるようになったけど、Kubernetesって何？」
「PodとDeploymentの違いがよくわからない…」
「Kubernetesの概念が複雑で挫折しそう」
そんな悩みを抱えていませんか？
Kubernetesは確かに複雑に見えますが、基本的な概念であるPodとDeploymentを理解することで、コンテナオーケストレーションの全体像が見えてきます！
この記事では、技術評論社から2024年に発売された「［改訂新版］イラストでわかるDockerとKubernetes」を参考に、視覚的でわかりやすい解説を心がけながら、KubernetesのPodとDeploymentについて詳しく説明していきます。
初心者の方でも理解できるように、具体例とイラストを交えながら解説していくので、ぜひ最後まで読んでみてください！
Kubernetesとは？コンテナオーケストレーションの必要性
Dockerコンテナだけでは限界がある
Dockerを使ってコンテナ化したアプリケーションを運用していると、こんな課題に直面することがありませんか？
- 複数のコンテナを協調して動作させたい
- 負荷に応じてコンテナの数を自動で増減したい
- コンテナが停止した時に自動で復旧したい
- アプリケーションを無停止でアップデートしたい
これらの課題を解決するのが、コンテナオーケストレーションと呼ばれる仕組みです。
Kubernetesが解決する課題
Kubernetes（k8s）は、Googleが開発したコンテナオーケストレーションプラットフォームです。以下のような機能を提供します：
- 自動スケーリング: 負荷に応じてコンテナ数を自動調整
- 自己修復: 失敗したコンテナの自動復旧
- ローリングアップデート: 無停止でのアプリケーション更新
- ロードバランシング: トラフィックの分散
- サービスディスカバリ: コンテナ間の通信管理
イラストで理解するKubernetesの全体像
Kubernetesクラスタは、以下のような構成要素で成り立っています：
【Kubernetesクラスタ】
┌─────────────────────────────────────┐
│ Master Node (制御プレーン) │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐│
│ │API Server│ │etcd │ │Scheduler││
│ └─────────┘ └─────────┘ └─────────┘│
└─────────────────────────────────────┘
│ 管理・制御
▼
┌─────────────────────────────────────┐
│ Worker Nodes │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Node1 │ │ Node2 │ │
│ │ ┌─────────┐ │ │ ┌─────────┐ │ │
│ │ │Pod │ │ │ │Pod │ │ │
│ │ │ ┌─────┐ │ │ │ │ ┌─────┐ │ │ │
│ │ │ │コンテナ│ │ │ │ │コンテナ│ │ │ │
│ │ │ └─────┘ │ │ │ │ └─────┘ │ │ │
│ │ └─────────┘ │ │ └─────────┘ │ │
│ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────┘この図からもわかるように、実際にコンテナが動作する最小単位が「Pod」なのです。
Podの基本概念と仕組み
Podとは何か
Pod（ポッド）は、Kubernetesにおけるデプロイメントの最小単位です。重要なポイントは以下の通りです：
- 1つ以上のコンテナをまとめたもの
- 同じPod内のコンテナは同じノード上で実行される
- IPアドレスとストレージを共有する
- ライフサイクルを共有する（一緒に作成・削除される）
なぜPodが必要なのか
「なんでコンテナを直接管理しないの？」と思うかもしれませんが、Podには重要な役割があります：
1. 密接に連携するコンテナのグループ化
例えば、以下のような組み合わせでコンテナを動かしたい場合：
【Webアプリケーションの例】
┌─────────────────────────┐
│ Pod │
│ ┌─────────┐ ┌─────────┐│
│ │Webサーバー│ │ログ収集 ││
│ │コンテナ │ │コンテナ ││
│ └─────────┘ └─────────┘│
│ 共有ボリューム（ログファイル） │
└─────────────────────────┘Webサーバーコンテナとログ収集コンテナが同じファイルシステムを共有する必要がある場合、Podにまとめることで簡単に実現できます。
2. ネットワークの共有
同じPod内のコンテナは：
- 同じIPアドレスを持つ
- localhostで相互通信できる
- ポート番号だけで区別される
Podの実例とイラスト解説
実際のPodの定義をYAMLファイルで見てみましょう：
apiVersion: v1
kind: Pod
metadata:
name: webapp-pod
spec:
containers:
- name: web-container
image: nginx:1.20
ports:
- containerPort: 80
- name: log-container
image: busybox
command: ["sh", "-c", "tail -f /var/log/nginx/access.log"]
volumeMounts:
- name: log-volume
mountPath: /var/log/nginx
volumes:
- name: log-volume
emptyDir: {}この例では：
- nginx Webサーバーコンテナ
- ログを監視するbusyboxコンテナ
- 2つのコンテナが共有するボリューム
が1つのPodとして定義されています。
Podのライフサイクル
Podは以下の状態を持ちます：
- Pending: スケジューリング待ち
- Running: 実行中
- Succeeded: 正常終了
- Failed: 異常終了
- Unknown: 状態不明
重要なのは、Podは基本的に一時的な存在だということです。ノードの障害やリソース不足で簡単に削除・再作成されます。
Deploymentによるアプリケーション管理
Deploymentとは
「Podが一時的なら、どうやって継続的にアプリケーションを動かすの？」
その答えが Deployment です！
Deploymentは：
- Podの定義（テンプレート）を管理
- 指定した数のPodレプリカを維持
- ローリングアップデートを実行
- ロールバック機能を提供
PodとDeploymentの関係
関係性をイラストで表現すると：
【Deploymentの仕組み】
┌─────────────────────────────────────┐
│ Deployment │
│ ┌─────────────────────────────────┐│
│ │ ReplicaSet ││
│ │ ┌─────┐ ┌─────┐ ┌─────┐ ││
│ │ │Pod1 │ │Pod2 │ │Pod3 │ ... ││
│ │ └─────┘ └─────┘ └─────┘ ││
│ └─────────────────────────────────┘│
└─────────────────────────────────────┘
│
▼ 管理・制御
┌─────────┐
│実際の │
│Podたち │
└─────────┘Deploymentが実際にPodを直接管理するのではなく、間にReplicaSetという仕組みが存在します。
スケーリングと更新戦略
自動スケーリング
レプリカ数を変更するだけで、簡単にスケーリングできます：
# レプリカ数を5に変更
kubectl scale deployment webapp-deployment --replicas=5
# 現在のPod数を確認
kubectl get podsローリングアップデート
アプリケーションを無停止で更新する仕組み：
【ローリングアップデートの流れ】
Step1: 新バージョンのPodを1つ作成
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│旧v1 │ │旧v1 │ │旧v1 │ │新v2 │
└─────┘ └─────┘ └─────┘ └─────┘
Step2: 旧バージョンのPodを1つ削除
┌─────┐ ┌─────┐ ┌─────┐
│旧v1 │ │旧v1 │ │新v2 │
└─────┘ └─────┘ └─────┘
Step3: 繰り返し...
┌─────┐ ┌─────┐
│旧v1 │ │新v2 │
└─────┘ └─────┘
Step4: 完了
┌─────┐ ┌─────┐ ┌─────┐
│新v2 │ │新v2 │ │新v2 │
└─────┘ └─────┘ └─────┘Deploymentの定義例
実際のDeploymentのYAMLファイル：
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp-deployment
spec:
replicas: 3
selector:
matchLabels:
app: webapp
template:
metadata:
labels:
app: webapp
spec:
containers:
- name: webapp-container
image: nginx:1.20
ports:
- containerPort: 80
resources:
limits:
cpu: 100m
memory: 128Mi
requests:
cpu: 50m
memory: 64MiこのDeploymentは：
- nginx:1.20のイメージを使用
- 3つのレプリカを維持
- CPUとメモリのリソース制限を設定
実践！PodとDeploymentの使い分け
具体的な使用シーン
Podを直接使う場合
以下のような場面では、Podを直接作成することがあります：
- デバッグやテスト目的
kubectl run debug-pod --image=busybox -it --rm -- /bin/sh- 一回限りのジョブ実行
kubectl run backup-job --image=postgres --restart=Never -- pg_dump ...- 開発環境での動作確認
kubectl run test-app --image=myapp:latestDeploymentを使う場合（推奨）
本番環境では基本的にDeploymentを使用します：
- Webアプリケーション
- 高可用性が必要
- スケーリングが必要
- ローリングアップデートが必要
- APIサーバー
- 複数のレプリカで負荷分散
- 障害時の自動復旧
- バックグラウンドワーカー
- 処理量に応じたスケーリング
- プロセスの監視と復旧
ベストプラクティス
1. リソース制限の設定
常にCPUとメモリの制限を設定しましょう：
resources:
limits:
cpu: 500m # 0.5 CPU core
memory: 512Mi # 512 MiB
requests:
cpu: 250m # 最低限必要なCPU
memory: 256Mi # 最低限必要なメモリ2. ヘルスチェックの実装
アプリケーションの健康状態を監視：
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 53. 適切なラベル付け
管理しやすいようにラベルを設定：
metadata:
labels:
app: webapp
version: "1.0"
environment: production
team: backendよくある疑問への回答
Q: PodとDeploymentの違いって結局何？
A: Podは「実際に動くコンテナのセット」、Deploymentは「Podの管理者」です。Podは一時的で手動管理が大変ですが、Deploymentは自動でPodを管理してくれる頼もしい存在です！
Q: レプリカ数はどうやって決めればいい？
A: まずは小さく始めましょう。CPU使用率が70-80%を超えるようならスケールアップ、リクエスト処理が遅くなるようならスケールアウトを検討します。
Q: 1つのPodに複数コンテナを入れるべき？
A: 基本的には1Pod = 1コンテナが推奨です。複数コンテナを入れるのは、密接に連携する必要がある場合（サイドカーパターンなど）のみにしましょう。
さらに学習を深めるために
KubernetesのPodとDeploymentについて理解が深まりましたか？
今回解説した内容は、Kubernetesの基礎中の基礎です。実際にKubernetesを活用するには、さらに以下のような概念を学ぶ必要があります：
- Service: Podへの通信経路を提供
- ConfigMap/Secret: 設定情報の管理
- Ingress: 外部からのアクセス制御
- Namespace: リソースの論理分割
- Volume: データの永続化
これらの概念について詳しく学びたい方には、今回参考にした「［改訂新版］イラストでわかるDockerとKubernetes」がとてもおすすめです！
この書籍では：
- イラストでの視覚的解説で理解しやすい
- 実際の設定例が豊富で実践的
- コンテナランタイムの仕組みまで深く学べる
- 最新の技術動向に対応（2024年3月発行）
著者の徳永航平さんは、CNCF containerdのレビュワーやMobyプロジェクトのBuildKitメンテナを務める現役エンジニア。現場での実践経験に基づいた解説は、きっと皆さんの学習に役立つはずです。
Kubernetesは確かに複雑ですが、基礎をしっかり理解することで、必ず使いこなせるようになります。今回学んだPodとDeploymentの概念を土台に、ぜひ実際にKubernetesクラスタを触ってみてください！
次回は、コンテナランタイムやnamespace、cgroupといった、より深いレベルの仕組みについて解説予定です。お楽しみに！
コメント