Kubernetesにおけるローリングアップデートとロールバック

Deploymentを使用する利点の1つは、ローリングアップデートを実行し、rollingupdatestrategyを作成する能力です。ローリングアップデートにより、ポッドの構成を徐々に更新できます。

更新戦略（k8s rollingupdate、k8s update strategy）は、ローリングアップデートを構成するための最も重要なオプションです。Deployment定義では、spec.strategy.typeには2つの可能な値があります：

• RollingUpdate: 新しいポッドが徐々に追加され、古いポッドが徐々に終了します。
• Recreate: 新しいポッドが追加される前に、すべての古いポッドが一度に終了します。

RollingUpdateを使用してデプロイメントを更新する際に、さらに2つのオプションがあります。

• maxSurge: 更新中に希望するポッド数を超えて作成できるポッドの数。
• maxUnavailable: 更新プロセス中に利用できないポッドの数。

デプロイメントのローリングアップデートを使用することで、デプロイメントで使用されるイメージをアップグレードできます。デプロイメントの状態（kubectl rollout status）が保存されているため、デプロイメントの以前のバージョンにロールバックできます。

アプリケーションが不正なイメージや不安定なデプロイメントのために失敗した場合、デプロイメントをロールバックしたい場合があります（k8s rollback）。デフォルトでは、すべてのデプロイメントのロールアウト履歴がシステムに保持されており、これは不安定なデプロイメントの場合にロールバックに使用できます。この履歴を使用して、いつでもロールバックできます。

ローリングアップデートとロールバックについて詳しく知りたい場合は、こちらのKubernetesの公式ドキュメントを訪れてください。

この記事では、デフォルトのローリングアップデート戦略でデプロイメントを更新し、デプロイメントをロールバックします。デプロイメントをロールバックするために、デプロイメントの更新の1つで不正なイメージを使用します。

前提条件

1. 1つ以上のワーカーノードを持つKubernetesクラスター。
   Kubernetesクラスターの作成方法を学びたい場合は、こちらをクリックしてください。このガイドでは、AWS Ubuntu 18.04 EC2インスタンス上に1つのマスターと2つのノードを持つKubernetesクラスターを作成する方法を説明します。

何をしますか？

1. ローリングアップデートとロールバック

ローリングアップデートとロールバック

デプロイメントのポッドテンプレートを持つNginxのデプロイメント定義ファイルを作成します。この中で、Nginxのバージョンを「nginx:1.14.2」と指定しました。

vim my-deployment.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-demo
  labels:
    app: nginx
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

既存のポッドを確認し、デプロイメントを作成しましょう。

kubectl get pods

kubectl create -f my-deployment.yml

作成したデプロイメントの詳細を取得します。このデプロイメントは4つのポッドを作成し、レプリカセットによって制御されています。

kubectl get deployments

kubectl get pods

kubectl get replicaset

上のスクリーンショットでは、1つのデプロイメントの下に1つのレプリカセットと4つのポッドがレプリカセットによって制御されていることがわかります。

次に、Nginxのバージョンを「nginx:1.14.2」から「nginx:1.61.1」に変更しましょう。

vim my-deployment.yml

デプロイメントに変更を適用し、ポッド、レプリカセット、デプロイメントの詳細を取得します。

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

kubectl get replicaset

上のスクリーンショットでは、新しいレプリカセットが作成され、その下に4つのポッドがあることがわかります。しかし、古いレプリカセットは0ポッドのままです。

次に、Nginxのバージョンを再度変更しますが、今度は不正なNginxバージョンを指定します。この場合、デプロイメントは失敗します。なぜなら、不正なバージョンのNginxイメージは存在しないからです。

vim my-deployment.yml

デプロイメントに変更を適用しましょう。

kubectl apply -f my-deployment.yml

kubectl get pods

kubectl get deployments

レプリカセットの詳細を取得してみましょう。

kubectl get replicaset

上のスクリーンショットでは、新しいポッドが「ErrImagePull」エラーで失敗していることがわかります。ポッドは、バージョン「ngin:1.1.1」のNginxイメージが存在しないために失敗しています。

以前の作動していたイメージに戻りたい場合、ロールアウトステータスが正常でない場合は、以前のリビジョンにロールバックできます。

ロールバックするには、まず次のコマンドを使用してデプロイメントのロールアウト履歴を取得します。

kubectl rollout history deployments rolling-update-demo

次に、次のコマンドを使用して「–revision=2」の詳細を確認できます。

kubectl rollout history deployments rolling-update-demo --revision=2

上のスクリーンショットでは、リビジョン2には「nginx:1.16.1」のNginxイメージバージョンがあり、これは「ngin:1.1.1」に更新する前に作動していたことがわかります。

次に、現在の失敗したデプロイメントの前のリビジョンにデプロイメントをロールバックしましょう。

kubectl get deployments

kubectl rollout undo deployment rolling-update-demo

kubectl get pods

kubectl get replicaset

上のスクリーンショットでは、最新のデプロイメントが元に戻され、最後の更新の前に作動していたデプロイメントのリビジョンがあることがわかります。

デプロイメントの詳細を知りたい場合は、次のコマンドを使用して説明できます。

kubectl get deployments

kubectl describe deployment rolling-update-demo

結論

この記事では、デプロイメントを作成し、更新する手順を見ました。デプロイメントが何らかの理由で失敗した場合、ロールバックできる方法を見ました。ここで、失敗したデプロイメントのエラーは「ErrImagePull」でした。デプロイメントが最新の更新を保持したくない場合に、ロールバックできるリビジョンを保持していることを確認しました。