概要

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

目標

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

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

ラボの設定

ラボにアクセスする

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

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • 残り時間
   • このラボで使用する必要がある一時的な認証情報
   • このラボを行うために必要なその他の情報（ある場合）

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの詳細] パネルでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの詳細] パネルでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後次のように進みます。

   • 利用規約に同意してください。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

その後、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスのリストを含むメニューを表示するには、左上のナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

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

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_region={{{ project_0.default_region | REGION }}} export my_cluster=autopilot-cluster-1

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

source <(kubectl completion bash)

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

gcloud container clusters get-credentials $my_cluster --region $my_region

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

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

1. 次のコマンドを使用して、nginx-deployment.yaml という名前のファイルを作成して nano で開きます。

nano nginx-deployment.yaml

2. nano が開いたら、以下を nginx-deployment.yaml ファイルに貼り付けます。

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

3. Ctrl+O キーの次に Enter キーを押し、編集したファイルを保存します。

4. Ctrl+X キーを押して nano テキスト エディタを終了します。

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

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

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

2. 変更の詳細に関するアノテーションをロールアウトに追加するには、次のコマンドを実行します。

kubectl annotate deployment nginx-deployment kubernetes.io/change-cause="version change to 1.9.1" --overwrite=true

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

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

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

kubectl get deployments

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

出力:

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

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

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

kubectl rollout history deployment nginx-deployment

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

出力:

deployments "nginx-deployment" REVISION CHANGE-CAUSE 1 2 version change to 1.9.1

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 version change to 1.9.1 3 注: 直前の更新では kubectl annotate コマンドを使用しなかったため、CHANGE-CAUSE が空白になります。

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 に配信するように構成されています。

1. 次のコマンドを使用して、service-nginx.yaml という名前のファイルを作成して nano で開きます。

nano service-nginx.yaml

2. nano が開いたら、以下を service-nginx.yaml ファイルに貼り付けます。

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

3. Ctrl+O キーの次に Enter キーを押し、編集したファイルを保存します。

4. Ctrl+X キーを押して nano テキスト エディタを終了します。

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

kubectl apply -f ./service-nginx.yaml

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

LoadBalancer の作成を確認する

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

kubectl get service nginx

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

出力:

NAME Type CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx LoadBalancer 10.X.X.X X.X.X.X 60000:31798/TCP 1m

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

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

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

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

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

このタスクでは、カナリア デプロイを作成して、メインのデプロイよりも新しいバージョンの nginx を実行する単一の Pod をデプロイします。

1. 次のコマンドを使用して、nginx-canary.yaml という名前のファイルを作成して nano で開きます。

nano nginx-canary.yaml

2. nano が開いたら、以下を nginx-canary.yaml ファイルに貼り付けます。

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

3. Ctrl+O キーの次に Enter キーを押し、編集したファイルを保存します。

4. Ctrl+X キーを押して nano テキスト エディタを終了します。

前のタスクでデプロイした 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

ラボを終了する

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

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

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

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

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

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

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