このページでは、Google Kubernetes Engine（GKE）でアプリケーションのローリング アップデートを実行する方法について説明します。
概要
ローリング アップデートを実行すると、クラスタ内のワークロードのイメージ、構成、ラベル、アノテーション、リソース制限 / リクエストを更新できます。ローリング アップデートは、リソースのポッドを新しいものに段階的に置き換えてから、利用可能なリソースを持つノードでポッドをスケジューリングします。ローリング アップデートは、ダウンタイムなしにワークロードを更新するように設計されています。
次のオブジェクトが Kubernetes ワークロードを表します。これらのワークロードの Pod テンプレートを更新することで、ワークロードのローリング アップデートをトリガーできます。
- DaemonSet
- Deployment
- StatefulSet
これらの各オブジェクトには Pod テンプレートがあり、オブジェクトのマニフェスト内の spec: template フィールドによって示されます。Pod テンプレートのフィールドには、望ましい状態や動作を実現するためにコントローラが作成する Pod の仕様が含まれています。オブジェクトの spec: template を更新すると、更新のロールアウトがトリガーされます。
Pod テンプレートには、次のフィールドが含まれています。
Pod テンプレートの詳細については、PodTemplateSpec のドキュメントをご覧ください。
Pod テンプレート以外でリソースのスケーリングやフィールドの更新を行っても、ロールアウトはトリガーされません。
始める前に
始める前に、次の作業が完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components updateを実行して最新のバージョンを取得する。
アプリケーションを更新する
次のセクションでは、Google Cloud コンソールまたは 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 は、マニフェスト ファイルの名前で置き換えます。ファイルが存在しない場合、このコマンドはリソースを作成し、構成を適用します。それ以外の場合は、更新された構成が適用されます。
コンソール
アプリケーションのライブ設定を編集する手順は次のとおりです。
Google Cloud コンソールの [ワークロード] ページに移動します。
更新するワークロードを選択します。
[デプロイの詳細] ページで、list [アクション] > [ローリング アップデート] の順にクリックします。
[ローリング アップデート] ダイアログで、ワークロードのイメージを設定します。
[更新] をクリックします。
更新ロールアウトを管理する
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 コントローラは、各 Pod を終了し、次の Pod を更新する前に、その Pod が実行中で準備完了になるまで待機します。
RollingUpdate のパーティショニング
partition パラメータを StatefulSet の RollingUpdate フィールドに指定できます。
partition を指定すると、partition の値以上の序数を持つすべてのポッドが更新されます。partition の値未満の序数を持つすべてのポッドは更新されず、削除された場合も以前のバージョンで再作成されます。
partition の値が replicas の数より大きい場合は、更新がそのポッドに伝播されません。パーティショニングは、更新のステージング、カナリアのロールアウト、段階的ロールアウトを行う場合に便利です。
たとえば、web StatefulSet をパーティショニングするには、次のコマンドを実行します。
kubectl patch statefulset web -p '{"spec":{"updateStrategy":{"type":"RollingUpdate","rollingUpdate":{"partition":3}}}}'
これにより、3 以上の序数を持つ Pod が更新されます。
DaemonSet の maxUnavailable パラメータと maxSurge パラメータ
DaemonSet のオプションの maxUnavailable パラメータと maxSurge パラメータは、DaemonSet の rollingUpdate フィールドの子です。
maxUnavailable が、更新中に使用できない DaemonSet Pod の最大数を決定します。省略した場合のデフォルト値は 1 です。
maxSurge は、更新中に更新された DaemonSet Pod を配置できる、既存の使用可能な DaemonSet Pod を持つノードの最大数です。省略した場合のデフォルト値は 0 です。
もう一方の値が 0 の場合、どちらの値も 0 にできません。どちらの値にも絶対数または割合を指定できます。
詳細については、DaemonSetSpec をご覧ください。
OnDelete 戦略の更新
StatefulSet または DaemonSet を手動で更新する場合は、spec.updateStrategy フィールドを省略します。これにより、コントローラは OnDelete 戦略を使用します。
OnDelete 戦略を使用するコントローラを更新する場合、Pod テンプレートに変更を行った後、Pod を手動で削除する必要があります。
たとえば、nginx-slim:0.7 イメージを使用するように web StatefulSet を設できます。
kubectl set image statefulset web nginx=nginx-slim:0.7
次に、最初の web を削除するには、次のコマンドを実行します。
kubectl delete pod web-0
Pod が 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
ジョブを更新する
Job の設定を更新すると、新しい Job とその Pod が新しい構成で実行されます。Job を更新したら、必要に応じて古い Job とその Pod を手動で削除する必要があります。
Job とそのすべての Pod を削除するには、次のコマンドを実行します。
kubectl delete job my-job
ジョブを削除しても Pod の実行を継続する場合は、--cascade=false フラグを指定します。
kubectl delete job my-job --cascade=false
また、kubectl describe deployment nginx コマンドを使用すると、Deployment の詳細が表示されます。