GSP766

概要

Google Kubernetes Engine（GKE）クラスタに基づいて構築された Google Cloud インフラストラクチャのコスト最適化ソリューションを検討する場合、課金対象リソースを効果的に使用することが重要です。よくある間違いは、1 つのクラスタに対して 1 ユーザーまたは 1 チームを割り当て、クラスタが乱立してしまうことです。

マルチテナンシー クラスタを利用すれば、複数のユーザーやチームが 1 つのクラスタを共有してワークロードを処理することができ、その際、分離性と公平なリソース共有が維持されます。これは、Namespace を作成することにより実現します。Namespace を使用すると、同じ物理クラスタ上に複数の仮想クラスタを存在させることができます。

このラボでは、複数の Namespace を使用してマルチテナント クラスタを構築し、リソースの使用を最適化することで、結果的にコストを最適化する方法を学びます。

目標

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

• GKE クラスタに複数の Namespace を作成する
• Namespace に対するロールベースのアクセス制御を構成する
• Kubernetes のリソースの割り当てを構成して複数の Namespace でリソースを公平に共有する
• 各 Namespace のリソース使用状況を確認するためのモニタリング ダッシュボードを表示、構成する
• Looker Studio で GKE 使用状況測定レポートを生成し、Namespace ごとのリソース使用に関する細かな指標を把握する

設定と要件

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

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、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 のプロダクトやサービスのリストを含むメニューを表示するには、左上のナビゲーション メニューをクリックします。

起動

[ラボを開始] ボタンをクリックすると、ラボ用のリソースをプロビジョニングしていますという青色のメッセージと残り時間の目安が表示されます。これにより、マルチテナント クラスタの管理をテストするための環境が作成、構成されます。約 5 分で、クラスタが作成され、BigQuery データセットがコピーされ、各チームを表すサービス アカウントが生成されます。

処理が完了すると、メッセージは表示されなくなります。

この起動プロセスが完了し、メッセージが消えるのを待ってから、ラボを進めてください。

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 の概要ガイドをご覧ください。

タスク 1. 必要なファイルのダウンロード

1. このラボでは、一部の手順で yaml ファイルを使用して Kubernetes クラスタを構成します。Cloud Shell で、これらのファイルを Cloud Storage バケットからダウンロードします。

gsutil -m cp -r gs://spls/gsp766/gke-qwiklab ~

2. 現在の作業ディレクトリを gke-qwiklab に変更します。

cd ~/gke-qwiklab

タスク 2. Namespace の表示と作成

• 次のコマンドを実行して、デフォルトのコンピューティング ゾーンを設定し、提供されるクラスタ multi-tenant-cluster を認証します。

export ZONE={{{project_0.default_zone|placeholder}}} gcloud config set compute/zone ${ZONE} && gcloud container clusters get-credentials multi-tenant-cluster

デフォルトの Namespace

Kubernetes クラスタには、システムの Namespace がデフォルトで 4 つあります。

1. 現在のクラスタの Namespace の全リストは、次のコマンドで取得できます。

kubectl get namespace

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

NAME STATUS AGE default Active 5m kube-node-lease Active 5m kube-public Active 5m kube-system Active 5m

• default - 他に Namespace が指定されていない場合に使用されるデフォルトの Namespace です
• kube-node-lease - クラスタの各ノードのハートビートに関連付けられた Lease オブジェクトを管理します
• kube-public - クラスタ全体を通してすべてのユーザーが表示または読み取る必要があるリソースに使用されます
• kube-system - Kubernetes システムによって作成されたコンポーネントに使用されます

すべてのリソースが Namespace に属するわけではありません。たとえば、ノード、永続ボリューム、Namespace 自体は Namespace に属しません。

2. 次のコマンドを実行すると、Namespace が指定されたリソースがすべて表示されます。

kubectl api-resources --namespaced=true

Namespace が指定されたリソースを作成する場合、Namespace との関連付けが必要です。関連付けを行うには、--namespace フラグを含めるか、yaml のメタデータ フィールドで Namespace を指定します。

