Tôi đang cố gắng áp dụng giới hạn tỷ lệ trên một số dịch vụ nội bộ của chúng tôi (bên trong mạng lưới).
Tôi đã sử dụng ví dụ từ các tài liệu và tạo ra các cấu hình giới hạn tỷ lệ redis bao gồm trình xử lý (redis), thể hiện hạn ngạch, thông số hạn ngạch, ràng buộc thông số hạn ngạch và quy tắc để áp dụng trình xử lý.
Trình xử lý redis này:
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
Ví dụ về hạn ngạch (Tôi chỉ quan tâm đến việc giới hạn theo điểm đến tại thời điểm này):
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"
Một thông số hạn ngạch, tính phí 1 cho mỗi yêu cầu nếu tôi hiểu chính xác:
apiVersion: config.istio.io/v1alpha2
kind: QuotaSpec
metadata:
name: request-count
namespace: istio-system
spec:
rules:
- quotas:
- charge: 1
quota: requestcountquota
Một thông số ràng buộc hạn ngạch mà tất cả các dịch vụ tham gia đều tìm nạp trước. Tôi cũng đã cố gắng service: "*"mà không làm gì cả.
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
Một quy tắc để áp dụng xử lý. Hiện tại trong tất cả các dịp (đã thử với các trận đấu nhưng cũng không thay đổi gì cả):
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: quota
namespace: istio-system
spec:
actions:
- handler: redishandler
instances:
- requestcountquota
Các định nghĩa VirtualService khá giống nhau cho tất cả người tham gia:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: s1
spec:
hosts:
- s1
http:
- route:
- destination:
host: s1
Vấn đề là không có gì thực sự xảy ra và không có giới hạn tỷ lệ diễn ra. Tôi đã thử nghiệm với curltừ vỏ bên trong lưới. Ví dụ redis trống (không có khóa trên db 0, mà tôi giả sử là giới hạn tốc độ sẽ sử dụng) vì vậy tôi biết nó thực tế không thể giới hạn tỷ lệ bất cứ điều gì.
Trình xử lý dường như được cấu hình đúng (làm thế nào tôi có thể chắc chắn?) Vì tôi có một số lỗi trong đó đã được báo cáo trong bộ trộn (chính sách). Vẫn còn một số lỗi nhưng không có lỗi nào liên quan đến vấn đề này hoặc cấu hình. Dòng duy nhất trong đó xử lý redis được đề cập là:
2019-12-17T13:44:22.958041Z info adapters adapter closed all scheduled daemons and workers {"adapter": "redishandler.istio-system"}
Nhưng nó không rõ nếu nó là một vấn đề hay không. Tôi cho rằng nó không phải.
Đây là những dòng còn lại từ tải lại sau khi tôi triển khai:
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"
Tôi đang sử dụng demohồ sơ disablePolicyChecks: falseđể kích hoạt giới hạn tỷ lệ. Đây là trên istio 1.4.0, được triển khai trên EKS.
Tôi cũng đã thử memquota (đây là môi trường dàn dựng của chúng tôi) với giới hạn thấp và dường như không có gì hoạt động. Tôi chưa bao giờ có 429 cho dù tôi có vượt quá giới hạn tốc độ được định cấu hình bao nhiêu.
Tôi không biết cách gỡ lỗi này và xem cấu hình sai ở đâu khiến nó không làm gì cả.
Bất kỳ trợ giúp được đánh giá cao.