GSP053

概要

DevOps のプラクティスでは、「継続的デプロイ」、「Blue/Green デプロイ」、「カナリア デプロイ」などのアプリケーション デプロイのシナリオを管理するために、複数のデプロイメントを使用することがよくあります。こうした複数の異種混合デプロイメントが使用される一般的なシナリオに対応できるように、このラボではコンテナのスケーリングと管理の演習を行います。

目標

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

• kubectl ツールを使用した実践演習を行う
• デプロイの yaml ファイルを作成する
• デプロイメントをリリース、更新、スケールする
• デプロイメントを更新し、デプロイのスタイルについて学ぶ

前提条件

学習の効果を最大化するために、このラボでは次のことをおすすめします。

• 以下の Google Cloud Skills Boost ラボを受講していること。
  • Docker の概要
  • Hello Node Kubernetes
• Linux システムの管理スキルがあること。
• DevOps の理論: 継続的デプロイのコンセプトを理解していること。

デプロイメントの概要

異種混合デプロイメントには通常、特定の技術的ニーズや運用上のニーズに対応するため、2 つ以上の異なるインフラストラクチャ環境またはリージョンが関与します。異種混合デプロイメントは、その特性に応じて「ハイブリッド」、「マルチクラウド」、「パブリック-プライベート」と呼ばれます。

このラボでは、単一のクラウド環境、複数のパブリック クラウド環境（マルチクラウド）、またはオンプレミス環境とパブリック クラウド環境の組み合わせ（ハイブリッドまたはパブリック / プライベート）において、複数のリージョンにまたがる異種混合デプロイメントを扱います。

単一の環境またはリージョンに限定されたデプロイでは、ビジネス上や技術上のさまざまな課題が発生する可能性があります。

• リソースの上限: 単一の環境、特にオンプレミス環境では、本番環境のニーズを満たすコンピューティング リソース、ネットワーキング リソース、ストレージ リソースを確保できない場合があります。
• 地理的範囲の制限: 単一環境のデプロイでは、地理的に離れた場所にいるユーザーが互いに 1 つのデプロイにアクセスする必要があります。つまり、ユーザーのトラフィックは、中心となる場所に到達するまでに世界中を移動する可能性があります。
• 限られた可用性: ウェブ規模のトラフィック パターンを処理するアプリケーションは、フォールト トレランスと復元力を維持する必要があります。
• ベンダー ロックイン: プラットフォームとインフラストラクチャがベンダーレベルで抽象化されるため、アプリケーションの移植が妨げられる場合があります。
• 柔軟性の低いリソース: リソースが特定のコンピューティング、ストレージ、ネットワーキング サービスに限定される場合があります。

異種混合デプロイはこれらの課題に対処するのに役立ちますが、プログラマティックで確定的なプロセスと手順を使用して設計する必要があります。一度限りまたはその場しのぎのデプロイ手順では、デプロイやプロセスが脆弱になり、障害に耐えられない可能性があります。また、その場しのぎのプロセスはデータの喪失やトラフィックの低下を招く場合もあります。優れたデプロイ プロセスは再現可能でなければならず、プロビジョニング、構成、メンテナンスの管理には実績のあるアプローチが必要になります。

異種混合デプロイの一般的なシナリオは、マルチクラウド デプロイ、オンプレミス データの外部接続、継続的インテグレーション / 継続的デリバリー（CI / CD）プロセスの 3 つです。

以降の演習では、Kubernetes とその他のインフラストラクチャ リソースを使用して適切に設計されたアプローチで異種混合デプロイメントの一般的なユースケースの実習を行います。

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。

このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生することを防ぎます。

• ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントへの追加料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

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

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

