このページでは、Google Kubernetes Engine（GKE）でアプリケーションのローリング アップデートを実行する方法について説明します。
概要
ローリング アップデートを実行すると、クラスタ内のワークロードのイメージ、構成、ラベル、アノテーション、リソース制限 / リクエストを更新できます。ローリング アップデートは、リソースのポッドを新しいものに段階的に置き換えてから、利用可能なリソースを持つノードでポッドをスケジューリングします。ローリング アップデートは、ダウンタイムなしにワークロードを更新するように設計されています。
次のオブジェクトが Kubernetes ワークロードを表します。これらのワークロードの Pod テンプレートを更新することで、ワークロードのローリング アップデートをトリガーできます。
- DaemonSet
- Deployment
- StatefulSet
これらの各オブジェクトには Pod テンプレートがあり、テンプレートはオブジェクトのマニフェスト内の spec: template フィールドによって示されます。ポッド テンプレートのフィールドには、望ましい状態や動作を実現するためにコントローラが作成するポッドの仕様が含まれています。オブジェクトの spec: template を更新すると、更新のロールアウトがトリガーされます。
Pod テンプレートには、次のフィールドが含まれています。
Pod テンプレートの詳細については、PodTemplateSpec のドキュメントをご覧ください。
Pod テンプレート以外でリソースのスケーリングやフィールドの更新を行っても、ロールアウトはトリガーされません。
始める前に
作業を始める前に、次のことを確認してください。
- 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 ゾーン、リージョン クラスタまたは Autopilot クラスタの場合はデフォルトの Compute Engine リージョンを選択します。
gcloud config の使用
- デフォルトのプロジェクト ID を設定します。
gcloud config set project PROJECT_ID
- ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
gcloud config set compute/zone COMPUTE_ZONE
- Autopilot クラスタまたはリージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
gcloud config set compute/region COMPUTE_REGION
gcloudを最新バージョンに更新します。gcloud components update
アプリケーションを更新する
次のセクションでは、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 の [ワークロード] ページに移動します。
目的のワークロードを選択します。
[edit 編集] をクリックします。
エディタを使用してオブジェクトのラベルまたは Pod テンプレートに必要な変更を加えます。
[保存] をクリックします。
更新ロールアウトを管理する
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
ジョブを更新する
ジョブの設定を更新すると、新しいジョブとそのポッドが新しい設定で実行されます。ジョブを更新したら、必要に応じて古いジョブとその Pod を手動で削除する必要があります。
ジョブとそのすべての Pod を削除するには、次のコマンドを実行します。
kubectl delete job my-job
ジョブを削除しても Pod の実行を継続する場合は、--cascade=false フラグを指定します。
kubectl delete job my-job --cascade=false
また、kubectl describe deployment nginx コマンドを使用すると、Deployment の詳細が表示されます。