GKE 指標の管理

Google Kubernetes Engine(GKE)では、Cloud Monitoring に指標を簡単に送信できます。Cloud Monitoring に指標を取り込み、カスタム ダッシュボードでの表示、アラートの生成、サービスレベル目標の設定を行うことができます。また、Monitoring API を使用してサードパーティのモニタリング サービスから指標を取得することもできます。

GKE にはいくつかの指標のソースが用意されています。

  • システム指標: 重要なシステム コンポーネントの指標。CPU、メモリ、ストレージなどの低レベルのリソースを記述します。
  • Managed Service for Prometheus: Prometheus を大規模に手動で管理、運用しなくても、Prometheus を使用してワークロードのモニタリングや、アラートの送信を行うことができます。
  • コントロール プレーンの指標: API サーバーやスケジューラなどの特定のコントロール プレーン コンポーネントからエクスポートされた指標。
  • ワークロード指標(非推奨): GKE ワークロード(CronJob やアプリケーションの Deployment など)によって公開される指標。

システム指標

クラスタが作成されると、GKE では、デフォルトでシステム コンポーネントによって出力された特定の指標が収集されます。

GKE クラスタから Cloud Monitoring に指標を送信するかどうかを選択できます。Cloud Monitoring に指標を送信する場合は、システム指標を送信する必要があります。

すべての GKE システム指標は、接頭辞 kubernetes.io を付けて Cloud Monitoring に取り込まれます。

料金

Cloud Monitoring は、GKE のシステム指標の取り込みに対して課金しません。詳しくは Cloud Monitoring の料金を確認してください。

システム指標の収集の構成

システム指標の収集を有効にするには、SYSTEM 値を gcloud container clusters create または gcloud container clusters update コマンドの --monitoring フラグと一緒に実行します。

システム指標の収集を無効にするには、--monitoring フラグに NONE 値を使用します。システム指標の収集が無効になっている場合、Google Cloud コンソールの GKE セクション内のクラスタで CPU 使用率、メモリ使用量、ディスク使用量などの基本情報が使用できません。また、Cloud Monitoring GKE ダッシュボードにはクラスタに関する情報は表示されません。

Cloud Monitoring と GKE のインテグレーションの詳細については、Cloud Operations for GKE の構成をご覧ください。

システム指標の一覧

システム指標には、Kubernetes のコア機能に重要なシステム コンポーネントの指標が含まれます。システム指標の一覧をご覧ください。

コントロール プレーンの指標

Kubernetes API サーバー、スケジューラ、コントローラ マネージャーによって出力された特定の指標を Cloud Monitoring に送信するように GKE クラスタを構成できます。

要件

Kubernetes コントロール プレーン コンポーネントによって出力された指標を Cloud Monitoring に送信するには、GKE コントロール プレーン バージョン 1.23.6 以降が必要です。また、システム指標の収集が有効になっている必要があります。

コントロール プレーン指標の収集の構成

既存の GKE クラスタで Kubernetes コントロール プレーンの指標を有効にする手順は次のとおりです。

コンソール

  1. Google Cloud コンソールで、GKE クラスタのリストに移動します。

    Kubernetes クラスタに移動

  2. クラスタの名前をクリックします。

  3. Cloud Monitoring」というラベルの付いた行で、編集アイコンをクリックします。

  4. 表示された [Cloud Monitoring の編集] ダイアログ ボックスで、[Cloud Monitoring を有効にする] が選択されていることを確認します。

  5. [コンポーネント] プルダウン メニューで、指標を収集するコントロール プレーン コンポーネントを選択します。API サーバースケジューラ または Controller Manager を使用します。

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

  7. [変更を保存] をクリックします。

gcloud

  1. Google Cloud SDK と Google Cloud CLI がインストールされているデバイスでターミナル ウィンドウを開きます。操作を行う 1 つの方法として、Cloud Shell を使用します。

  2. コンソールで Cloud Shell をアクティブにします。

    Cloud Shell をアクティブにする

    コンソールの下部にある Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

  3. API_SERVERSCHEDULERCONTROLLER_MANAGER のうち 1 つ以上の値を、gcloud container clusters create コマンドまたは gcloud container clusters update コマンドの --monitoring フラグに渡します。

    たとえば、API サーバー、スケジューラ、コントローラ マネージャーから指標を収集するには、次のコマンドを実行します。

    gcloud container clusters update [CLUSTER_ID] \
      --zone=[ZONE] \
      --project=[PROJECT_ID] \
      --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER
    

指標の形式

