Debugowanie obsługi ograniczającej szybkość istio

Próbuję zastosować ograniczenie stawek w niektórych naszych usługach wewnętrznych (wewnątrz siatki).

Skorzystałem z przykładu z dokumentów i wygenerowałem konfiguracje ograniczające szybkość redis, które zawierają moduł obsługi (redis), instancję przydziału, specyfikację przydziału, powiązanie specyfikacji przydziału i regułę do zastosowania procedury obsługi.

Ten moduł obsługi 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

Instancja przydziału (w tej chwili interesuje mnie ograniczenie według miejsca docelowego):

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"

Specyfikacja kontyngentu, opłata 1 na żądanie, jeśli dobrze rozumiem:

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

Specyfikacja wiążąca przydział, którą wszystkie usługi uczestniczące pobierają wstępnie. Próbowałem też, z service: "*"czym też nic nie zrobiłem.

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

Reguła stosowania procedury obsługi. Obecnie za każdym razem (próbowałem z meczami, ale niczego też nie zmieniłem):

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

Definicje VirtualService są dość podobne dla wszystkich uczestników:

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

  http:
  - route:
    - destination:
        host: s1

Problem polega na tym, że tak naprawdę nic się nie dzieje i nie ma ograniczenia prędkości. Testowałem z curlstrąkami wewnątrz siatki. Instancja redis jest pusta (brak kluczy w db 0, co, jak zakładam, byłaby używana przez ograniczenie szybkości), więc wiem, że praktycznie nie może niczego ograniczać.

Wygląda na to, że moduł obsługi jest poprawnie skonfigurowany (jak mogę się upewnić?), Ponieważ miałem w nim kilka błędów, które zostały zgłoszone w mikserze (polityka). Nadal występują błędy, ale nie kojarzą się z tym problemem lub konfiguracją. Jedyny wiersz, w którym wspomniany jest moduł obsługi redis, to:

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

Ale nie jest jasne, czy to problem, czy nie. Zakładam, że nie.

Oto pozostałe linie z przeładowania po wdrożeniu:

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"

Korzystam z demoprofilu, disablePolicyChecks: falseaby włączyć ograniczenie prędkości. To jest na istio 1.4.0, wdrożone na EKS.

Próbowałem też memquota (to jest nasze środowisko inscenizacyjne) z niskimi limitami i nic nie działa. Nigdy nie dostałem 429 bez względu na to, jak bardzo przekroczyłem skonfigurowany limit prędkości.

Nie wiem, jak to debugować i zobaczyć, gdzie konfiguracja jest nieprawidłowa, co powoduje, że nic nie robi.

Każda pomoc jest mile widziana.

redis handler istio rate-limiting eks Reut Sharabani
źródło

+1, nie dostaję też nic, co działałoby z 1.4.2 i memquota na zwykłym klastrze kubeadm clean. Sporo czasu poświęciłem na debugowanie bezskutecznie. Chciałbym też zobaczyć tutaj odpowiedzi. Zacznę nagrodę.

gertvdijk

Włożyłem już największą nagrodę. Wygasło.

Reut Sharabani

Debugowanie obsługi ograniczającej szybkość istio

Odpowiedzi: