クラウド エンジニアには、機能の追加が頻繁に生じる重要なアプリケーションを維持する責任があります。ユーザーに対する影響とアプリケーションのダウンタイムを最小限に抑えながら、新機能とアップデートをロールアウトしなければなりません。アプリケーションはコンテナ化され、Kubernetes にデプロイされます。ユーザーの需要の変化に応じたスケールアップとスケールダウンが必要になる場合もあります。また、インターネットからアプリケーションに流入するトラフィックを制御する必要もあります。アプリケーションを維持、更新する際には、以下のような点に注意してください。

• クラスタの Deployment マニフェストをどのように作成するか。
• Deployment に含まれる Pod の数を手動でスケーリングするにはどうすればよいか。
• アプリケーションに流入する受信トラフィックを制御する Service を作成するにはどうすればよいか。
• ユーザーに対する影響を最小限に抑えてアップデートをロールアウトするにはどうすればよいか。
• 完全なロールアウトを完了する前に、カナリア デプロイを実行して新機能をテストするにはどうすればよいか。

Azure Kubernetes Service（AKS）の使用に精通しているクラウド プロフェッショナルであれば、YAML マニフェスト ファイルを使用して AKS で Kubernetes Deployment を実行したことがあるでしょう。おそらく、DevOps パイプラインを使用して、アプリケーション コードとコンテナを Kubernetes クラスタで利用可能にしていると思います。

需要に応じて Pod の数をスケーリングするには、マニフェスト ファイルを手動で変更するか、kubectl コマンドを使用します。アプリケーションに流入する受信トラフィックを制御するには、DevOps パイプラインにロードバランサをデプロイするプランを作成して実行します。コンテナ イメージを更新する必要がある場合は、DevOps パイプラインを実行してコンテナ イメージを利用可能にし、kubectl コマンドを使用して Deployment のロールアウトをトリガーします。

カナリア更新を実行するには、Prometheus をインストールし、パイプラインを構成して、マニフェスト ファイルを追加し、Deployment パイプラインを実行する必要があります。

以上を念頭に、Google Kubernetes Engine（GKE）の Deployment マニフェストを作成して、Deployment の作成、スケーリング、更新を行う方法を具体的に説明していきます。

概要

このラボでは、Deployment マニフェストの基本的な使用方法について学習します。マニフェストとは、さまざまな Pod で使用できる Deployment に必要な構成を含むファイルであり、簡単に変更できます。

目標

このラボでは、次のタスクの実行方法について学びます。

• Deployment マニフェストを作成してクラスタにデプロイし、ノードが無効な場合の Pod のスケジュール再設定を確認する
• Deployment に含まれる Pod の手動でのスケールアップとスケールダウンをトリガーする
• Deployment のロールアウト（新しいバージョンへのローリング アップデート）とロールバックをトリガーする
• カナリア デプロイを実行する

ラボの設定

ラボにアクセスする

各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。

1. Qwiklabs にシークレット ウィンドウでログインします。

2. ラボのアクセス時間（例: 1:15:00）に注意し、時間内に完了できるようにしてください。
   一時停止機能はありません。必要な場合はやり直せますが、最初からになります。

3. 準備ができたら、[ラボを開始] をクリックします。

4. ラボの認証情報（ユーザー名とパスワード）をメモしておきます。この情報は、Google Cloud Console にログインする際に使用します。

5. [Google Console を開く] をクリックします。

6. [別のアカウントを使用] をクリックし、このラボの認証情報をコピーしてプロンプトに貼り付けます。
   他の認証情報を使用すると、エラーが発生したり、料金の請求が発生したりします。

7. 利用規約に同意し、再設定用のリソースページをスキップします。

最初のログイン手順を完了すると、プロジェクト ダッシュボードが表示されます。

Google Cloud Shell の有効化

Google Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。

Google Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールで、右上のツールバーにある [Cloud Shell をアクティブにする] ボタンをクリックします。

   

2. [続行] をクリックします。

環境がプロビジョニングされ、接続されるまでしばらく待ちます。接続した時点で認証が完了しており、プロジェクトに各自のプロジェクト ID が設定されます。次に例を示します。

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

• 次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

出力:

Credentialed accounts: - @.com (active)

出力例:

Credentialed accounts: - google1623327_student@qwiklabs.net

