ロードバランサのカスタム指標を公開する

このドキュメントでは、Pod またはワークロードからロードバランサに 1 つ以上の指標を送信する方法について説明します。

これらの指標は、実行しているサービスまたはアプリケーションから取得されます。たとえば、vLLM Engine によって公開される指標をご覧ください。

ロードバランサは、このデータを使用率ベースのロード バランシングで使用して、ワークロードをより効率的に分散できます。たとえば、この機能を使用して、ワークロードの使用量が多いリージョンをモニタリングし、ロードバランサがより多くのリソースを利用できるリージョンにトラフィックをリダイレクトできるようにします。vLLM の例では、使用率の追跡に役立つ指標は vllm:gpu_cache_usage_perc です。

要件

Pod の要件は次のとおりです。

指標の要件は次のとおりです。

  • 指標は、Gateway によってロード バランシングされる Pod の HTTP エンドポイントでアクセスできる必要があります。デフォルトのエンドポイント パスは /metrics です。
  • 指標は Prometheus 標準に従ってフォーマットする必要があります。

  • ロードバランサには指標名に関する制限があります。たとえば、名前は 64 文字以下にする必要があります。制限事項の一覧については、BackendService の API リファレンスの backends[].customMetrics[].name フィールドの詳細をご覧ください。

    サービスの指標がこれらの制限に準拠していない場合は、exportName フィールドを使用して名前を変更できます。

  • 0 ～ 1 のゲージ指標のみがサポートされています。1 は使用率 100% を表します。

  • Pod ラベル セレクタのラベル名に特殊文字を含めることはできません。サポートされているのは、a ～ z の文字（小文字または大文字）、数字、ハイフン、アンダースコアのみです。

  • クラスタごとに最大 20 個の一意の指標を公開できます。他のサービスには独自の上限があります。たとえば、ロードバランサの制限事項と要件をご覧ください。クラスタは複数のロードバランサを使用できます。

カスタム指標に基づく GKE 使用率ベースのバランシング（UBB）

GKE 使用率ベースのバランシング（UBB）を使用すると、ロードバランサがバックエンド Pod の使用率に基づいてトラフィックを分散できます。 CPU などの汎用的な指標に依存するのではなく、アプリケーションのパフォーマンスに関連するカスタム指標を使用するように UBB を構成できます。

GKE でカスタム指標を使用して UBB を使用する場合、次の制限が適用されます。

  • Gateway API のみ: UBB は、Gateway API を使用して公開する Service でカスタム指標を使用できます。GKE は、GKE Gateway Controller を使用して Gateway API とやり取りします。 Service API と Ingress API は、カスタム指標を使用した UBB をサポートしていません。カスタム指標は、Service のメンバーである Pod から取得する必要があります。
  • Cloud Service Mesh なし: Cloud Service Mesh でカスタム指標を使用して UBB を使用することはできません。
  • サポートされていないロードバランサ: 外部パススルー ネットワーク ロードバランサと外部プロキシ ネットワーク ロードバランサでカスタム指標を使用して UBB を使用することはできません。

ロード バランシングの指標を公開する

  1. 公開する指標を選択します。サーバーが公開し、前のセクションに記載されている要件を満たす指標であれば、どれでも選択できます。この例では、queue_depth_util という名前のカスタム指標を使用します。

  2. 次のカスタム リソースを追加します。指標と Pod に固有の詳細は置き換えてください。

    apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: NAME
  namespace:NAMESPACE
spec:
  metrics:
  - pod:
      selector:
        matchLabels:
          APP_LABEL_NAME: APP_LABEL_VALUE
      containers:
      - endpoint:
          port: METRIC_PORT
          path: METRIC_PATH
        metrics:
        - gauge:
          name: METRIC
          prometheusMetricName: METRIC_PROMETHEUS_NAME
          loadBalancing:
            enabled: true

    ワークロードに合わせて次の値を置き換えます。

    • NAME: AutoscalingMetric オブジェクトの名前。
    • NAMESPACE: Pod が存在する Namespace。
    • APP_LABEL_NAME 、APP_LABEL_VALUE: 指標を出力する Pod に一致するラベル名と値。
    • METRIC_PORT: ポート番号。
    • METRIC_PATH: 指標のパス。サービスまたはアプリケーションで使用されているパスを確認します。このパスは通常 /metrics です。
    • METRIC: 公開する指標の名前。名前は正規表現 ^[a-z]([a-z0-9_-]*[a-z0-9])? に一致し、長さは 63 文字以下にする必要があります。つまり、最初の文字は小文字にする必要があり、それに続く文字はハイフン、アンダースコア、小文字、数字でなければなりません。ただし、最後の文字は文字または数字にする必要があります。

    • 省略可: METRIC_PROMETHEUS_NAME: Pod によって公開される Prometheus 指標名。このフィールドを使用して指標の名前を変更できます。たとえば、Pod によって公開される指標名がロードバランサで設定された名前の制限に準拠していない場合などです。

      制限事項の一覧については、 BackendService の API リファレンスの backends[].customMetrics[].name フィールドの詳細をご覧ください。

  3. 次のコマンドを使用してマニフェストをデプロイします。

    kubectl apply -f FILE_NAME.yaml

    FILE_NAME は、YAML ファイルの名前に置き換えます。

    カスタム リソースを追加すると、指標が自動スケーリング API に push されます。指標は数秒ごとに読み取られ、ロードバランサに送信されます。

  4. ロード バランシングの目的でこのシグナルを使用するには、GCPBackendPolicy を指定します。次に例を示します。

    kind: GCPBackendPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: my-backend-policy
spec:
  targetRef:
    group: ""
    kind: Service
    name: store-v1
  default:
    balancingMode: CUSTOM_METRICS
    customMetrics:
    -   name: gke.named_metrics.queue_depth_util
        dryRun: false

Prometheus によって報告される指標は、異なる命名標準に従います。ロード バランシングの指標が報告されると、GKE Metrics Agent は BackendService API 要件に従うために、内部的に gke.named_metrics. 接頭辞を追加します。

2 つ目の指標を公開するには、同じ手順で別のカスタム リソースを作成します。

指標をロードバランサに公開したので、これらの指標を使用するようにロードバランサを構成できます。詳細については、カスタム指標を使用するようにロードバランサを構成するをご覧ください。

ロードバランサの操作の詳細については、 GKE Service の使用率ベースのロード バランシングを構成するをご覧ください。

ロードバランサに公開された指標のトラブルシューティング

指標がロードバランサに正しく公開されていることを確認するには、次の操作を行います。

次のステップ