Gestore di limitazione della velocità di istio del debug


9

Sto cercando di applicare la limitazione della velocità su alcuni dei nostri servizi interni (all'interno della mesh).

Ho usato l'esempio dai documenti e ho generato configurazioni di limitazione della velocità di redis che includono un gestore (redis), un'istanza di quota, specifiche di quota, associazione di specifiche di quota e regola per applicare il gestore.

Questo gestore 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

L'istanza della quota (al momento mi interessa solo limitare la destinazione):

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"

Una specifica di quota, addebitando 1 per richiesta se capisco correttamente:

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

Una specifica di bind quota che tutti i servizi partecipanti pre-prelevano. Ho anche provato con service: "*"cui non ha fatto nulla.

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

Una regola per applicare il gestore. Attualmente in tutte le occasioni (provato con le partite ma non ha cambiato nulla):

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

Le definizioni di VirtualService sono abbastanza simili per tutti i partecipanti:

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

  http:
  - route:
    - destination:
        host: s1

Il problema è che non succede nulla e non si verifica alcun limite di velocità. Ho provato con curlda baccelli all'interno della maglia. L'istanza redis è vuota (nessun tasto su db 0, che presumo sia quello che la limitazione della velocità userebbe) quindi so che non può praticamente limitare nulla.

Il gestore sembra essere configurato correttamente (come posso essere sicuro?) Perché ho riscontrato degli errori che sono stati segnalati nel mixer (politica). Ci sono ancora alcuni errori ma nessuno che associo a questo problema o alla configurazione. L'unica riga in cui viene menzionato il gestore redis è questa:

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

Ma non è chiaro se sia un problema o meno. Presumo che non lo sia.

Queste sono le altre righe della ricarica una volta che dispongo:

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"

Sto usando il demoprofilo con disablePolicyChecks: falseper abilitare la limitazione della velocità. Questo è su istio 1.4.0, distribuito su EKS.

Ho anche provato memquota (questo è il nostro ambiente di gestione temporanea) con limiti bassi e nulla sembra funzionare. Non ho mai ricevuto un 429, non importa quanto ho superato il limite di velocità configurato.

Non so come eseguire il debug di questo e vedere dove la configurazione è errata causando che non faccia nulla.

Qualsiasi aiuto è apprezzato.


+1, non riesco anche a far funzionare nulla con 1.4.2 e memquota sul cluster pulito di kubeadm. Ho impiegato molto tempo per eseguire il debug senza risultati. Mi piacerebbe vedere alcune risposte anche qui. Inizierò una taglia.
gertvdijk,

Ho già messo la taglia più grande. È scaduto.
Reut Sharabani,

Risposte:


2

Anch'io ho passato ore a cercare di decifrare la documentazione e far funzionare un campione.

Secondo la documentazione, hanno raccomandato di abilitare i controlli delle politiche:

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

Tuttavia, quando non ha funzionato, ho eseguito un "dump del profilo istioctl", ho cercato i criteri e provato diverse impostazioni.

Ho usato Helm install e ho passato quanto segue e poi sono stato in grado di ottenere il comportamento descritto:

--set global.disablePolicyChecks = false \ --set valori.pilot.policy.enabled = true \ ===> questo ha funzionato, ma non è nei documenti.


1
Grazie! Questo è troppo vecchio e abbiamo abbandonato istio (in parte per questo). Ti darò comunque la generosità per aver indicato qualche indizio sul perché questo non funziona: github.com/istio/istio/issues/19139
Reut Sharabani
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.