GSP767

概要

Google Kubernetes Engine クラスタの基盤となるインフラストラクチャは、それぞれが Compute VM インスタンスであるノードで構成されます。このラボでは、クラスタのインフラストラクチャを最適化することで費用を抑え、アプリケーションのアーキテクチャをより効率的なものにする方法を説明します。

貴重なインフラストラクチャ リソースを最大限に活用する（そして、リソースが十分に活用されない事態を防ぐ）ために、ワークロードの例に適切な構成のマシンタイプを選択する戦略を学びます。使用するインフラストラクチャの種類だけでなく、インフラストラクチャの物理的な地理的位置も費用に影響します。この演習では、より高可用性のリージョン クラスタを管理するために費用対効果に優れた戦略を立てる方法も確認します。

目標

このラボでは、次の方法について学びます。

• Deployment のリソース使用状況を確認する
• Deployment をスケールアップする
• マシンタイプが最適化されたノードプールにワークロードを移行する
• クラスタで使用できるロケーション オプションについて学習する
• 異なるゾーンにある Pod 間でのフローログをモニタリングする
• 通信量の多い Pod を移動して、複数ゾーンにまたがるトラフィックの費用を最小限に抑える

設定と要件

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

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

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

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

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

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

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。

ラボを開始して 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 のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

このラボでは、小規模なクラスタを作成して使用します。クラスタのプロビジョニングには、2～5 分程度かかります。

[ラボを開始] ボタンを押した後で、青い文字の「resources being provisioned」というメッセージと、読み込み中であることを意味する円アイコンが表示される場合は、クラスタがまだ作成中です。

この待ち時間の間に次の指示と説明を読み始めても構いませんが、リソースのプロビジョニングが完了するまでシェルコマンドは実行できません。

タスク 1. ノードのマシンタイプを理解する

全体の概要

マシンタイプとは、システムメモリ サイズ、仮想 CPU（vCPU）数、永続ディスクの上限など、仮想マシン（VM）インスタンスで使用できる仮想ハードウェア リソースのセットのことです。マシンタイプはさまざまなワークロード向けにファミリー単位で選別され、グループ化されています。

ノードプールのマシンタイプを選択する場合、一般的に、汎用マシンタイプ ファミリーがさまざまなワークロードで優れたコスト パフォーマンスを発揮します。汎用マシンタイプは、N シリーズと E2 シリーズで構成されます。

マシンタイプの違いがアプリにとって有益なこともあれば、そうでないこともあります。一般的に、E2 は N1 と同程度のパフォーマンスを実現しますが、費用を重視して最適化されています。通常は E2 マシンタイプを使用するだけでも、費用を抑えられます。

ただし、クラスタでは、使用されるリソースがアプリケーションのニーズに応じて最適化されることが特に重要です。大幅にスケールする必要がある大規模なアプリケーションや Deployment の場合、ワークロードを多数の汎用マシンに分散するよりも、少数の最適化されたマシンにスタックする方が費用を抑えられることもあります。

この意思決定を行うには、アプリについて細部まで十分に理解している必要があります。アプリに固有の要件がある場合は、それに合わせてマシンタイプを構成できます。

次のセクションでは、デモアプリを確認し、適切な構成のマシンタイプを使用するノードプールにそのアプリを移行します。

タスク 2. Hello App にふさわしいマシンタイプを選ぶ

Hello デモクラスタの要件を調べる

ラボの開始時に 2 つの e2-medium（vCPU × 2、メモリ 4 GB）ノードを使用して Hello デモクラスタが生成されました。このクラスタは、Hello App という簡単なウェブ アプリケーションのレプリカを 1 つデプロイします。これは Go で記述されたウェブサーバーで、すべてのリクエストに「Hello, World!」というメッセージで応答します。

1. ラボでプロビジョニングが完了した後、Cloud コンソールのナビゲーション メニューをクリックしてから [Kubernetes Engine] > [クラスタ] をクリックします。

2. [Kubernetes クラスタ] ウィンドウで、hello-demo-cluster を選択します。

3. 次のウィンドウで、[ノード] タブを選択します。

クラスタのノード一覧が表示されます。

クラスタのリソースが GKE でどのように利用されているかを観察します。各ノードでリクエストされた CPU とメモリの量や、ノードで割り当て可能な容量がわかります。

4. クラスタの最初のノードをクリックします。

[Pod] セクションを見てください。hello-server Pod が default Namespace にあることがわかります。hello-server Pod が表示されない場合は、前に戻ってクラスタの 2 番目のノードを選択します。