• 次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project =

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: gcloud ドキュメントの全文については、 gcloud CLI の概要ガイド をご覧ください。

タスク 1. Deployment マニフェストを作成してクラスタにデプロイする

このタスクでは、クラスタ内の Pod の Deployment マニフェストを作成します。

ラボの GKE クラスタに接続する

1. Cloud Shell で次のコマンドを入力して、ゾーンとクラスタ名の環境変数を設定します。

export my_zone={{{project_0.default_zone|Zone}}} export my_cluster=standard-cluster-1

2. Cloud Shell で kubectl のタブ補完を構成します。

source <(kubectl completion bash)

3. Cloud Shell で次のコマンドを使用して、kubectl コマンドライン ツールのクラスタへのアクセスを構成します。

gcloud container clusters get-credentials $my_cluster --zone $my_zone

4. Cloud Shell に次のコマンドを入力して、ラボの Cloud Shell にリポジトリのクローンを作成します。

git clone https://github.com/GoogleCloudPlatform/training-data-analyst

5. 作業ディレクトリへのショートカットとしてソフトリンクを作成します。

ln -s ~/training-data-analyst/courses/ak8s/v1.1 ~/ak8s

6. このラボのサンプル ファイルが含まれているディレクトリに移動します。

cd ~/ak8s/Deployments/

Deployment マニフェストを作成する

用意されているサンプルの Deployment マニフェスト（nginx-deployment.yaml）を使用して Deployment を作成します。この Deployment は 3 つの Pod レプリカを実行するように構成されています。各 Pod には TCP ポート 80 でリッスンする 1 つの nginx コンテナが含まれています。

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80

1. 次のコマンドを実行して、マニフェストをデプロイします。

kubectl apply -f ./nginx-deployment.yaml

2. 次のコマンドを実行して、Deployment のリストを表示します。

kubectl get deployments

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

出力:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 0/3 3 0 3s

3. 数秒待ってから、このコマンドの出力で現在の数字が目的の数字と一致するまで繰り返しコマンドを実行します。

最終的な出力は次の例のようになります。

出力:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 42s

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 nginx Deployment マニフェストを作成、デプロイする

タスク 2. Deployment に含まれる Pod の数を手動でスケールアップまたはスケールダウンする

状況によっては、Pod インスタンスのシャットダウンが必要になる場合があります。また、10 個の Pod を実行する必要が生じる場合もあります。Kubernetes には、特定の Pod を所定のインスタンス数にスケーリングする機能があります。Pod をシャットダウンするには、Pod 数をゼロにスケーリングします。

このタスクでは、Google Cloud コンソールと Cloud Shell で Pod のスケールアップとスケールダウンを行います。

コンソールで Pod をスケールアップまたはスケールダウンする

1. [Google Cloud コンソール] タブに切り替えます。
2. ナビゲーション メニュー（）で、[Kubernetes Engine] > [ワークロード] をクリックします。
3. [nginx-deployment]（自分の Deployment）をクリックして、[Deployment の詳細] ページを開きます。
4. 上部にある [アクション] > [スケール] > [レプリカを編集] をクリックします。
5. 「1」と入力して [スケール] をクリックします。

この操作を行うとクラスタがスケールダウンされ、[マネージド Pod] で Pod のステータスが更新されます。場合によっては、[更新] をクリックする必要があります。

シェルで Pod をスケールアップまたはスケールダウンする

1. ブラウザの Cloud Shell タブに戻ります。
2. 次のコマンドを実行して、Deployment に含まれる Pod のリストを表示します。

kubectl get deployments

出力:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 1/1 1 1 3m

3. 次のコマンドを実行して、Pod のレプリカ数を 3 つに再度スケーリングします。

kubectl scale --replicas=3 deployment nginx-deployment

4. 次のコマンドを実行して、Deployment に含まれる Pod のリストを表示します。

kubectl get deployments

出力:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 4m

タスク 3. Deployment のロールアウトとロールバックをトリガーする

Deployment のロールアウトがトリガーされるのは、Deployment の Pod テンプレート（.spec.template）が変更された場合のみです。たとえば、テンプレートのラベルやコンテナ イメージが更新された場合がこれに該当します。Deployment のスケーリングなど、その他の更新でロールアウトがトリガーされることはありません。