2. [Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。

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

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

3. 必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。

4. [ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。

   重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

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

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

その後このタブで Cloud Console が開きます。

注: 左上にある [ナビゲーション メニュー] をクリックすると、Google Cloud のプロダクトやサービスのリストが含まれるメニューが表示されます。

Cloud Shell をアクティブにする

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

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

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

2. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

3. [承認] をクリックします。

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

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

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

ゾーンを設定する

ローカルゾーンとして を指定して次のコマンドを実行し、使用する Google Cloud ゾーンを設定します。

gcloud config set compute/zone {{{ project_0.default_zone | ZONE }}}

このラボのサンプルコードを入手する

1. コンテナと Deployment を作成して実行するためのサンプルコードを入手します。

gsutil -m cp -r gs://spls/gsp053/orchestrate-with-kubernetes . cd orchestrate-with-kubernetes/kubernetes

2. 3 つのノードがあるクラスタを作成します（完了するまでに数分かかります）。

gcloud container clusters create bootcamp \ --machine-type e2-small \ --num-nodes 3 \ --scopes "https://www.googleapis.com/auth/projecthosting,storage-rw"

タスク 1. Deployment オブジェクトについて学習する

まず、Deployment オブジェクトについて調べます。

1. kubectl の explain コマンドで、Deployment オブジェクトの説明を確認できます。

kubectl explain deployment

2. --recursive オプションを使用してすべてのフィールドを確認することもできます。

kubectl explain deployment --recursive

3. ラボを進めながら explain コマンドを使用すると、Deployment オブジェクトの構造や、各フィールドの機能を理解するのに役立ちます。

kubectl explain deployment.metadata.name

タスク 2. Deployment を作成する

1. deployments/auth.yaml 構成ファイルを更新します。

vi deployments/auth.yaml

2. エディタを開きます。

i

3. Deployment の containers セクションにある image を次のように変更します。

... containers: - name: auth image: "kelseyhightower/auth:1.0.0" ...

4. auth.yaml ファイルを保存します（Esc キーを押してから、次のように入力します）。

:wq

5. Enter キーを押します。次に単純な Deployment を作成します。Deployment の構成ファイルを確認します。

cat deployments/auth.yaml

出力:

apiVersion: apps/v1 kind: Deployment metadata: name: auth spec: replicas: 1 selector: matchLabels: app: auth template: metadata: labels: app: auth track: stable spec: containers: - name: auth image: "kelseyhightower/auth:1.0.0" ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

Deployment でレプリカが 1 つ作成され、バージョン 1.0.0 の auth コンテナが使用されていることがわかります。

kubectl create コマンドを使用して auth Deployment を作成すると、Deployment のマニフェスト内のデータに準拠する Pod が 1 つ作成されます。これは、replicas フィールドに指定する数を変更することで、Pod の数をスケールできることを意味しています。

6. では、kubectl create を使用して Deployment オブジェクトを作成しましょう。

kubectl create -f deployments/auth.yaml

7. Deployment が実際に作成されていることを確認します。

kubectl get deployments

8. Deployment が作成されると、Kubernetes はその ReplicaSet を作成します。Deployment の ReplicaSet が作成されたことを確認できます。

kubectl get replicasets

auth-xxxxxxx のような名前の ReplicaSet が表示されます。

9. Deployment の一部として作成された Pod を確認します。ReplicaSet が作成されるときに、Kubernetes によって Pod が 1 つ作成されます。

kubectl get pods

次に、auth Deployment 用の Service を作成します。Service マニフェスト ファイルについてはすでに説明したためここでは詳細は割愛します。

10. kubectl create コマンドを使用して auth Service を作成します。

kubectl create -f services/auth.yaml

11. 次に、同じ手順で hello Deployment を作成して公開します。

kubectl create -f deployments/hello.yaml kubectl create -f services/hello.yaml

12. さらに、同じ手順でフロントエンド Deployment を作成して公開します。

kubectl create secret generic tls-certs --from-file tls/ kubectl create configmap nginx-frontend-conf --from-file=nginx/frontend.conf kubectl create -f deployments/frontend.yaml kubectl create -f services/frontend.yaml 注: フロントエンドの ConfigMap が作成されました。

13. フロントエンドの外部 IP を取得して curl を実行し、フロントエンドを操作します。

kubectl get services frontend 注: Service の External-IP フィールドに値が表示されるまでに数秒かかる場合がありますが、これは正常な動作です。このフィールドに値が表示されるまで、数秒ごとに上のコマンドを実行します。 curl -ks https://<EXTERNAL-IP>

hello レスポンスが返されます。

14. kubectl の出力テンプレート機能を使用して、curl を 1 行で実行することもできます。

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`

完了したタスクをテストする

下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。Kubernetes クラスタに加え、Auth、Hello、フロントエンド Deployment が正常に作成されている場合は、評価スコアが表示されます。

Kubernetes クラスタと Deployment（Auth、Hello、フロントエンド）を作成する

Deployment をスケールする

次は、作成した Deployment をスケールします。そのために、spec.replicas フィールドを更新します。

1. kubectl explain コマンドをもう一度使用して、このフィールドの説明を確認してください。

kubectl explain deployment.spec.replicas

2. replicas フィールドは、kubectl scale コマンドを使って簡単に更新できます。

kubectl scale deployment hello --replicas=5 注: 新しい Pod がすべて起動するまでに数分かかる場合があります。

Deployment が更新されると、Kubernetes は関連する ReplicaSet を自動的に更新し、Pod の総数が 5 になるように新しい Pod を起動します。

3. 5 つの hello Pod が実行されていることを確認します。

kubectl get pods | grep hello- | wc -l

4. 今度はアプリケーションのスケールを戻します。

kubectl scale deployment hello --replicas=3

5. ここでも、Pod の数が正しいことを確認します。

kubectl get pods | grep hello- | wc -l

Kubernetes の Deployment と、Pod のグループを管理してスケールする方法について学びました。

タスク 3. ローリング アップデート

Deployment では、ローリング アップデートのメカニズムを使用してイメージを新しいバージョンに更新できます。Deployment を新しいバージョンで更新すると、ReplicaSet が新たに作成され、古い ReplicaSet のレプリカ数が減少するにつれて、新しい ReplicaSet のレプリカ数が徐々に増加します。

ローリング アップデートをトリガーする

1. Deployment を更新するには、次のコマンドを実行します。

kubectl edit deployment hello

2. Deployment の containers セクションにある image を次のように変更します。

... containers: image: kelseyhightower/hello:2.0.0 ...

3. 保存して終了します。

保存してエディタを終了すると、更新された Deployment がクラスタに保存され、Kubernetes がローリング アップデートを開始します。

4. Kubernetes によって作成された新しい ReplicaSet を確認します。

kubectl get replicaset

5. ロールアウト履歴にも新しいエントリが表示されます。

kubectl rollout history deployment/hello

ローリング アップデートを一時停止する

実行中のロールアウトで問題が検出された場合は、一時停止してアップデートを中止します。

1. 次の手順を試してください。

kubectl rollout pause deployment/hello

2. ロールアウトの現在の状態を確認します。

kubectl rollout status deployment/hello

3. Pod で直接確認することもできます。

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

ローリング アップデートを再開する

ロールアウトを一時停止すると、新旧のバージョンの Pod が混在した状態になります。

1. resume コマンドを使用してロールアウトを続行してください。

kubectl rollout resume deployment/hello

2. ロールアウトの完了後に status コマンドを実行すると、次のように表示されます。

kubectl rollout status deployment/hello

出力:

deployment "hello" successfully rolled out

アップデートをロールバックする

新しいバージョンでバグが検出されたと仮定します。この場合は新しいバージョンに問題があると考えられるため、新しいポッドに接続したユーザーにこれらの問題が発生することになります。

調査後にきちんと修正したバージョンをリリースするためには、以前のバージョンにロールバックする必要があります。

1. rollout コマンドを使用して、以前のバージョンにロールバックします。

kubectl rollout undo deployment/hello

2. 履歴でロールバックを確認します。

kubectl rollout history deployment/hello

3. 最後に、すべての Pod が以前のバージョンにロールバックされていることを確認します。

kubectl get pods -o jsonpath --template='{range .items[*]}{.metadata.name}{"\t"}{"\t"}{.spec.containers[0].image}{"\n"}{end}'

これで、Kubernetes Deployment のローリング アップデートと、ダウンタイムなしでアプリケーションを更新する方法について学びました。

タスク 4. カナリア デプロイ

本番環境で一部のユーザーを対象に新しいデプロイをテストする場合は、カナリア デプロイメントを使用します。この方法では一部のユーザーに変更をリリースすることで、新しいリリースに伴うリスクを軽減できます。

カナリア デプロイメントを作成する

カナリア Deployment は、新しいバージョンを含む独立した Deployment と、通常の安定した Deployment とカナリア Deployment の両方をターゲットとする Service で構成されています。

1. まず、新しいバージョン用の新しいカナリア Deployment を作成します。

cat deployments/hello-canary.yaml

出力:

apiVersion: apps/v1 kind: Deployment metadata: name: hello-canary spec: replicas: 1 selector: matchLabels: app: hello template: metadata: labels: app: hello track: canary # Use ver 2.0.0 so it matches version on service selector version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 ...

2. カナリア Deployment を作成します。

kubectl create -f deployments/hello-canary.yaml

3. カナリア Deployment を作成すると、hello と hello-canary の 2 つの Deployment が存在する状態になります。次の kubectl コマンドを使用して確認してください。

kubectl get deployments

hello Service のセレクタは、本番環境 Deployment とカナリア Deployment の両方の Pod に一致する app:hello セレクタを使用します。ただし、カナリア デプロイメントのポッド数は少ないため、少数のユーザーにしか表示されません。

カナリア デプロイメントを確認する

1. リクエストに応じて提供される hello バージョンを確認できます。

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

2. これを数回実行すると、一定のリクエストが hello 1.0.0 によって処理され、ごく一部（1/4 = 25%）が 2.0.0 によって処理されることがわかります。

完了したタスクをテストする

下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。カナリア Deployment が正常に作成されている場合は、評価スコアが表示されます。

カナリア デプロイ

本番環境でのカナリア デプロイ - セッション アフィニティ

このラボで Nginx サービスに送信した各リクエストは、カナリア デプロイで処理される可能性がありましたが、これを避けたい場合もあります。たとえば、アプリケーションの UI が変更されるユースケースで、ユーザーを混乱させたくないときなどです。このような場合は、ユーザーをいずれかのデプロイに「固定」できます。

これは、セッション アフィニティを指定してサービスを作成することで実現できます。これにより、同じユーザーが常に同じバージョンで処理されます。以下の例では、Service は前と同じですが、新しく追加された sessionAffinity フィールドが ClientIP に設定されているため、同じ IP アドレスを持つすべてのクライアントのリクエストは、同じバージョンの hello アプリケーションに送信されることになります。

kind: Service apiVersion: v1 metadata: name: "hello" spec: sessionAffinity: ClientIP selector: app: "hello" ports: - protocol: "TCP" port: 80 targetPort: 80

このテスト環境の設定は簡単ではないためここでは行いませんが、本番環境でのカナリア デプロイには sessionAffinity を使用することをおすすめします。

タスク 5. Blue/Green デプロイ

オーバーヘッド、パフォーマンスへの影響、ダウンタイムを最小限に抑えながら徐々にアプリケーションをデプロイできるローリング アップデートは、理想的な方法です。さらに、完全にデプロイされるまで新しいバージョンを指定しないようにロードバランサを変更すると効果的な場合があります。これには、Blue / Green デプロイが有効です。

Kubernetes は、古い「Blue」バージョン用と新しい「Green」バージョン用に 2 つの異なるデプロイメントを作成することでこれを実現します。「Blue」バージョンには既存の hello デプロイメントを使用します。ここでは、ルータとして機能するサービスを介してアクセスします。新しい「Green」バージョンが稼働したら、Service を更新してそのバージョンを使用するように切り替えます。

注: Blue/Green デプロイの主な短所は、アプリケーションをホストするために必要なクラスタのリソースが少なくとも 2 倍になることです。アプリケーションの両方のバージョンを同時にデプロイする前に、クラスタに十分なリソースがあることを確認してください。

Service

既存の hello サービスを使用しますが、app:hello、version: 1.0.0 のセレクタを持つように更新してください。このセレクタは既存の「Blue」デプロイとは一致しますが、使用するバージョンが異なるため、「Green」デプロイメントとは一致しません。

• まずは Service を更新します。

kubectl apply -f services/hello-blue.yaml 注: resource service/hello is missing という警告は無視します（自動的にパッチが適用されるため）。

Blue/Green デプロイを使用して更新する

Blue/Green デプロイ スタイルをサポートするために、新しいバージョン用に「Green」Deployment を新たに作成します。この Green Deployment によって、バージョン ラベルとイメージパスが更新されます。

apiVersion: apps/v1 kind: Deployment metadata: name: hello-green spec: replicas: 3 selector: matchLabels: app: hello template: metadata: labels: app: hello track: stable version: 2.0.0 spec: containers: - name: hello image: kelseyhightower/hello:2.0.0 ports: - name: http containerPort: 80 - name: health containerPort: 81 resources: limits: cpu: 0.2 memory: 10Mi livenessProbe: httpGet: path: /healthz port: 81 scheme: HTTP initialDelaySeconds: 5 periodSeconds: 15 timeoutSeconds: 5 readinessProbe: httpGet: path: /readiness port: 81 scheme: HTTP initialDelaySeconds: 5 timeoutSeconds: 1

1. Green Deployment を作成します。

kubectl create -f deployments/hello-green.yaml

2. 作成した Green Deployment が正常に起動したら、現在のバージョンである 1.0.0 が使用されていることを確認します。

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

3. 次に、新しいバージョンを指定するように Service を更新します。

kubectl apply -f services/hello-green.yaml

4. Service が更新されると、すぐに「Green」Deployment が使用されるようになり、常に新しいバージョンが使用されていることを確認できます。

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

Blue/Green ロールバック

必要に応じて、同じ方法で古いバージョンにロールバックできます。

1. 「Blue」Deployment が実行されている間に、Service を古いバージョンに戻すだけです。

kubectl apply -f services/hello-blue.yaml

2. Service が更新されたら、ロールバックは完了です。再度、正しいバージョンが使用されていることを確認してください。

curl -ks https://`kubectl get svc frontend -o=jsonpath="{.status.loadBalancer.ingress[0].ip}"`/version

これで完了です。Blue / Green デプロイメントと、バージョンをすべて一度に切り替える必要があるアプリケーションにアップデートをデプロイする方法について学びました。

お疲れさまでした

これで、Kubernetes を使ったデプロイメントの管理に関する演習は完了です。このラボでは、kubectl コマンドライン ツールと、YAML ファイルに設定されたさまざまなスタイルの構成を活用して、デプロイメントをリリース、更新、スケールしました。この基礎演習で培ったスキルは、実際の DevOps 環境で問題なく役立つことでしょう。

次のステップと詳細情報

• Google Cloud ウェブサイトに次のような詳細情報があります。

  • Kubernetes を使ったデプロイ パターン
  • DevOps ソリューションと DevOps ガイド（Google Cloud ドキュメント）

• Kubernetes ウェブサイトで Kubernetes コミュニティとつながりましょう。

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2024 年 1 月 26 日

ラボの最終テスト日: 2023 年 8 月 14 日

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