Saya mencoba menerapkan pembatasan tarif pada beberapa layanan internal kami (di dalam mesh).
Saya menggunakan contoh dari dokumen dan menghasilkan konfigurasi pembatasan tingkat redis yang mencakup penangan (redis), contoh kuota, spesifikasi kuota, pengikatan spesifikasi kuota dan aturan untuk menerapkan handler.
Handler redis ini:
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
Contoh kuota (saya hanya tertarik membatasi berdasarkan tujuan saat ini):
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"
Spesifikasi kuota, menagih 1 per permintaan jika saya mengerti benar:
apiVersion: config.istio.io/v1alpha2
kind: QuotaSpec
metadata:
name: request-count
namespace: istio-system
spec:
rules:
- quotas:
- charge: 1
quota: requestcountquota
Spesifikasi kuota mengikat yang diambil semua layanan yang berpartisipasi. Saya juga mencoba service: "*"
yang juga tidak melakukan apa pun.
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
Aturan untuk menerapkan pawang. Saat ini di semua kesempatan (mencoba dengan pertandingan tetapi tidak mengubah apa-apa juga):
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
name: quota
namespace: istio-system
spec:
actions:
- handler: redishandler
instances:
- requestcountquota
Definisi VirtualService sangat mirip untuk semua peserta:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: s1
spec:
hosts:
- s1
http:
- route:
- destination:
host: s1
Masalahnya adalah tidak ada yang benar-benar terjadi dan tidak ada pembatasan tingkat terjadi. Saya diuji dengan curl
dari polong di dalam jala. Contoh redis kosong (tidak ada kunci pada db 0, yang saya asumsikan adalah apa yang akan digunakan pembatasan tingkat) jadi saya tahu itu tidak bisa menilai-batas apa pun secara praktis.
Pawang tampaknya sudah dikonfigurasikan dengan benar (bagaimana saya bisa memastikan?) Karena saya memiliki beberapa kesalahan di dalamnya yang dilaporkan dalam mixer (kebijakan). Masih ada beberapa kesalahan tetapi tidak ada yang saya kaitkan dengan masalah ini atau konfigurasi. Satu-satunya baris di mana redis handler disebutkan adalah ini:
2019-12-17T13:44:22.958041Z info adapters adapter closed all scheduled daemons and workers {"adapter": "redishandler.istio-system"}
Tetapi tidak jelas apakah ini masalah atau tidak. Saya berasumsi tidak.
Ini adalah sisa baris dari isi ulang setelah saya gunakan:
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"
Saya menggunakan demo
profil dengan disablePolicyChecks: false
untuk mengaktifkan pembatasan tingkat. Ini pada istio 1.4.0, digunakan pada EKS.
Saya juga mencoba memquota (ini adalah lingkungan pementasan kami) dengan batas rendah dan sepertinya tidak ada yang berhasil. Saya tidak pernah mendapatkan 429 tidak peduli berapa banyak saya melewati batas tingkat yang dikonfigurasi.
Saya tidak tahu cara men-debug ini dan melihat di mana konfigurasi yang salah menyebabkannya tidak melakukan apa-apa.
Bantuan apa pun dihargai.