3. また、kubectl get サブコマンドで Namespace を指定すると、その Namespace のリソースを表示できます。例:

kubectl get services --namespace=kube-system

これにより、kube-system Namespace 内のすべての Service が出力されます。

新しい Namespace の作成

注: Namespace を新たに作成する場合、名前の先頭に「kube」を付けないようにしてください。これはシステムの Namespace のために予約されています。

1. team-a 用と team-b 用の 2 つの Namespace を作成します。

kubectl create namespace team-a && \ kubectl create namespace team-b

kubectl get namespace を実行すると、出力に 2 つの新しい Namespace が含まれているはずです。

namespace/team-a created namespace/team-b created

--namespace タグを指定すると、指定された Namespace にクラスタ リソースを作成できます。Deployment や Pod などのリソースの名前は、それぞれの Namespace 内で一意であれば問題ありません。

2. たとえば、次のコマンドを実行して、team-a と team-b のそれぞれの Namespace に同じ名前の Pod をデプロイします。

kubectl run app-server --image=centos --namespace=team-a -- sleep infinity && \ kubectl run app-server --image=centos --namespace=team-b -- sleep infinity

3. kubectl get pods -A を実行すると、app-server という名前の Pod が各 team の Namespace に 1 つずつ、合わせて 2 つあることがわかります。

kubectl get pods -A

出力:

NAMESPACE NAME READY STATUS RESTARTS AGE kube-system event-exporter-gke-8489df9489-k2blq 2/2 Running 0 3m41s kube-system fluentd-gke-fmt4v 2/2 Running 0 113s kube-system fluentd-gke-n9dvn 2/2 Running 0 79s kube-system fluentd-gke-scaler-cd4d654d7-xj78p 1/1 Running 0 3m37s kube-system gke-metrics-agent-4jvn8 1/1 Running 0 3m33s kube-system gke-metrics-agent-b4vvw 1/1 Running 0 3m27s kube-system kube-dns-7c976ddbdb-gtrct 4/4 Running 0 3m41s kube-system kube-dns-7c976ddbdb-k9bgk 4/4 Running 0 3m kube-system kube-dns-autoscaler-645f7d66cf-jwqh5 1/1 Running 0 3m36s kube-system kube-proxy-gke-new-cluster-default-pool-eb9986d5-tpql 1/1 Running 0 3m26s kube-system kube-proxy-gke-new-cluster-default-pool-eb9986d5-znm6 1/1 Running 0 3m33s kube-system l7-default-backend-678889f899-xvt5t 1/1 Running 0 3m41s kube-system metrics-server-v0.3.6-64655c969-jtl57 2/2 Running 0 3m kube-system prometheus-to-sd-d6dpf 1/1 Running 0 3m27s kube-system prometheus-to-sd-rfdlv 1/1 Running 0 3m33s kube-system stackdriver-metadata-agent-cluster-level-79f9ddf6d6-7ck2w 2/2 Running 0 2m56s team-a app-server 1/1 Running 0 33s team-b app-server 1/1 Running 0 33s

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

4. --namespace タグで Namespace を指定して kubectl describe を実行すると、新しく作成された各 Pod の詳細を確認できます。

kubectl describe pod app-server --namespace=team-a

5. 特定の Namespace のリソースのみを扱う場合は、コマンドごとに --namespace フラグを使用するのではなく、次のように kubectl コンテキストで一度設定すれば済みます。

kubectl config set-context --current --namespace=team-a

6. これ以降のコマンドは、--namespace フラグを使用しなくても、指定されている Namespace に対して実行されます。

kubectl describe pod app-server

次のセクションでは、クラスタを整理できるように、Namespace にロールベースのアクセス制御を構成します。

タスク 3. Namespace でのアクセス制御

クラスタ内の Namespace が指定されたリソースへのアクセスをプロビジョニングするには、IAM ロールと Kubernetes に組み込みのロールベース アクセス制御（RBAC）を組み合わせて付与します。IAM ロールはまずアカウントに対してプロジェクトへの初期アクセスを許可します。RBAC 権限はクラスタの Namespace が指定されたリソース（Pod、Deployment、Service など）へのアクセス権をきめ細かく設定します。

