Performa dan penskalakan add-on jala layanan Istio
Add-on jala layanan berbasis Istio secara logis dibagi menjadi sarana kontrol (istiod
) dan bidang data. Bidang data terdiri dari proksi sidecar Envoy di dalam pod beban kerja. Istiod mengelola dan mengonfigurasi proksi Envoy ini. Artikel ini menyajikan performa sarana kontrol dan data untuk revisi asm-1-19, termasuk konsumsi sumber daya, kapasitas sespan, dan overhead latensi. Selain itu, ini memberikan saran untuk mengatasi potensi strain pada sumber daya selama periode beban berat. Artikel ini juga membahas cara menyesuaikan penskalaan untuk sarana kontrol dan gateway.
Persyaratan CPU dan memori Istiod berkorelasi dengan tingkat penyebaran dan perubahan konfigurasi dan jumlah proksi yang terhubung. Skenario yang diuji adalah:
- Churn pod: memeriksa dampak churning pod pada
istiod
. Untuk mengurangi variabel, hanya satu layanan yang digunakan untuk semua sespan. - Beberapa layanan: memeriksa dampak beberapa layanan pada sespan maksimum yang dapat dikelola Istiod (kapasitas sespan), di mana setiap layanan memiliki
N
sespan, dengan total maksimum keseluruhan.
- Satu
istiod
instans dengan pengaturan default - Penskalakan otomatis pod horizontal dinonaktifkan
- Diuji dengan dua plugin jaringan: Azure Container Networking Interface (CNI) Overlay dan Azure CNI Overlay dengan Cilium (plugin jaringan yang direkomendasikan untuk kluster skala besar)
- SKU Simpul: D16 v3 Standar (16 vCPU, memori 64 GB)
- Versi Kubernetes: 1.28.5
- Revisi Istio: asm-1-19
Kerangka kerja ClusterLoader2 digunakan untuk menentukan jumlah maksimum sidecar yang dapat dikelola Istiod ketika ada churning sidecar. Persentase churn didefinisikan sebagai persentase sespan yang terpotong/naik selama pengujian. Misalnya, 50% churn untuk 10.000 sespan berarti bahwa 5.000 sespan diluncurkan, kemudian 5.000 sespan terpotong. Persentase churn yang diuji ditentukan dari persentase churn khas selama peluncuran penyebaran (maxUnavailable
). Tingkat churn dihitung dengan menentukan jumlah total sespan yang di-churn (naik dan turun) selama waktu aktual yang diperlukan untuk menyelesaikan proses churning.
Overlay Azure CNI
Churn (%) | Laju Churn (sespan/detik) | Kapasitas Sidecar | Memori Istiod (GB) | Istiod CPU |
---|---|---|---|---|
0 | -- | 25000 | 32.1 | 15 |
25 | 31.2 | 15000 | 22.2 | 15 |
50 | 31.2 | 15000 | 25.4 | 15 |
Overlay Azure CNI dengan Cilium
Churn (%) | Laju Churn (sespan/detik) | Kapasitas Sidecar | Memori Istiod (GB) | Istiod CPU |
---|---|---|---|---|
0 | -- | 30000 | 41.2 | 15 |
25 | 41.7 | 25000 | 36.1 | 16 |
50 | 37.9 | 25000 | 42.7 | 16 |
Kerangka kerja ClusterLoader2 digunakan untuk menentukan jumlah maksimum sespan istiod
yang dapat dikelola dengan 1.000 layanan. Hasilnya dapat dibandingkan dengan tes churn 0% (satu layanan) dalam skenario churn pod. Setiap layanan memiliki N
sespan yang berkontribusi pada jumlah sespan maksimum secara keseluruhan. Penggunaan sumber daya API Server diamati untuk menentukan apakah ada stres yang signifikan dari add-on.
Kapasitas sespan
Overlay Azure CNI | Overlay Azure CNI dengan Cilium |
---|---|
20000 | 20000 |
CPU dan memori
Sumber daya | Overlay Azure CNI | Overlay Azure CNI dengan Cilium |
---|---|---|
Memori Api Server (GB) | 38.9 | 9.7 |
API Server CPU | 6.1 | 4.7 |
Memori Istiod (GB) | 40.4 | 42.6 |
Istiod CPU | 15 | 16 |
Berbagai faktor berdampak pada performa sidecar seperti ukuran permintaan, jumlah utas pekerja proksi, dan jumlah koneksi klien. Selain itu, setiap permintaan yang mengalir melalui jala melintasi proksi sisi klien dan kemudian proksi sisi server. Oleh karena itu, latensi dan konsumsi sumber daya diukur untuk menentukan performa data plane.
Fortio
digunakan untuk membuat beban. Pengujian dilakukan dengan repositori tolok ukur Istio yang dimodifikasi untuk digunakan dengan add-on.
- Diuji dengan dua plugin jaringan: Azure CNI Overlay dan Azure CNI Overlay dengan Cilium (plugin jaringan yang direkomendasikan untuk kluster skala besar)
- SKU Simpul: D16 v5 Standar (16 vCPU, memori 64 GB)
- Versi Kubernetes: 1.28.5
- Dua pekerja proksi
- Payload 1 KB
- 1.000 Kueri per detik (QPS) pada koneksi klien yang bervariasi
http/1.1
protokol dan Keamanan Lapisan Transportasi bersama (TLS) diaktifkan- 26 poin data dikumpulkan
Memori dan penggunaan CPU untuk klien dan proksi server untuk 16 koneksi klien dan 1.000 QPS di semua skenario plugin jaringan kira-kira 0,4 vCPU dan 72 MB.
Proksi Envoy sidecar mengumpulkan data telemetri mentah setelah menanggapi klien, yang tidak secara langsung memengaruhi total waktu pemrosesan permintaan. Namun, proses ini menunda awal penanganan permintaan berikutnya, berkontribusi pada waktu tunggu antrean dan berpengaruh pada latensi rata-rata dan ekor. Tergantung pada pola lalu lintas, latensi ekor aktual bervariasi.
Hasil berikut mengevaluasi dampak penambahan proksi sidecar ke jalur data, menampilkan latensi P90 dan P99.
- Jalur lalu lintas sidecar: klien --> client-sidecar --> server-sidecar --> server
- Jalur lalu lintas garis besar: klien --> server
Perbandingan performa latensi bidang data di seluruh add-on Istio dan versi AKS dapat ditemukan di sini.
Penskalaan otomatis pod horizontal (HPA) diaktifkan untuk istiod
pod gateway ingress dan . Konfigurasi default untuk istiod
dan gateway adalah:
- Replika Min: 2
- Replika Maks: 5
- Pemanfaatan CPU: 80%
Catatan
Untuk mencegah konflik dengan PodDisruptionBudget
, add-on tidak memungkinkan pengaturan minReplicas
di bawah default 2
awal .
Berikut ini adalah istiod
sumber daya HPA gateway masuk dan :
NAMESPACE NAME REFERENCE
aks-istio-ingress aks-istio-ingressgateway-external-asm-1-19 Deployment/aks-istio-ingressgateway-external-asm-1-19
aks-istio-ingress aks-istio-ingressgateway-internal-asm-1-19 Deployment/aks-istio-ingressgateway-internal-asm-1-19
aks-istio-system istiod-asm-1-19 Deployment/istiod-asm-1-19
Konfigurasi HPA dapat dimodifikasi melalui patch dan pengeditan langsung. Contoh:
kubectl patch hpa aks-istio-ingressgateway-external-asm-1-19 -n aks-istio-ingress --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'
Catatan
Lihat dokumentasi peningkatan add-on Istio untuk detail tentang bagaimana pengaturan HPA diterapkan di kedua revisi selama peningkatan kenari.
Definisi sumber daya kustom ServiceEntry Istio memungkinkan penambahan layanan lain ke dalam registri layanan internal Istio. ServiceEntry memungkinkan layanan yang sudah ada dalam jala untuk merutekan atau mengakses layanan yang ditentukan. Namun, konfigurasi beberapa ServiceEntries dengan bidang yang resolution
diatur ke DNS dapat menyebabkan beban berat pada server Sistem Nama Domain (DNS). Saran berikut dapat membantu mengurangi beban:
- Beralih ke untuk
resolution: NONE
menghindari pencarian DNS proksi sepenuhnya. Cocok untuk sebagian besar kasus penggunaan. - Tingkatkan TTL (Time To Live) jika Anda mengontrol domain yang sedang diselesaikan.
- Batasi cakupan ServiceEntry dengan
exportTo
.
Umpan balik Azure Kubernetes Service
Azure Kubernetes Service adalah proyek sumber terbuka. Pilih tautan untuk memberikan umpan balik: