Debugowanie obsługi ograniczającej szybkość istio

9

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.

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

Odpowiedzi:

2

Ja też spędziłem godziny próbując rozszyfrować dokumentację i przygotować próbkę.

Zgodnie z dokumentacją zalecili włączenie kontroli zasad:

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

Jednak gdy to nie zadziałało, zrobiłem „zrzut profilu istioctl”, szukałem zasad i wypróbowałem kilka ustawień.

Użyłem instalacji Helma i przekazałem następujące, a następnie udało mi się uzyskać opisane zachowanie:

--set global.disablePolicyChecks = false \ --set values.pilot.policy.enabled = true \ ===> to sprawiło, że działało, ale nie ma go w dokumentacji.

Sateesh Valluru
źródło
1
Dziękuję Ci! To jest za stare i porzuciliśmy istio (częściowo z tego powodu). Dam ci nagrodę za wskazanie jakiejś wskazówki, dlaczego to nie działa: github.com/istio/istio/issues/19139
Reut Sharabani