Day 17: Pod, ReplicaSet, Deployment：Kubernetesの基本リソースを使いこなす 🚀
皆さん、こんにちは！30日集中講座、Day 17へようこそ。
昨日は、eksctlとkubectlを使い、EKSクラスターを構築しました。これで、いよいよKubernetesの世界に足を踏み入れる準備が整いました。
今日からはいよいよkubectlを本格的に使い始め、Kubernetesの最も基本的なリソースであるPod、ReplicaSet、そしてDeploymentについて学びます。これらのリソースは、ECSの「タスク」や「サービス」に相当するものですが、より柔軟で強力な機能を持っています。
今日の学習目標 🎯
- Podを作成し、その一時的な性質を理解する。
- ReplicaSetによる自動復旧機能を体験する。
- Deploymentでローリングアップデートを実行する。
- 本番運用で考慮すべきポイントを理解する。
1. Kubernetesの最小単位：Pod 📦
Podは、Kubernetesで実行されるコンテナの最小単位です。Podは、1つまたは複数のコンテナを密接に連携させて実行するためのグループです。Pod内のコンテナは、IPアドレスやストレージを共有するため、連携が非常にスムーズです。
実際に試してみましょう！Podの作成
Podを直接作成するのは学習用に限られます。本番運用ではDeploymentなどの上位リソースを通じて管理しましょう。
# pod.yamlファイルを作成
cat > pod.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
name: my-nginx-pod
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx:1.21-alpine
ports:
- containerPort: 80
EOF
# Podを作成
kubectl apply -f pod.yaml
# Podの状態を確認
kubectl get pods
# Podを削除
kubectl delete pod my-nginx-pod
✅ 理解度チェック: Podを削除すると自動で再起動されないことを確認できましたか？
2. Podを管理するReplicaSet 👯
ReplicaSetは、指定された数のPodが常に稼働していることを保証するリソースです。Podがダウンした場合、ReplicaSetは自動で新しいPodを起動し、指定されたレプリカ数を維持します。
ReplicaSetの動作を体験
# replicaset.yamlファイルを作成
cat > replicaset.yaml << EOF
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-nginx-replicaset
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx:1.21-alpine
ports:
- containerPort: 80
EOF
# ReplicaSetを作成
kubectl apply -f replicaset.yaml
# Podを1つ削除して自動復旧を確認
kubectl get pods -l app=nginx # 3つのPodが稼働していることを確認
kubectl delete pod [表示されたPod名の1つ]
kubectl get pods -w # 新しいPodが自動作成されることを観察
✅ 理解度チェック: Podを削除した際、自動で新しいPodが作成されることを確認できましたか？
3. Kubernetesの心臓部：Deployment ❤️
Deploymentは、Kubernetesでのアプリケーション運用において最も重要なリソースです。Deploymentは、ReplicaSetとPodを抽象化し、デプロイメントのライフサイクル全体を管理します。
ローリングアップデートを実際に体験
# deployment.yamlファイルを作成
cat > deployment.yaml << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx-container
image: nginx:1.21-alpine
ports:
- containerPort: 80
EOF
# Deploymentを作成
kubectl apply -f deployment.yaml
# 別ターミナルでPodを監視
kubectl get pods -l app=nginx -w
# イメージを更新し、ローリングアップデートを開始
kubectl set image deployment/my-nginx-deployment nginx-container=nginx:1.22-alpine
# Podが段階的に入れ替わる様子を観察
kubectl rollout status deployment/my-nginx-deployment
✅ 理解度チェック: Deploymentでローリングアップデートの様子を観察できましたか？
4. まとめ：3つのリソースの使い分け
| リソース | 役割 | 特徴 | ECSとの対応 |
|---|---|---|---|
| Pod | コンテナの最小実行単位 | 一時的、手動管理 | タスク |
| ReplicaSet | Pod数の維持 | 自動復旧、スケーリング | サービス（基本機能） |
| Deployment | アプリケーションのデプロイ管理 | ローリングアップデート、ロールバック | サービス（高度な機能） |
補足: ECSの「サービス」とKubernetesの「Deployment」は似ていますが、完全な1対1対応ではありません。概念として近いものと考えてください。
5. 本番運用のポイント 💡
本番環境のYAMLファイルには、以下のような設定を追加して、信頼性とセキュリティを向上させます。
# 本番運用での実装例
apiVersion: apps/v1
kind: Deployment
metadata:
name: production-nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21-alpine
ports:
- containerPort: 80
resources: # リソース制限
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
readinessProbe: # 準備完了チェック
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe: # 生存チェック
httpGet:
path: /
port: 80
initialDelaySeconds: 15
periodSeconds: 20
securityContext: # セキュリティ設定
runAsNonRoot: true
runAsUser: 1000
readOnlyRootFilesystem: true
-
resources:requestsはリソース保証、limitsはリソース上限です。 -
livenessProbe/readinessProbe: ヘルスチェックによりPodの健全性をKubernetesに知らせます。readinessProbeが成功しないPodには、Serviceからトラフィックが流れないようにできます。 -
securityContext: 非rootユーザーでコンテナを実行するなどのセキュリティ設定です。
次回の予告
Day 18: ServiceとIngress：外部からアプリケーションにアクセスできるようにする
それでは、また明日お会いしましょう！