このページは Cloud Translation API によって翻訳されました。

起動レイテンシ指標をモニタリングする

Autopilot Standard

このページでは、Google Kubernetes Engine（GKE）ワークロードと基盤となるクラスタノードの起動レイテンシのモニタリングに使用できる指標とダッシュボードについて説明します。この指標を使用して、起動レイテンシの追跡、トラブルシューティング、削減を行うことができます。

このページは、ワークロードの起動レイテンシをモニタリングして最適化する必要があるプラットフォーム管理者とオペレーターを対象としています。 Google Cloud コンテンツで参照する一般的なロールの詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

概要

起動レイテンシは、アプリケーションがトラフィックの急増にどのように応答するか、レプリカが中断からどれだけ迅速に復元するか、クラスタとワークロードの運用費用をどれだけ効率化できるかに大きく影響します。ワークロードの起動レイテンシをモニタリングすると、レイテンシの低下を検出し、ワークロードとインフラストラクチャの更新が起動レイテンシに与える影響を追跡できます。

ワークロードの起動レイテンシを最適化すると、次のメリットがあります。

トラフィックの急増時に、ユーザーに対するサービスのレスポンスレイテンシを短縮します。
新しいレプリカの作成中に需要の急増を吸収するために必要な余分なサービング容量を削減します。
バッチ計算中に、すでにデプロイされ、残りのリソースの起動を待機しているリソースのアイドル状態時間を短縮します。

始める前に

作業を始める前に、次のことを確認してください。

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API の有効化

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region と compute/zone のプロパティを設定してください。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

Cloud Logging API と Cloud Monitoring API を有効にします。

Enable the APIs

要件

ワークロードの起動レイテンシの指標とダッシュボードを表示するには、GKE クラスタが次の要件を満たしている必要があります。

GKE バージョン 1.31.1-gke.1678000 以降が必要です。
システム指標の収集を構成する必要があります。
システムログの収集を構成する必要があります。
クラスタの POD コンポーネントで kube 状態指標を有効にして、Pod とコンテナの指標を表示します。

必要なロールと権限

ログの生成を有効にしてログにアクセスして処理するために必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

GKE クラスタ、ノード、ワークロードを表示する: プロジェクトに対する Kubernetes Engine ビューア（roles/container.viewer）
起動レイテンシ指標にアクセスしてダッシュボードを表示する: プロジェクトに対するモニタリング閲覧者（roles/monitoring.viewer）
Kubelet イメージの pull イベントなどのレイテンシ情報を含むログにアクセスし、ログエクスプローラとログ分析で表示します。プロジェクトに対するログビューア（roles/logging.viewer）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

起動レイテンシの指標

起動レイテンシ指標は GKE システム指標に含まれ、GKE クラスタと同じプロジェクトの Cloud Monitoring にエクスポートされます。

この表の Cloud Monitoring の指標名には、kubernetes.io/ という接頭辞を付ける必要があります。この接頭辞は、表中の項目では省略されています。

指標タイプ（リソース階層レベル）表示名
種類、タイプ、単位モニタリング対象リソース	説明ラベル
`pod/latencies/pod_first_ready` *（プロジェクト）* Pod の最初の準備完了までのレイテンシ
`GAUGE`、`Double`、`s` k8s_pod	イメージの pull を含む Pod のエンドツーエンドの起動レイテンシ（Pod `Created` から `Ready` まで）。60 秒ごとにサンプリングされます。
`node/latencies/startup` *（プロジェクト）* ノード起動レイテンシ
`GAUGE`、`INT64`、`s` k8s_node	ノード起動の合計レイテンシ（GCE インスタンスの `CreationTimestamp` から `Kubernetes node ready` への初回起動）。60 秒ごとにサンプリングされます。 `accelerator_family`: ハードウェアアクセラレータ（`gpu`、`tpu`、`cpu`）に基づくノードの分類。 `kube_control_plane_available`: KCP（kube コントロールプレーン）が使用可能だったときにノード作成リクエストが受信されたかどうか。
`autoscaler/latencies/per_hpa_recommendation_scale_latency_seconds` *（プロジェクト）* HPA 推奨スケールあたりのレイテンシ
`GAUGE`、`DOUBLE`、`s` k8s_scale	HPA ターゲットの Horizontal Pod Autoscaler（HPA）スケーリングの推奨事項のレイテンシ（指標が作成されてから、対応するスケーリングの推奨事項が apiserver に適用されるまでの時間）。60 秒ごとにサンプリングされます。サンプリング後、データは最長 20 秒間表示されません。 `metric_type`: 指標ソースのタイプ。`"ContainerResource"`、`"External"`、`"Object"`、`"Pods"`、`"Resource"` のいずれかにする必要があります。

