このチュートリアルでは、VPA の推奨事項と使用状況の指標を使用して、Google Kubernetes Engine（GKE）ワークロードのサイズを適正化する方法について説明します。
リソースサイズの適正化が重要な理由について
プロビジョニングが十分でない場合、アプリケーションの実行に必要なリソースのコンテナが枯渇して、それらの動作が遅くなり、信頼性が低下する可能性があります。プロビジョニングが過剰な場合、アプリケーションのパフォーマンスには影響しませんが、毎月の請求額が増加する可能性があります。
次のテーブルに、CPU とメモリの過少プロビジョニングおよび過剰プロビジョニングによる影響を示します。
| リソース | プロビジョニングのステータス | リスク | 説明 |
|---|---|---|---|
| CPU | 過剰 | 費用 | 不要なリソースを予約することで、ワークロードの費用が増加します。 |
| 過少 | パフォーマンス | ワークロードが遅くなったり、応答しなくなったりする可能性があります。 | |
| 未設定 | 信頼性 | CPU が 0 にスロットリングされ、ワークロードが応答しなくなる可能性があります。 | |
| メモリ | 過剰 | 費用 | 不要なリソースを予約することで、ワークロードの費用が増加します。 |
| 過少 | 信頼性 | アプリケーションがメモリ不足（OOM）エラーで終了する可能性があります。 | |
| 未設定 | 信頼性 | kubelet が Pod を停止し、それらを失敗としてマークする可能性があります。 |
リポジトリを作成する
指標エクスポータ イメージを保存するリポジトリを作成します。
新しい Docker リポジトリを作成します。
gcloud artifacts repositories create main --repository-format=docker \ --location=$REGION \ --description="docker repository"Docker リポジトリの認証を設定します。
gcloud auth configure-docker $REGION-docker.pkg.dev次のコマンドを実行して、イメージをデプロイします。
gcloud builds submit metrics-exporter --region=$REGION --tag $IMAGE
アプリケーションをデプロイする
次のセクションでは、Terraform を使用して次のタスクを実行します。
- サービス アカウントを作成して、 Google Cloud リソースの管理と操作に必要な権限を割り当てます。
- サービス アカウントにモニタリング閲覧者、BigQuery データ編集者、BigQuery データオーナー、BigQuery ジョブユーザー、Cloud Run 起動元のロールを付与します。
- Artifact Registry から Docker イメージを pull し、指定された構成でイメージを実行する Cloud Run ジョブをデプロイします。
- Cloud Run サービスを毎日トリガーする Cloud Scheduler ジョブを作成します。
- 指標データと推奨事項を保存する BigQuery のデータセット、テーブル、ビューを作成します。
Terraform を構成する
構成の環境変数を設定します。
export TF_VAR_BIGQUERY_DATASET=gke_metrics_dataset export TF_VAR_BIGQUERY_TABLE=gke_metrics export TF_VAR_RECOMMENDATION_WINDOW_SECONDS=1209600 export TF_VAR_RECOMMENDATION_DISTANCE=86400 export TF_VAR_LATEST_WINDOW_SECONDS=600 export TF_VAR_METRIC_WINDOW=259200 export TF_VAR_METRIC_DISTANCE=600このコマンドには次のものが含まれます。
TF_VAR_BIGQUERY_DATASETとTF_VAR_BIGQUERY_TABLE: GKE 指標データを保持します。TF_VAR_RECOMMENDATION_WINDOW_SECONDS: VPA 推奨事項の期間。デフォルトは 1,209,600 秒（14 日）です。TF_VAR_RECOMMENDATION_DISTANCE: VPA 推奨事項データポイントが返される間隔。デフォルトは 86,400 秒（1 日）です。TF_VAR_LATEST_WINDOW_SECONDS: 最近リクエストされたリソース値と上限を取得する期間。デフォルトは 600 秒（10 分）です。METRIC_WINDOW: GKE の使用状況と使用率の指標の期間を設定します。デフォルトは 259,200 秒（3 日）です。METRIC_DISTANCE: データポイントが返される間隔。デフォルトは 600 秒（10 分）です。
これらの値をワークロードのニーズに応じて調整します。たとえば、月に 1 回実行されるバッチ ワークロードの場合は、
TF_VAR_RECOMMENDATION_WINDOW_SECONDSとMETRIC_WINDOWを2592000秒（30 日）に更新します。
Terraform 構成をデプロイする
構成を初期化、検証、適用します。
terraform -chdir=terraform init terraform -chdir=terraform validate terraform -chdir=terraform apply -var project_id=$PROJECT_ID -var region=$REGION -var image=$IMAGEこのコマンドは、実行プランを提供し、変更を行う前に承認を求めます。プランを確認し、すべてが想定どおりになっている場合は、「
yes」と入力して続行します。apply コマンドが正常に完了すると、Terraform によってリソースが作成され、管理されます。
Cloud Scheduler ジョブを手動で実行します。
gcloud scheduler jobs run recommendation-schedule --location ${REGION}
デプロイを確認する
workload-recommendationsの詳細ページで [ログ] タブを選択します。Cloud Run コンソールで指標ログが処理されていることを確認します。
ログには、BigQuery に書き込まれている指標が示されます。出力例を以下に示します。
INFO - Building Row INFO - Successfully wrote 12 rows to BigQuery table [PROJECT_ID].gke_metric_dataset.gke_metrics. INFO - Run Completed出力が一致しない場合は、5 分待ってから
gcloud scheduler jobs run recommendation-schedule --location $REGIONコマンドを実行します。
BigQuery でコンテナの推奨事項を表示する
Google Cloud コンソールの [BigQuery] ページに移動します。
gke_metricsテーブルとcontainer_recommendationsビューにデータが表示されていることを確認します。ワークロードの数によっては、すべての指標を BigQuery に書き込むのに数分かかることがあります。クエリエディタで、
container_recommendationsビューのすべての行を選択します。SELECT * FROM `PROJECT_ID.gke_metrics_dataset.container_recommendations`このプログラムは、Cloud Monitoring から次の指標を抽出します。
ワークロードの詳細: プロジェクト ID、クラスタ名、コントローラ、コンテナ名。
CPU / メモリの使用率と使用量: ワークロードによって使用されている CPU とメモリの使用量と使用率。
リクエストされた量と上限: ワークロードに対してリクエストされた CPU とメモリの量、ワークロードで許可されている CPU とメモリの最大量。
CPU とメモリに関するワークロードの推奨事項: ワークロードが円滑に実行されるように、ワークロードに割り当てられる CPU とメモリの量に関する推奨事項（Deployment に対する VPA の推奨事項と Deployment 以外のオブジェクトに対する目標使用率に基づく）。
Looker Studio で推奨事項を可視化する
Looker Studio はセルフサービス型の無料のビジネス インテリジェンス プラットフォームで、データを可視化し、ダッシュボードやレポートを作成して利用することができます。Looker Studio を使用すると、データに接続し、可視化を行い、分析情報を他のユーザーと共有できます。
Looker Studio を使用して、BigQuery の container_recommendations ビューでデータを可視化します。
- ワークロードのサイズ適正化ダッシュボード テンプレートを開きます。
- [自分のデータを使用] をクリックします。
- プロジェクトを選択します。
- データセットの場合、[
gke_metric_dataset] を選択します。 - テーブルの場合、[
container_recommendations] を選択します。 - [追加] をクリックします。
- [レポートに追加] をクリックします。
Looker Studio テンプレートの詳細
Looker Studio テンプレートの詳細ページには、次の情報が表示されます。
- GKE ワークロードのサイズ適正化の概要: 次のようなクラスタの概要が提供されます。
- 信頼性とパフォーマンスの問題のリスクがあるベスト エフォートとバースト可能なワークロードの数。
- CPU とメモリのリソースを節約できる可能性。正の値は過剰プロビジョニングを示し、負の値は過少プロビジョニングであることを示します。
- ワークロードの推奨事項: ワークロードの CPU とメモリのリクエスト量と上限に関する推奨事項を提供します。
- リスクのある GKE ワークロード: 信頼性とパフォーマンスの問題が発生するリスクが特に高いワークロードが表示されます。
- 履歴 - ワークロードのサイズ適正化 - 現状:ワークロードのサイズ適正化とベスト エフォート型のワークロード数の削減の実装に関する履歴ビューを提供します。
リクエストされた CPU と上限に関するコンテナの推奨事項
リクエストされたワークロードの CPU と上限の値が等しい場合、QoS は保証済みとみなされ、CPU 推奨値は 14 日の期間内で最大値に設定されます。それ以外の場合は、14 日以内にリクエストされた CPU の推奨値の 95 パーセンタイルが使用されます。
CPU リクエストと上限の値が等しい場合、CPU 上限の推奨事項は、Deployment オブジェクトに対してのみ最大 CPU リクエストの VPA 推奨値に設定され、CPU 使用率は目標使用率の 70% に設定されます。ワークロードのリクエストと上限が同じでない場合は、既存の上限比率が使用されます。
リクエストされたメモリと上限に関するコンテナの推奨事項
メモリの推奨事項では、ワークロードの信頼性を確保するために、Deployment オブジェクトに対してのみ最大 VPA 推奨値を使用します。最大メモリ使用量には目標使用率の 80% が使用されます。目標使用率の値は、container_recommendation ビューのクエリで更新できます。
メモリは圧縮不可能なリソースのため、リクエストと上限に同じ量のメモリを使用することをおすすめします。メモリが枯渇した場合は、Pod を削除する必要があります。Pod の削除と環境の不安定化を回避するには、リクエストされたメモリをメモリ制限に設定する必要があります。
優先順位付けに関する推奨事項
各行には優先度の値が割り当てられ、推奨事項に基づいてすぐに対応が必要なワークロードが表示されます。CPU とメモリの単位は異なります。単位を正規化するために、事前定義された CPU とメモリの間の E2 マシンタイプのオンデマンド料金の比率が、メモリ単位を CPU 単位に変換する近似値として使用されます。
優先度は次の式で計算されます。
priority = (CPU requested - CPU recommendation) + ((memory requested -
memory recommendation) / (vCPUs on-demand pricing /memory on-demand pricing ))
Autopilot の場合、デプロイ構成でリクエストされるリソースの合計は、サポートされている最小値と最大値の範囲内にある必要があります。
複数のプロジェクトの VPA 推奨事項を表示する
複数のプロジェクトにわたる VPA コンテナの推奨値を表示するには、スコープ対象のプロジェクトとして新しいプロジェクトを使用します。
このプロジェクトを本番環境にデプロイするときに、分析するすべてのプロジェクトを新しいプロジェクトの指標スコープに追加します。