hello-server Pod が 400 mCPU をリクエストしていることがわかります。他にも少数の kube-system Pod が実行中であることが確認できます。これらは GKE のクラスタ サービス（モニタリングなど）を実行するために読み込まれた Pod です。

5. [戻る] ボタンを押して、前の [ノード] ページに戻ります。

Hello-App の 1 つのレプリカと基本的な kube-system サービスを実行するために、2 つの e2-medium ノードが必要であることがわかります。また、クラスタの CPU リソースは大部分が使用されていますが、割り当て可能なメモリは約 3 分の 1 しか使用されていません。

このアプリのワークロードがまったく変動しない場合は、必要な CPU とメモリの使用量も正確にわかるため、それに合わせてカスタマイズしたマシンタイプを作成することも可能でしょう。そのようにすると、クラスタ インフラストラクチャ全体の費用を抑えられます。

しかし実際には、GKE クラスタの実行するワークロードは複数あることが多く、ほとんどの場合スケールアップやスケールダウンが必要です。

Hello App のスケールアップが必要になった場合、何が起こるでしょうか。

Cloud Shell をアクティブにする

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

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

2. ウィンドウで次の操作を行います。

   • Cloud Shell 情報ウィンドウで操作を進めます。
   • Cloud Shell が認証情報を使用して Google Cloud API を呼び出すことを承認します。

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

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

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

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

gcloud auth list

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

出力:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

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

gcloud config list project

出力:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

Hello App をスケールアップする

1. クラスタの認証情報にアクセスします。

gcloud container clusters get-credentials hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

2. Hello-Server をスケールアップします。

kubectl scale deployment hello-server --replicas=2

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 Hello App をスケールアップする

3. コンソールで、左側の [Kubernetes Engine] メニューの [ワークロード] を選択します。

hello-server に「Does not have minimum availability」というエラー ステータスが表示されます。

注: ラボ環境では、このエラーが表示されない場合があります。クラスタの Kubernetes のバージョンによっては、kube-system Pod がリクエストするリソースが小さく、クラスタが新しいワークロードに対応できるためです。エラーが表示されなくても心配はいりません。このエラーの有無が、ラボの完了に影響することはありません。

4. エラー メッセージをクリックしてステータスの詳細を確認します。エラーの原因が「Insufficient cpu」と表示されます。

これは予想どおりです。先ほど確認したとおり、クラスタには CPU リソースの余裕がほとんどない状態でしたが、hello-server の別のレプリカでさらに 400m をリクエストしました。

5. 新しいリクエストに対応できるようにノードプールを拡大します。

gcloud container clusters resize hello-demo-cluster --node-pool my-node-pool \ --num-nodes 3 --zone {{{project_0.default_zone | "ZONE"}}}

6. 続行するかどうかを確認するメッセージが表示されたら、「y」と入力して Enter キーを押します。

7. コンソールで、hello-server ワークロードのステータスが「OK」に変わるまで、[ワークロード] ページを更新します。

クラスタを確認する

ワークロードのスケールアップが正常に行われたら、クラスタの [ノード] タブに戻ります。

1. hello-demo-cluster をクリックします。

2. 次に、[ノード] タブをクリックします。

大きくなったノードプールは、処理の重いワークロードに対応できますが、インフラストラクチャ リソースの使用状況に注目してください。

GKE はクラスタのリソースを最大限に利用していますが、最適化の余地はまだあります。1 つのノードはメモリの大半を使用しているものの、2 つのノードでは相当量のメモリが未使用です。

この時点でアプリのスケールアップを続けると、同じようなパターンが見え始めるでしょう。Kubernetes は、hello-server Deployment の新しいレプリカごとにノードを見つけようとし、見つけられず、CPU が約 600m の新しいノードを作成することになります。

ビンパッキング問題

ビンパッキング問題とは、体積や形状にばらつきがある複数の品目を、数に限りのある、形状の定まった「ビン（容器）」に収めなくてはならないという問題です。基本的には、これらの品目をできる限り少ない数のビンに効率よく「パッキング」することが課題です。

これは、実行するアプリケーションに合わせて Kubernetes クラスタを最適化するときに直面する課題と似ています。多くの場合、複数のアプリケーションがあれば、リソースの要件（メモリ、CPU など）はそれぞれ異なります。これらのアプリケーションを、Kubernetes によって管理されるインフラストラクチャ リソース（おそらくはクラスタの費用のほとんどを占める部分）に、できる限り効率的に収める必要があります。

