はじめに
この実験では、Kubernetes クラスタに展開されたアプリケーションを更新およびロールバックする方法を学びます。まず、Minikube を使ってローカルの Kubernetes クラスタをセットアップし、次にサンプルの NGINX アプリケーションを展開します。次に、アプリケーションのイメージを更新し、正常な更新を確認します。更新エラーをシミュレートするために、問題を診断してから安定したバージョンにロールバックします。最後に、Deployment YAML ファイルのローリング更新戦略を調整します。
Kubernetes クラスタを起動する
このステップでは、Minikube を使ってローカルの Kubernetes クラスタを起動して検証する方法を学びます。これは、Kubernetes 開発環境をセットアップするための重要な最初のステップです。
まず、プロジェクトディレクトリにいることを確認します。
cd ~/project
Minikube クラスタを起動します。
minikube start
出力例：
😄 minikube v1.29.0 on Ubuntu 22.04
✨ Automatically selected the docker driver
📌 Using Docker driver with root permissions
🔥 Creating kubernetes in kubernetes cluster
🔄 Restarting existing kubernetes cluster
🐳 Preparing Kubernetes v1.26.1 on Docker 20.10.23...
🚀 Launching Kubernetes...
🌟 Enabling addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace
クラスタの状態を検証します。
minikube status
出力例：
minikube
type: Control Plane
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured
クラスタのノードを確認します。
kubectl get nodes
出力例：
NAME STATUS ROLES AGE VERSION
minikube Ready control-plane 1m v1.26.1
このステップのポイント：
minikube startは、ローカルの単一ノード Kubernetes クラスタを作成します。- クラスタはデフォルトのドライバとして Docker を使用します。
- Kubernetes v1.26.1 が自動的に構成されます。
minikube statusとkubectl get nodesでクラスタの準備状態を確認できます。
サンプルアプリケーションを展開する
このステップでは、Kubernetes Deployment を使って単純な Web アプリケーションを作成して展開する方法を学びます。展開プロセスを示すために、サンプルアプリケーションとして NGINX イメージを使用します。
まず、プロジェクトディレクトリに移動します。
cd ~/project
mkdir -p k8s-manifests
cd k8s-manifests
Web アプリケーション用の新しい展開マニフェストを作成します。
nano nginx-deployment.yaml
ファイルに以下の内容を追加します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.23.3-alpine
ports:
- containerPort: 80
ファイルを保存して nano エディタを終了します。
kubectl を使ってアプリケーションを展開します。
kubectl apply -f nginx-deployment.yaml
出力例：
deployment.apps/web-app created
展開を検証します。
kubectl get deployments
出力例：
NAME READY UP-TO-DATE AVAILABLE AGE
web-app 3/3 3 3 30s
作成されたポッドを確認します。
kubectl get pods -l app=web
出力例：
NAME READY STATUS RESTARTS AGE
web-app-xxx-yyy 1/1 Running 0 45s
web-app-xxx-zzz 1/1 Running 0 45s
web-app-xxx-www 1/1 Running 0 45s
この展開のポイント：
- NGINX Web サーバーの 3 つのレプリカを持つ Deployment を作成しました。
- 特定の安定したバージョンの NGINX（1.23.3-alpine）を使用しました。
- コンテナポート 80 を公開しました。
- ポッドを識別および管理するためにラベルを使用しました。
展開 YAML 内のアプリケーションイメージを更新する
このステップでは、Kubernetes Deployment 内のコンテナイメージを更新する方法を学びます。これは、現実世界のアプリケーションのアップグレードシナリオをシミュレートします。
まず、正しいディレクトリにいることを確認します。
cd ~/project/k8s-manifests
既存の展開マニフェストを開きます。
nano nginx-deployment.yaml
イメージを nginx:1.23.3-alpine から更新されたバージョンに更新します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.24.0-alpine
ports:
- containerPort: 80
更新された展開を適用します。
kubectl apply -f nginx-deployment.yaml
出力例：
deployment.apps/web-app configured
展開の更新プロセスを監視します。
kubectl rollout status deployment web-app
出力例：
Waiting for deployment "web-app" to roll out...
Waiting for deployment spec update to be applied...
Waiting for available replicas to reach desired number...
deployment "web-app" successfully rolled out
新しいイメージバージョンを検証します。
kubectl get pods -l app=web -o jsonpath='{.items[*].spec.containers[0].image}'
出力例：
nginx:1.24.0-alpine nginx:1.24.0-alpine nginx:1.24.0-alpine
イメージ更新に関するポイント：
kubectl applyを使って展開を更新します。- Kubernetes はデフォルトでローリング更新を行います。
- アプリケーションの可用性を維持するために、徐々にポッドが置き換えられます。
- 更新プロセスはゼロダウンタイムの展開を保証します。
正常な更新を確認する
このステップでは、ポッドのバージョン、状態、および追加の展開詳細を調べることで、Kubernetes 展開の正常な更新を検証する方法を学びます。
まず、詳細情報付きでポッドを一覧表示します。
kubectl get pods -l app=web -o wide
出力例：
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
web-app-xxx-yyy 1/1 Running 0 3m 10.244.0.5 minikube <none> <none>
web-app-xxx-zzz 1/1 Running 0 3m 10.244.0.6 minikube <none> <none>
web-app-xxx-www 1/1 Running 0 3m 10.244.0.7 minikube <none> <none>
ポッドの特定のイメージバージョンを確認します。
kubectl get pods -l app=web -o jsonpath='{range.items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
出力例：
web-app-xxx-yyy nginx:1.24.0-alpine
web-app-xxx-zzz nginx:1.24.0-alpine
web-app-xxx-www nginx:1.24.0-alpine
展開の詳細情報を取得するために、展開を記述します。
kubectl describe deployment web-app
出力例：
Name: web-app
Namespace: default
CreationTimestamp: [現在のタイムスタンプ]
Labels: app=web
Annotations: deployment.kubernetes.io/revision: 2
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=web
Containers:
nginx:
Image: nginx:1.24.0-alpine
Port: 80/TCP
Host Port: 0/TCP
Environment: <none>
Mounts: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
展開履歴を検証します。
kubectl rollout history deployment web-app
出力例：
REVISION CHANGE-CAUSE
1 <none>
2 <none>
検証に関するポイント：
- すべてのポッドが新しいイメージバージョンを実行しています。
- 展開には 3 つの利用可能なレプリカがあります。
- ローリングアウト戦略はゼロダウンタイムの更新を保証します。
- 展開のリビジョンが増加しています。
更新失敗をシミュレートして診断する
このステップでは、問題のあるイメージ更新をシミュレートし、Kubernetes の診断ツールを使用して、潜在的な展開更新の失敗を診断する方法を学びます。
まず、プロジェクトディレクトリに移動します。
cd ~/project/k8s-manifests
無効なイメージを持つ展開マニフェストを作成します。
nano problematic-deployment.yaml
以下の内容を追加します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: troubleshoot-app
labels:
app: troubleshoot
spec:
replicas: 3
selector:
matchLabels:
app: troubleshoot
template:
metadata:
labels:
app: troubleshoot
spec:
containers:
- name: nginx
image: nginx:non-existent-tag
ports:
- containerPort: 80
問題のある展開を適用します。
kubectl apply -f problematic-deployment.yaml
出力例：
deployment.apps/troubleshoot-app created
展開の状態を確認します。
kubectl rollout status deployment troubleshoot-app
出力例：
Waiting for deployment "troubleshoot-app" to roll out...
Ctrl+C を押して展開状態を終了します。
ポッドのイベントと状態を確認します。
kubectl get pods -l app=troubleshoot
出力例：
NAME READY STATUS RESTARTS AGE
troubleshoot-app-6b8986c555-gcjj9 0/1 ImagePullBackOff 0 2m56s
troubleshoot-app-6b8986c555-p29dp 0/1 ImagePullBackOff 0 2m56s
troubleshoot-app-6b8986c555-vpv5q 0/1 ImagePullBackOff 0 2m56s
ポッドの詳細とログを調べます。
## 'xxx-yyy'を実際のポッド名に置き換えてください
POD_NAME=$(kubectl get pods -l app=troubleshoot -o jsonpath='{.items[0].metadata.name}')
kubectl describe pod $POD_NAME
kubectl logs $POD_NAME
イメージのプルに失敗していることを示すポッドの状態とログが表示されます。
Failed to pull image "nginx:non-existent-tag"
イメージを修正して問題を解決します。
nano problematic-deployment.yaml
イメージを有効なタグに更新します。
image: nginx:1.24.0-alpine
修正された展開を再適用します。
kubectl apply -f problematic-deployment.yaml
再度ポッドの状態を確認します。
kubectl get pods -l app=troubleshoot
出力例：
NAME READY STATUS RESTARTS AGE
troubleshoot-app-5dc9b58d57-bvqbr 1/1 Running 0 5s
troubleshoot-app-5dc9b58d57-tdksb 1/1 Running 0 8s
troubleshoot-app-5dc9b58d57-xdq5n 1/1 Running 0 6s
失敗の診断に関するポイント：
kubectl describeを使用して展開とポッドのイベントを表示します。ImagePullBackOffやその他のエラー状態をポッドの状態で確認します。- 詳細なエラー情報を取得するためにポッドのログを調べます。
- イメージの可用性とタグの正確性を確認します。
安定したバージョンにロールバックする
このステップでは、kubectl rollout undo コマンドを使用して、Kubernetes 展開を以前の安定したバージョンにロールバックする方法を学びます。
まず、プロジェクトディレクトリに移動します。
cd ~/project/k8s-manifests
Web アプリケーションの展開履歴を確認します。
kubectl rollout history deployment web-app
出力例：
REVISION CHANGE-CAUSE
1 <none>
2 <none>
現在の展開の詳細を確認します。
kubectl describe deployment web-app | grep Image
出力例：
Image: nginx:1.24.0-alpine
前のリビジョンにロールバックします。
kubectl rollout undo deployment web-app
出力例：
deployment.apps/web-app rolled back
ロールバックを確認します。
kubectl rollout status deployment web-app
出力例：
Waiting for deployment "web-app" to roll out...
deployment "web-app" successfully rolled out
更新されたイメージバージョンを確認します。
kubectl get pods -l app=web -o jsonpath='{range.items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\n"}{end}'
出力例：
web-app-xxx-yyy nginx:1.23.3-alpine
web-app-xxx-zzz nginx:1.23.3-alpine
web-app-xxx-www nginx:1.23.3-alpine
展開履歴を確認します。
kubectl rollout history deployment web-app
出力例：
REVISION CHANGE-CAUSE
2 <none>
3 <none>
ロールバックに関するポイント：
kubectl rollout undoは前の展開リビジョンに戻します。- Kubernetes は展開の変更履歴を保持します。
- ロールバックはゼロダウンタイムで実行されます。
- ロールバックにより履歴に新しいリビジョンが作成されます。
展開 YAML 内のローリング更新戦略を調整する
このステップでは、Kubernetes 展開においてローリングアップデート戦略をカスタマイズして、アプリケーションがどのように更新およびスケーリングされるかを制御する方法を学びます。
まず、プロジェクトディレクトリに移動します。
cd ~/project/k8s-manifests
カスタムローリングアップデート戦略を持つ新しい展開マニフェストを作成します。
nano custom-rollout-deployment.yaml
以下の内容を追加します。
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app-custom-rollout
labels:
app: web
spec:
replicas: 5
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 2
maxSurge: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.24.0-alpine
ports:
- containerPort: 80
展開を適用します。
kubectl apply -f custom-rollout-deployment.yaml
出力例：
deployment.apps/web-app-custom-rollout created
展開の状態を確認します。
kubectl rollout status deployment web-app-custom-rollout
出力例：
Waiting for deployment "web-app-custom-rollout" to roll out...
deployment "web-app-custom-rollout" successfully rolled out
展開を記述して戦略を確認します。
kubectl describe deployment web-app-custom-rollout
出力例には以下が含まれます。
StrategyType: RollingUpdate
RollingUpdateStrategy: 2 max unavailable, 3 max surge
イメージを更新してローリングアップデートをトリガーします。
kubectl set image deployment/web-app-custom-rollout nginx=nginx:1.25.0-alpine
更新プロセスを監視します。
kubectl rollout status deployment web-app-custom-rollout
ローリングアップデート戦略に関するポイント：
maxUnavailable：更新中に利用できなくなることができるポッドの最大数maxSurge：必要な数を超えて作成できるポッドの最大数- 更新速度とアプリケーションの可用性を制御するのに役立ちます
- 展開の動作を微調整できます
まとめ
この実験では、Kubernetes の開発環境をセットアップする上で重要な最初のステップである Minikube を使用して、ローカルの Kubernetes クラスタを起動して検証する方法を学びました。また、サンプルアプリケーションとして NGINX イメージを使用して、Kubernetes Deployment を使って単純な Web アプリケーションを作成して展開する方法も学びました。展開プロセスには、展開マニフェストファイルを作成してクラスタに適用する作業が含まれていました。
アプリケーションの初期バージョンを展開した後、展開 YAML 内のアプリケーションイメージを更新する方法、更新の成功を検証する方法、更新の失敗をシミュレートして診断する方法、安定したバージョンにロールバックする方法、および展開 YAML 内のローリングアップデート戦略を調整する方法を学びます。