IAM ロール

注: プロジェクトで IAM ロールを付与するには、プロジェクト IAM 管理者のロールが割り当てられている必要があります。このロールは、ご利用の一時的な Qwiklabs アカウントですでに設定されています。

Kubernetes のアクセス制御を管理する際は、Identity and Access Management（IAM）を使用して、より上位の組織やプロジェクトのレベルでアクセスと権限を管理します。

IAM には、GKE でのアクセスレベルを管理するためにユーザーとサービス アカウントに割り当てることができる、いくつかのロールが用意されています。RBAC のきめ細かい権限は、IAM によって提供されているアクセス権を下地としたものであり、IAM によるアクセス権を制限することはできません。そのため、Namespace が指定されたマルチテナント クラスタでは、IAM ロールによって付与されるアクセス権を最小限にとどめる必要があります。

以下は、割り当て可能な一般的な GKE の IAM ロールの一覧です。

ロール	説明
Kubernetes Engine 管理者	クラスタとその Kubernetes API オブジェクトを完全に管理するためのアクセス権を付与します。このロールを持つユーザーは、任意のクラスタとその Namespace に含まれるすべてのリソースを作成、編集、削除できます。
Kubernetes Engine デベロッパー	クラスタ内の Kubernetes API オブジェクトへのアクセス権を付与します。このロールを持つユーザーは、任意のクラスタとその Namespace に含まれるリソースを作成、編集、削除できます。
Kubernetes Engine クラスタ管理者	クラスタを管理するためのアクセス権を付与します。このロールを持つユーザーは、クラスタまたはその Namespace に含まれるリソースを直接作成、編集することはできませんが、任意のクラスタを作成、編集、削除することができます。
Kubernetes Engine 閲覧者	GKE リソースへの読み取り専用アクセス権を付与します。このロールを持つユーザーには、Namespace とそのリソースへの読み取り専用アクセス権があります。
Kubernetes Engine クラスタ閲覧者	GKE クラスタを取得して一覧表示できるアクセス権が付与されます。これは、クラスタの Namespace 内のリソースにアクセスする必要があるユーザーに必要な最小限のロールです。

これらのロールのほとんどでは RBAC で制限できない過剰なアクセス権が付与されますが、Kubernetes Engine クラスタ閲覧者の IAM ロールでは、クラスタおよび Namespace が指定されたリソースにアクセスするのに必要十分な権限のみがユーザーに付与されます。

ラボのプロジェクトには、team-a Namespace を使用するデベロッパーを表すサービス アカウントがあります。

• 次のコマンドを実行して、このアカウントに Kubernetes Engine クラスタ閲覧者のロールを付与します。

gcloud projects add-iam-policy-binding ${GOOGLE_CLOUD_PROJECT} \ --member=serviceAccount:team-a-dev@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com \ --role=roles/container.clusterViewer

Kubernetes RBAC

クラスタ内では、すべてのリソースタイプ（Pod、Service、Deployment など）へのアクセスは、ロールまたはクラスタロールのいずれかによって定義されます。Namespace にスコープを設定できるのは、ロールだけです。ロールは、リソースと各リソースで許可されるアクションを示し、ロール バインディングは、そのアクセス権をどのユーザー アカウントまたはグループに割り当てるかを示します。

現在の Namespace にロールを作成するには、リソースタイプと、許可されるアクションのタイプを示す verb を指定します。

1. 単一のルールを持つロールは、kubectl create で次のように作成できます。

kubectl create role pod-reader \ --resource=pods --verb=watch --verb=get --verb=list

複数のルールを持つロールは、yaml ファイルを使用して作成できます。ラボで先ほどダウンロードしたファイルの中にサンプル ファイルがあります。

2. yaml ファイルを調べます。

cat developer-role.yaml