Hello デモクラスタでは、ビンパッキングが効率よく行われていません。このワークロードにもっと適切なマシンタイプを使用するよう Kubernetes を構成すると、費用効率が向上するでしょう。

注: 説明をわかりやすくするため、このラボでは 1 つのアプリケーションの最適化に専念します。現実には、要件の異なる多数のアプリケーションを Kubernetes クラスタで実行することになるでしょう。Kubernetes には、Kubernetes で利用可能なさまざまなマシンからアプリケーションのワークロードに最適なものを探す際に役立つツールが用意されています。複数の GKE ノードプールを使用して、1 つの Kubernetes クラスタで複数のマシンタイプを管理できます。

最適化されたノードプールに移行する

• より大きなマシンタイプを使用して新しいノードプールを作成します。

gcloud container node-pools create larger-pool \ --cluster=hello-demo-cluster \ --machine-type=e2-standard-2 \ --num-nodes=1 \ --zone={{{project_0.default_zone | "ZONE"}}}

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。ノードプールを作成する

次の手順で Pod を新しいノードプールに移行できます。

1. 既存のノードプールを閉鎖する: これにより、既存のノードプール内のノード（node）がスケジュール不可に設定されます。Kubernetes は、スケジュール不可に設定されたノードに新しい Pod をスケジュールしなくなります。
2. 既存のノードプールをドレインする: これにより、既存のノードプールのノード（node）で実行されているワークロードが正常に強制排除されます。

• まず、元のノードプールを閉鎖します。

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=my-node-pool -o=name); do kubectl cordon "$node"; done

• 次に、プールをドレインします。

for node in $(kubectl get nodes -l cloud.google.com/gke-nodepool=my-node-pool -o=name); do kubectl drain --force --ignore-daemonsets --delete-emptydir-data --grace-period=10 "$node"; done

この時点で、Pod が新しい larger-pool ノードプールで実行されていることが確認できます。

kubectl get pods -o=wide

3. Pod が移行されたので、古いノードプールを削除しても問題ありません。

gcloud container node-pools delete my-node-pool --cluster hello-demo-cluster --zone {{{project_0.default_zone | "ZONE"}}}

4. 続行するかどうかを確認するメッセージが表示されたら、「y」と入力して Enter キーを押します。

削除に 2 分ほどかかります。その間に次のセクションに目を通してください。

費用分析

この時点で、3 台の e2-medium マシンを必要とした同じワークロードを 1 台の e2-standard-2 マシンで実行しています。

そこで、e2 標準マシンタイプと e2 共有コア マシンタイプを使用する 1 時間あたりの費用に注目してみましょう。

標準:

共有コア:

e2-medium マシン 3 台の費用は 1 時間あたり約 $0.1 ですが、e2-standard-2 1 台は 1 時間あたり約 $0.067 です。

1 時間あたり $0.04 の削減は小さいと感じるかもしれませんが、実行するアプリケーションのライフサイクルの間、これがずっと積み重なります。もっと規模が大きければ、さらに目に見える違いがあるでしょう。e2-standard-2 マシンはこのワークロードをより効率よくパッキングできるので、未使用の領域が減り、スケールアップ費用の増加のペースが下がります。

これは興味深い事実です。というのも、e2-medium は共有コア マシンタイプであり、リソースを大量に消費しない小規模なアプリケーションで費用対効果が高くなるように設計されているからです。ところが、Hello-App の現在のワークロードについては、より大きなマシンタイプのノードプールを使用することが、結果としてより費用対効果に優れた戦略となっています。

Cloud コンソールで、hello-demo クラスタの [ノード] タブがまだ表示されているはずです。このタブを更新し、larger-pool ノードの [リクエストされた CPU] と [割り当て可能な CPU] の各フィールドを確認します。

さらに最適化できる余地があることがわかります。この新しいノードには、別のノードをプロビジョニングしなくても、ワークロードの別のレプリカを収めることができます。また、アプリケーションに必要な CPU とメモリの量に適合するカスタムサイズのマシンタイプを選択すると、リソースの使用をさらに抑えられる可能性もあります。

こうした料金はクラスタのロケーションによって異なることに留意する必要があります。このラボの次のセクションでは、最適なリージョンを選択し、リージョン クラスタを管理する方法を説明します。

クラスタに適したロケーションを選択する

リージョンとゾーンの概要

クラスタのノードに使用される Compute Engine リソースは、世界各地の複数のロケーションでホストされています。これらのロケーションはリージョンとゾーンからなります。リージョンとは、リソースをホストできる特定の地理的位置です。リージョンには 3 つ以上のゾーンがあります。

