ローリングアップデートの実施

このページでは、Google Kubernetes Engine でアプリケーションのローリングアップデートを実行する方法について説明します。

概要

ローリングアップデートを実行すると、クラスタ内のワークロードのイメージ、構成、ラベル、アノテーション、リソース制限 / リクエストを更新できます。ローリングアップデートは、リソースのポッドを新しいものに段階的に置き換えてから、利用可能なリソースを持つノードでポッドをスケジューリングします。ローリングアップデートは、ダウンタイムなしにワークロードを更新するように設計されています。

次のオブジェクトが Kubernetes ワークロードを表します。これらのワークロードのポッドテンプレートを更新することで、ワークロードのローリング更新をトリガーできます。

DaemonSet
Deployment
StatefulSet

これらの各オブジェクトにはポッドテンプレートがあり、テンプレートはオブジェクトのマニフェスト内の spec: template フィールドによって示されます。ポッドテンプレートのフィールドには、望ましい状態や動作を実現するためにコントローラが作成するポッドの仕様が含まれています。オブジェクトの spec: template を更新すると、更新のロールアウトがトリガーされます。

ポッドテンプレートには、次のフィールドが含まれています。

ポッドテンプレートの詳細については、PodTemplateSpec のドキュメントをご覧ください。

ポッドテンプレート以外でリソースをスケーリングしたりフィールドを更新したりしても、ロールアウトはトリガーされません。

始める前に

作業を始める前に、次のことを確認してください。

Google Kubernetes Engine API が有効になっていることを確認します。

Google Kubernetes Engine API の有効化

Cloud SDK がインストール済みであることを確認します。

次のいずれかの方法で gcloud のデフォルトの設定を指定します。

gcloud init。デフォルトの設定全般を確認する場合に使用します。
gcloud config。プロジェクト ID、ゾーン、リージョンを個別に設定する場合に使用します。

gcloud init の使用

エラー One of [--zone, --region] must be supplied: Please specify location を受信した場合は、このセクションの内容を実施します。

gcloud init を実行して、次の操作を行います。
```
gcloud init
```
リモートサーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。
```
gcloud init --console-only
```
手順に従って gcloud を承認し、Google Cloud アカウントを使用します。
新しい構成を作成するか、既存の構成を選択します。
Google Cloud プロジェクトを選択します。
デフォルトの Compute Engine ゾーンを選択します。

注: これらのデフォルト設定は、gcloud コマンドで --project、--zone、--region フラグを使用することでオーバーライドできます。

gcloud config の使用

デフォルトのプロジェクト ID を設定します。
```
gcloud config set project project-id
```
ゾーンクラスタを使用する場合は、デフォルトのコンピューティングゾーンを設定します。
```
gcloud config set compute/zone compute-zone
```
リージョンクラスタを使用する場合は、デフォルトのコンピューティングリージョンを設定します。
```
gcloud config set compute/region compute-region
```
gcloud を最新バージョンに更新します。
```
gcloud components update
```

注: これらのデフォルト設定は、gcloud コマンドで --project、--zone、--region フラグを使用することでオーバーライドできます。

アプリケーションを更新する

次のセクションでは、Google Cloud Console または kubectl を使用してアプリケーションを更新する方法について説明します。

kubectl set

kubectl set を使用すると、オブジェクトの image、resources（CPU、メモリなどのコンピューティングリソース）または selector フィールドを変更できます。

たとえば、Deployment を nginx バージョン 1.7.9 から 1.9.1 に更新するには、次のコマンドを実行します。

kubectl set image deployment nginx nginx=nginx:1.9.1

kubectl set image コマンドは、Deployment のポッドの nginx イメージを 1 つずつ更新します。

別の例として、Deployment のリソースリクエストと制限を設定するには、次のようにします。

kubectl set resources deployment nginx --limits cpu=200m,memory=512Mi --requests cpu=100m,memory=256Mi

または、Deployment のリソースリクエストを削除するには、次のようにします。

kubectl set resources deployment nginx --limits cpu=0,memory=0 --requests cpu=0,memory=0

kubectl apply

kubectl apply を使用すると、新しいまたは更新後のマニフェストファイルを適用してオブジェクトを更新できます。

新しいマニフェストファイルを適用するには、次のコマンドを実行します。

kubectl apply -f [MANIFEST]

ここで、[MANIFEST] は更新されたマニフェストファイルです。

Console

アプリケーションのライブ構成を編集する手順は次のとおりです。

Cloud Console で Google Kubernetes Engine の [ワークロード] メニューに移動します。

[ワークロード] メニューに移動
目的のワークロードを選択します。
[編集] をクリックします。
エディタを使用してオブジェクトのラベルまたはポッドテンプレートに必要な変更を加えます。
[保存] をクリックします。

