Pendahuluan
Kami di Shopify menggunakan Istio sebagai service mesh. Pada prinsipnya, semuanya sesuai, kecuali untuk satu hal: itu mahal .
Tolok ukur yang diterbitkan untuk Istio mengatakan:
Dengan Istio 1.1, proksi mengkonsumsi sekitar 0,6 vCPU (virtual core) per 1000 permintaan per detik.
Untuk wilayah pertama di jala layanan (2 proxy di setiap sisi koneksi), kami akan memiliki 1.200 inti hanya untuk proxy, dengan kecepatan satu juta permintaan per detik. Menurut kalkulator biaya Google, Anda mendapatkan sekitar $ 40 / bulan / inti untuk konfigurasi n1-standard-64 , yaitu, wilayah ini saja akan dikenakan biaya lebih dari $ 50.000 per bulan untuk 1 juta permintaan per detik.
Ivan Sim ( Ivan Sim ) dengan jelas membandingkan penundaan service mesh tahun lalu dan menjanjikan hal yang sama untuk memori dan prosesor, tetapi gagal:
Rupanya, values-istio-test.yaml akan secara serius meningkatkan permintaan prosesor. Jika saya menghitung semuanya dengan benar, Anda memerlukan sekitar 24 inti prosesor untuk panel kontrol dan 0,5 CPU untuk setiap proksi. Saya tidak punya banyak. Saya akan mengulangi tes ketika lebih banyak sumber daya dialokasikan untuk saya.
Saya ingin melihat sendiri bagaimana kinerja Istio mirip dengan layanan open source lain: Linkerd .
Instalasi layanan jala
Hal pertama yang saya instal di cluster SuperGloo adalah :
$ supergloo init installing supergloo version 0.3.12 using chart uri https://storage.googleapis.com/supergloo-helm/charts/supergloo-0.3.12.tgz configmap/sidecar-injection-resources created serviceaccount/supergloo created serviceaccount/discovery created serviceaccount/mesh-discovery created clusterrole.rbac.authorization.k8s.io/discovery created clusterrole.rbac.authorization.k8s.io/mesh-discovery created clusterrolebinding.rbac.authorization.k8s.io/supergloo-role-binding created clusterrolebinding.rbac.authorization.k8s.io/discovery-role-binding created clusterrolebinding.rbac.authorization.k8s.io/mesh-discovery-role-binding created deployment.extensions/supergloo created deployment.extensions/discovery created deployment.extensions/mesh-discovery created install successful!
Saya menggunakan SuperGloo karena sangat menyederhanakan boot dari service mesh. Saya hampir tidak ada hubungannya. Dalam produksi, kami tidak menggunakan SuperGloo, tetapi sangat ideal untuk tugas serupa. Saya harus menerapkan hanya beberapa perintah untuk setiap service mesh. Saya menggunakan dua kelompok untuk isolasi - satu untuk Istio dan Linkerd.
Percobaan dilakukan di Google Kubernetes Engine. Saya menggunakan Kubernetes 1.12.7-gke.7 dan 1.12.7-gke.7 n1-standard-4 dengan penskalaan simpul otomatis (minimum 4, maksimum 16).
Kemudian saya menginstal kedua service mesh dari baris perintah.
Tautan pertama:
$ supergloo install linkerd --name linkerd +---------+--------------+---------+---------------------------+ | INSTALL | TYPE | STATUS | DETAILS | +---------+--------------+---------+---------------------------+ | linkerd | Linkerd Mesh | Pending | enabled: true | | | | | version: stable-2.3.0 | | | | | namespace: linkerd | | | | | mtls enabled: true | | | | | auto inject enabled: true | +---------+--------------+---------+---------------------------+
Kemudian Istio:
$ supergloo install istio --name istio --installation-namespace istio-system --mtls=true --auto-inject=true +---------+------------+---------+---------------------------+ | INSTALL | TYPE | STATUS | DETAILS | +---------+------------+---------+---------------------------+ | istio | Istio Mesh | Pending | enabled: true | | | | | version: 1.0.6 | | | | | namespace: istio-system | | | | | mtls enabled: true | | | | | auto inject enabled: true | | | | | grafana enabled: true | | | | | prometheus enabled: true | | | | | jaeger enabled: true | +---------+------------+---------+---------------------------+
Crash-loop memakan waktu beberapa menit, dan kemudian panel kontrol stabil.
(Catatan: SuperGloo saat ini hanya mendukung Istio 1.0.x. Saya mengulangi percobaan dengan Istio 1.1.3, tetapi tidak melihat adanya perbedaan yang nyata.)
Menyiapkan penyebaran Istio secara otomatis
Agar Istio menginstal Utusan sespan, kami menggunakan injektor sespan - MutatingAdmissionWebhook . Kami tidak akan membicarakannya di artikel ini. Saya hanya bisa mengatakan bahwa ini adalah pengontrol yang memonitor akses semua pod baru dan secara dinamis menambahkan sespan dan initContainer, yang bertanggung jawab untuk tugas iptables .
Kami di Shopify menulis pengontrol akses kami untuk mengimplementasikan sespan, tetapi dalam tolok ukur ini saya mengambil pengontrol yang disertakan dengan Istio. Pengontrol menyuntikkan sespan secara default ketika ada istio-injection: enabled pintasan yang istio-injection: enabled di namespace:
$ kubectl label namespace irs-client-dev istio-injection=enabled namespace/irs-client-dev labeled $ kubectl label namespace irs-server-dev istio-injection=enabled namespace/irs-server-dev labeled
Konfigurasikan Penerapan Otomatis Linkerd
Untuk mengkonfigurasi implementasi sidecar Linkerd, kami menggunakan anotasi (saya menambahkannya secara manual melalui kubectl edit ):
metadata: annotations: linkerd.io/inject: enabled
$ k edit ns irs-server-dev namespace/irs-server-dev edited $ k get ns irs-server-dev -o yaml apiVersion: v1 kind: Namespace metadata: annotations: linkerd.io/inject: enabled name: irs-server-dev spec: finalizers: - kubernetes status: phase: Active
Simulator toleransi kesalahan Istio
Kami membuat simulator toleransi kesalahan Istio untuk bereksperimen dengan lalu lintas yang unik untuk Shopify. Kami membutuhkan alat untuk membuat topologi sewenang-wenang yang akan mewakili bagian tertentu dari grafik layanan kami dengan penyetelan dinamis untuk mensimulasikan beban kerja tertentu.
Infrastruktur Shopify berada di bawah beban berat selama penjualan kilat. Pada saat yang sama, Shopify merekomendasikan agar penjual melakukan penjualan seperti itu lebih sering . Pelanggan besar terkadang memperingatkan penjualan flash yang direncanakan. Orang lain membelanjakannya secara tak terduga untuk kita kapan saja, siang atau malam hari.
Kami ingin simulator toleransi kesalahan kami untuk memodelkan alur kerja yang cocok dengan topologi dan beban kerja yang telah membebani infrastruktur Shopify di masa lalu. Tujuan utama menggunakan service mesh adalah kita membutuhkan keandalan dan toleransi kesalahan pada level jaringan, dan penting bagi kita bahwa service mesh secara efektif mengatasi beban yang sebelumnya mengganggu operasi layanan.
Simulator failover didasarkan pada simpul kerja yang bertindak sebagai simpul mesh layanan. Node kerja dapat dikonfigurasi secara statis saat startup atau secara dinamis melalui REST API. Kami menggunakan penyetelan dinamis node kerja untuk membuat alur kerja dalam bentuk tes regresi.
Ini adalah contoh dari proses semacam itu:
- Kami memulai 10 server sebagai layanan
bar , yang mengembalikan respons 200/OK setelah 100 ms. - Kami memulai 10 klien - masing-masing mengirim 100 permintaan per detik ke
bar . - Setiap 10 detik kami menghapus 1 server, kami memantau kesalahan
5xx pada klien.
Di akhir alur kerja, kami mempelajari log dan metrik dan memeriksa apakah tes lulus. Ini adalah bagaimana kami belajar tentang kinerja mesh layanan kami dan melakukan uji regresi untuk menguji asumsi kami tentang toleransi kesalahan.
(Catatan: Kami sedang mempertimbangkan untuk membuka kode sumber untuk simulator toleransi kesalahan Istio, tetapi kami belum siap untuk itu.)
Simulator toleransi kesalahan Istio untuk tolok ukur layanan mesh
Kami mengonfigurasi beberapa simpul kerja dari simulator:
irs-client-loadgen : 3 replika yang mengirim 100 permintaan per detik ke irs-client .irs-client : 3 replika yang menerima permintaan tunggu 100 ms dan arahkan permintaan ke irs-server .irs-server : 3 replika yang mengembalikan 200/OK setelah 100 ms.
Dengan konfigurasi ini, kita dapat mengukur arus lalu lintas yang stabil antara 9 titik akhir. Sidecar di irs-client-loadgen dan irs-server menerima 100 permintaan per detik, dan irs-client - 200 (masuk dan keluar).
Kami melacak penggunaan sumber daya melalui DataDog karena kami tidak memiliki cluster Prometheus.
Hasil
Panel kontrol
Pertama, kami memeriksa konsumsi CPU.
Panel Kontrol Linkerd ~ 22M
Panel Kontrol Istio: ~ 750 Juta Core
Panel kontrol Istio menggunakan sekitar 35 kali lebih banyak sumber daya prosesor daripada Linkerd. Tentu saja, semuanya diatur secara default, dan istio-telemetri menghabiskan banyak sumber daya prosesor (Anda dapat menonaktifkannya dengan meninggalkan beberapa fungsi). Jika Anda menghapus komponen ini, ternyata masih lebih dari 100 multicore, itu 4 kali lebih banyak dari Linkerd.
Proksi sespan
Kemudian kami memeriksa penggunaan proksi. Seharusnya ada ketergantungan linear pada jumlah permintaan, tetapi untuk setiap sespan ada beberapa overhead yang mempengaruhi kurva.
Linkerd: ~ 100Mnuclear untuk irs-client, ~ 50Mnuclear untuk irs-client-loadgen
Hasilnya terlihat logis, karena proksi klien menerima lalu lintas dua kali lebih banyak daripada proksi loadgen: untuk setiap permintaan keluar dari loadgen, klien memiliki satu masuk dan satu keluar.
Istio / Utusan: ~ 155 jutawan untuk irs-client, ~ 75 jutawan untuk irs-client-loadgen
Kami melihat hasil yang sama untuk sesecar Istio.
Namun secara keseluruhan, proxy Istio / Utusan mengonsumsi sekitar 50% lebih banyak sumber daya prosesor daripada Linkerd.
Kami melihat skema yang sama di sisi server:
Linkerd: ~ 50 multicore untuk irs-server
Istio / Utusan: ~ 80 multicore untuk irs-server
Di sisi server, sesecar Istio / Utusan mengkonsumsi sekitar 60% lebih banyak sumber daya prosesor daripada Linkerd.
Kesimpulan
Proxy Istio Envoy mengkonsumsi CPU 50% lebih banyak daripada Linkerd pada beban kerja simulasi kami. Panel kontrol Linkerd mengkonsumsi sumber daya jauh lebih sedikit daripada Istio, terutama untuk komponen utama.
Kami masih memikirkan cara mengurangi biaya ini. Jika Anda punya ide, bagikan!