Bagikan melalui

Performa dan penskalakan add-on jala layanan Istio

  • Artikel

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.

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 beberapa layanan pada sespan maksimum yang dapat dikelola Istiod (kapasitas sespan), di mana setiap layanan memiliki N sespan, 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

Churn pod

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.

Kapasitas sidecar dan Istiod CPU dan memori

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

Beberapa layanan

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

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 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.

Overlay Azure CNI Overlay Azure CNI dengan Cilium
Diagram yang membandingkan latensi P99 untuk Azure CNI Overlay. Diagram yang membandingkan latensi P99 untuk Azure CNI Overlay dengan Cilium.
Diagram yang membandingkan latensi P90 untuk Azure CNI Overlay. Diagram yang membandingkan latensi P90 untuk Azure CNI Overlay dengan Cilium.

Penskalaan

Kustomisasi penskalaan otomatis pod horizontal

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 2awal .

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.

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 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.