このタスクでは、Deployment のロールアウトをトリガーしてから、ロールバックをトリガーします。

Deployment のロールアウトをトリガーする

1. 次のコマンドを実行して、Deployment に含まれる nginx のバージョンを更新します。

kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record

Deployment に含まれるコンテナ イメージが nginx v1.9.1 に更新されます。

2. 次のコマンドを実行して、ロールアウトのステータスを表示します。

kubectl rollout status deployment.v1.apps/nginx-deployment

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

出力:

Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 1 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 2 out of 3 new replicas updated... Waiting for rollout to finish: 1 old replicas pending termination... Waiting for rollout to finish: 1 old replicas pending termination... deployment "nginx-deployment" successfully rolled out

3. Deployment のリストを取得して変更を確認します。

kubectl get deployments

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

出力:

NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 6m

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Deployment に含まれる nginx のバージョンを更新します

4. Deployment のロールアウト履歴を表示します。

kubectl rollout history deployment nginx-deployment

出力は次の例のようになります。実際の出力はこの例と完全には一致しない場合があります。

出力:

deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true

Deployment のロールバックをトリガーする

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

1. 次のコマンドを実行して、nginx Deployment を以前のバージョンにロールバックします。

kubectl rollout undo deployments nginx-deployment

2. 更新された Deployment のロールアウト履歴を表示します。

kubectl rollout history deployment nginx-deployment

出力は次の例のようになります。実際の出力はこの例と完全には一致しない場合があります。

出力:

deployments "nginx-deployment" REVISION CHANGE-CAUSE 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 --record=true 3

3. Deployment の最新リビジョンの詳細を表示します。

kubectl rollout history deployment/nginx-deployment --revision=3

出力は次の例のようになります。実際の出力はこの例と完全には一致しない場合がありますが、現在のリビジョンが nginx:1.7.9 にロールバックされたことが示されます。

出力:

deployments "nginx-deployment" with revision #3 Pod Template: Labels: app=nginx pod-template-hash=3123191453 Containers: nginx: Image: nginx:1.7.9 Port: 80/TCP Host Port: 0/TCP Environment: Mounts: Volumes:

タスク 4. マニフェストで Service のタイプを定義する

このタスクでは、アプリケーションへの受信トラフィックを制御する Service を作成して確認を行います。構成できる Service のタイプには、ClusterIP、NodePort、LoadBalancer がありますが、このラボでは LoadBalancer を使用します。

マニフェストで Service のタイプを定義する

LoadBalancer タイプの Service をデプロイする service-nginx.yaml というマニフェスト ファイルがあらかじめ用意されています。この Service は TCP ポート 60000 の受信トラフィックを、app: nginx というラベルが付いた任意のコンテナのポート 80 に配信するように構成されています。

apiVersion: v1 kind: Service metadata: name: nginx spec: type: LoadBalancer selector: app: nginx ports: - protocol: TCP port: 60000 targetPort: 80

• Cloud Shell で次のコマンドを実行して、マニフェストをデプロイします。

kubectl apply -f ./service-nginx.yaml

このマニフェストは Service を定義し、セレクタに対応する Pod にその Service を適用します。この例の場合、マニフェストはタスク 1 でデプロイした nginx コンテナに適用されます。このサービスは app: nginx というラベルが付いた任意の他の Pod（後から作成したものも含む）にも適用されます。

LoadBalancer の作成を確認する

1. 次のコマンドを実行して、nginx Service の詳細を表示します。

kubectl get service nginx

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

出力:

NAME CLUSTER_IP EXTERNAL_IP PORT(S) SELECTOR AGE nginx 10.X.X.X X.X.X.X 60000/TCP run=nginx 1m

2. 外部 IP が表示される場合は、ブラウザの新しいタブで http://[外部 IP]:60000/ を開き、ネットワーク ロード バランシング経由で提供されているサーバーを確認します。

注: Service の ExternalIP フィールドに値が入力されるまでに数秒かかる場合がありますが、これは正常な動作です。このフィールドに値が表示されるまで、数秒ごとに kubectl get services nginx コマンドを再実行します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 LoadBalancer タイプの Service をデプロイするマニフェスト ファイルをデプロイする

タスク 5. カナリア デプロイを実行する

