2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Kubernetes入門 Part 2: 運用編

今回は、Kubernetsを触ってみようのPart2:運用編をやってみます。

目次

  1. スケーリング
  2. ローリングアップデート
  3. ログとデバッグ
  4. クリーンアップ
  5. まとめ

スケーリング

負荷に応じて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

スクリーンショット 2026-01-12 8.21.53.png
増減している。古いものが残るようだ。安定稼働だから?
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

スクリーンショット 2026-01-12 8.29.53.png
今回はちょっと原因わからずロールアウトできませんでした。。。が、
失敗したときにpod数が増えていたことから、ローリングアップデートでは更新時に新しいPodを作成し、作成完了したら古いものを削除しているという動きは理解できました。
スクリーンショット 2026-01-12 8.31.30.png
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の概念図
スクリーンショット 2026-01-12 8.39.45.png
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

まとめ

スクリーンショット 2026-01-12 9.05.55.png
Namespace, ReplicaSet, Podについての理解が深められました。

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?