【问题标题】:Debugging istio rate limiting handler调试 istio 限速处理程序
【发布时间】:2020-01-14 11:56:34
【问题描述】:

我正在尝试对我们的一些内部服务(网格内部)应用速率限制。

我使用了文档中的示例并生成了 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"

我正在使用demo 配置文件和disablePolicyChecks: false 来启用速率限制。这是部署在 EKS 上的 istio 1.4.0。

我还尝试了低限制的 memquota(这是我们的暂存环境),但似乎没有任何效果。无论我超过配置的速率限制多少,我都没有得到 429。

我不知道如何调试它并查看配置错误导致它什么也不做。

感谢任何帮助。

【问题讨论】:

  • +1,我也无法在普通的 kubeadm clean 集群上使用 1.4.2 和 memquota。我花了很多时间调试无济于事。也很想在这里看到一些答案。我要开始赏金了。
  • 我已经投入了最大的赏金。它已过期。

标签: redis handler istio rate-limiting amazon-eks


【解决方案1】:

我也花了几个小时试图破译文档并让样本工作。

根据文档,他们建议我们启用政策检查:

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

但是当这不起作用时,我做了一个“istioctl 配置文件转储”,搜索策略,并尝试了几个设置。

我使用 Helm install 并通过了以下内容,然后能够获得所描述的行为:

--设置 global.disablePolicyChecks=false \ --set values.pilot.policy.enabled=true \ ===> 这使它工作,但它不在文档中。

【讨论】:

  • 谢谢!这太旧了,我们放弃了 istio(部分是因为这个)。不过,我会给你赏金指出一些关于为什么这不起作用的线索:github.com/istio/istio/issues/19139
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-06-05
  • 2019-07-04
  • 2015-04-19
  • 1970-01-01
相关资源
最近更新 更多