チェックポイント
Create a Kubernetes cluster and deployments (Auth, Hello, and Frontend)
/ 50
Canary Deployment
/ 50
Kubernetes Engine によるデプロイメントの管理
GSP053
概要
DevOps のプラクティスでは、「継続的デプロイ」、「Blue/Green デプロイ」、「カナリア デプロイ」などのアプリケーション デプロイのシナリオを管理するために、複数のデプロイメントを使用することがよくあります。こうした複数の異種混合デプロイメントが使用される一般的なシナリオに対応できるように、このラボではコンテナのスケーリングと管理の演習を行います。
目標
このラボでは、次のタスクの実行方法について学びます。
- kubectl ツールを使用した実践演習を行う
- デプロイの yaml ファイルを作成する
- デプロイメントをリリース、更新、スケールする
- デプロイメントを更新し、デプロイのスタイルについて学ぶ
前提条件
学習の効果を最大化するために、このラボでは次のことをおすすめします。
- 以下の Google Cloud Skills Boost ラボを受講していること。
- Linux システムの管理スキルがあること。
- DevOps の理論: 継続的デプロイのコンセプトを理解していること。
デプロイメントの概要
異種混合デプロイメントには通常、特定の技術的ニーズや運用上のニーズに対応するため、2 つ以上の異なるインフラストラクチャ環境またはリージョンが関与します。異種混合デプロイメントは、その特性に応じて「ハイブリッド」、「マルチクラウド」、「パブリック-プライベート」と呼ばれます。
このラボでは、単一のクラウド環境、複数のパブリック クラウド環境(マルチクラウド)、またはオンプレミス環境とパブリック クラウド環境の組み合わせ(ハイブリッドまたはパブリック / プライベート)において、複数のリージョンにまたがる異種混合デプロイメントを扱います。
単一の環境またはリージョンに限定されたデプロイでは、ビジネス上や技術上のさまざまな課題が発生する可能性があります。
- リソースの上限: 単一の環境、特にオンプレミス環境では、本番環境のニーズを満たすコンピューティング リソース、ネットワーキング リソース、ストレージ リソースを確保できない場合があります。
- 地理的範囲の制限: 単一環境のデプロイでは、地理的に離れた場所にいるユーザーが互いに 1 つのデプロイにアクセスする必要があります。つまり、ユーザーのトラフィックは、中心となる場所に到達するまでに世界中を移動する可能性があります。
- 限られた可用性: ウェブ規模のトラフィック パターンを処理するアプリケーションは、フォールト トレランスと復元力を維持する必要があります。
- ベンダー ロックイン: プラットフォームとインフラストラクチャがベンダーレベルで抽象化されるため、アプリケーションの移植が妨げられる場合があります。
- 柔軟性の低いリソース: リソースが特定のコンピューティング、ストレージ、ネットワーキング サービスに限定される場合があります。
異種混合デプロイはこれらの課題に対処するのに役立ちますが、プログラマティックで確定的なプロセスと手順を使用して設計する必要があります。一度限りまたはその場しのぎのデプロイ手順では、デプロイやプロセスが脆弱になり、障害に耐えられない可能性があります。また、その場しのぎのプロセスはデータの喪失やトラフィックの低下を招く場合もあります。優れたデプロイ プロセスは再現可能でなければならず、プロビジョニング、構成、メンテナンスの管理には実績のあるアプローチが必要になります。
異種混合デプロイの一般的なシナリオは、マルチクラウド デプロイ、オンプレミス データの外部接続、継続的インテグレーション / 継続的デリバリー(CI / CD)プロセスの 3 つです。
以降の演習では、Kubernetes とその他のインフラストラクチャ リソースを使用して適切に設計されたアプローチで異種混合デプロイメントの一般的なユースケースの実習を行います。
設定と要件
[ラボを開始] ボタンをクリックする前に
こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。
このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。
このラボを完了するためには、下記が必要です。
- 標準的なインターネット ブラウザ(Chrome を推奨)
- ラボを完了するために十分な時間を確保してください。ラボをいったん開始すると一時停止することはできません。
ラボを開始して Google Cloud コンソールにログインする方法
-
[ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。
- [Google コンソールを開く] ボタン
- 残り時間
- このラボで使用する必要がある一時的な認証情報
- このラボを行うために必要なその他の情報(ある場合)
-
[Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。 -
必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。
-
[ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。
重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。 -
その後次のように進みます。
- 利用規約に同意してください。
- 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
- 無料トライアルには登録しないでください。
その後このタブで Cloud Console が開きます。
Cloud Shell をアクティブにする
Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
- Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。
接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。
gcloud
は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。
- (省略可)次のコマンドを使用すると、有効なアカウント名を一覧表示できます。
-
[承認] をクリックします。
-
出力は次のようになります。
出力:
- (省略可)次のコマンドを使用すると、プロジェクト ID を一覧表示できます。
出力:
出力例:
gcloud
ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。
ゾーンを設定する
ローカルゾーンとして
このラボのサンプルコードを入手する
- コンテナと Deployment を作成して実行するためのサンプルコードを入手します。
- 3 つのノードがあるクラスタを作成します(完了するまでに数分かかります)。
タスク 1. Deployment オブジェクトについて学習する
まず、Deployment オブジェクトについて調べます。
-
kubectl
のexplain
コマンドで、Deployment オブジェクトの説明を確認できます。
-
--recursive
オプションを使用してすべてのフィールドを確認することもできます。
- ラボを進めながら explain コマンドを使用すると、Deployment オブジェクトの構造や、各フィールドの機能を理解するのに役立ちます。
タスク 2. Deployment を作成する
-
deployments/auth.yaml
構成ファイルを更新します。
- エディタを開きます。
- Deployment の containers セクションにある
image
を次のように変更します。
-
auth.yaml
ファイルを保存します(Esc
キーを押してから、次のように入力します)。
-
Enter
キーを押します。次に単純な Deployment を作成します。Deployment の構成ファイルを確認します。
出力:
Deployment でレプリカが 1 つ作成され、バージョン 1.0.0 の auth コンテナが使用されていることがわかります。
kubectl create
コマンドを使用して auth Deployment を作成すると、Deployment のマニフェスト内のデータに準拠する Pod が 1 つ作成されます。これは、replicas
フィールドに指定する数を変更することで、Pod の数をスケールできることを意味しています。
- では、
kubectl create
を使用して Deployment オブジェクトを作成しましょう。
- Deployment が実際に作成されていることを確認します。
- Deployment が作成されると、Kubernetes はその ReplicaSet を作成します。Deployment の ReplicaSet が作成されたことを確認できます。
auth-xxxxxxx
のような名前の ReplicaSet が表示されます。
- Deployment の一部として作成された Pod を確認します。ReplicaSet が作成されるときに、Kubernetes によって Pod が 1 つ作成されます。
次に、auth Deployment 用の Service を作成します。Service マニフェスト ファイルについてはすでに説明したためここでは詳細は割愛します。
-
kubectl create
コマンドを使用して auth Service を作成します。
- 次に、同じ手順で hello Deployment を作成して公開します。
- さらに、同じ手順でフロントエンド Deployment を作成して公開します。
- フロントエンドの外部 IP を取得して curl を実行し、フロントエンドを操作します。
hello レスポンスが返されます。
-
kubectl
の出力テンプレート機能を使用して、curl を 1 行で実行することもできます。
完了したタスクをテストする
下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。Kubernetes クラスタに加え、Auth、Hello、フロントエンド Deployment が正常に作成されている場合は、評価スコアが表示されます。
Deployment をスケールする
次は、作成した Deployment をスケールします。そのために、spec.replicas
フィールドを更新します。
-
kubectl explain
コマンドをもう一度使用して、このフィールドの説明を確認してください。
- replicas フィールドは、
kubectl scale
コマンドを使って簡単に更新できます。
Deployment が更新されると、Kubernetes は関連する ReplicaSet を自動的に更新し、Pod の総数が 5 になるように新しい Pod を起動します。
- 5 つの
hello
Pod が実行されていることを確認します。
- 今度はアプリケーションのスケールを戻します。
- ここでも、Pod の数が正しいことを確認します。
Kubernetes の Deployment と、Pod のグループを管理してスケールする方法について学びました。
タスク 3. ローリング アップデート
Deployment では、ローリング アップデートのメカニズムを使用してイメージを新しいバージョンに更新できます。Deployment を新しいバージョンで更新すると、ReplicaSet が新たに作成され、古い ReplicaSet のレプリカ数が減少するにつれて、新しい ReplicaSet のレプリカ数が徐々に増加します。
ローリング アップデートをトリガーする
- Deployment を更新するには、次のコマンドを実行します。
- Deployment の containers セクションにある
image
を次のように変更します。
- 保存して終了します。
保存してエディタを終了すると、更新された Deployment がクラスタに保存され、Kubernetes がローリング アップデートを開始します。
- Kubernetes によって作成された新しい ReplicaSet を確認します。
- ロールアウト履歴にも新しいエントリが表示されます。
ローリング アップデートを一時停止する
実行中のロールアウトで問題が検出された場合は、一時停止してアップデートを中止します。
- 次の手順を試してください。
- ロールアウトの現在の状態を確認します。
- Pod で直接確認することもできます。
ローリング アップデートを再開する
ロールアウトを一時停止すると、新旧のバージョンの Pod が混在した状態になります。
-
resume
コマンドを使用してロールアウトを続行してください。
- ロールアウトの完了後に
status
コマンドを実行すると、次のように表示されます。
出力:
アップデートをロールバックする
新しいバージョンでバグが検出されたと仮定します。この場合は新しいバージョンに問題があると考えられるため、新しいポッドに接続したユーザーにこれらの問題が発生することになります。
調査後にきちんと修正したバージョンをリリースするためには、以前のバージョンにロールバックする必要があります。
-
rollout
コマンドを使用して、以前のバージョンにロールバックします。
- 履歴でロールバックを確認します。
- 最後に、すべての Pod が以前のバージョンにロールバックされていることを確認します。
これで、Kubernetes Deployment のローリング アップデートと、ダウンタイムなしでアプリケーションを更新する方法について学びました。
タスク 4. カナリア デプロイ
本番環境で一部のユーザーを対象に新しいデプロイをテストする場合は、カナリア デプロイメントを使用します。この方法では一部のユーザーに変更をリリースすることで、新しいリリースに伴うリスクを軽減できます。
カナリア デプロイメントを作成する
カナリア Deployment は、新しいバージョンを含む独立した Deployment と、通常の安定した Deployment とカナリア Deployment の両方をターゲットとする Service で構成されています。
- まず、新しいバージョン用の新しいカナリア Deployment を作成します。
出力:
- カナリア Deployment を作成します。
- カナリア Deployment を作成すると、
hello
とhello-canary
の 2 つの Deployment が存在する状態になります。次のkubectl
コマンドを使用して確認してください。
hello
Service のセレクタは、本番環境 Deployment とカナリア Deployment の両方の Pod に一致する app:hello
セレクタを使用します。ただし、カナリア デプロイメントのポッド数は少ないため、少数のユーザーにしか表示されません。
カナリア デプロイメントを確認する
- リクエストに応じて提供される
hello
バージョンを確認できます。
- これを数回実行すると、一定のリクエストが hello 1.0.0 によって処理され、ごく一部(1/4 = 25%)が 2.0.0 によって処理されることがわかります。
完了したタスクをテストする
下の [進行状況を確認] をクリックして、ラボの進捗状況を確認します。カナリア Deployment が正常に作成されている場合は、評価スコアが表示されます。
本番環境でのカナリア デプロイ - セッション アフィニティ
このラボで Nginx サービスに送信した各リクエストは、カナリア デプロイで処理される可能性がありましたが、これを避けたい場合もあります。たとえば、アプリケーションの UI が変更されるユースケースで、ユーザーを混乱させたくないときなどです。このような場合は、ユーザーをいずれかのデプロイに「固定」できます。
これは、セッション アフィニティを指定してサービスを作成することで実現できます。これにより、同じユーザーが常に同じバージョンで処理されます。以下の例では、Service は前と同じですが、新しく追加された sessionAffinity
フィールドが ClientIP に設定されているため、同じ IP アドレスを持つすべてのクライアントのリクエストは、同じバージョンの hello
アプリケーションに送信されることになります。
このテスト環境の設定は簡単ではないためここでは行いませんが、本番環境でのカナリア デプロイには sessionAffinity
を使用することをおすすめします。
タスク 5. Blue/Green デプロイ
オーバーヘッド、パフォーマンスへの影響、ダウンタイムを最小限に抑えながら徐々にアプリケーションをデプロイできるローリング アップデートは、理想的な方法です。さらに、完全にデプロイされるまで新しいバージョンを指定しないようにロードバランサを変更すると効果的な場合があります。これには、Blue / Green デプロイが有効です。
Kubernetes は、古い「Blue」バージョン用と新しい「Green」バージョン用に 2 つの異なるデプロイメントを作成することでこれを実現します。「Blue」バージョンには既存の hello
デプロイメントを使用します。ここでは、ルータとして機能するサービスを介してアクセスします。新しい「Green」バージョンが稼働したら、Service を更新してそのバージョンを使用するように切り替えます。
Service
既存の hello サービスを使用しますが、app:hello
、version: 1.0.0
のセレクタを持つように更新してください。このセレクタは既存の「Blue」デプロイとは一致しますが、使用するバージョンが異なるため、「Green」デプロイメントとは一致しません。
- まずは Service を更新します。
resource service/hello is missing
という警告は無視します(自動的にパッチが適用されるため)。Blue/Green デプロイを使用して更新する
Blue/Green デプロイ スタイルをサポートするために、新しいバージョン用に「Green」Deployment を新たに作成します。この Green Deployment によって、バージョン ラベルとイメージパスが更新されます。
- Green Deployment を作成します。
- 作成した Green Deployment が正常に起動したら、現在のバージョンである 1.0.0 が使用されていることを確認します。
- 次に、新しいバージョンを指定するように Service を更新します。
- Service が更新されると、すぐに「Green」Deployment が使用されるようになり、常に新しいバージョンが使用されていることを確認できます。
Blue/Green ロールバック
必要に応じて、同じ方法で古いバージョンにロールバックできます。
- 「Blue」Deployment が実行されている間に、Service を古いバージョンに戻すだけです。
- Service が更新されたら、ロールバックは完了です。再度、正しいバージョンが使用されていることを確認してください。
これで完了です。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 の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。