Cloud Monitoring に書き込まれる Kubernetes コントロール プレーンの指標はすべて、リソースタイプ prometheus_target を使用します。各指標名には接頭辞 prometheus.googleapis.com/ が使用され、PromQL 指標タイプ(/gauge/histogram/counter など)を示す接尾辞があります。それ以外の場合、各指標名はオープンソースの Kubernetes によって公開される指標名と同一です。

料金

GKE コントロール プレーンの指標は Google Cloud Managed Service for Prometheus を使用して、Cloud Monitoring に指標を取り込みます。Cloud Monitoring では、取り込まれたサンプルの数に基づいて GKE コントロール プレーン指標の取り込みに対して課金されます。Cloud Monitoring の料金をご確認ください。

Monitoring の料金について

取り込まれるサンプル数が最も多いコントロール プレーン指標を特定するには、monitoring.googleapis.com/collection/attribution/write_sample_count 指標を使用します。

  1. コンソールで [Monitoring] を選択します。

    [Monitoring] に移動

  2. [Monitoring] のナビゲーション パネルで、[Metrics Explorer] をクリックします。

  3. [Metric] フィールドで [monitoring.googleapis.com/collection/attribution/write_sample_count] を選択します。

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

  5. [Label] フィールドで attribution_dimension を選択します。

  6. [Comparison] フィールドで [= (equals)] を選択します。

  7. [Value] に「cluster」と入力します。

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

  9. 必要に応じて、特定の指標のみをフィルタします。特に、API サーバーの指標は指標名に「apiserver」が含まれ、スケジューラの指標は指標名に「scheduler」が含まれているため、この文字列を含む指標に限定できます。

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

    • [Label] フィールドで metric_type を選択します。

    • [Comparison] フィールドで [=~ (equals regex)] を選択します。

    • [Value] に「.*apiserver.*」または「.*scheduler.*」と入力します。

    • [DONE] をクリックします。

  10. 必要に応じて、取り込まれたサンプル数を GKE リージョンまたはプロジェクトでグループ化します。

    • [Group by] をクリックします。

    • metric_type が選択されていることを確認します。

    • GKE リージョンでグループ化するには、[location] を選択します。

    • プロジェクトでグループ化するには、[project_id] を選択します。

    • [OK] をクリックします。

  11. 必要に応じて、取り込まれたサンプル数を GKE クラスタ名でグループ化します。

    • [Group by] をクリックします。

    • GKE クラスタ名でグループ化するには、attribution_dimensionattribution_id の両方が選択されていることを確認します。

    • [OK] をクリックします。

  12. 指標のリストの上にある列ヘッダーの [Value] をクリックして、指標のリストを降順で並べ替えます。

以下の手順では、Cloud Monitoring に取り込まれたサンプルレートが最も高い指標について説明しています。GKE コントロール プレーンの指標は取り込みサンプル数に応じて課金されるため、取り込まれるサンプルが最も多い指標に注意してください。

Cloud Monitoring からのエクスポート

コントロール プレーンの指標は、Cloud Monitoring API を使用して Cloud Monitoring からエクスポートできます。コントロール プレーンの指標は Managed Service for Prometheus を使用して取り込まれるため、コントロール プレーンの指標は、PromQL を使用してクエリするか、MQL を使用してクエリできます。

割り当て

コントロール プレーンの指標は、Cloud Monitoring API の「1 分あたりの時系列取り込みリクエスト」の割り当てを消費します。コントロール プレーンの指標を有効にする前に、その割り当ての直近のピーク使用量を確認することをおすすめします。同じプロジェクトに多くのクラスタがある場合や、すでに割り当ての上限に近づいている場合は、コントロール プレーンの指標を有効にする前に割り当ての上限の引き上げをリクエストすることをおすすめします。

指標のクエリ

コントロール プレーンの指標をクエリするときに使用する名前は、PromQL と Cloud Monitoring の機能(Metrics Explorer、MQL、ダッシュボードなど)のどちらを使用するかによって異なります。以下の API サーバーの指標スケジューラの指標コントローラ マネージャーの指標の表では、各指標名に 2 つのバージョンが表示されています。

API サーバーの指標

API サーバーの指標を有効にすると、次の表に示されているすべての指標が、GKE クラスタと同じプロジェクトの Cloud Monitoring にエクスポートされます。

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

PromQL 指標名リリース ステージ
Cloud Monitoring の指標名
種類、タイプ、単位
モニタリング対象リソース
必要な GKE バージョン
説明
ラベル
apiserver_current_inflight_requests 一般提供
apiserver_current_inflight_requests/gauge
GaugeDouble1
prometheus_target
1.23.6+
この apiserver で現在使用されている処理中のリクエストの上限(過去 1 秒間のリクエストの種類ごと)。