カナリア デプロイは、新しいバージョンのアプリケーションをテストするために使用する独立した Deployment です。1 つの Service でカナリア デプロイと通常の Deployment の両方を実行できます。また、一部のユーザーをカナリア バージョンに振り向けることにより、新しいリリースに伴うリスクを軽減することも可能です。

あらかじめ用意されているマニフェスト ファイル nginx-canary.yaml は、メインの Deployment よりも新しいバージョンの nginx を実行する 1 つの Pod をデプロイします。このタスクでは、この新しい Deployment ファイルを使用してカナリア デプロイを作成します。

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-canary labels: app: nginx spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx track: canary Version: 1.9.1 spec: containers: - name: nginx image: nginx:1.9.1 ports: - containerPort: 80

前のタスクでデプロイした nginx Service のマニフェストでは、ラベル セレクタを使用して、app: nginx というラベルが付いた Pod を対象にしています。通常の Deploymemt とこの新しいカナリア デプロイのどちらにも app: nginx ラベルが付いています。この Service により、通常の Deployment とカナリア デプロイの両方の Pod に受信接続が分散されます。カナリア デプロイのレプリカ（Pod）数は通常の Deployment よりも少ないため、カナリア デプロイを利用できるユーザー数は通常の Deployment よりも少なくなります。

1. 構成ファイルに基づいてカナリア デプロイを作成します。

kubectl apply -f nginx-canary.yaml

2. 完了したら、nginx と nginx-canary の両方の Deployment が存在することを確認します。

kubectl get deployments

3. LoadBalancer Service の外部 IP に接続されているブラウザタブに戻り、ページを更新します。引き続き標準の「Welcome to nginx」ページが表示されます。
4. Cloud Shell に戻り、メインの Deployment のレプリカ数を 0 にスケールダウンします。

kubectl scale --replicas=0 deployment nginx-deployment

5. 実行されているレプリカがカナリア デプロイのみになったことを確認します。

kubectl get deployments

6. LoadBalancer Service の外部 IP に接続されているブラウザタブに戻り、ページを更新します。引き続き標準の「Welcome to nginx」ページが表示され、Service によって自動的にトラフィックがカナリア デプロイに配信されていることがわかります。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 カナリア デプロイを作成する

セッション アフィニティ

ラボで使用されている Service の構成では、1 つのクライアントから送信されるすべてのリクエストが常に同じ Pod に接続されるとは限りません。各リクエストは個別に扱われるため、通常の nginx Deployment に接続される場合もあれば、nginx-canary Deployment に接続される場合もあります。

カナリア リリースで機能が大きく変更されている場合、リクエストごとに接続先のバージョンが異なると、問題が発生する可能性があります。クライアントの最初のリクエスト時に、以降の全接続に使用される Pod を決定する必要がある場合、Service の仕様で sessionAffinity フィールドを ClientIP に設定することによってこの問題を回避します。

例:

apiVersion: v1 kind: Service metadata: name: nginx spec: type: LoadBalancer sessionAffinity: ClientIP selector: app: nginx ports: - protocol: TCP port: 60000 targetPort: 80

まとめ

このラボでは、アプリケーションのカナリア更新をデプロイ、スケーリング、実行するために、GKE でマニフェスト ファイルを使用する方法を確認しました。GKE と AKS の主な類似点と相違点は次のとおりです。

類似点:

GKE と AKS はどちらもマネージド Kubernetes サービスであり、どちらのサービスを利用しても、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを行うことができます。

• Kubernetes Deployment の YAML ファイルの基本構造と構文は GKE と AKS で同じです。
• AKS と GKE では、どちらも kubectl コマンドを使用します。

相違点:

• GKE では、クラスタ、Pod、管理の属性を指定でき、AKS Deployment のように DevOps パイプラインを作成する必要はありません。これは、マニフェスト ファイルを使用してプロビジョニング タスクを実行するうえで必要になるバックエンド インフラストラクチャが GKE に備わっているためです。

ラボを終了する

ラボが完了したら、[ラボを終了] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。

ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信] をクリックします。

星の数は、それぞれ次の評価を表します。

• 星 1 つ = 非常に不満
• 星 2 つ = 不満
• 星 3 つ = どちらともいえない
• 星 4 つ = 満足
• 星 5 つ = 非常に満足

フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。

フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート] タブをご利用ください。

Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。