Kubernetes入門 Part 2: 運用編
今回は、Kubernetsを触ってみようのPart2:運用編をやってみます。
目次
スケーリング
負荷に応じてPod数を増減し、高可用性の確保・リソースの効率的な利用をする。
# レプリカ数を5に増やす
kubectl scale deployment web-app-deployment --replicas=5
# 出力例:
# deployment.apps/web-app-deployment scaled
# Podの状態を確認
kubectl get pods
# 出力例:
# NAME READY STATUS RESTARTS AGE
# web-app-deployment-abc123-xxxxx 1/1 Running 0 5m
# web-app-deployment-abc123-yyyyy 1/1 Running 0 5m
# web-app-deployment-abc123-zzzzz 1/1 Running 0 5m
# web-app-deployment-abc123-aaaaa 1/1 Running 0 10s
# web-app-deployment-abc123-bbbbb 1/1 Running 0 10s
# レプリカ数を2に減らす
kubectl scale deployment web-app-deployment --replicas=2

増減している。古いものが残るようだ。安定稼働だから?
IBM Bobによると、kubectl get podsで表示されているNAMEの構成は以下。Pod名が示されているが、Pod名にReplicaSet IDが入っている。このReplicaSet IDについては次のローリングアップデートで。
web-app-deployment-6cf976454-dzq4s
└──────┬─────────┘└────┬────┘└─┬─┘
│ │ └─ ランダムID(Pod識別)
│ └─ ReplicaSet ID
└─ Deployment名
ローリングアップデート
サービスを止めずに、少しずつPodを新しいバージョンに置き換える。
ローリングアップデート時は新旧2つのReplicaSetが存在し、新しいReplicaSetが起動すると古いものが削除される。
ReplicaSetは、Deploymentが管理する中間レイヤー。Deploymentが目標のPod数を指定すると、ReplicaSetが実際にPodを作成・管理する。
# イメージを更新
docker build -t web-app:v2 .
# Deploymentを更新
kubectl set image deployment/web-app-deployment web-app=web-app:v2
# ロールアウトの状態を確認
kubectl rollout status deployment/web-app-deployment
# 出力例:
# Waiting for deployment "web-app-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
# Waiting for deployment "web-app-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
# Waiting for deployment "web-app-deployment" rollout to finish: 1 old replicas are pending termination...
# deployment "web-app-deployment" successfully rolled out
# ロールアウト履歴を確認
kubectl rollout history deployment/web-app-deployment
# 前のバージョンにロールバック
kubectl rollout undo deployment/web-app-deployment

今回はちょっと原因わからずロールアウトできませんでした。。。が、
失敗したときにpod数が増えていたことから、ローリングアップデートでは更新時に新しいPodを作成し、作成完了したら古いものを削除しているという動きは理解できました。

roll backしたら、Podの数2個に戻った。
ログとデバッグ
ログの確認
# 特定のPodのログを表示
kubectl logs web-app-deployment-abc123-xxxxx
# リアルタイムでログを表示
kubectl logs -f web-app-deployment-abc123-xxxxx
# 全てのPodのログを表示
kubectl logs -l app=web-app
Podの詳細情報
# Podの詳細情報を表示
kubectl describe pod web-app-deployment-abc123-xxxxx
# 出力内容:
# - Podの状態
# - イベント履歴
# - リソース使用状況
# - エラーメッセージ
Podとは=Pod = Kubernetesで実行される最小単位のコンテナグループということを理解した上で、その詳細を見ていきたいと思います。
Podの概念図

Podの中に複数のコンテナがあり、それらのコンテナが共有リソース(共有ネットワークやストレージ)を持つ。
hinanokawahori@HinanoKawahorinoMacBook-Air web-app-comparison % kubectl describe pod web-app-deployment-6cf976454-dzq4s
# 基本情報
Name: web-app-deployment-6cf976454-dzq4s
Namespace: default
Priority: 0
Service Account: default
Node: minikube/192.168.49.2
Start Time: Mon, 12 Jan 2026 07:43:49 +0900
# ラベル(サービスがこのラベルを用いてPodを見つける)
Labels: app=web-app
pod-template-hash=6cf976454
Annotations: <none>
Status: Running
IP: 10.244.0.14
IPs:
IP: 10.244.0.14
Controlled By: ReplicaSet/web-app-deployment-6cf976454
# コンテナ情報
Containers:
web-app:
Container ID: docker://7ef0ca2b04d0432e3b5e268bd90e856b9cf23d418a155eac87d992b456e923c5
Image: web-app:latest
Image ID: docker://sha256:7137ba8d4fd871e4cc7c24bbe6dede10e4a9542b86a406925ad0202afdbaf843
Port: 3000/TCP
Host Port: 0/TCP
State: Running
Started: Mon, 12 Jan 2026 07:43:49 +0900
Ready: True
Restart Count: 0
# リソース制限(コンテナが使用できる最大値。超えると強制終了)
Limits:
cpu: 200m
memory: 256Mi
#リクエスト(kubernetesがこの量を予約する、スケジューリング時の判断基準)
Requests:
cpu: 100m
memory: 128Mi
# ヘルスチェック
Liveness: http-get http://:3000/api/status delay=10s timeout=1s period=10s #success=1 #failure=3
Readiness: http-get http://:3000/api/status delay=5s timeout=1s period=5s #success=1 #failure=3
Environment:
NODE_ENV: production
PORT: 3000
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-kdgb6 (ro)
# Podの状態(Conditions)
Conditions:
Type Status
PodReadyToStartContainers True
Initialized True
Ready True
ContainersReady True
PodScheduled True
# ボリューム
Volumes:
kube-api-access-kdgb6:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
Optional: false
DownwardAPI: true
# QoS(Quality of Service):どれだけPodの生存が保証されるか。
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
# イベント
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 49m default-scheduler Successfully assigned default/web-app-deployment-6cf976454-dzq4s to minikube
Normal Pulled 49m kubelet spec.containers{web-app}: Container image "web-app:latest" already present on machine
Normal Created 49m kubelet spec.containers{web-app}: Created container: web-app
Normal Started 49m kubelet spec.containers{web-app}: Started container web-app
hinanokawahori@HinanoKawahorinoMacBook-Air web-app-comparison %
defaultのnamespaceに配置されたpodで、正常稼働していることが確認できた。
Pod内でコマンドを実行
# Pod内でシェルを起動
kubectl exec -it web-app-deployment-abc123-xxxxx -- sh
# Pod内で
ls -la
ps aux
exit
シェルを起動すると、app配下のファイルがずらっと出てきました。不要なファイルも含まれていたので、.dockerignoreで最小限のファイルのみ含めるようコードを編集した方が良さそうです。
クリーンアップ
リソースの削除
### リソースの削除
# Deploymentを削除
kubectl delete deployment web-app-deployment
# Serviceを削除
kubectl delete service web-app-service
# または全て削除
kubectl delete -f k8s/
### Minikubeの停止・削除
# Minikubeを停止
minikube stop
# 出力例:
# ✋ Stopping node "minikube" ...
# 🛑 Powering off "minikube" via SSH ...
# 🛑 1 node stopped.
# Minikubeを削除
minikube delete
# 出力例:
# 🔥 Deleting "minikube" in docker ...
# 🔥 Deleting container "minikube" ...
# 🔥 Removing /Users/username/.minikube/machines/minikube ...
# 💀 Removed all traces of the "minikube" cluster.
# または、いきなりクラスター削除
minikube delete
まとめ

Namespace, ReplicaSet, Podについての理解が深められました。
- Namespaceは、リソースを目的ごとにまとめた論理的グループ
- ReplicaSetは、Deploymentが指定したPod数を維持する中間レイヤー
- Podは、k8sの最小実行単位。Pod内の複数コンテナはネットワークなどの共通リソースを共有する