request_kind
apiserver_request_duration_seconds 一般提供
apiserver_request_duration_seconds/histogram
CumulativeDistributions
prometheus_target
1.23.6+
動詞、ドライラン値、グループ、バージョン、リソース、サブリソース、スコープ、コンポーネントごとのレスポンスのレイテンシの分布(秒)。

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total 一般提供
apiserver_request_total/counter
CumulativeDouble1
prometheus_target
1.23.6+
動詞、ドライラン値、グループ、バージョン、リソース、スコープ、コンポーネント、HTTP レスポンス コードごとに分類された apiserver リクエストのカウンタ。

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes 一般提供
apiserver_response_sizes/histogram
CumulativeDistribution1
prometheus_target
1.23.6+
グループ、バージョン、動詞、リソース、サブリソース、スコープ、コンポーネントごとのレスポンス サイズの分布(バイト単位)。

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects 一般提供
apiserver_storage_objects/gauge
GaugeDouble1
prometheus_target
1.23.6+
最終チェック時に保存されたオブジェクトの数(種類別)。

resource
apiserver_admission_controller_admission_duration_seconds 一般提供
apiserver_admission_controller_admission_duration_seconds/histogram
CumulativeDistributions
prometheus_target
1.23.6+
アドミッション コントローラのレイテンシのヒストグラム(秒単位)。オペレーション、API リソースと種類(検証または承認)ごとに分類されます。

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds 一般提供
apiserver_admission_step_admission_duration_seconds/histogram
CumulativeDistributions
prometheus_target
1.23.6+
アドミッション サブステップのレイテンシのヒストグラム(秒単位)。オペレーションごとに API リソースとステップタイプ(検証または承認)で分類されます。

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds 一般提供
apiserver_admission_webhook_admission_duration_seconds/histogram
CumulativeDistributions
prometheus_target
1.23.6+
アドミッション Webhook レイテンシのヒストグラム(秒単位)。名前で識別され、各オペレーションと API リソースとタイプ(検証または承認)で分類されます。

name
operation
rejected
type

スケジューラの指標

スケジューラの指標を有効にすると、次の表に示されているすべての指標が、GKE クラスタと同じプロジェクトの Cloud Monitoring にエクスポートされます。

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

PromQL 指標名リリース ステージ
Cloud Monitoring の指標名
種類、タイプ、単位
モニタリング対象リソース
必要な GKE バージョン
説明
ラベル
scheduler_pending_pods 一般提供
scheduler_pending_pods/gauge
GaugeDouble1
prometheus_target
1.23.6+
保留中の Pod の数(キュータイプ別)。「active」は activeQ 内の Pod 数を表します。「Backoff」は、backoffQ 内の Pod 数を表します。「unschedulable」は、unschedulablePods 内の Pod 数を表します。

queue
scheduler_preemption_attempts_total 一般提供
scheduler_preemption_attempts_total/counter
CumulativeDouble1
prometheus_target
1.23.6+
現在までのクラスタ内のプリエンプション試行回数
scheduler_preemption_victims 一般提供
scheduler_preemption_victims/histogram
CumulativeDistribution1
prometheus_target
1.23.6+
選択したプリエンプションの対象数
scheduler_scheduling_attempt_duration_seconds 一般提供
scheduler_scheduling_attempt_duration_seconds/histogram
CumulativeDistribution1
prometheus_target
1.23.6+
スケジューリングのレイテンシ(秒単位)(スケジューリング アルゴリズムとバインディング)。

profile
result
scheduler_schedule_attempts_total 一般提供
scheduler_schedule_attempts_total/counter
CumulativeDouble1
prometheus_target
1.23.6+
Pod のスケジュール設定の試行回数(結果別)。「unschedulable」は、Pod をスケジュールできなかったことを表し、「error」は内部スケジューラの問題を表します。

profile
result

コントローラ マネージャーの指標

コントローラ マネージャーの指標を有効にすると、次の表に示されているすべての指標が、GKE クラスタと同じプロジェクトの Cloud Monitoring にエクスポートされます。

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

PromQL 指標名リリース ステージ
Cloud Monitoring の指標名
種類、タイプ、単位
モニタリング対象リソース
必要な GKE バージョン
説明
ラベル
node_collector_evictions_total 一般提供
node_collector_evictions_total/counter
CumulativeDouble1
prometheus_target
1.24+
NodeController の現在のインスタンスの開始後に発生したノード エビクションの数。

zone

ワークロード指標

GKE クラスタでワークロード指標を使用している場合は、クラスタを GKE 1.24 にアップグレードする前に、Prometheus 向けのマネージド サービスに移行します。これは、GKE 1.24 でワークロード指標のサポートが削除されているためです。