仮想マシン インスタンスやゾーン永続ディスクなど、ゾーンを有効範囲とするリソースはゾーンリソースと呼ばれます。静的外部 IP アドレスなど、それ以外のリソースはリージョン リソースです。リージョン リソースは、ゾーンに関係なく、そのリージョン内のどのリソースでも使用できますが、ゾーンリソースは同じゾーン内の他のリソースでのみ使用できます。

リージョンまたはゾーンを選択する際は、次のことに注意してください。

1. 障害対応 - アプリで使用するリソースが 1 つのゾーン内にのみ配置されている場合、そのゾーンが使用できなくなると、アプリも使用できなくなります。規模が大きく、需要の多いアプリであれば、障害に対応するため、リソースを複数のゾーンまたはリージョンに分散することをおすすめします。
2. ネットワーク レイテンシの短縮 - サービス提供地点に近いリージョンまたはゾーンを選択すると、ネットワーク レイテンシを短縮できます。たとえば、ほとんどの顧客が米国東海岸にいる場合は、このエリアに近いリージョンとゾーンをプライマリとして選択するとよいでしょう。

クラスタのベスト プラクティス

リージョンによる費用の差はさまざまな要因に左右されます。たとえば、us-west2 リージョンのリソースは、us-central1 のリソースより高価になりがちです。

クラスタで使用するリージョンまたはゾーンを選択する際は、アプリで実行する処理を確認します。レイテンシの影響を受けやすい本番環境の場合、ネットワークのレイテンシが少なく、効率が高いリージョンまたはゾーンにアプリを配置すると、パフォーマンスと費用の最適なバランスが得られるでしょう。

これに対して、レイテンシの影響を受けにくい開発環境は、廉価なリージョンに配置することで費用を抑えられます。

注: VM とリージョン別の料金については、VM インスタンスの料金をご覧ください。

クラスタの可用性に対処する

GKE で使用できるクラスタのタイプには、ゾーン（シングルゾーンまたはマルチゾーン）とリージョンがあります。額面の料金では、シングルゾーンのクラスタが最も廉価です。しかし、アプリケーションの高可用性を確保するには、クラスタのインフラストラクチャ リソースを複数のゾーンに分散するのが最適です。

多くのケースで、マルチゾーン クラスタまたはリージョン クラスタを使用してクラスタ内の可用性を優先させると、パフォーマンスと費用のバランスが最適なアーキテクチャになります。

注: マルチゾーン クラスタでは 1 つ以上のゾーンが追加で定義されますが、コントロール プレーンは 1 つのレプリカのみが単一のゾーンで動作します。コントロール プレーンのゾーンが停止しているときもワークロードは実行できますが、コントロール プレーンが使用可能になるまでクラスタの構成を変更することはできません。

リージョン クラスタの場合、コントロール プレーンの複数のレプリカが、特定の 1 リージョン内の複数のゾーンで動作します。ノードも、コントロール プレーンのレプリカが動作する各ゾーンで実行されます。リージョン クラスタは最も多くのリソースを消費する代わりに最大の可用性を提供します。

詳細については、クラスタのタイプに関する記事をご覧ください。

タスク 3. リージョン クラスタを管理する

設定

複数のゾーンにまたがったクラスタのリソース管理は、やや複雑になります。注意を怠ると、Pod 間での不必要なゾーン間通信によって余計な費用が積み重なる可能性があります。

このセクションでは、クラスタのネットワーク トラフィックを観察し、大量のトラフィックを相互に送っている 2 つの Pod を同じゾーンに移動します。

1. [Cloud Shell] タブで、新しいリージョン クラスタを作成します（このコマンドは完了までに数分かかります）。

gcloud container clusters create regional-demo --region={{{project_0.default_region | "REGION"}}} --num-nodes=1

Pod とノードでやり取りされるトラフィックを実際に確認するため、リージョン クラスタ内で 2 つの Pod を別々のノードに作成します。トラフィックをモニタリングするために、ping を使用して Pod 間のトラフィックを生成します。

2. 次のコマンドを実行して、最初の Pod のマニフェストを作成します。

cat << EOF > pod-1.yaml apiVersion: v1 kind: Pod metadata: name: pod-1 labels: security: demo spec: containers: - name: container-1 image: wbitt/network-multitool EOF

3. 次のコマンドを使用して、Kubernetes に最初の Pod を作成します。

kubectl apply -f pod-1.yaml