出力例:

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: team-a name: developer rules: - apiGroups: [""] resources: ["pods", "services", "serviceaccounts"] verbs: ["update", "create", "delete", "get", "watch", "list"] - apiGroups:["apps"] resources: ["deployments"] verbs: ["update", "create", "delete", "get", "watch", "list"]

3. 上記のロールを適用します。

kubectl create -f developer-role.yaml

4. team-a-developers サービス アカウントと developer ロールの間にロール バインディングを作成します。

kubectl create rolebinding team-a-developers \ --role=developer --user=team-a-dev@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com

ロール バインディングのテスト

1. サービス アカウントの権限借用のために使用するサービス アカウント キーをダウンロードします。

gcloud iam service-accounts keys create /tmp/key.json --iam-account team-a-dev@${GOOGLE_CLOUD_PROJECT}.iam.gserviceaccount.com

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 Namespace でのアクセス制御

2. Cloud Shell で、[+] をクリックしてターミナルに新しいタブを開きます。

3. ここで、次のコマンドを実行してサービス アカウントを有効にします。これにより、そのアカウントとしてコマンドを実行できるようになります。

gcloud auth activate-service-account --key-file=/tmp/key.json

4. サービス アカウントとして、クラスタの認証情報を取得します。

export ZONE={{{project_0.default_zone|placeholder}}} gcloud container clusters get-credentials multi-tenant-cluster --zone ${ZONE} --project ${GOOGLE_CLOUD_PROJECT}

5. これで、team-a-dev として team-a Namespace の Pod をリストできるようになりました。

kubectl get pods --namespace=team-a

出力:

NAME READY STATUS RESTARTS AGE app-server 1/1 Running 0 6d

6. しかし、team-b Namespace の Pod のリスト取得は制限されています。

kubectl get pods --namespace=team-b

出力:

Error from server (Forbidden): pods is forbidden: User "team-a-dev@a-gke-project.iam.gserviceaccount.com" cannot list resource "pods" in API group "" in the namespace "team-b": requires one of ["container.pods.list"] permission(s).

7. 最初の Cloud Shell タブに戻るか、新しいタブを開きます。

8. クラスタの認証情報を更新し、コンテキストを team-a Namespace にリセットします。

export ZONE={{{project_0.default_zone|placeholder}}} gcloud container clusters get-credentials multi-tenant-cluster --zone ${ZONE} --project ${GOOGLE_CLOUD_PROJECT}

タスク 4. リソースの割り当て

マルチテナント環境でクラスタを共有する場合、ユーザーが適切な割り当て量よりも多いクラスタ リソースを使用できないようにすることが重要です。リソース割り当てオブジェクト（ResourceQuota）は、Namespace でのリソースの使用量を制限する制約を定義します。リソースの割り当てでは、オブジェクト（Pod、Service、StatefulSet など）の数、ストレージ リソース（永続ボリュームの要求、エフェメラル ストレージ、ストレージ クラス）の合計数、コンピューティング リソース（CPU とメモリ）の合計数の上限を指定できます。

1. たとえば、次のコマンドを実行すると、team-a Namespace で許可される Pod の数を 2 つに、ロードバランサの数を 1 つに制限できます。

kubectl create quota test-quota \ --hard=count/pods=2,count/services.loadbalancers=1 --namespace=team-a

2. team-a Namespace に 2 つ目の Pod を作成します。

kubectl run app-server-2 --image=centos --namespace=team-a -- sleep infinity

3. 今度は 3 つ目の Pod を作成してみましょう。

kubectl run app-server-3 --image=centos --namespace=team-a -- sleep infinity

次のようなエラーが表示されるはずです。

Error from server (Forbidden): pods "app-server-3" is forbidden: exceeded quota: test-quota, requested: count/pods=1, used: count/pods=2, limited: count/pods=2

4. リソースの割り当ての詳細は、kubectl describe で確認できます。

kubectl describe quota test-quota --namespace=team-a

出力:

Name: test-quota Namespace: team-a Resource Used Hard -------- ---- ---- count/pods 2 2 count/services.loadbalancers 0 1