GKE 1.20.8-gke.2100 以降と GKE バージョン 1.24 以前には、GKE ワークロードによって公開された Prometheus 形式の指標を収集するためのフルマネージド指標収集パイプライン(CronJob やアプリケーションの Deployment など)が用意されており、これらの指標を Cloud Monitoring に送信できます。

GKE ワークロード指標パイプラインによって収集されたすべての指標は、接頭辞 workload.googleapis.com を付けて Cloud Monitoring に取り込まれます。

GKE ワークロード指標の利点は次のとおりです。

  • 簡単な設定: 単一の kubectl コマンドで PodMonitor カスタム リソースをデプロイし、指標の収集を開始できます。手動でのエージェントのインストールは必要ありません。
  • 柔軟な構成が可能: スクレイピング エンドポイント、頻度、その他のパラメータを調整できます。
  • フルマネージド: Google がパイプラインを管理するので、ユーザーは自分のアプリケーションに集中できます。
  • 費用の管理: 指標を柔軟にフィルタリングできるため、Cloud Monitoring のコストを簡単に管理できます。
  • オープン標準: Prometheus Operator の PodMonitor リソースに従ってモデル化された PodMonitor カスタム リソースを使用して、ワークロード指標を構成できます。
  • 低価格設定: より直感的かつ予測可能で手頃な価格設定となっています。
  • Autopilot のサポート: GKE Standard と GKE Autopilot クラスタの両方に対応しています。

要件

GKE ワークロード指標には GKE コントロール プレーンのバージョン 1.20.8-gke.2100 以降が必要であり、GKE Windows ワークロードをサポートしていません。

ワークロード指標のパイプラインを有効にする場合は、システム指標の収集も有効にする必要があります。

手順 1: ワークロード指標パイプラインを有効にする

既存の GKE クラスタでワークロード指標収集パイプラインを有効にするには、次の手順を行います。

コンソール

  1. Google Cloud コンソールで、GKE クラスタのリストに移動します。

    Kubernetes クラスタに移動

  2. クラスタの名前をクリックします。

  3. [Cloud Monitoring] 行にある編集アイコンをクリックします。

  4. 表示された [Cloud Monitoring の編集] ダイアログ ボックスで、[Cloud Monitoring を有効にする] が選択されていることを確認します。

  5. プルダウン メニューで [ワークロード] を選択します。

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

  7. [変更を保存] をクリックします。

gcloud

  1. Google Cloud CLI がインストールされているデバイスでターミナル ウィンドウを開きます。たとえば、Cloud Shell を使用してこの操作を行います。

  2. コンソールで Cloud Shell をアクティブにします。

    Cloud Shell をアクティブにする

    コンソールの下部にある Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

  3. 次のコマンドを実行します。

    gcloud beta container clusters update [CLUSTER_ID] \
      --zone=[ZONE] \
      --project=[PROJECT_ID] \
      --monitoring=SYSTEM,WORKLOAD
    

    gcloud beta container clusters create または gcloud beta container clusters update コマンドの --monitoring フラグに WORKLOAD 値を含めると、ワークロード指標収集パイプラインが有効になります。

ワークロード指標の収集パイプラインを有効にすると、Kubernetes ワークロードによって発行されたアプリケーション指標を収集できる各ノードに指標収集エージェントがデプロイされます。

Cloud Monitoring と GKE のインテグレーションの詳細については、Cloud Operations for GKE の構成をご覧ください。

手順 2: 収集する指標を構成する

1)my-pod-monitor.yaml という名前の PodMonitor カスタム リソースを作成します。


apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  # POD_MONITOR_NAME is how you identify your PodMonitor
  name: [POD_MONITOR_NAME]
  # POD_NAMESPACE is the namespace where your workload is running, and the
  # namespace of your PodMonitor object
  namespace: [POD_NAMESPACE]
spec:
  # POD_LABEL_KEY and POD_LABEL_VALUE identify which pods to collect metrics
  # from. For example, POD_LABEL_KEY of app.kubernetes.io/name and
  # POD_LABEL_VALUE of mysql would collect metrics from all pods with the label
  # app.kubernetes.io/name=mysql
  selector:
    matchLabels:
      [POD_LABEL_KEY]: [POD_LABEL_VALUE]
  podMetricsEndpoints:
    # CONTAINER_PORT_NAME is the name of the port of the container to be scraped
    # Use the following command to list all ports exposed by the container:
    # kubectl get pod [POD_NAME] -n [POD_NAMESPACE] -o json | jq '.items[].spec.containers[].ports[]?' | grep -v null
    # If the port for your metrics does not have a name, modify your application's pod spec
    # to add a port name.
  - port: [CONTAINER_PORT_NAME]