ワークロードの起動レイテンシダッシュボードを表示する

ワークロードの [起動レイテンシ] ダッシュボードは、Deployment でのみ使用できます。Deployment の起動レイテンシ指標を表示するには、Google Cloud コンソールで次の操作を行います。

[ワークロード] ページに移動します。

[ワークロード] に移動
[Deployment の詳細] ビューを開くには、検査するワークロードの名前をクリックします。
[オブザーバビリティ] タブをクリックします。
左側のメニューから [起動レイテンシ] を選択します。

Pod の起動レイテンシの分布を表示する

Pod の起動レイテンシは、イメージ pull を含む合計起動レイテンシを指します。これは、Pod の Created ステータスから Ready ステータスまでの時間を測定します。Pod の起動レイテンシは、次の 2 つのグラフを使用して評価できます。

Pod の起動レイテンシ分布グラフ: このグラフには、Pod の起動レイテンシのパーセンタイル（50 パーセンタイル、95 パーセンタイル、99 パーセンタイル）が表示されます。これは、午前 0 時から午前 3 時、午前 3 時から午前 6 時など、3 時間の固定時間間隔で Pod の起動イベントを観測して計算されます。このグラフは、次の目的で使用できます。
- Pod の起動レイテンシのベースラインを把握する。
- Pod 起動レイテンシの経時的な変化を特定します。
- Pod 起動レイテンシの変化を、ワークロードのデプロイやクラスタオートスケーラーイベントなどの最近のイベントと関連付けます。イベントは、ダッシュボード上部の [アノテーション] リストで選択できます。

Pod 起動数グラフ: このグラフは、選択した期間に起動された Pod の数を示します。このグラフは、次の目的で使用できます。
- 特定の期間の Pod 起動レイテンシ分布のパーセンタイルの計算に使用される Pod のサンプルサイズについて説明します。
- ワークロード Deployment や Horizontal Pod Autoscaler イベントなど、Pod の起動の原因を把握します。イベントは、ダッシュボードの上部にある [アノテーション] リストで選択できます。

個々の Pod の起動レイテンシを表示する

個々の Pod の起動レイテンシは、[Pod First Ready Latency] タイムライングラフと関連リストで確認できます。

[Pod First Ready Latency] タイムライングラフを使用して、個々の Pod の起動と最近のイベント（Horizontal Pod Autoscaler イベントや Cluster Autoscaler イベントなど）を関連付けます。これらのイベントは、ダッシュボード上部の [アノテーション] リストで選択できます。このグラフは、他の Pod と比較して起動レイテンシが変化する原因を特定するのに役立ちます。
[Pod First Ready Latency] リストを使用して、起動に最も時間がかかった Pod または最も時間がかからなかった Pod を特定します。リストは [レイテンシ] 列で並べ替えることができます。起動レイテンシが最も高い Pod を特定したら、Pod の起動イベントを他の最近のイベントと関連付けることで、レイテンシの低下をトラブルシューティングできます。

個々の Pod が作成された日時を確認するには、対応する Pod 作成イベントの timestamp フィールドの値を確認します。timestamp フィールドを表示するには、ログエクスプローラで次のクエリを実行します。

   log_id("cloudaudit.googleapis.com/activity") AND
   protoPayload.methodName="io.k8s.core.v1.pods.create" AND
   resource.labels.project_id=PROJECT_ID AND
   resource.labels.cluster_name=CLUSTER_NAME AND
   resource.labels.location=CLUSTER_LOCATION AND
   protoPayload.response.metadata.namespace=NAMESPACE AND
   protoPayload.response.metadata.name=POD_NAME

ワークロードのすべての Pod 作成イベントを一覧表示するには、上記のクエリで次のフィルタを使用します。protoPayload.response.metadata.name=~"POD_NAME_PREFIX-[a-f0-9]{7,10}-[a-z0-9]{5}"

個々の Pod のレイテンシを比較すると、さまざまな構成が Pod の起動レイテンシに与える影響をテストし、要件に基づいて最適な構成を特定できます。

Pod のスケジューリングレイテンシを確認する

Pod のスケジューリングレイテンシは、Pod が作成されてから Pod がノードでスケジュールされるまでの時間です。Pod のスケジューリングレイテンシは、Pod のエンドツーエンドの起動時間に影響します。これは、Pod のスケジューリングイベントと Pod 作成リクエストのタイムスタンプを差し引いて計算されます。