ここでは、リソースの割り当てによって上限が設定されているリソースと、各リソースに設定されたハードリミットおよび現在の使用数が表示されています。

5. 次のコマンドを実行して test-quota を更新し、Pod 数の上限を 6 つに設定します。

export KUBE_EDITOR="nano" kubectl edit quota test-quota --namespace=team-a

割り当てを更新するために kubectl で使用する yaml ファイルを編集できるようになります。spec の下にある count/pods がハードリミット値です。

5. spec の count/pods の値を 6 に変更します。

apiVersion: v1 kind: ResourceQuota metadata: creationTimestamp: "2020-10-21T14:12:07Z" name: test-quota namespace: team-a resourceVersion: "5325601" selfLink: /api/v1/namespaces/team-a/resourcequotas/test-quota uid: a4766300-29c4-4433-ba24-ad10ebda3e9c spec: hard: count/pods: "6" count/services.loadbalancers: "1" status: hard: count/pods: "5" count/services.loadbalancers: "1" used: count/pods: "2"

6. Ctrl+X、Y、Enter の順にキーを押して、保存して終了します。

次のコマンドを実行すると、更新された割り当てが出力に反映されているはずです。

kubectl describe quota test-quota --namespace=team-a

出力:

Name: test-quota Namespace: team-a Resource Used Hard -------- ---- ---- count/pods 2 6 count/services.loadbalancers 0 1

CPU とメモリの割り当て

CPU とメモリの割り当てを設定する際には、リクエストの合計（コンテナにおいて必ず取得できる値）の割り当て、または上限の合計（コンテナにおいて超えることができない値）の割り当てを指定できます。

このラボで使用するクラスタには、4 つの e2-standard-2 マシンがあり、それぞれに 2 つのコアと 8 GB のメモリがあります。クラスタのリソースの割り当てを定義するサンプルの yaml ファイルが提供されています。

cpu-mem-quota.yaml

apiVersion: v1 kind: ResourceQuota metadata: name: cpu-mem-quota namespace: team-a spec: hard: limits.cpu: "4" limits.memory: "12Gi" requests.cpu: "2" requests.memory: "8Gi"

1. このファイルの構成を適用します。

注: 現在の作業ディレクトリが gke-qwiklab であることを確認します。 kubectl create -f cpu-mem-quota.yaml

この割り当てを設定すると、すべての Pod の CPU とメモリのリクエストの合計がそれぞれ 2 CPU と 8 GiB に制限され、各上限が 4 CPU と 12 GiB に制限されます。

注: Namespace に CPU またはメモリのリソース割り当てが存在する場合、その Namespace でその後作成されるすべてのコンテナには、作成時に独自の CPU とメモリの制限を定義するか、Namespace に LimitRange としてデフォルト値を割り当てる必要があります。

2. CPU とメモリの割り当てを実際に確認するために、cpu-mem-demo-pod.yaml を使用して新しい Pod を作成します。

cpu-mem-demo-pod.yaml:

apiVersion: v1 kind: Pod metadata: name: cpu-mem-demo namespace: team-a spec: containers: - name: cpu-mem-demo-ctr image: nginx resources: requests: cpu: "100m" memory: "128Mi" limits: cpu: "400m" memory: "512Mi"

3. このファイルの構成を適用します。

kubectl create -f cpu-mem-demo-pod.yaml --namespace=team-a

4. この Pod が作成できたら、次のコマンドを実行して、その CPU とメモリのリクエストおよび上限が割り当てに反映されていることを確認します。

kubectl describe quota cpu-mem-quota --namespace=team-a

出力:

Name: cpu-mem-quota Namespace: team-a Resource Used Hard -------- ---- ---- limits.cpu 400m 4 limits.memory 512Mi 12Gi requests.cpu 100m 2 requests.memory 128Mi 8Gi

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 リソースの割り当て

タスク 5. GKE のモニタリングと GKE 使用状況測定