更新ロールアウトを管理する

kubectl rollout を使用すると、発生したロールアウトの検査、ロールアウトの一時停止と再開、更新のロールバック、オブジェクトのロールアウト履歴の表示を行うことができます。

`kubectl rollout status` でのロールアウトの調査結果

kubectl rollout status コマンドを実行して、ロールアウトの状態を確認できます。

たとえば、nginx Deployment のロールアウトを調査するには、次のコマンドを実行します。

kubectl rollout status deployment nginx

出力は次のようになります。

Waiting for rollout to finish: 2 out of 3 newreplicas have been updated...
deployment "nginx" successfully rolled out

ロールアウトが成功したら、kubectl get deployment nginx を実行して、すべてのポッドが動作中であることを確認します。出力は次のようになります。

NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx              3         3         3            3           36s

ロールアウトを一時停止、再開する

kubectl rollout pause を使用して、ロールオーバーを一時停止します。

たとえば、nginx Deployment のロールアウトを一時停止するには、次のコマンドを実行します。

kubectl rollout pause deployment nginx

再開するには、次のコマンドを実行します。

kubectl rollout resume deployment nginx

`kubectl rollout history` でのロールアウト履歴の表示

kubectl rollout history を使用すると、オブジェクトのロールアウト履歴を表示できます。

たとえば、nginx Deployment のロールアウト履歴を表示するには、次のいずれかのコマンドを実行します。

kubectl rollout history deployment nginx

3 つ目のリビジョンの履歴を表示するには、次のコマンドを実行します。

kubectl rollout history deployment nginx --revision 3

`kubectl rollout undo` で更新をロールバックする

オブジェクトのロールアウトをロールバックするには、kubectl rollout undo コマンドを使用します。

たとえば、以前のバージョンの nginx Deployment をロールバックするには、次のコマンドを実行します。

kubectl rollout undo deployments nginx

別の例として、Deployment の 3 つ目のリビジョンにロールバックするには、次のコマンドを実行します。

kubectl rollout undo deployment nginx --to-revision 3

StatefulSet と DaemonSet に関する考慮事項

Kubernetes 1.7 以降の StatefulSet と Kubernetes 1.6 以降の DaemonSet は、更新戦略を使用して、コンテナ、ラベル、リソースリクエスト / 制限、そのポッドのアノテーションの自動ローリングアプリケーションを構成または無効化します。更新戦略は、spec.updateStrategy フィールドを使用して構成されます。

spec.updateStrategy.type フィールドは、値として OnDelete または RollingUpdate を受け入れます。

spec.updateStrategy.type が未指定の場合、OnDelete がデフォルトの動作になります。OnDelete は、コントローラがそのポッドを自動的に更新しないようにします。コントローラに変更が反映された新しいポッドを作成させるには、ポッドを手動で削除する必要があります。OnDelete は、ポッドを手動で更新したい場合に便利です。

RollingUpdate は、StatefulSet でポッドの自動ローリングアップデートを実施します。RollingUpdate では、コントローラが、それぞれのポッドを 1 つずつ削除して再作成します。そして、更新されたポッドが実行中で準備完了になるまで待機してから、次のポッドを更新します。

StatefulSet コントローラは、StatefulSet の保証を尊重しながら、すべてのポッドを逆順に更新します。

`RollingUpdate` 戦略の使用

RollingUpdate 戦略を使用すると、StatefulSet または DaemonSet 内のすべてのポッドを自動的に更新できます。

たとえば、web StatefulSet にパッチを適用し、RollingUpdate の監査戦略を適用するには、次のコマンドを実行します。

kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate"}}}'

次に、StatefulSet の spec.template を変更します。たとえば、kubectl set を使用してコンテナイメージを変更できます。次の例では、nginx コンテナが nginx-slim:0.7 イメージで実行されるように、web StatefulSet が設定されています。

kubectl set image statefulset web nginx=nginx-slim:0.7

nginx コンテナを実行している StatefulSet のポッドが更新中かどうか確認するには、次のコマンドを実行します。

kubectl get pods -l app=nginx -w

出力は次のようになります。