2)Google Cloud CLI を使用して認証情報を初期化し、kubectl を設定します。

gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]

3)PodMonitor カスタム リソースをデプロイします。

kubectl apply -f my-pod-monitor.yaml

料金

Cloud Monitoring では、取り込まれたサンプルの数に基づいて GKE ワークロード指標の取り込みに対して課金されます。詳しくは Cloud Monitoring の料金を確認してください。

費用の管理

費用を管理するには、まず、モニタリングのニーズに最も適したワークロード指標を決めます。GKE ワークロード指標パイプラインではきめ細かな制御が可能なため、詳細な指標の取得とコストの削減で適切なトレードオフを実現できます。

多くのアプリケーションでは、さまざまな Prometheus 指標が公開されています。デフォルトでは、GKE ワークロード指標パイプラインでは、選択された各 Pod から 60 秒ごとにすべての指標が取得されます。

次の方法を使用して指標のコストを削減できます。

  1. スクレイピング頻度の調整: 指標のコストを削減するには、必要に応じてスクレイピング頻度を下げることをおすすめします。たとえば、ビジネスに関連する KPI がゆっくりと変化する場合は、10 分ごとにスクレイピングするだけで十分です。PodMonitor で、interval を設定してスクレイピング頻度を制御します。

  2. 指標のフィルタリング: Cloud Monitoring で使用されていない指標を特定し、metricRelabelings を使用してダッシュボード、アラート、SLO に役立つ指標のみが Cloud Monitoring に送信されるようにします。

両方の手法を使用する PodMonitor カスタム リソースの具体的な例を次に示します。

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: prom-example
  namespace: gke-workload-metrics
spec:
  selector:
    matchLabels:
      app: example
  podMetricsEndpoints:
  - port: metrics
    path: /metrics
    scheme: http

    # (1) scrape metrics less frequently than the default (once every 60s)
    interval: 10m

    metricRelabelings:

    - # (2) drop the irrelevant metric named "foo" and all metrics
      # with the prefix "bar_"
      sourceLabels: [__name__]
      regex: foo|bar_.*
      action: drop

    - # (3) keep only metrics with a subset of values for a particular label
      sourceLabels: [region]
      regex: us-.*
      action: keep

取り込まれたサンプル数が最も多い指標を特定するには、monitoring.googleapis.com/collection/attribution/write_sample_count 指標を使用します。

  1. コンソールで [Monitoring] を選択します。

    [Monitoring] に移動

  2. [Monitoring] のナビゲーション パネルで、[Metrics Explorer] をクリックします。

  3. [Metric] フィールドで [monitoring.googleapis.com/collection/attribution/write_sample_count] を選択します。

  4. 必要に応じて、GKE ワークロードの指標のみをフィルタリングします。

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

    • [Label] フィールドで metric_domain を選択します。

    • [Value] に「workload.googleapis.com」と入力します。

    • [DONE] をクリックします。

  5. 必要に応じて、Kubernetes 名前空間、GKE リージョン、Google Cloud プロジェクト、またはモニタリング対象のリソースタイプによって取り込まれたサンプル数をグループ化します。

    • [Group by] をクリックします。

    • Kubernetes 名前空間でグループ化するには、[attribution_dimension] と [attribution_id] を選択します。

    • GKE リージョンでグループ化するには、[location] を選択します。

    • Cloud プロジェクト別にグループ化するには、[resource_container] を選択します。

    • モニタリング対象のリソースタイプでグループ化するには、[resource_type] を選択します。

  6. 指標のリストの上にある列ヘッダーの [Value] をクリックして、指標のリストを降順で並べ替えます。

以下の手順では、Cloud Monitoring に取り込まれたサンプルレートが最も高い指標について説明しています。GKE ワークロードの指標は取り込みサンプル数に応じて課金されるため、取り込まれるサンプルが最も多い指標に注意してください。これらの指標の取得頻度を減らすことが可能かどうか、あるいは収集を停止できるかどうかを検討してください。

最後に、Cloud Monitoring に取り込まれた GKE 指標のコストを把握して、これらの費用を最適化するために利用できる多くのリソースがあります。Cloud Monitoring の費用を削減するその他の方法については、費用の最適化ガイドをご覧ください。

以前のバージョンの GKE

GKE コントロール プレーンのバージョンが 1.20.8-gke.2100 より前のクラスタでアプリケーション指標を収集するには、Stackdriver Prometheus サイドカーを使用します。

トラブルシューティング

Cloud Monitoring で指標が予期したとおりに表示されない場合は、以降のセクションの手順でトラブルシューティングを行います。