個々の Pod スケジューリングイベントのタイムスタンプは、対応する Pod スケジューリングイベントの jsonPayload.eventTime フィールドで確認できます。jsonPayload.eventTime フィールドを表示するには、ログエクスプローラで次のクエリを実行します。

  log_id("events")
  jsonPayload.reason="Scheduled"
  resource.type="k8s_pod"
  resource.labels.project_id=PROJECT_ID
  resource.labels.location=CLUSTER_LOCATION
  resource.labels.cluster_name=CLUSTER_NAME
  resource.labels.namespace_name=NAMESPACE
  resource.labels.pod_name=POD_NAME

ワークロードのすべての Pod スケジューリングイベントを一覧表示するには、上記のクエリで次のフィルタを使用します。resource.labels.pod_name=~"POD_NAME_PREFIX-[a-f0-9]{7,10}-[a-z0-9]{5}"

イメージ pull のレイテンシを表示する

コンテナイメージの pull レイテンシは、ノードでイメージがまだ使用できない場合や、イメージを更新する必要がある場合に、Pod の起動レイテンシに影響します。イメージの pull レイテンシを最適化すると、クラスタスケールアウトイベント中のワークロードの起動レイテンシが短縮されます。

[Kubelet Image Pull Events] テーブルを表示して、ワークロードコンテナイメージが pull された日時とプロセスに要した時間を確認できます。

イメージの pull レイテンシは jsonPayload.message フィールドで確認できます。このフィールドには次のようなメッセージが含まれます。

  "Successfully pulled image "gcr.io/example-project/image-name" in 17.093s (33.051s including waiting). Image size: 206980012 bytes."

HPA スケーリングの推奨事項のレイテンシ分布を表示する

HPA ターゲットに対する Horizontal Pod Autoscaler（HPA）スケーリングの推奨事項のレイテンシは、指標が作成されてから、対応するスケーリングの推奨事項が API サーバーに適用されるまでの時間です。HPA スケーリングの推奨事項のレイテンシを最適化すると、スケールアウトイベント中のワークロードの起動レイテンシが短縮されます。

HPA スケーリングは、次の 2 つのグラフで確認できます。

HPA スケーリングの推奨のレイテンシ分布チャート: このチャートには、過去 3 時間の期間における HPA スケーリングの推奨事項の観測に基づいて計算された、HPA スケーリングの推奨事項のレイテンシのパーセンタイル（50 パーセンタイル、95 パーセンタイル、99 パーセンタイル）が表示されます。このグラフは、次の目的で使用できます。
- ベースラインの HPA スケーリングの推奨事項のレイテンシを把握する。
- HPA スケーリングの推奨事項のレイテンシの経時的な変化を特定します。
- HPA スケーリングの推奨事項のレイテンシの変化を最近のイベントと関連付けます。ダッシュボードの上部にある [アノテーション] リストでイベントを選択できます。

HPA スケーリングの推奨のレイテンシ分布グラフ — 図: HPA スケーリングの推奨のレイテンシ分布のグラフ

HPA スケーリングの推奨事項の数グラフ: このグラフには、選択した期間に検出された HPA スケーリングの推奨事項の数が表示されます。このグラフは、次のタスクに使用します。
- HPA スケーリングの推奨事項のサンプルサイズについて理解します。サンプルは、特定の期間の HPA スケーリングの推奨事項のレイテンシ分布のパーセンタイルの計算に使用されます。
- HPA スケーリングの推奨事項を、新しい Pod 起動イベントと Horizontal Pod Autoscaler イベントと関連付けます。イベントは、ダッシュボード上部の [アノテーション] リストで選択できます。

HPA スケーリングの推奨事項の数のグラフ — 図: HPA スケーリングの推奨事項の数のチャート

Pod のスケジューリングの問題を表示する

Pod のスケジューリングに関する問題は、ワークロードのエンドツーエンドの起動レイテンシに影響する可能性があります。ワークロードのエンドツーエンドの起動レイテンシを短縮するには、トラブルシューティングを行い、これらの問題の数を減らします。

このような問題を追跡するために使用できるグラフは次の 2 つです。

[スケジュール不可/保留中/失敗した Pod] グラフには、スケジュール不可、保留中、失敗した Pod の数の経時的な変化が表示されます。
[バックオフ/待機中/準備状況チェックに失敗したコンテナ] グラフには、これらの状態のコンテナの数の経時的な変化が表示されます。

ノードの起動レイテンシダッシュボードを表示する

ノードの起動レイテンシ指標を表示するには、Google Cloud コンソールで次の操作を行います。

