GKE クラスタでワークロード指標を使用している場合は、クラスタを GKE 1.24 にアップグレードする前に、Prometheus のマネージド サービスに移行します。これは、GKE 1.24 でワークロード指標のサポートが削除されているためです。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 クラスタでワークロード指標収集パイプラインを有効にするには、次の手順を行います。
Console
-
Google Cloud コンソールで [Kubernetes Engine] を選択し、[クラスタ] を選択するか、次のボタンをクリックします。
クラスタの名前をクリックします。
[Cloud Monitoring] 行にある編集アイコンをクリックします。
表示された [Cloud Monitoring の編集] ダイアログ ボックスで、[Cloud Monitoring を有効にする] が選択されていることを確認します。
プルダウン メニューで [ワークロード] を選択します。
[OK] をクリックします。
[変更を保存] をクリックします。
gcloud
Google Cloud CLI がインストールされているデバイスでターミナル ウィンドウを開きます。たとえば、Cloud Shell を使用してこの操作を行います。
-
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。
Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
次のコマンドを実行します。
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 の統合の詳細については、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 秒ごとにすべての指標が取得されます。
次の方法を使用して指標のコストを削減できます。
スクレイピング頻度の調整: 指標のコストを削減するには、必要に応じてスクレイピング頻度を下げることをおすすめします。たとえば、ビジネスに関連する KPI がゆっくりと変化する場合は、10 分ごとにスクレイピングするだけで十分です。PodMonitor で、
interval
を設定してスクレイピング頻度を制御します。指標のフィルタリング: 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
指標を使用します。
-
Google Cloud コンソールで [Monitoring]、leaderboard [Metrics Explorer] の順に選択するか、次のボタンをクリックします。
[Metric] フィールドで [
monitoring.googleapis.com/collection/attribution/write_sample_count
] を選択します。必要に応じて、GKE ワークロードの指標のみをフィルタリングします。
[フィルタを追加] をクリックします。
[Label] フィールドで
metric_domain
を選択します。[Value] に「
workload.googleapis.com
」と入力します。[完了] をクリックします。
必要に応じて、Kubernetes の名前空間、GKE リージョン、Google Cloud プロジェクト、またはモニタリング対象リソースのタイプによって取り込まれたサンプル数をグループ化します。
[グループ条件] をクリックします。
Kubernetes Namespace でグループ化するには、[attribution_dimension] と [attribution_id] を選択します。
GKE リージョン別にグループ化するには、[location] を選択します。
Google Cloud プロジェクトでグループ化するには、[resource_container] を選択します。
モニタリング対象のリソースタイプでグループ化するには、[resource_type] を選択します。
指標のリストの上にある列ヘッダーの [Value] をクリックして、指標のリストを降順で並べ替えます。
以下の手順では、Cloud Monitoring に取り込まれたサンプルレートが最も高い指標について説明しています。GKE ワークロードの指標は取り込みサンプル数に応じて課金されるため、取り込まれるサンプルの最大の割合の指標に注意してください。これらの指標の取得頻度を減らすことが可能かどうか、あるいは収集を停止できるかどうかを検討してください。
最後に、Cloud Monitoring に取り込まれた GKE 指標のコストを把握して、これらの費用を最適化するために利用できる多くのリソースがあります。Cloud Monitoring の費用を削減するその他の方法については、費用の最適化ガイドをご覧ください。
以前のバージョンの GKE
GKE コントロール プレーンのバージョンが 1.20.8-gke.2100 より前のクラスタでアプリケーション指標を収集するには、Stackdriver Prometheus サイドカーを使用します。
トラブルシューティング
Cloud Monitoring で指標が予期したとおりに表示されない場合は、以降のセクションの手順でトラブルシューティングを行います。
ワークロード指標のトラブルシューティング
Cloud Monitoring でワークロード指標が予期したとおりに表示されない場合は、次の手順で問題を解決できます。
クラスタが最小要件を満たしていることを確認する
GKE クラスタがコントロール プレーン バージョン 1.20.8-gke.2100 以降を実行していることを確認します。そうでない場合は、クラスタのコントロール プレーンをアップグレードしてください。
ワークロード指標が有効であることを確認する
次の手順で、ワークロード指標の収集パイプラインを有効にするように GKE クラスタが構成されていることを確認します。
Console
-
Google Cloud コンソールで [Kubernetes Engine] を選択し、[クラスタ] を選択するか、次のボタンをクリックします。
クラスタの名前をクリックします。
クラスタの [詳細] パネルで、Cloud Monitoring のステータスにワークロードが含まれていることを確認します。ここに [ワークロード] が表示されていない場合は、ワークロード指標を有効にします。
gcloud
gcloud CLI がインストールされているデバイスで、ターミナル ウィンドウを開きます。たとえば、Cloud Shell を使用してこの操作を行います。
-
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。
Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
次のコマンドを実行します。
gcloud container clusters describe [CLUSTER_ID] --zone=[ZONE]
コマンドの出力で、
monitoringConfig:
行を探します。 2~3 行後のenableComponents:
セクションにWORKLOADS
が含まれていることを確認します。ここにWORKLOADS
がない場合は、ワークロード指標を有効にします。
アプリケーションから指標が収集されていることを確認する
Cloud Monitoring でアプリケーションの指標を表示できない場合は、以下の手順で問題を解決できます。この手順ではデモを目的としてサンプル アプリケーションを使用していますが、以下の同じ手順を適用してアプリケーションのトラブルシューティングを行うことができます。
最初の数ステップでは、テストに使用できるサンプル アプリケーションをデプロイします。残りの手順では、そのアプリケーションの指標が Cloud Monitoring に表示されない理由について説明します。
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"
Google Cloud CLI を使用して認証情報を初期化し、
kubectl
を設定します。gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
gke-workload-metrics
名前空間を作成します。kubectl create ns gke-workload-metrics
サンプル アプリケーションをデプロイします。
kubectl apply -f prometheus-example-app.yaml
次のコマンドを実行して、サンプル アプリケーションが実行されていることを確認します。
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
アプリケーションが想定どおりに指標を公開していることを確認します。
上記のコマンドで返された 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 ...
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
次の PodMonitor リソースを作成します。
kubectl apply -f my-pod-monitor.yaml
PodMonitor リソースを作成すると、GKE ワークロード指標パイプラインでは、適切な Pod を検出して定期的な収集が自動的に開始されます。パイプラインでは収集した指標が Cloud Monitoring に送信されます
PodMonitor でラベルと Namespace が正しく設定されていることを確認します。次のコマンドの
NAMESPACE
とSELECTOR
の値を更新して、PodMonitor カスタム リソースのnamespace
とmatchLabels
であることを確認します。次のコマンドを実行します。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
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 の場合は、準備完了ではない理由を示すイベントを探します。次に、これらの指標が実際に Cloud Monitoring によって受信されていることを確認します。Google Cloud コンソールの [Cloud Monitoring] セクションで、Metrics Explorer に移動します。
[Metric] フィールドに「
example_requests_total
」と入力します。表示されたプルダウン メニューで、[
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_name
やpod_name
などのラベルでグループ化することもできます。この指標は、Cloud Monitoring 内の任意の場所で使用することも、Cloud Monitoring API を使用してクエリすることもできます。たとえば、このグラフを既存のダッシュボードや新しいダッシュボードに追加するには、右上にある [グラフを保存] ボタンをクリックして、ダイアログ ウィンドウでダッシュボードを選択します。
Cloud Monitoring API へ送信されるエラーを確認する
Cloud Monitoring に送信される指標は、カスタム指標の上限内に収める必要があります。エラーは Cloud Monitoring の監査ログに表示されます。
-
Google Cloud コンソールで [ロギング] を選択し、[ログ エクスプローラ] を選択するか、次のボタンをクリックします。
PROJECT_ID をプロジェクトの 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 の取り込み割り当てを確認する
- Cloud Monitoring API の割り当てページに移動します
- 関連するプロジェクトを選択します。
- [Time series ingestion requests] セクションを開きます。
- [Time series ingestionrequests per minute] の [割り当て超過エラーの数] が 0 であることを確認します(その場合、「割り当て超過エラーの数」グラフに「No data is available for the selected tim」と表示されます)。
- ピーク使用率が 100% を超える場合は、Pod の数を少なくすること、指標の数を少なくすること、または
monitoring.googleapis.com/ingestion_requests
割り当ての割り当て上限のリクエスト増加することを検討します。
DaemonSet がデプロイされていることを確認する
クラスタにワークロード指標の DaemonSet がデプロイされていることを確認します。期待どおりに動作していることを確認するには、kubectl
を使用します。
Google Cloud CLI を使用して認証情報を初期化し、
kubectl
を設定します。gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
ワークロード指標の 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 になります。数分後、READY
とAVAILABLE
の数値がDESIRED
の数値と一致するはずです。そうでない場合は、デプロイで問題が発生している可能性があります。