web-dev-qa-db-ja.com

istioレート制限ハンドラーのデバッグ

一部の内部サービス（メッシュ内）にレート制限を適用しようとしています。

私はドキュメントの例を使用して、（redis）ハンドラー、割り当てインスタンス、割り当て仕様、割り当て仕様バインディング、およびハンドラーを適用するルールを含む、Redisレート制限構成を生成しました。

このredisハンドラー：

apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  name: redishandler
  namespace: istio-system
spec:
  compiledAdapter: redisquota
  params:
    redisServerUrl: <REDIS>:6379
    connectionPoolSize: 10
    quotas:
    - name: requestcountquota.instance.istio-system
      maxAmount: 10
      validDuration: 100s
      rateLimitAlgorithm: FIXED_WINDOW
      overrides:
      - dimensions:
          destination: s1
        maxAmount: 1
      - dimensions:
          destination: s3
        maxAmount: 1
      - dimensions:
          destination: s2
        maxAmount: 1

クォータインスタンス（現時点では宛先による制限のみに関心があります）：

apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
  name: requestcountquota
  namespace: istio-system
spec:
  compiledTemplate: quota
  params:
    dimensions:
      destination: destination.labels["app"] | destination.service.Host | "unknown"

割り当ての仕様。正しく理解している場合は、リクエストごとに1つ課金されます。

apiVersion: config.istio.io/v1alpha2
kind: QuotaSpec
metadata:
  name: request-count
  namespace: istio-system
spec:
  rules:
  - quotas:
    - charge: 1
      quota: requestcountquota

参加しているすべてのサービスがプリフェッチする割り当てバインディング仕様。私もservice: "*"を試しましたが、これも何もしませんでした。

apiVersion: config.istio.io/v1alpha2
kind: QuotaSpecBinding
metadata:
  name: request-count
  namespace: istio-system
spec:
  quotaSpecs:
  - name: request-count
    namespace: istio-system
  services:
  - name: s2
    namespace: default
  - name: s3
    namespace: default
  - name: s1
    namespace: default
    # - service: '*'  # Uncomment this to bind *all* services to request-count

ハンドラーを適用するためのルール。現在、すべての状況で（一致を試してみましたが、何も変更しませんでした）：

apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: quota
  namespace: istio-system
spec:
  actions:
  - handler: redishandler
    instances:
    - requestcountquota

VirtualServiceの定義は、すべての参加者にとってかなり似ています。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: s1
spec:
  hosts:
  - s1

  http:
  - route:
    - destination:
        Host: s1

問題は実際には何も起こらず、レート制限が行われないことです。メッシュ内のポッドからcurlを使用してテストしました。 redisインスタンスは空です（db 0にはキーがありません。これはレート制限が使用するものと想定しています）ので、実際には何もレート制限できないことがわかります。

ハンドラーは適​​切に構成されているようです（確認方法は？）。ミキサー（ポリシー）で報告されたエラーがいくつかあったためです。まだいくつかのエラーがありますが、この問題または構成に関連するエラーはありません。 redisハンドラーが言及されている唯一の行は次のとおりです。

2019-12-17T13:44:22.958041Z info    adapters    adapter closed all scheduled daemons and workers    {"adapter": "redishandler.istio-system"}

しかし、それが問題かどうかは不明です。私はそうではないと思います。

これらは私がデプロイした後のリロードの残りの行です：

2019-12-17T13:44:22.601644Z info    Built new config.Snapshot: id='43'
2019-12-17T13:44:22.601866Z info    adapters    getting kubeconfig from: "" {"adapter": "kubernetesenv.istio-system"}
2019-12-17T13:44:22.601881Z warn    Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
2019-12-17T13:44:22.602718Z info    adapters    Waiting for kubernetes cache sync...    {"adapter": "kubernetesenv.istio-system"}
2019-12-17T13:44:22.903844Z info    adapters    Cache sync successful.  {"adapter": "kubernetesenv.istio-system"}
2019-12-17T13:44:22.903878Z info    adapters    getting kubeconfig from: "" {"adapter": "kubernetesenv.istio-system"}
2019-12-17T13:44:22.903882Z warn    Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
2019-12-17T13:44:22.904808Z info    Setting up event handlers
2019-12-17T13:44:22.904939Z info    Starting Secrets controller
2019-12-17T13:44:22.904991Z info    Waiting for informer caches to sync
2019-12-17T13:44:22.957893Z info    Cleaning up handler table, with config ID:42
2019-12-17T13:44:22.957924Z info    adapters    deleted remote controller   {"adapter": "kubernetesenv.istio-system"}
2019-12-17T13:44:22.957999Z info    adapters    adapter closed all scheduled daemons and workers    {"adapter": "prometheus.istio-system"}
2019-12-17T13:44:22.958041Z info    adapters    adapter closed all scheduled daemons and workers    {"adapter": "redishandler.istio-system"}   
2019-12-17T13:44:22.958065Z info    adapters    shutting down daemon... {"adapter": "kubernetesenv.istio-system"}
2019-12-17T13:44:22.958050Z info    adapters    shutting down daemon... {"adapter": "kubernetesenv.istio-system"}
2019-12-17T13:44:22.958096Z info    adapters    shutting down daemon... {"adapter": "kubernetesenv.istio-system"}
2019-12-17T13:44:22.958182Z info    adapters    shutting down daemon... {"adapter": "kubernetesenv.istio-system"}
2019-12-17T13:44:23.958109Z info    adapters    adapter closed all scheduled daemons and workers    {"adapter": "kubernetesenv.istio-system"}
2019-12-17T13:55:21.042131Z info    transport: loopyWriter.run returning. connection error: desc = "transport is closing"
2019-12-17T14:14:00.265722Z info    transport: loopyWriter.run returning. connection error: desc = "transport is closing"

レート制限を有効にするために、disablePolicyChecks: falseでdemoプロファイルを使用しています。これはEKSにデプロイされたistio 1.4.0にあります。

また、下限を設定してmemquota（これは私たちのステージング環境です）を試しましたが、何も動作しないようです。設定されているレート制限をいくら超えても、429は得られませんでした。

これをデバッグする方法がわからず、設定が間違っているために何も実行されない原因を確認します。

どんな助けでもありがたいです。

redishandleristiorate-limitingeks
9
Reut Sharabani

私もドキュメントを解読してサンプルを機能させるために何時間も費やしました。

ドキュメントによると、彼らはポリシーチェックを有効にすることを推奨しました：

https://istio.io/docs/tasks/policy-enforcement/rate-limited/

ただし、それが機能しない場合は、「istioctlプロファイルダンプ」を実行し、ポリシーを検索して、いくつかの設定を試しました。

Helmのインストールを使用して次のコードを渡したところ、記述された動作を得ることができました。

--set global.disablePolicyChecks = false\--set values.pilot.policy.enabled = true\===>これにより機能しましたが、ドキュメントには含まれていません。

2
Sateesh Valluru