マルチテナント クラスタでは、各テナントのワークロードとリソースの要件が変化し、リソース割り当ての調整が必要になることがよくあります。Monitoring を使えば、各 Namespace が使用しているリソースの全体像を把握することができます。

GKE 使用状況測定を使えば、リソースの使用状況をより詳細に把握し、その結果、各テナントに関連するコストをより正確に把握できます。

Monitoring のダッシュボード

1. Cloud コンソールで、ページ左上隅のナビゲーション メニューを展開し、このメニューで [オペレーション] > [Monitoring] を選択します。

プロジェクトのワークスペースが構築されるまでしばらく待ちます。

2. [概要] ページが表示されたら、左側のメニューで [ダッシュボード] を選択します。

3. [ダッシュボードの概要] ページで [GKE] を選択します。

[GKE ダッシュボード] には、CPU、メモリ、ディスクの各使用率をいくつかのリソース別に集計した表が表示されます。

たとえば、[Namespace] の表には、クラスタの各 Namespace での使用状況が表示されます。

また、[ワークロード] 表にも、クラスタ上で実行されているワークロードでの使用状況データが表示されます。

4. [すべて表示] をクリックします。

5. [フィルタを追加] ボックスで [Namespaces] > [team-a] を選択します。

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

これにより、ワークロードがフィルタされ、team-a Namespace 上で実行されているワークロードのみが表示されます。

Metrics Explorer

1. 左側のペインで [Metrics Explorer] を選択します。

2. [指標を選択] フィールドで、[指標] プルダウンをクリックします。

3. [リソース名または指標名でフィルタ] に「Kubernetes Container」と入力します。

4. [Kubernetes Container] > [Container] の順にクリックします。

5. [CPU 使用時間] を選択します。

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

注: 指標フィールドに「cp」と入力すると、プルダウン メニューに選択肢として [CPU 使用時間] が表示されます。

7. kube-system Namespace を除外するには、[フィルタ] セクションで [フィルタを追加] をクリックします。

8. ラベルとして [namespace_name] を選択します。

9. 比較法として !=（次と等しくない）、値として kube-system を選択します。

10. 次に、[集計] プルダウンで [Sum] を選択し、[by] プルダウンで [namespace_name] を選択して [OK] をクリックします。

    これにより、コンテナの CPU 使用時間を Namespace 別に示したグラフが表示されます。

GKE 使用状況測定

GKE 使用状況測定では、GKE クラスタのリソースの使用率と使用量を BigQuery データセットにエクスポートし、Looker Studio を使用して可視化できます。これにより、リソースの使用状況をより詳細に把握できます。使用状況測定を使用することで、リソースの割り当てや効率的なクラスタ構成について、より多くの情報に基づいた決定を行うことができます。

注: GKE 指標データが BigQuery に反映されるまでに数時間かかる場合があるため、ラボのプロジェクトには、デモ用にリソース使用量と課金データをシミュレートした BigQuery データセットが含まれています。

次の 2 つのデータセットがプロジェクトに追加されています。

cluster_dataset - クラスタ上で GKE 使用状況測定を有効にする前に手動で作成されたデータセットです。このデータセットには、GKE によって生成された 2 つのテーブル（gke_cluster_resource_consumption と gke_cluster_resource_usage）が含まれており、クラスタの使用状況の指標をもとに継続的に更新されます。

billing_dataset - 課金用に BigQuery Export を有効にする前に手動で作成されたデータセットです。このデータセットには 1 つのテーブル（gcp_billing_export_v1_xxxx）が含まれており、プロジェクトの 1 日あたりの費用をもとに毎日更新されます。

• 次のコマンドを実行して、クラスタ上で GKE 使用状況測定を有効にし、データセット cluster_dataset を指定します。

export ZONE={{{project_0.default_zone|placeholder}}} gcloud container clusters \ update multi-tenant-cluster --zone ${ZONE} \ --resource-usage-bigquery-dataset cluster_dataset

GKE 費用内訳テーブルを作成する

cost_breakdown テーブルは、プロジェクト内の課金テーブルとリソース使用量テーブルから生成できます。このテーブルは、usage_metering_query_template.sql ファイルを使用してクラスタ データセット内で生成します。このテンプレートは、クラスタ リソースの使用方法についてで入手できます。

まず、Cloud Shell でいくつかの環境変数を設定します。

1. 提供された課金テーブルのパス、提供された使用状況測定データセット、新しい費用内訳テーブルの名前を設定します。

export GCP_BILLING_EXPORT_TABLE_FULL_PATH=${GOOGLE_CLOUD_PROJECT}.billing_dataset.gcp_billing_export_v1_xxxx export USAGE_METERING_DATASET_ID=cluster_dataset export COST_BREAKDOWN_TABLE_ID=usage_metering_cost_breakdown

2. 次に、このラボの最初にダウンロードした使用状況測定クエリのテンプレートのパス、生成される使用状況測定クエリの出力ファイル、データの開始日（データの最も早い日付は 2020-10-26）を指定します。

export USAGE_METERING_QUERY_TEMPLATE=~/gke-qwiklab/usage_metering_query_template.sql export USAGE_METERING_QUERY=cost_breakdown_query.sql export USAGE_METERING_START_DATE=2020-10-26

3. これらの環境変数とクエリ テンプレートを使用して、使用状況測定クエリを生成します。

sed \ -e "s/\${fullGCPBillingExportTableID}/$GCP_BILLING_EXPORT_TABLE_FULL_PATH/" \ -e "s/\${projectID}/$GOOGLE_CLOUD_PROJECT/" \ -e "s/\${datasetID}/$USAGE_METERING_DATASET_ID/" \ -e "s/\${startDate}/$USAGE_METERING_START_DATE/" \ "$USAGE_METERING_QUERY_TEMPLATE" \ > "$USAGE_METERING_QUERY"

4. 次のコマンドを実行して、前の手順でレンダリングしたクエリを使って費用内訳テーブルを設定します。

bq query \ --project_id=$GOOGLE_CLOUD_PROJECT \ --use_legacy_sql=false \ --destination_table=$USAGE_METERING_DATASET_ID.$COST_BREAKDOWN_TABLE_ID \ --schedule='every 24 hours' \ --display_name="GKE Usage Metering Cost Breakdown Scheduled Query" \ --replace=true \ "$(cat $USAGE_METERING_QUERY)"

5. Data Transfer では、承認のためのリンクが表示されます。このリンクをクリックして受講者アカウントでログインし、指示に従って version_info を Cloud Shell に貼り付けます。

その後、転送構成が正常に作成されたことを示すメッセージが表示されます。

Looker Studio でデータソースを作成する

1. Looker Studio の [データソース] ページを開きます。

2. 新しいデータソースを追加するには、左上の [作成] > [データソース] をクリックします。

最初に、[まず、アカウントの設定を完了します] のウィンドウが表示されます。

3. 利用規約に同意するチェックボックスをオンにして、[続行] をクリックします。

4. これは一時的なラボ / アカウントなので、[どの更新情報を受け取るかを選択します] の各項目では [いいえ] を選択します。

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

Looker Studio でサポートされている Google コネクタのリストが表示されます。

6. リストから [BigQuery] を選択します。

7. [承認] ボタンをクリックして、Looker Studio が BigQuery プロジェクトにアクセスできるようにします。

8. ページの左上で、データソースの名前を [無題のデータソース] から「GKE 使用状況」に変更します。

9. 最初の列で、[カスタムクエリ] を選択します。

10. プロジェクト列で、ご利用のプロジェクト ID を選択します。

11. [カスタムクエリを入力] ボックスに以下のクエリを入力し、[PROJECT-ID] を Qwiklabs のプロジェクト ID に置き換えます。

SELECT * FROM `[PROJECT-ID].cluster_dataset.usage_metering_cost_breakdown`

12. [接続] をクリックします。

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。GKE のモニタリングと GKE 使用状況測定

13. 次に、右上をクリックします。