システム指標のトラブルシューティング

Cloud Monitoring でシステム指標が予期したとおりに表示されない場合は、次の手順で問題を解決できます。

指標エージェントに十分なメモリがあることを確認する

ほとんどの場合、GKE 指標エージェントのリソースはデフォルトの割り当てで十分です。ただし、DaemonSet が頻繁にクラッシュする場合は、次の手順で終了の理由を確認できます。

  1. GKE 指標エージェントの Pod の名前を取得します。

    kubectl get pods -n kube-system -l component=gke-metrics-agent
    

    ステータスが CrashLoopBackOff の Pod を見つけます。

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

    NAME                    READY STATUS           RESTARTS AGE
    gke-metrics-agent-5857x 0/1   CrashLoopBackOff 6        12m
    
  2. ステータスが CrashLoopBackOff の Pod の説明を取得します。

    kubectl describe pod POD_NAME -n kube-system
    

    POD_NAME は、前の手順の Pod の名前に置き換えます。

    Pod の終了の理由が OOMKilled の場合、エージェントに追加のメモリが必要です。

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

      containerStatuses:
      ...
      lastState:
        terminated:
          ...
          exitCode: 1
          finishedAt: "2021-11-22T23:36:32Z"
          reason: OOMKilled
          startedAt: "2021-11-22T23:35:54Z"
    
  3. 失敗した指標エージェントを含むノードに一時的なノードラベルを追加します。このラベルはアップグレード後に保持されません。

    kubectl label node/NODE_NAME \
    ADDITIONAL_MEMORY_NODE_LABEL --overwrite
    

    ADDITIONAL_MEMORY_NODE_LABEL を次のいずれかに置き換えます。

    • 10 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=10
    • 20 MB を追加するには: cloud.google.com/gke-metrics-agent-scaling-level=20

    NODE_NAME は、影響を受ける指標エージェントのノードの名前に置き換えます。

    また、永続ノードラベルを使用して新しいノードプールを作成し、Node Taints を使用してワークロードを新しいノードプールに移行することもできます。

    永続ラベルを持つノードプールを作成するには、次のコマンドを実行します。

    gcloud container node-pools create NODEPOOL_NAME \
     --cluster=CLUSTER_NAME  \
     --node-labels=ADDITIONAL_MEMORY_NODE_LABEL
    

    次のように置き換えます。

    • CLUSTER_NAME: 既存のクラスタの名前。
    • NODEPOOL_NAME: 新しいノードプールの名前。
    • ADDITIONAL_MEMORY_NODE_LABEL: 前の手順で追加したメモリノード ラベルのいずれか(10 MB の追加メモリまたは 20 MB の追加メモリ)。

ワークロード指標のトラブルシューティング

Cloud Monitoring でワークロード指標が予期したとおりに表示されない場合は、次の手順で問題を解決できます。

クラスタが最小要件を満たしていることを確認する

GKE クラスタがコントロール プレーン バージョン 1.20.8-gke.2100 以降を実行していることを確認します。そうでない場合は、クラスタのコントロール プレーンをアップグレードしてください。

ワークロード指標が有効であることを確認する

次の手順で、ワークロード指標の収集パイプラインを有効にするように GKE クラスタが構成されていることを確認します。

コンソール

  1. Google Cloud コンソールで、GKE クラスタのリストに移動します。

    Kubernetes クラスタに移動

  2. クラスタの名前をクリックします。

  3. クラスタの [詳細] パネルで、Cloud Monitoring のステータスにワークロードが含まれていることを確認します。ここに [ワークロード] が表示されていない場合は、ワークロード指標を有効にします

gcloud

  1. gcloud CLI がインストールされているデバイスで、ターミナル ウィンドウを開きます。たとえば、Cloud Shell を使用してこの操作を行います。

  2. コンソールで Cloud Shell をアクティブにします。

    Cloud Shell をアクティブにする

    コンソールの下部にある Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

  3. 次のコマンドを実行します。

    gcloud container clusters describe [CLUSTER_ID] --zone=[ZONE]
    

    コマンドの出力で、monitoringConfig: 行を探します。 2~3 行後の enableComponents: セクションに WORKLOADS が含まれていることを確認します。ここに WORKLOADS がない場合は、ワークロード指標を有効にします

アプリケーションから指標が収集されていることを確認する

Cloud Monitoring でアプリケーションの指標を表示できない場合は、以下の手順で問題を解決できます。この手順ではデモを目的としてサンプル アプリケーションを使用していますが、以下の同じ手順を適用してアプリケーションのトラブルシューティングを行うことができます。

