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 カスタム リソースを同等の PodMonitoringOperatorConfig のカスタム リソースに変換します。移行が完了して検証されるまで、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_.*"}'

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

  • 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 指標を使用します。

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

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

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

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

  1. Google Cloud コンソールで、[Kubernetes Engine] を選択します。
  2. 関連する GKE クラスタの名前をクリックします。
  3. [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 のセルフデプロイ コレクションを使用すると、ユーザーは必要に応じてリソース リクエストを調整できます。