Performa dan penskalaan mesh layanan Istio

Add-on jala layanan berbasis Istio secara logis dibagi menjadi sarana kontrol (istiod) dan bidang data. Lapisan data terdiri dari proksi Envoy sidecar yang berada 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 skala untuk bidang kontrol dan gerbang.

Performa sarana kontrol

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 dari beberapa layanan terhadap jumlah maksimum sidecar yang dapat dikelola oleh Istiod (kapasitas sidecar), di mana setiap layanan memiliki N sidecar, dengan total maksimum keseluruhan.

Spesifikasi pengujian

• 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

Perubahan Pod

Kerangka ClusterLoader2 digunakan untuk menentukan jumlah maksimum sidecar yang dapat dikelola Istiod ketika terjadi pergantian sidecar. Persentase churn didefinisikan sebagai persentase komponen yang diaktifkan/dinonaktifkan selama pengujian. Misalnya, 50% churn untuk 10.000 sespan berarti bahwa 5.000 sespan mengalami penurunan, kemudian 5.000 sespan mengalami peningkatan. Persentase churn yang diuji ditentukan dari persentase churn khas selama peluncuran (maxUnavailable). Tingkat churn dihitung dengan menentukan jumlah total sespan yang di-churn (naik dan turun) selama waktu aktual yang diperlukan untuk menyelesaikan proses churning.

Kapasitas sidecar dan CPU serta memori Istiod

Overlay Azure CNI

Churn (%)	Laju Churn (sidecar/detik)	Kapasitas Kereta Samping	Memori Istiod (GB)	Istiod CPU
0	--	25000	32.1	15
Dua puluh lima	31.2	15000	22.2	15
50	31.2	15000	25.4	15

Overlay Azure CNI dengan Cilium

Churn (%)	Laju Churn (sidecar/detik)	Kapasitas Kereta Samping	Memori Istiod (GB)	Istiod Unit Pemrosesan Pusat
0	--	30000	41.2	15
Dua puluh lima	41.7	25000	36.1	16
50	37.9	25000	42.7	16

Beberapa layanan

Kerangka kerja ClusterLoader2 digunakan untuk menentukan jumlah maksimum sidecar 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	Azure CNI Overlay memanfaatkan Cilium
20000	20000

CPU dan memori

Sumber daya	Overlay Azure CNI	Azure CNI Overlay memanfaatkan 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

Performa sarana data

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.

Spesifikasi pengujian

• 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

CPU dan memori

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.

Latensi

Proksi Sidecar Envoy mengumpulkan data telemetri mentah setelah menyelesaikan tanggapan terhadap klien, yang tidak berdampak langsung pada seluruh 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 --> sidecar-klien --> sidecar-server --> 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.

Overlay Azure CNI	Azure CNI Overlay memanfaatkan Cilium

Penskalaan

Kustomisasi penskalaan otomatis pod horizontal

Penskalaan otomatis pod horizontal (HPA) diaktifkan untuk pernyebaran keluar/masuk gateway. Konfigurasi default untuk istiod dan gateway adalah:

• Jumlah Replika Minimal: 2
• Replika Maksimum: 5
• Pemanfaatan CPU: 80%

Catatan

Untuk mencegah konflik dengan PodDisruptionBudget, add-on tidak memungkinkan pengaturan minReplicas di bawah default awal 2.

Berikut ini adalah istiod dan sumber daya HPA gateway masuk:

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.

Entri layanan

Definisi sumber daya kustom ServiceEntry Istio memungkinkan penambahan layanan lain ke dalam registri layanan internal Istio. ServiceEntry memungkinkan layanan yang sudah ada dalam jaringan 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 resolution: NONE untuk menghindari pencarian DNS proksi sepenuhnya. Cocok untuk sebagian besar kasus penggunaan. Namun, saat menggunakan gateway keluar add-on Istio, resolusi ServiceEntry harus diatur ke DNS.
• Tingkatkan TTL (Time To Live) jika Anda mengontrol domain yang sedang diselesaikan.
• Batasi cakupan ServiceEntry dengan exportTo.