J'essaie d'appliquer une limitation de taux sur certains de nos services internes (à l'intérieur du maillage).
J'ai utilisé l'exemple des documents et généré des configurations de limitation de débit redis qui incluent un gestionnaire (redis), une instance de quota, une spécification de quota, une liaison de spécification de quota et une règle pour appliquer le gestionnaire.
Ce gestionnaire de 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'instance de quota (je ne suis intéressé que par la limitation par destination pour le moment):
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"
Une spécification de quota, facturant 1 par demande si je comprends bien:
apiVersion: config.istio.io/v1alpha2
kind: QuotaSpec
metadata:
name: request-count
namespace: istio-system
spec:
rules:
- quotas:
- charge: 1
quota: requestcountquota
Une spécification de liaison de quota que tous les services participants prélèvent. J'ai aussi essayé avec service: "*"qui n'a rien fait non plus.
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
Une règle pour appliquer le gestionnaire. Actuellement à toutes les occasions (essayé avec des matchs mais n'a rien changé aussi):
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: quota
namespace: istio-system
spec:
actions:
- handler: redishandler
instances:
- requestcountquota
Les définitions de VirtualService sont assez similaires pour tous les participants:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: s1
spec:
hosts:
- s1
http:
- route:
- destination:
host: s1
Le problème est que rien ne se passe vraiment et aucune limitation de taux n'a lieu. J'ai testé avec curldes pods à l'intérieur du maillage. L'instance de redis est vide (pas de clés sur db 0, ce que je suppose est ce que la limitation de débit utiliserait) donc je sais qu'elle ne peut pratiquement rien limiter.
Le gestionnaire semble être configuré correctement (comment puis-je m'assurer?) Car j'ai eu des erreurs qui ont été signalées dans le mélangeur (stratégie). Il y a encore quelques erreurs mais aucune que j'associe à ce problème ou à la configuration. La seule ligne dans laquelle le gestionnaire redis est mentionné est la suivante:
2019-12-17T13:44:22.958041Z info adapters adapter closed all scheduled daemons and workers {"adapter": "redishandler.istio-system"}
Mais ce n'est pas clair si c'est un problème ou non. Je suppose que ce n'est pas le cas.
Voici le reste des lignes du rechargement une fois que je déploie:
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"
J'utilise le demoprofil avec disablePolicyChecks: falsepour activer la limitation de débit. C'est sur istio 1.4.0, déployé sur EKS.
J'ai également essayé memquota (c'est notre environnement de mise en scène) avec des limites basses et rien ne semble fonctionner. Je n'ai jamais eu de 429, peu importe combien j'ai dépassé la limite de taux configurée.
Je ne sais pas comment déboguer cela et voir où la configuration est incorrecte, ce qui ne fait rien.
Toute aide est appréciée.