このページでは、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 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
アプリケーションを更新する
次のセクションでは、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 の詳細が表示されます。