GKE ワークロード指標から Prometheus 向けのマネージドサービスへの移行

コントロールプレーンバージョンが 1.24 以降の GKE クラスタでは、GKE ワークロードの指標を使用できません。このガイドでは、GKE ワークロードの指標から Prometheus 向けのマネージドサービスに移行する方法を説明します。これは、Google Cloud で実行中のユーザーワークロードによって公開される Prometheus スタイルの指標を取得するためのおすすめの方法です。Prometheus 向けのマネージドサービスでは、GKE ワークロードの指標と同等の機能に加えて、いくつかの改善が行われています。

Managed Service for Prometheus には、GKE ワークロードの指標と同様に、指標を収集するためのフルマネージドパイプライン、スケーラビリティの高い時系列ストア、Cloud Monitoring を使用して構成されたダッシュボードとアラートが含まれています。さらに、Managed Service for Prometheus には、クエリとルールでの PromQL のサポートなどが含まれ、オープンソースの Prometheus エコシステムとの互換性が向上しています。

これまで Stackdriver コレクタを使用していたお客様の場合、Prometheus 向けのマネージドサービスは、機能と安定性の向上に加えて、大幅なコスト削減につながります。

ステップ 1: Prometheus 向けのマネージドサービスを有効にする

こちらの手順に沿って、Prometheus 向けのマネージドサービスのマネージドコレクションパイプラインを設定します。

ステップ 2: コレクションの構成を変換する

GKE ワークロード指標は、オープンソースの Prometheus Operator の構成の厳格なサブセットである PodMonitor カスタムリソースを使用して構成されます。一方、Managed Service for Prometheus は、次の 3 種類のカスタムリソースを使用して構成します。

PodMonitoring。単一 Namespace 内でターゲットを収集する Prometheus ジョブを定義します。多数の PodMonitoring カスタムリソースがあります（通常はワークロードごとに 1 つ）。
ClusterPodMonitoring。クラスタ内のすべての名前空間にわたってターゲットを収集する Prometheus ジョブを定義します。このリソースは、クラスタをスコープする指標（kube-state-metrics など）向けの特別なツールです。
OperatorConfig。クラスタ全体の構成を定義します。OperatorConfig カスタムリソースはクラスタごとに 1 つだけです。

使用中のクラスタ内に存在するすべての PodMonitor リソースを一覧表示できます。

kubectl get --all-namespaces --output=yaml podmonitor.monitoring.gke.io | tee wlm-config.yaml

移行を開始するには、以下の例を使用して、既存の PodMonitor カスタムリソースを同等の PodMonitoring と OperatorConfig のカスタムリソースに変換します。移行が完了して検証されるまで、PodMonitor リソースをそのままにすることを強くおすすめします。

GKE ワークロードの指標	Prometheus 向けのマネージドサービス
apiVersion: monitoring.gke.io/v1alpha1 kind: PodMonitor metadata: name: my-pod-monitor namespace: pod-monitor-namespace spec: namespaceSelector: matchNames: - pod-monitor-namespace selector: matchLabels: pod-label-key: pod-label-value podMetricsEndpoints: - port: port-name scrapeTimeout: 20s path: /metrics scheme: http interval: 30s metricRelabelings: - sourceLabels: [__name__] regex: foo\|bar_.* action: drop	apiVersion: monitoring.googleapis.com/v1alpha1 kind: PodMonitoring metadata: name: my-pod-monitor namespace: pod-monitor-namespace spec: selector: matchLabels: pod-label-key: pod-label-value endpoints: - port: port-name timeout: 20s path: /metrics scheme: http interval: 30s --- apiVersion: monitoring.googleapis.com/v1alpha1 kind: OperatorConfig metadata: namespace: gmp-public name: config collection: filter: matchOneOf: # keep metrics if they are # part of a different job - '{job!="my-pod-monitor"}' # apply the metric relabeling logic - '{__name__!~"foo\|bar_.*"}'

GKE ワークロードの指標

Prometheus 向けのマネージドサービス


apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: my-pod-monitor
  namespace: pod-monitor-namespace