データソースが追加されたので、それを使ってレポートを作成してみましょう。

1. データソースのページ上部の [レポートを作成] をクリックします。

注: この時点でエラーが発生した場合、Data Transfer のジョブがまだ完了していない可能性があります。1 分ほど待ってからもう一度試してください。

データソースから新しいレポートを作成する際に、レポートへのデータの追加を求めるメッセージが表示されます。

2. [レポートに追加] をクリックします。

Looker Studio レポートを作成する

レポートでは、BigQuery テーブルに基づいて、データソースから使用状況の指標を可視化できます。

次のようなシンプルなテーブルから始めます。

このテーブルを、Namespace ごとの費用内訳を表示するように構成します。テーブルを選択すると、関連するデータが右側のパネルに表示されます。

1. そのパネルで以下を変更します。

• 期間のディメンション: usage_start_time
• ディメンション: namespace
• 指標: cost

他のフィールドはデフォルト値のままにしておきます。

テーブルに表示されるデータを、Namespace が指定されたリソースのものに制限するには、フィルタを適用します。

2. [データ] パネルで、[フィルタ] セクションの [フィルタを追加] をクリックします。Namespace に割り当てられていないリソースを除外するフィルタを作成します。

3. [保存] をクリックします。

4. もう一度 [フィルタを追加] をクリックし、[フィルタを作成] をクリックして、データを request に制限する 2 つ目のフィルタを作成します。

5. [保存] をクリックしてフィルタを適用します。結果のテーブルは次のようになります。

次に、Namespace ごとの費用内訳を示す円グラフをレポートに追加します。

6. 作成したテーブルを右クリックし、[複製] を選択します。

7. 複製したテーブル オブジェクトをレポートの任意の場所にドラッグします。

8. 次に、構成パネルのヘッダーをクリックします。

9. 表示されたオプションから、円グラフ アイコンをクリックします。

表示される円グラフは次のようになります。

次に、リソースタイプ別に費用内訳を表示するドーナツグラフを追加します。

1. 上部ツールバーの [グラフを追加] をクリックし、（ドーナツグラフ）を選択してドーナツグラフを作成します。

2. グラフをレポートの任意の場所にドラッグし、以下のように構成します。

• 期間のディメンション: usage_start_time
• ディメンション: resource_name
• 指標: cost

3. [フィルタを追加] をクリックして、先ほどのグラフに適用した 2 つのフィルタを選択します。表示されるドーナツグラフは以下のようになります。

4. Namespace 別の内訳を追加するには、[コントロールを追加] をクリックして、[プルダウン リスト] を選択します。

5. ドーナツグラフの横にドラッグし、以下のように設定します。

• 期間のディメンション: usage_start_time
• コントロール フィールド: namespace
• 指標: None

6. [フィルタを追加] をクリックします。

7. リストから [unallocated (namespace filter)] を選択します。

8. コントロールをドーナツグラフに対してのみ有効にするには、セレクタ カーソルを使ってコントロール オブジェクトとドーナツグラフの両方を選択し、両方のオブジェクトを囲むように四角形を描きます。

9. 右クリックして [グループ] を選択し、これらのオブジェクトをグループ化します。

10. レポートをプレビューするには、上部ツールバーの [表示] をクリックします。

表示モードでは、ドーナツグラフの表示を特定の Namespace のものに絞ることができます。

11. ページ上部の [Share] メニューで [レポートをダウンロード] をクリックすると、レポート全体を PDF ファイルでダウンロードできます。

お疲れさまでした

Namespace を利用することで、クラスタをマルチテナントとして構成でき、リソースの使用率低下やクラスタの増加といったリスクを最小限に抑え、追加コストの発生を回避できます。また、Monitoring と GKE 使用状況測定を使用することで、Namespace ごとのリソース使用率を可視化し、リソースの割り当てやクラスタ構成について十分な情報に基づいた決定を行うことができます。

次のステップと詳細情報

• クラスタ マルチテナンシーのドキュメント
• コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティス

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

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

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

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

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