Налагодження обробника обмеження швидкості istio


9

Я намагаюся застосувати обмеження швидкості до деяких наших внутрішніх служб (всередині сітки).

Я використав приклад із документів і створив конфігурації, що обмежують швидкість перенаправлення, які включають обробник (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щоб увімкнути обмеження швидкості. Це на istio 1.4.0, розгорнутий на EKS.

Я також спробував memquota (це наше середовище постановки) з низькими межами, і, здається, нічого не працює. Я ніколи не отримував 429, скільки б я не перейшов налаштований ліміт ставок.

Я не знаю, як налагодити це і побачити, де конфігурація неправильна, що змушує її нічого не робити.

Будь-яка допомога вдячна.


+1, мені також не вдається отримати щось, що працює з 1.4.2 & memquota на звичайному кластері kubeadm clean. Я витратив чимало часу на налагодження безрезультатно. Я також хотів би побачити деякі відповіді і тут. Я розпочну щедроту.
gertvdijk

Я ставлю найбільшу суму вже. Він минув.
Reut Sharabani

Відповіді:


2

Я теж витратив години, намагаючись розшифрувати документацію і взяти зразок в роботі.

Відповідно до документації, вони рекомендували включити перевірку політики:

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

Однак, коли це не вийшло, я зробив "дамп профілю istioctl", шукав політику та спробував кілька налаштувань.

Я використав Helm install і пройшов наступне, а потім зміг отримати описане поведінку:

--set global.disablePolicyChecks = false \ --set values.pilot.policy.enabled = true \ ===> це змусило його працювати, але це не в документах.


1
Дякую! Це занадто старе, і ми скинули istio (частково через це). Я дам вам винагороду, хоча за вказівку на деяку підказку, чому це не працює: github.com/istio/istio/isissue/19139
Reut Sharabani
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.