spec:
  namespaceSelector:
    matchNames:
    - pod-monitor-namespace
  selector:
    matchLabels:
      pod-label-key: pod-label-value
  podMetricsEndpoints:
  - port: port-name
    scrapeTimeout: 20s
    path: /metrics
    scheme: http
    interval: 30s
    metricRelabelings:
    - sourceLabels: [__name__]
      regex: foo|bar_.*
      action: drop


apiVersion: monitoring.googleapis.com/v1alpha1
kind: PodMonitoring
metadata:
  name: my-pod-monitor
  namespace: pod-monitor-namespace
spec:
  selector:
    matchLabels:
      pod-label-key: pod-label-value
  endpoints:
  - port: port-name
    timeout: 20s
    path: /metrics
    scheme: http
    interval: 30s
---

apiVersion: monitoring.googleapis.com/v1alpha1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
collection:
  filter:
    matchOneOf:
    # keep metrics if they are
    # part of a different job
    - '{job!="my-pod-monitor"}'
    # apply the metric relabeling logic
    - '{__name__!~"foo|bar_.*"}'

互換性に関する注意事項:

namespaceSelector フィールドは Prometheus のマネージドサービスでサポートされていません。複数の名前空間を収集する PodMonitor リソースを移行するには、選択した各名前空間に PodMonitoring リソースのコピーを作成します。
metricRelabelings フィールドは、コレクションフィルタに置き換えます。

PodMonitoring カスタムリソースと OperatorConfig カスタムリソースが gmp-config.yaml というファイル内にある場合は、以下を使用してクラスタにデプロイできます。

kubectl apply -f gmp-config.yaml

デプロイ後、Prometheus 向けのマネージドサービスのパイプラインが指標の収集を開始します。GKE ワークロード指標を使用して以前に収集されたデータポイントは、新しい時系列には表示されないことに注意してください。

ステップ 3: ダッシュボードとアラートを移行する

次のガイドラインを使用して、GKE ワークロードの指標に依存するダッシュボードとアラートを再作成します。

	GKE ワークロードの指標	Prometheus 向けのマネージドサービス
指標名	workload.googleapis.com/my_prometheus_metric	prometheus.googleapis.com/my_prometheus_metric/gauge prometheus.googleapis.com/my_prometheus_metric/counter prometheus.googleapis.com/my_prometheus_metric/histogram
モニタリング対象リソース	k8s_container	prometheus_target
リソースラベル	pod_name container_name	job `instance`（形式は `pod_name:port_name`） `container_name` はサポートされなくなりました。

ステップ 4: `PodMonitor` のカスタムリソースを削除して GKE のワークロード指標を無効にする

GKE ワークロード指標パイプラインを使用して指標をアップロードすると課金は発生しませんが、割り当てを回復して不要なネットワークトラフィックを避けるため、パイプラインを無効にすることをおすすめします。

for each in $(kubectl get ns -o jsonpath="{.items[*].metadata.name}");
do
  kubectl delete --all podmonitor.monitoring.gke.io --namespace="$each"
done
gcloud container clusters update $CLUSTER_NAME --monitoring=SYSTEM --zone=$ZONE --project=$PROJECT

よくある質問

対応しないと、どうなりますか？

GKE のワークロード指標は、GKE 1.23 を介して変更せずにクラスタからエクスポートされます。GKE クラスタを GKE 1.24 にアップグレードすると、GKE ワークロード指標が無効になり、GKE ワークロード指標エージェントがクラスタの DaemonSet としてもうデプロイされなくなります。GKE ワークロード指標パイプラインを使用して収集される指標は収集されず、Cloud Monitoring に送信されなくなります。

本番環境のワークロードに GKE ワークロード指標を使用しません（たとえば、開発クラスタの機能を探しています）。対応が必要なことはありますか？

いいえ。

クラスタのコントロールプレーンバージョンが GKE 1.24 にアップグレードされると、GKE ワークロードの指標が自動的に無効になります。その前に GKE ワークロード指標を無効にする場合は、ここに示すように、--monitoring=SYSTEM フラグを gcloud container clusters update コマンドに渡します。

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

GKE ワークロード指標を使用しているクラスタのリストを見つけるにはどうすればよいですか？