NAME      READY     STATUS    RESTARTS   AGE
web-0     1/1       Running   0          7m
web-1     1/1       Running   0          7m
web-2     1/1       Running   0          8m
web-2     1/1       Terminating   0         8m
web-2     1/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Terminating   0         8m
web-2     0/1       Pending   0         0s
web-2     0/1       Pending   0         0s
web-2     0/1       ContainerCreating   0         0s
web-2     1/1       Running   0         19s
web-1     1/1       Terminating   0         8m
web-1     0/1       Terminating   0         8m
web-1     0/1       Terminating   0         8m
web-1     0/1       Terminating   0         8m
web-1     0/1       Pending   0         0s
web-1     0/1       Pending   0         0s
web-1     0/1       ContainerCreating   0         0s
web-1     1/1       Running   0         6s
web-0     1/1       Terminating   0         7m
web-0     1/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Terminating   0         7m
web-0     0/1       Pending   0         0s
web-0     0/1       Pending   0         0s
web-0     0/1       ContainerCreating   0         0s
web-0     1/1       Running   0         10s

StatefulSet 内のポッドは、逆順に更新されます。StatefulSet コントローラは、各ポッドを終了し、次のポッドを更新する前に、そのポッドが実行中で準備完了になるまで待機します。

`RollingUpdate` のパーティショニング

partition パラメータを StatefulSet の RollingUpdate フィールドに指定できます。

partition を指定すると、partition の値以上の序数を持つすべてのポッドが更新されます。partition の値未満の序数を持つすべてのポッドは更新されず、削除された場合も以前のバージョンで再作成されます。

partition の値が replicas の数より大きい場合は、更新がそのポッドに伝播されません。パーティショニングは、更新のステージング、カナリアのロールアウト、段階的ロールアウトを行う場合に便利です。

たとえば、web StatefulSet をパーティショニングするには、次のコマンドを実行します。

kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'

これにより、3 以上の序数を持つポッドが更新されます。

DaemonSet の `maxUnavailable` パラメータ

DaemonSet のオプションの maxUnavailable パラメータは、rollingUpdate フィールドの子になります。

maxUnavailable が、更新中に使用できない DaemonSet ポッドの最大数を決定します。省略された場合、デフォルト値は 1 です。この値を 0 にすることはできません。絶対数やパーセンテージにすることはできます。

`OnDelete` 戦略の更新

StatefulSet または DaemonSet を手動で更新する場合は、spec.updateStrategy フィールドを省略します。これにより、コントローラは OnDelete 戦略を使用します。

OnDelete 戦略を使用するコントローラを更新する場合、ポッドテンプレートに変更を行った後、ポッドを手動で削除する必要があります。

たとえば、nginx-slim:0.7 イメージを使用するように web StatefulSet を設できます。

kubectl set image statefulset web nginx=nginx-slim:0.7

次に、最初の web を削除するには、次のコマンドを実行します。

kubectl delete pod web-0

ポッドが StatefulSet によって再作成され、実行中で準備完了になるのを観察するには、次のコマンドを実行します。

kubectl get pod web-0 -w

このコマンドの出力は、次のようになります。

NAME      READY     STATUS               RESTARTS   AGE
web-0     1/1       Running              0          54s
web-0     1/1       Terminating          0         1m
web-0     0/1       Terminating          0         1m
web-0     0/1       Terminating          0         1m
web-0     0/1       Terminating          0         1m
web-0     0/1       Pending              0         0s
web-0     0/1       Pending              0         0s
web-0     0/1       ContainerCreating    0         0s
web-0     1/1       Running              0         3s

ジョブを更新する

ジョブの設定を更新すると、新しいジョブとそのポッドが新しい設定で実行されます。ジョブを更新したら、必要に応じて古いジョブとそのポッドを手動で削除する必要があります。

ジョブとそのすべてのポッドを削除するには、次のコマンドを実行します。

kubectl delete job my-job

ジョブを削除してもポッドの実行を継続する場合は、--cascade=false フラグを指定します。

kubectl delete job my-job --cascade=false

また、kubectl describe deployment nginx コマンドを使用すると、Deployment の詳細が表示されます。

次のステップ

クラスタのアップグレードについて確認する。

ローリング アップデートの実施

概要

始める前に

gcloud init の使用

gcloud config の使用

アプリケーションを更新する

kubectl set

kubectl apply

Console

更新ロールアウトを管理する

kubectl rollout status でのロールアウトの調査結果

ロールアウトを一時停止、再開する

kubectl rollout history でのロールアウト履歴の表示

kubectl rollout undo で更新をロールバックする

StatefulSet と DaemonSet に関する考慮事項

RollingUpdate 戦略の使用

RollingUpdate のパーティショニング

DaemonSet の maxUnavailable パラメータ

OnDelete 戦略の更新

ジョブを更新する

次のステップ

ローリングアップデートの実施

`kubectl rollout status` でのロールアウトの調査結果

`kubectl rollout history` でのロールアウト履歴の表示

`kubectl rollout undo` で更新をロールバックする

`RollingUpdate` 戦略の使用

`RollingUpdate` のパーティショニング

DaemonSet の `maxUnavailable` パラメータ

`OnDelete` 戦略の更新