Topik ini menjelaskan cara menggunakan ConcurrencySchedulingPolicy yang disediakan oleh suite penjadwalan lalu lintas untuk menerapkan penjadwalan permintaan berdasarkan prioritas di bawah kontrol konkurensi.
Informasi latar belakang
ConcurrencySchedulingPolicy menentukan apakah lalu lintas kelebihan beban berdasarkan batasan pada permintaan konkuren. Ketika jumlah permintaan konkuren melebihi batas atas yang ditentukan, permintaan berikutnya akan dimasukkan ke dalam antrian dan dijadwalkan berdasarkan prioritas mereka. ConcurrencySchedulingPolicy bekerja dengan cara berikut:
ConcurrencySchedulingPolicy menggunakan pembatas konkurensi untuk mencatat jumlah permintaan konkuren yang sedang diproses dan menentukan apakah jumlah tersebut mencapai batas atas.
Ketika jumlah permintaan konkuren mencapai batas atas, permintaan berikutnya dimasukkan ke dalam antrian dan dikirim ke layanan tujuan setelah permintaan sebelumnya diproses. Ini memastikan bahwa sejumlah tertentu permintaan konkuren dipertahankan. Selain itu, permintaan dengan prioritas tinggi memiliki peluang lebih besar untuk dikeluarkan dari antrian dan dikirim ke layanan tujuan.
Ketika jumlah permintaan konkuren melebihi batas atas permintaan yang dapat diproses oleh sistem, ConcurrencySchedulingPolicy tidak langsung menolak permintaan tetapi memasukkannya ke dalam antrian prioritas. Ini berbeda dari ConcurrencyLimitingPolicy yang menolak permintaan ketika ambang batas yang ditentukan tercapai. ConcurrencySchedulingPolicy menjadwalkan permintaan berdasarkan prioritas mereka sambil memastikan bahwa jumlah permintaan konkuren berada dalam batas atas.
Prasyarat
Sebuah kluster Container Service for Kubernetes (ACK) yang dikelola telah ditambahkan ke instance Service Mesh (ASM) Anda, dan versi instance ASM Anda adalah V1.21.6.97 atau lebih baru. Untuk informasi lebih lanjut, lihat Tambahkan kluster ke instance ASM.
Injeksi proxy sidecar otomatis diaktifkan untuk namespace default di kluster ACK. Untuk informasi lebih lanjut, lihat Kelola namespace global.
Anda telah terhubung ke kluster ACK menggunakan kubectl. Untuk informasi lebih lanjut, lihat Dapatkan file kubeconfig kluster dan gunakan kubectl untuk terhubung ke kluster.
Suite penjadwalan lalu lintas ASM diaktifkan. Untuk informasi lebih lanjut, lihat Aktifkan suite penjadwalan lalu lintas ASM.
Aplikasi HTTPBin telah diterapkan dan dapat diakses menggunakan gateway ingress ASM. Untuk informasi lebih lanjut, lihat Terapkan aplikasi HTTPBin.
Langkah 1: Buat ConcurrencySchedulingPolicy
Gunakan kubectl untuk terhubung ke instance ASM Anda. Untuk informasi lebih lanjut, lihat Gunakan kubectl di bidang kontrol untuk mengakses sumber daya Istio.
Buat file concurrencyschedulingpolicy.yaml yang berisi konten berikut:
apiVersion: istio.alibabacloud.com/v1 kind: ConcurrencySchedulingPolicy metadata: name: concurrencyscheduling namespace: istio-system spec: concurrency_scheduler: max_concurrency: 10 concurrency_limiter: max_inflight_duration: 60s scheduler: workloads: - label_matcher: match_labels: http.request.header.user_type: guest parameters: priority: 50.0 name: guest - label_matcher: match_labels: http.request.header.user_type: subscriber parameters: priority: 200.0 name: subscriber selectors: - service: httpbin.default.svc.cluster.localTabel berikut menjelaskan beberapa parameter. Untuk informasi lebih lanjut tentang item konfigurasi, lihat Deskripsi bidang ConcurrencySchedulingPolicy.
Bidang
Deskripsi
max_concurrency
Jumlah maksimum permintaan konkuren. Dalam contoh ini, bidang ini diatur ke 10, yang menunjukkan bahwa layanan diizinkan memproses 10 permintaan pada satu waktu.
max_inflight_duration
Periode timeout untuk pemrosesan permintaan. Karena kejadian tak terduga seperti restart pod di kluster, suite penjadwalan lalu lintas ASM mungkin gagal mencatat peristiwa terminasi permintaan. Untuk mencegah permintaan tersebut memengaruhi penilaian algoritma pembatasan konkurensi, Anda perlu menentukan periode timeout untuk pemrosesan permintaan. Jika permintaan belum direspons sebelum periode timeout ini, sistem menganggap bahwa permintaan tersebut telah diproses. Anda dapat mengatur bidang ini dengan mengevaluasi waktu respons maksimum yang diharapkan dari sebuah permintaan. Dalam contoh ini, bidang ini diatur ke 60s.
workloads
Dua jenis permintaan didefinisikan berdasarkan user_type di header permintaan: guest dan subscriber. Prioritas permintaan tipe guest adalah 50, dan prioritas permintaan tipe subscriber adalah 200.
selectors
Layanan tempat kebijakan throttling diterapkan. Dalam contoh ini, service: httpbin.default.svc.cluster.local digunakan, yang menunjukkan bahwa kebijakan pembatasan konkurensi diterapkan ke layanan httpbin.default.svc.cluster.local.
Jalankan perintah berikut untuk membuat ConcurrencySchedulingPolicy:
kubectl apply -f concurrencyschedulingpoilcy.yaml
Langkah 2: Verifikasi hasil penjadwalan permintaan berdasarkan prioritas dalam skenario di mana permintaan konkuren dikendalikan
Dalam contoh ini, alat uji stres Fortio digunakan. Untuk informasi lebih lanjut, lihat bagian Instalasi Fortio di situs web GitHub.
Buka dua terminal dan jalankan dua perintah uji stres berikut secara bersamaan untuk memulai pengujian. Selama pengujian keseluruhan, pastikan kedua terminal bekerja sesuai harapan. Dalam pengujian pada dua terminal, 10 permintaan konkuren dikirim ke layanan dan laju permintaan per detik (QPS) adalah 10.000, yang secara signifikan melebihi permintaan konkuren yang dapat ditangani layanan.
fortio load -c 10 -qps 10000 -H "user_type:guest" -t 30s -timeout 60s -a http://${IP address of the ASM ingress gateway}/status/201fortio load -c 10 -qps 10000 -H "user_type:subscriber" -t 30s -timeout 60s -a http://${IP address of the ASM ingress gateway}/status/202CatatanGanti
${IP address of the ASM gateway}dalam perintah di atas dengan alamat IP gateway ingress ASM Anda. Untuk informasi lebih lanjut tentang cara mendapatkan alamat IP gateway ingress ASM, lihat sublangkah 1 dari Langkah 3 dalam topik Gunakan sumber daya Istio untuk merutekan lalu lintas ke versi layanan yang berbeda.Output yang diharapkan dari tes 1:
... # target 50% 4.35294 # target 75% 5.39689 # target 90% 5.89697 # target 99% 6.19701 # target 99.9% 6.22702 Sockets used: 10 (for perfect keepalive, would be 10) Uniform: false, Jitter: false Code 201 : 84 (100.0 %) Response Header Sizes : count 84 avg 249.88095 +/- 0.3587 min 248 max 250 sum 20990 Response Body/Total Sizes : count 84 avg 249.88095 +/- 0.3587 min 248 max 250 sum 20990 All done 84 calls (plus 10 warmup) 3802.559 ms avg, 2.6 qps Successfully wrote 5186 bytes of Json data to xxxxxx.jsonCatat nama file JSON yang dihasilkan oleh tes 1, misalnya, xxxxxx.json.
Output yang diharapkan dari tes 2:
... # target 50% 1.18121 # target 75% 1.63423 # target 90% 1.90604 # target 99% 2.22941 # target 99.9% 2.28353 Sockets used: 10 (for perfect keepalive, would be 10) Uniform: false, Jitter: false Code 202 : 270 (100.0 %) Response Header Sizes : count 270 avg 250.52963 +/- 0.5418 min 249 max 251 sum 67643 Response Body/Total Sizes : count 270 avg 250.52963 +/- 0.5418 min 249 max 251 sum 67643 All done 270 calls (plus 10 warmup) 1117.614 ms avg, 8.8 qps Successfully wrote 5305 bytes of Json data to yyyyyy.jsonCatat nama file JSON yang dihasilkan oleh tes 2, misalnya, yyyyyy.json.
Output di atas menunjukkan bahwa latensi permintaan rata-rata tes 2 sekitar 1/4 kali dari tes 1, dan QPS sekitar empat kali lipat dari tes 1. Hal ini karena dalam kebijakan yang didefinisikan sebelumnya, prioritas permintaan tipe subscriber adalah empat kali lipat dari permintaan tipe guest.
(Opsional) Lihat hasil dalam cara visual.
Jalankan perintah berikut di direktori lokal tempat dua perintah dijalankan pada langkah sebelumnya untuk membuka server Fortio lokal:
fortio serverGunakan browser untuk mengakses
http://localhost:8080/fortio/browse, dan klik nama file JSON yang sesuai yang Anda catat di sublangkah 1 untuk melihat hasil tes dalam bentuk visual.Contoh hasil visual untuk tes 1:
Contoh hasil visualisasi untuk tes 2:
Hasil visual di atas menunjukkan bahwa kecuali beberapa permintaan yang tidak dibatasi, sebagian besar permintaan tipe guest memiliki latensi 4.000-6.000 ms. Namun, sebagian besar permintaan tipe subscriber memiliki latensi 1.000-2.000 ms. Ketika permintaan ke layanan melebihi batas atas, permintaan tipe subscriber direspons terlebih dahulu. Selain itu, permintaan konkuren yang dikirim ke layanan dibatasi pada nilai tertentu.
Referensi
Anda dapat memverifikasi apakah ConcurrencySchedulingPolicy berlaku di Grafana. Anda perlu memastikan bahwa instance Prometheus untuk Grafana telah dikonfigurasi dengan suite penjadwalan lalu lintas ASM.
Anda dapat mengimpor konten berikut ke Grafana untuk membuat dasbor untuk ConcurrencySchedulingPolicy.
Dasbor adalah sebagai berikut.