4. 続けて、次のコマンドを実行して、2 番目の Pod のマニフェストを作成します。

cat << EOF > pod-2.yaml apiVersion: v1 kind: Pod metadata: name: pod-2 spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: security operator: In values: - demo topologyKey: "kubernetes.io/hostname" containers: - name: container-2 image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 EOF

5. 2 番目の Pod を Kubernetes に作成します。

kubectl apply -f pod-2.yaml

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 Pod の作成を確認する

作成した Pod は、node-hello コンテナを使用し、リクエストされたときに Hello Kubernetes メッセージを出力します。

作成した pod-2.yaml ファイルを確認すると、podAntiAffinity がルールとして定義されていることがわかります。これにより、この Pod は pod-1 と同じノードにスケジュールされないように指定されます。pod-1 の security: demo ラベルに基づいて matchExpressions のロジックが適用されるためです。podAffinity は Pod が同じノードにスケジュールされるようにし、podAntiAffinity は Pod が同じノードにスケジュールされないようにします。

注: Kubernetes には Node Affinity のコンセプトもあり、アプリケーションを最適なマシンタイプで実行するために利用できます。

このケースでは、ノード間のトラフィックについて説明するために podAntiAffinity を使用しますが、podAntiAffinity と podAffinity を賢く使用すれば、リージョン クラスタのリソースをさらに効率よく利用できます。

6. 作成した Pod を表示します。

kubectl get pod pod-1 pod-2 --output wide

どちらの Pod も「Running」ステータスと内部 IP を返します。

出力例:

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod-1 1/1 Running 0 33s 10.88.2.3 gke-regional-demo-default-pool-855ab1e8-kqr8 pod-2 1/1 Running 0 21s 10.88.0.5 gke-regional-demo-default-pool-77d74e37-xt63

pod-2 の IP アドレスをメモしておきます。これは次のコマンドで使用します。

トラフィックをシミュレートする

1. pod-1 コンテナへのシェルを取得します。

kubectl exec -it pod-1 -- sh

2. シェルを使用して、pod-2 にリクエストを送信します。ここで [POD-2-IP] は、pod-2 のものとして表示された内部 IP アドレスに置き換えます。

ping [POD-2-IP]

pod-1 から pod-2 への ping で発生する平均レイテンシをメモしておきます。

フローログを確認する

pod-1 から pod-2 に ping が実行されている状態で、クラスタが作成された VPC のサブネットでフローログを有効にして、トラフィックを観察できます。

1. [VPC ネットワーク] > [VPC Flow Logs] コンソールに移動し、[Network Management API を有効にする] をクリックします。

2. [VPC Flow Logs の構成を追加] ボタンをクリックし、[サブネット] で [サブネット向けの構成を追加] をクリックします。

3. [現在のプロジェクトのサブネット] タブの [VPC ネットワーク] プルダウンで、[デフォルト] をオンにして、[OK] をクリックします。

4. 次に、 リージョンのサブネットを選択し、[フローログを管理する] をクリックしてから、[新しい構成を追加] をクリックします。

5. [構成 - サブネット（Compute Engine API）] で [構成を追加] をクリックし、[完了] をクリックします。

6. 次に、[保存] をクリックします。

7. 次に、Cloud コンソールのログ エクスプローラに移動します。[すべてのログ名] をクリックし、[vpc_flows] を選択します。[適用] をクリックします。

ログのリストが表示され、いずれかのインスタンスで送信または受信があるたびに大量の情報が示されます。

注: vpc_flows のログ名がすぐに表示されない場合は、1 分ほど待ってからコンソールを更新してください。

ログが生成されない場合は、上記のスクリーンショットを参考にして、「vpc_flows」の前にある「/」を「%2F」に置き換えます。

このままでは少し読みづらいかもしれません。次に、このログを BigQuery テーブルに書き出して、関連情報をクエリできるようにします。

7. [操作] > [シンクの作成] をクリックします。

8. シンクに「FlowLogsSample」という名前を付けます。

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

シンクの宛先

• [シンクサービスの選択] で [BigQuery データセット] を選択します。
• [BigQuery データセットを選択] で [新しい BigQuery データセットを作成する] を選択します。
• [データセット ID] に「us_flow_logs」と入力し、[データセットを作成] をクリックします。

これ以外はそのままで構いません。

1. [シンクを作成] をクリックします。

2. 新しく作成したデータセットを確認してみましょう。Cloud コンソールのナビゲーション メニューで、[分析] セクションの [BigQuery] をクリックします。

