Trying to understand QuotaSpec & QuotaSpecBinding CRDs

1

I understand the mixer adapter model through which we can configure what attributes get sent to which adapter under what conditions. Basically all the stuff described here: https://istio.io/docs/concepts/policies-and-telemetry/

But the CRDs QuotaSpec and QuotaSpecBinding used in the rate-limiting task seem completely different from this adapter model. Can someone explain which Istio entity acts upon this CRD? I see that part of what is specified in this CRD flows down to the envoy config as well - how and why?

Is it not possible to do rate limiting using only the adapters? As per the guide “The Envoy sidecar logically calls Mixer before each request to perform precondition checks”, so enforcing rate limits should be possible using only an adapter right?

@mandarjog: would appreciate your help in clarifying this.

Thanks!

2

Mixer Quota operation is performed in the same call as a precondition check, however it is a distinct operation. For quota efficiency the client needs to request quota by name and quantity.
QuotaSpec and QuotaSpecBindings CRDs describe which quota applies to which service, and how much quantity to request. This configuration is converted by pilot into mixer client configuration and delivered to envoy as part of service config
Doing quota this way enables the client to pre-fetch quota tokens.

Is it not possible to do rate limiting using only the adapters?

Yes it is possible to implement a rate limiter as a check adapter. It will not be possible to do quota pre-fetch in that case. If this is done, then you will not need quotaSpec and quotaSpecBinding configuration.

  • Mandar
3

Thanks a ton Mandar! This helps a lot in understanding the architecture.

4

hi,

Could you explain this in the context of the rate limiting task from the doc.

Thank you,
Laszlo

5

@lbudai: In the rate limiting task, we see 5 CRDs being used. My understanding is that out of those the QuotaSpec and QuotaSpecBindings is used by pilot to send mixer client config to the sidecar proxies. In the task, we see the following examples:

apiVersion: config.istio.io/v1alpha2
kind: QuotaSpec
metadata:
  name: request-count
  namespace: istio-system
spec:
  rules:
  - quotas:
    - charge: 1
      quota: requestcount
---
apiVersion: config.istio.io/v1alpha2
kind: QuotaSpecBinding
metadata:
  name: request-count
  namespace: istio-system
spec:
  quotaSpecs:
  - name: request-count
    namespace: istio-system
  services:
  - name: productpage
    namespace: default
    #  - service: '*'  # Uncomment this to bind *all* services to request-count

This means that pods that are part of the productpage service in the default namespace ask for the quota named request-count defined in the istio-system namespace. Further the request-count quota charges 1 unit for each request. You can verify this by looking at the config_dump from the envoy sidecar. That’s my understanding. Hope that helps.