GKE ワークロードの指標を使用してクラスタのリストを作成するには、monitoring.googleapis.com/collection/attribution/write_sample_count 指標を使用します。

Google Cloud コンソールで [Monitoring] を選択します。
[Monitoring] のナビゲーションパネルで、[Metrics Explorer] をクリックします。
[Metric] フィールドで [monitoring.googleapis.com/collection/attribution/write_sample_count] を選択します。
[ADD FILTER] をクリックします。
[Label] フィールドで metric_domain を選択します。
[Value] に「workload.googleapis.com」と入力します。
[完了] をクリックします。
[Group by] をクリックします。
Kubernetes Namespace でグループ化するには、[attribution_dimension] と [attribution_id] を選択します。
GKE リージョン別にグループ化するには、[location] を選択します。
Cloud プロジェクト別にグループ化するには、[resource_container] を選択します。
指標のリストの上にある列ヘッダーの [Value] をクリックして、指標のリストを降順で並べ替えます。

これにより、GKE ワークロードの指標の収集元となる GCP プロジェクト、GKE クラスタ、Kubernetes Namespace の完全なリストが表示されます。

特定の GKE クラスタで GKE ワークロード指標を使用しているかどうかを確認するには、どうすればよいですか？

特定の GKE クラスタで GKE ワークロード指標パイプラインが有効になっているかどうかを確認するには:

Google Cloud コンソールで、[Kubernetes Engine] を選択します。
関連する GKE クラスタの名前をクリックします。
[Cloud Monitoring] 行で、[ワークロード] を探します。「ワークロード」と表示されている場合、GKE ワークロードの指標のパイプラインはクラスタで有効になっています。「システム」または「無効」と表示された場合、そのクラスタは GKE ワークロードの指標を使用していません。

GKE のワークロード指標が非推奨になったのはなぜですか？

GKE ワークロード指標は、Prometheus 向けのマネージドサービスに置き換えられます。これは、GKE ワークロード指標と同じ機能をサポートしていますが、他にも多くの改善点があります。

GKE ワークロード指標と Prometheus 向けのマネージドサービスの違いは何ですか？

主な違いには次のものがあります。* Prometheus 向けのマネージドサービスを使用して収集された指標は、PromQL または MQL を使用してクエリできます。GKE ワークロード指標を使用して収集された指標は、MQL を使用してのみクエリできます。* GKE ワークロード指標は、workload.googleapis.com 指標ドメインと k8s_container リソースタイプに指標を書き込みますが、Prometheus 向けのマネージドサービスは prometheus.googleapis.com 指標ドメインと prometheus_target モニタリング対象リソースに指標を書き込みます。* GKE ワークロード指標はプレビュー版で、一般提供ではないため、現在、GKE ワークロード指標を使用して取り込まれた指標は課金されません。ただし、GKE を使用して取り込まれた指標は課金されます。詳細については、料金をご覧ください。

GKE ワークロード指標が機能しなくなるのは、いつですか？

GKE ワークロード指標は、コントロールプレーンのバージョン 1.24 未満を使用するすべての GKE クラスタで引き続きそのまま機能します。GKE クラスタがコントロールプレーンのバージョン 1.24 にアップグレードされると、GKE ワークロード指標は無効になり、GKE ワークロード指標エージェントはクラスタで DaemonSet としてデプロイされなくなります。GKE ワークロード指標パイプラインを使用して収集された指標が収集され、Cloud Monitoring に送信されることもなくなります。

GKE ワークロード指標のリソースリクエストは、Managed Service for Prometheus と比較してどうですか？

Managed Service for Prometheus のマネージドコレクションを使用している場合、daemonset は GKE ワークロード指標の daemonset の約 2 倍のリソースをリクエストします。GKE ワークロード指標は 1 分あたり約 5,000 の指標サンプルをサポートしていますが、これはすべてのユーザーに十分な値とはいえません。Managed Service for Prometheus のマネージドコレクションには、GKE ワークロードの指標よりも多くのコンピューティングリソースが必要です。1 分あたりのサンプル数が大幅に増えています。Managed Service for Prometheus のセルフデプロイコレクションを使用すると、ユーザーは必要に応じてリソースリクエストを調整できます。