[Kubernetes クラスタ] ページに移動します。

Kubernetes クラスタに移動
[クラスタの詳細] ビューを開くには、検査するクラスタの名前をクリックします。
[オブザーバビリティ] タブをクリックします。
左側のメニューで [起動レイテンシ] を選択します。

ノードの起動レイテンシの分布を表示する

ノードの起動レイテンシは、ノードの CreationTimestamp から Kubernetes node ready ステータスまでの時間を測定する、起動レイテンシの合計を指します。ノードの起動レイテンシは、次の 2 つのグラフで確認できます。

ノードの起動レイテンシの分布グラフ: このグラフは、固定の 3 時間の時間間隔（午前 0 時～午前 3 時、午前 3 時～午前 6 時など）にわたるノードの起動イベントの観測に基づいて計算された、ノードの起動レイテンシのパーセンタイル（50 パーセンタイル、95 パーセンタイル、99 パーセンタイル）を示します。このグラフは、次の目的で使用できます。
- ベースラインノードの起動レイテンシを把握する。
- ノード起動レイテンシの経時的な変化を特定します。
- ノードの起動レイテンシの変化を、クラスタの更新やノードプールの更新などの最近のイベントと関連付けます。イベントは、ダッシュボード上部の [アノテーション] リストで選択できます。

ノード起動数グラフ: このグラフには、選択した期間に起動されたノードの数が表示されます。このグラフは、次の目的で使用できます。
- 特定の時間間隔のノード起動レイテンシ分布のパーセンタイルの計算に使用されるノードのサンプルサイズについて説明します。
- ノードプールの更新やクラスタオートスケーラーイベントなど、ノードの起動の原因を把握する。ダッシュボード上部の [アノテーション] リストでイベントを選択できます。

個々のノードの起動レイテンシを表示する

個々のノードのレイテンシを比較すると、さまざまなノード構成がノードの起動レイテンシに与える影響をテストし、要件に基づいて最適な構成を特定できます。個々のノードの起動レイテンシは、[ノード起動レイテンシ] タイムライングラフと関連リストで確認できます。

[ノード起動レイテンシ] タイムライングラフを使用して、個々のノードの起動と最近のイベント（クラスタの更新やノードプールの更新など）を関連付けます。他のノードと比較して起動レイテンシが変化する原因を特定できます。ダッシュボード上部の [アノテーション] リストでイベントを選択できます。
[Node Startup Latency] リストを使用して、起動に最も時間がかかったノードまたは最も時間がかからなかったノードを特定します。リストは [レイテンシ] 列で並べ替えることができます。起動レイテンシが最も高いノードを特定したら、ノードの起動イベントと他の最近のイベントを関連付けることで、レイテンシの低下をトラブルシューティングできます。

個々のノードが作成された日時を確認するには、対応するノード作成イベントの protoPayload.metadata.creationTimestamp フィールドの値を確認します。protoPayload.metadata.creationTimestamp フィールドを表示するには、ログエクスプローラで次のクエリを実行します。

   log_id("cloudaudit.googleapis.com/activity") AND
   protoPayload.methodName="io.k8s.core.v1.nodes.create" AND
   resource.labels.project_id=PROJECT_ID AND
   resource.labels.cluster_name=CLUSTER_NAME AND
   resource.labels.location=CLUSTER_LOCATION AND
   protoPayload.response.metadata.name=NODE_NAME

ノードプールの起動レイテンシを表示する

ノードプールの構成が異なる場合（異なるワークロードを実行する場合など）は、ノードプールごとにノードの起動レイテンシを個別にモニタリングする必要があります。ノードプール間でノードの起動レイテンシを比較すると、ノードの構成がノードの起動レイテンシにどのように影響するかに関する分析情報を取得し、レイテンシを最適化できます。

デフォルトでは、[ノード起動レイテンシ] ダッシュボードには、クラスタ内のすべてのノードプール全体の集計された起動レイテンシ分布と個々のノード起動レイテンシが表示されます。特定のノードプールのノードの起動レイテンシを表示するには、ダッシュボードの上部にある $node_pool_name_var フィルタを使用して、ノードプールの名前を選択します。

次のステップ

指標に基づいて Pod の自動スケーリングを最適化する方法を確認する。
GKE でコールドスタートレイテンシを短縮する方法の詳細を確認する。
イメージストリーミングを使用してイメージの pull レイテンシを短縮する方法を確認する。
水平 Pod 自動スケーリングのチューニングの驚くべき経済性について学習する。
自動アプリケーションモニタリングでワークロードをモニタリングします。