以下に、テストに使用できるサンプル アプリケーションをデプロイする手順を示します。残りの手順では、そのアプリケーションの指標が Cloud Monitoring に表示されない理由について説明します。

  1. prometheus-example-app.yaml という名前のファイルを作成し、次の内容を保存します。

    # This example application exposes prometheus metrics on port 1234.
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: prom-example
      name: prom-example
      namespace: gke-workload-metrics
    spec:
      selector:
        matchLabels:
          app: prom-example
      template:
        metadata:
          labels:
            app: prom-example
        spec:
          containers:
          - image: nilebox/prometheus-example-app@sha256:dab60d038c5d6915af5bcbe5f0279a22b95a8c8be254153e22d7cd81b21b84c5
            name: prom-example
            ports:
            - name: metrics-port
              containerPort: 1234
            command:
            - "/main"
            - "--process-metrics"
            - "--go-metrics"
    
  2. Google Cloud CLI を使用して認証情報を初期化し、kubectl を設定します。

    gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
    
  3. gke-workload-metrics 名前空間を作成します。

    kubectl create ns gke-workload-metrics
    
  4. サンプル アプリケーションをデプロイします。

    kubectl apply -f prometheus-example-app.yaml
    
  5. 次のコマンドを実行して、サンプル アプリケーションが実行されていることを確認します。

    kubectl get pod -n gke-workload-metrics -l app=prom-example
    

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

    NAME                            READY   STATUS    RESTARTS   AGE
    prom-example-775d8685f4-ljlkd   1/1     Running   0          25m
    
  6. アプリケーションが想定どおりに指標を公開していることを確認します。

    上記のコマンドで返された Pod のいずれかを使用して、指標エンドポイントが正しく動作していることを確認します。

    POD_NAME=prom-example-775d8685f4-ljlkd
    NAMESPACE=gke-workload-metrics
    PORT_NUMBER=1234
    METRICS_PATH=/metrics
    kubectl get --raw /api/v1/namespaces/$NAMESPACE/pods/$POD_NAME:$PORT_NUMBER/proxy/$METRICS_PATH
    

    上記のサンプル アプリケーションを使用すると、次のような出力が表示されます。

    # HELP example_random_numbers A histogram of normally distributed random numbers.
    # TYPE example_random_numbers histogram
    example_random_numbers_bucket{le="0"} 501
    example_random_numbers_bucket{le="0.1"} 1.75933011554e+11
    example_random_numbers_bucket{le="0.2"} 3.50117676362e+11
    example_random_numbers_bucket{le="0.30000000000000004"} 5.20855682325e+11
    example_random_numbers_bucket{le="0.4"} 6.86550977647e+11
    example_random_numbers_bucket{le="0.5"} 8.45755380226e+11
    example_random_numbers_bucket{le="0.6"} 9.97201199544e+11
    ...
    
  7. my-pod-monitor.yaml という名前のファイルを作成し、次の内容を保存します。

    # Note that this PodMonitor is in the monitoring.gke.io domain,
    # rather than the monitoring.coreos.com domain used with the
    # Prometheus Operator.  The PodMonitor supports a subset of the
    # fields in the Prometheus Operator's PodMonitor.
    apiVersion: monitoring.gke.io/v1alpha1
    kind: PodMonitor
    metadata:
      name: example
      namespace: gke-workload-metrics
    # spec describes how to monitor a set of pods in a cluster.
    spec:
      # selector determines which pods are monitored.  Required
      # This example matches pods with the `app: prom-example` label
      selector:
        matchLabels:
          app: prom-example
      podMetricsEndpoints:
        # port is the name of the port of the container to be scraped.
      - port: metrics-port
        # path is the path of the endpoint to be scraped.
        # Default /metrics
        path: /metrics
        # scheme is the scheme of the endpoint to be scraped.
        # Default http
        scheme: http
        # interval is the time interval at which metrics should
        # be scraped. Default 60s
        interval: 20s
    
  8. 次の PodMonitor リソースを作成します。

    kubectl apply -f my-pod-monitor.yaml
    

    PodMonitor リソースを作成すると、GKE ワークロード指標パイプラインでは、適切な Pod を検出して定期的な収集が自動的に開始されます。パイプラインでは収集した指標が Cloud Monitoring に送信されます

  9. PodMonitor でラベルと Namespace が正しく設定されていることを確認します。PodMonitor カスタム リソースの namespacematchLabels を反映するように、以下の NAMESPACESELECTOR の値を更新します。次のコマンドを実行します。

    NAMESPACE=gke-workload-metrics
    SELECTOR=app=prom-example
    kubectl get pods --namespace $NAMESPACE --selector $SELECTOR
    

    次のような結果が表示されます。

    NAME                            READY   STATUS    RESTARTS   AGE
    prom-example-7cff4db5fc-wp8lw   1/1     Running   0          39m
    
  10. PodMonitor が Ready 状態であることを確認します。

    次のコマンドを実行して、クラスタにインストールしたすべての PodMonitor を確認します。

    kubectl get podmonitor.monitoring.gke.io --all-namespaces
    

    次のような出力が表示されます。

    NAMESPACE              NAME      AGE
    gke-workload-metrics   example   2m36s
    

    返された結果から関連する PodMonitor を特定し、次のコマンドを実行します(下記のコマンドの example は PodMonitor の名前に置き換えます)。

    kubectl describe podmonitor.monitoring.gke.io example --namespace gke-workload-metrics
    

    kubectl describe から返された結果を調べて、Ready 条件が True であることを確認します。Ready が False の場合は、準備完了ではない理由を示すイベントを探します。

  11. 次に、これらの指標が実際に Cloud Monitoring によって受信されていることを確認します。Google Cloud コンソールの [Cloud Monitoring] セクションで、Metrics Explorer に移動します。

  12. [Metric] フィールドに「example_requests_total」と入力します。

  13. 表示されたプルダウン メニューで、[workload.googleapis.com/example_requests_total] を選択します。

    次の example_requests_total 指標は、サンプル アプリケーションによって出力される Prometheus 指標の一つです。

    プルダウン メニューが表示されない場合や、プルダウン メニューに workload.googleapis.com/example_requests_total が表示されない場合には、数分後にもう一度お試しください。

    すべての指標は、収集元の Kubernetes コンテナ(k8s_container)リソースに関連付けられます。Metrics Explorer の [Resource type] フィールドを使用して、k8s_container を選択できます。namespace_namepod_name などのラベルでグループ化することもできます。

    この指標は、Cloud Monitoring 内の任意の場所で使用することも、Cloud Monitoring API を介してクエリすることもできます。たとえば、このダッシュボードを既存のダッシュボードや新しいダッシュボードに追加するには、右上にある [Save Chart] ボタンをクリックして、ダイアログ ウィンドウで目的のダッシュボードを選択します。