3. [完了] をクリックします。

4. プロジェクト名のプルダウンをクリックし、us_flow_logs データセットを選択して、新しく作成されたテーブルを表示します。テーブルが表示されない場合は、作成されるまで更新してください。

5. us_flow_logs データセットの下で compute_googleapis_com_vpc_flows_xxx テーブルをクリックします。

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

7. BigQuery エディタで、SELECT と FROM の間に以下のコードを貼り付けます。

jsonPayload.src_instance.zone AS src_zone, jsonPayload.src_instance.vm_name AS src_vm, jsonPayload.dest_instance.zone AS dest_zone, jsonPayload.dest_instance.vm_name

8. [実行] をクリックします。

先ほどのフローログが、source zone、source vm、destination zone、destination vm でフィルタされて表示されます。

regional-demo クラスタ内の 2 つのゾーン間で呼び出しが行われている行を探します。

注: 実際のログの数値は、このサンプル画像に示されているものと完全には一致しません。

フローログを観察すると、異なるゾーン間で頻繁にトラフィックが発生することがわかります。

次に、Pod を同じゾーンに移動し、効果を観察してみましょう。

通信量の多い Pod を移動して、複数ゾーンにまたがるトラフィックの費用を最小限に抑える

1. Cloud Shell に戻り、Ctrl+C キーを押して ping コマンドをキャンセルします。

2. exit コマンドを入力して pod-1 のシェルを終了します。

exit

3. 次のコマンドを実行して、pod-2 のマニフェストを編集します。

sed -i 's/podAntiAffinity/podAffinity/g' pod-2.yaml

podAntiAffinity ルールを podAffinity ルールに変更しますが、ロジックは変更しません。これで、pod-2 が pod-1 と同じノードにスケジュールされます。

4. 実行中の pod-2 を削除します。

kubectl delete pod pod-2

5. pod-2 が削除されたら、新しく編集したマニフェストを使用して再作成します。

kubectl create -f pod-2.yaml

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 トラフィックをシミュレートする

6. 作成した Pod を表示し、どちらもステータスが「Running」であることを確認します。

kubectl get pod pod-1 pod-2 --output wide

出力を見ると、pod-1 と pod-2 が同じノードで実行されていることがわかります。

pod-2 の IP アドレスをメモしておきます。これは次のコマンドで使用します。

7. pod-1 コンテナへのシェルを取得します。

kubectl exec -it pod-1 -- sh

8. シェルを使用して、pod-2 にリクエストを送信します。ここで [POD-2-IP] は、先ほどのコマンドで取得した pod-2 の内部 IP に置き換えます。

ping [POD-2-IP]

2 つの Pod 間の ping にかかる平均時間が、かなり短くなったことがわかるでしょう。

この時点で、フローログの BigQuery データセットに戻り、最新のログをチェックして、望ましくないゾーン間通信がなくなったことを確認できます。

費用分析

Google Cloud 内の VM 間外向きトラフィックの料金に注目します。

Pod が別々のゾーンから互いに ping を実行していたときは、1 GB あたり $0.01 の料金が発生していました。少額だと思うかもしれませんが、複数のサービスがゾーン間で頻繁に呼び出しを行う大規模なクラスタであれば、たちまち費用がかさみます。

その後、Pod を同じゾーンに移動したので、ping の実行に料金が発生しなくなりました。

お疲れさまでした

ここでは、GKE クラスタの一部である仮想マシンの費用を最適化する方法について学習しました。まず、より適切なマシンタイプのノードプールにワークロードを移行し、次に、異なるリージョンの長所と短所について理解したうえで、最後に、リージョン クラスタ内にある通信量の多い Pod を通信先の Pod と同じゾーンに配置しました。

このラボでは、GKE VM の費用対効果を高めるためのツールと戦略を紹介しましたが、仮想マシンを最適化するには、まずアプリケーションとそのニーズを理解する必要があります。実行するワークロードの種類を知り、アプリケーションのニーズを見積もると、GKE クラスタの基盤となる仮想マシンに最適なロケーションとマシンタイプの判断が変わってきます。

クラスタのインフラストラクチャを効率的に利用することは、費用の最適化に大いに役立ちます。

次のステップと詳細情報

• マシンタイプに関するドキュメント
• コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティス: 適切なマシンタイプを選択する
• コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティス: 適切なリージョンを選択する

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

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

マニュアルの最終更新日: 2026 年 2 月 18 日

ラボの最終テスト日: 2026 年 2 月 18 日

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