GKE 指標の管理

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

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

  • システム指標: 重要なシステム コンポーネントの指標。CPU、メモリ、ストレージなどの低レベルのリソースを記述します。
  • ワークロード指標: 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 値を使用します。システム指標の収集が無効になっている場合、Cloud Console の GKE セクション内のクラスタで CPU 使用率、メモリ使用量、ディスク使用量などの基本情報が使用できません。また、Cloud Monitoring GKE ダッシュボードにはクラスタに関する情報は表示されません。

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

システム指標の一覧

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

ワークロード指標

GKE ワークロード指標は、Cloud Monitoring を使用して Kubernetes アプリケーションをモニタリングする Google の推奨方法です。

GKE 1.20.8-gke.2100 以降は、フルマネージドの指標収集パイプラインを備えており、GKE ワークロード(CronJob や Deployment)によって公開される Prometheus スタイルの指標を取得して Cloud Monitoring に送信します。

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

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

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

要件

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

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

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

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

Console

  1. Google Cloud Console で、GKE クラスタのリストに移動します。

    Kubernetes クラスタに移動

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

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

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

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

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

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

gcloud

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

  2. Cloud Console で、Cloud Shell をアクティブにします。

    Cloud Shell をアクティブにする

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

  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)kubectl を設定するために、gcloud コマンドライン ツールを使用して認証情報を初期化します。

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

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

kubectl apply -f my-pod-monitor.yaml

移行

Stackdriver Prometheus サイドカーをすでに使用している場合、GKE ワークロード指標は多くの改善点を提供します。GKE ワークロード指標を使用に切り替えて、アプリケーションによって生成された指標を収集することを強くおすすめします。Stackdriver Prometheus サイドカーから GKE ワークロード指標への移行ガイドをご覧ください。

料金

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. Cloud Console で、[Monitoring] を選択します。

    [Monitoring] に移動

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

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

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

    • [ADD FILTER] をクリックします。

    • [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 でワークロード指標が予期したとおりに表示されない場合は、次の手順で問題を解決できます。

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

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

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

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

Console

  1. Google Cloud Console で、GKE クラスタのリストに移動します。

    Kubernetes クラスタに移動

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

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

gcloud

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

  2. Cloud Console で、Cloud Shell をアクティブにします。

    Cloud Shell をアクティブにする

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

  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. kubectl を設定するために、gcloud コマンドライン ツールを使用して認証情報を初期化します。

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

    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 Console の [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. kubectl を設定するために、gcloud コマンドライン ツールを使用して認証情報を初期化します。

    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 の数値と一致するはずです。そうでない場合は、デプロイで問題が発生している可能性があります。

その他の指標

上記のシステム指標ワークロード指標の他に、GKE クラスタで使用できるその他の指標は次のとおりです。

  • Istio 指標は、Cloud Monitoring で使用できます。