Cloud Monitoring API へ送信されるエラーを確認する

Cloud Monitoring に送信される指標は、カスタム指標の上限内に収める必要があります。エラーは Cloud Monitoring の監査ログに表示されます。

Cloud Logging のログ エクスプローラを使用して、このログフィルタでログを確認します(PROJECT_ID は実際のプロジェクト名に置き換えます)。

resource.type="audited_resource"
resource.labels.service="monitoring.googleapis.com"
protoPayload.authenticationInfo.principalEmail=~".*-compute@developer.gserviceaccount.com"
resource.labels.project_id="[PROJECT_ID]"
severity>=ERROR

これにより、クラスタからの書き込みだけでなく、プロジェクトの Cloud Monitoring へのすべての書き込みでのエラーが表示されます。

Cloud Monitoring の取り込み割り当てを確認する

  1. Cloud Monitoring API の割り当てページに移動します
  2. 関連するプロジェクトを選択します。
  3. [Time series ingestion requests] セクションを開きます。
  4. [Time series ingestionrequests per minute] の [割り当て超過エラーの数] が 0 であることを確認します(その場合、「割り当て超過エラーの数」グラフに「No data is available for the selected tim」と表示されます)。
  5. ピーク使用率が 100% を超える場合は、Pod の数を少なくすること、指標の数を少なくすること、または monitoring.googleapis.com/ingestion_requests 割り当ての割り当て上限のリクエスト増加することを検討します。

DaemonSet がデプロイされていることを確認する

クラスタにワークロード指標の DaemonSet がデプロイされていることを確認します。期待どおりに動作していることを確認するには、kubectl を使用します。

  1. Google Cloud CLI を使用して認証情報を初期化し、kubectl を設定します。

    gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
    
  2. ワークロード指標の DaemonSet が存在し、正常であることを確認します。次のコマンドを実行します。

    kubectl get ds -n kube-system workload-metrics
    

    コンポーネントが正常にデプロイされると、次のような出力が表示されます。

    NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
    workload-metrics   3         3         3       3            3           2m
    

    上記のレプリカの数は、クラスタ内の Linux GKE ノードの数と一致している必要があります。たとえば、3 つのノードを持つクラスタの場合、DESIRED = 3 になります。数分後、READYAVAILABLE の数値が DESIRED の数値と一致するはずです。そうでない場合は、デプロイで問題が発生している可能性があります。

その他の指標

このドキュメントのシステム指標コントロール プレーン指標に加えて、Istio の指標も GKE クラスタで使用可能です。