pengenalan
Kami berada di mulai menerapkan Istio sebagai mesh layanan. Pada prinsipnya, semuanya baik-baik saja, kecuali satu hal: itu mahal.
Π untuk Istio dikatakan:
Dengan Istio 1.1, proksi menggunakan sekitar 0,6 vCPU (virtual core) per 1000 permintaan per detik.
Untuk wilayah pertama dalam mesh layanan (2 proxy di setiap sisi koneksi), kami akan memiliki 1200 inti hanya untuk proxy, dengan kecepatan satu juta permintaan per detik. Menurut kalkulator biaya Google, biayanya sekitar $40/bulan/inti untuk konfigurasi n1-standard-64, artinya, wilayah ini saja akan menelan biaya lebih dari 50 ribu dolar per bulan untuk 1 juta permintaan per detik.
Ivan Sim () penundaan layanan mesh tahun lalu dan menjanjikan hal yang sama untuk memori dan prosesor, tetapi tidak berhasil:
Rupanya, value-istio-test.yaml akan meningkatkan permintaan CPU secara serius. Jika saya menghitungnya dengan benar, Anda memerlukan sekitar 24 inti CPU untuk panel kontrol dan 0,5 CPU untuk setiap proxy. Saya tidak punya sebanyak itu. Saya akan mengulangi pengujian ketika lebih banyak sumber daya dialokasikan kepada saya.
Saya ingin melihat sendiri seberapa mirip kinerja Istio dengan layanan open source lainnya: .
Pemasangan jaring layanan
Pertama-tama, saya menginstalnya di sebuah cluster :
$ 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 membuat bootstrap mesh layanan menjadi lebih mudah. Saya tidak perlu berbuat banyak. Kami tidak menggunakan SuperGloo dalam produksi, tapi ini ideal untuk tugas seperti itu. Saya harus menggunakan beberapa perintah untuk setiap mesh layanan. Saya menggunakan dua cluster untuk isolasi - masing-masing satu untuk Istio dan Linkerd.
Percobaan dilakukan pada Google Kubernetes Engine. Saya menggunakan Kubernet 1.12.7-gke.7 dan kumpulan node n1-standard-4 dengan penskalaan node otomatis (minimal 4, maksimal 16).
Kemudian saya menginstal kedua jerat layanan 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 menjadi stabil.
(Catatan: SuperGloo hanya mendukung Istio 1.0.x untuk saat ini. Saya mengulangi percobaan dengan Istio 1.1.3, tetapi tidak melihat adanya perbedaan yang mencolok.)
Menyiapkan Penerapan Otomatis Istio
Untuk membuat Istio memasang sespan Envoy, kami menggunakan injektor sespan β MutatingAdmissionWebhook. Kami tidak akan membicarakannya di artikel ini. Izinkan saya mengatakan bahwa ini adalah pengontrol yang memantau akses semua pod baru dan secara dinamis menambahkan sespan dan initContainer, yang bertanggung jawab atas tugas-tugas iptables.
Kami di Shopify menulis pengontrol akses kami sendiri untuk mengimplementasikan sidecar, tetapi untuk benchmark ini saya menggunakan pengontrol yang disertakan dengan Istio. Pengontrol menyuntikkan sidecar secara default ketika ada pintasan di namespace istio-injection: enabled:
$ 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 labeledMenyiapkan penerapan Linkerd otomatis
Untuk mengatur penyematan sespan 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: ActiveSimulator Toleransi Kesalahan Istio
Kami membuat simulator toleransi kesalahan yang disebut Istio untuk bereksperimen dengan lalu lintas unik untuk Shopify. Kami memerlukan alat untuk membuat topologi khusus yang akan mewakili bagian tertentu dari grafik layanan kami, yang dikonfigurasi secara dinamis untuk memodelkan beban kerja tertentu.
Infrastruktur Shopify mengalami beban berat selama penjualan kilat. Pada saat yang sama, Shopify . Pelanggan besar terkadang memperingatkan tentang rencana penjualan kilat. Yang lain melakukannya secara tidak terduga untuk kita kapan saja, siang atau malam.
Kami ingin simulator ketahanan kami memodelkan alur kerja yang sesuai dengan topologi dan beban kerja yang pernah membebani infrastruktur Shopify di masa lalu. Tujuan utama penggunaan mesh layanan adalah bahwa kita memerlukan keandalan dan toleransi kesalahan di tingkat jaringan, dan penting bagi kita bahwa mesh layanan secara efektif mengatasi beban yang sebelumnya mengganggu layanan.
Inti dari simulator toleransi kesalahan adalah node pekerja, yang bertindak sebagai node mesh layanan. Node pekerja dapat dikonfigurasi secara statis saat startup atau secara dinamis melalui REST API. Kami menggunakan konfigurasi dinamis node pekerja untuk membuat alur kerja dalam bentuk uji regresi.
Berikut ini contoh proses tersebut:
- Kami meluncurkan 10 server sebagai
barlayanan yang mengembalikan respons200/OKsetelah 100 ms. - Kami meluncurkan 10 klien - masing-masing mengirimkan 100 permintaan per detik ke
bar. - Setiap 10 detik kami menghapus 1 server dan memantau kesalahan
5xxpada klien.
Di akhir alur kerja, kami memeriksa log dan metrik serta memeriksa apakah pengujian berhasil. Dengan cara ini kami mempelajari kinerja mesh layanan kami dan menjalankan uji regresi untuk menguji asumsi kami tentang toleransi kesalahan.
(Catatan: Kami sedang mempertimbangkan untuk membuat simulator toleransi kesalahan Istio menjadi sumber terbuka, namun kami belum siap untuk melakukannya.)
Simulator toleransi kesalahan Istio untuk benchmark mesh layanan
Kami menyiapkan beberapa node kerja simulator:
irs-client-loadgen: 3 replika yang mengirimkan 100 permintaan per detik perirs-client.irs-client: 3 replika yang menerima permintaan, tunggu 100 ms dan teruskan permintaan keirs-server.irs-server: 3 replika yang kembali200/OKsetelah 100 ms.
Dengan konfigurasi ini, kita dapat mengukur arus lalu lintas yang stabil antara 9 titik akhir. Sidecar masuk irs-client-loadgen ΠΈ irs-server menerima 100 permintaan per detik, dan irs-client β 200 (masuk dan keluar).
Kami melacak penggunaan sumber daya melalui karena kami tidak memiliki cluster Prometheus.
Temuan
Panel kendali
Pertama, kami memeriksa konsumsi CPU.
Panel kontrol Linkerd ~22 milicore
Panel kontrol Istio: ~750 milicore
Panel kontrol Istio menggunakan kira-kira Sumber daya CPU 35 kali lebih banyakdaripada Linkerd. Tentu saja, semuanya diinstal secara default, dan istio-telemetri menghabiskan banyak sumber daya prosesor di sini (dapat dinonaktifkan dengan menonaktifkan beberapa fungsi). Jika kita menghapus komponen ini, kita masih mendapatkan lebih dari 100 milicore 4 kali lebih banyakdaripada Linkerd.
Proksi sespan
Kami kemudian menguji penggunaan proxy. Harus ada hubungan linear dengan jumlah permintaan, tetapi untuk setiap sidecar ada beberapa overhead yang mempengaruhi kurva.
Linkerd: ~100 milicore untuk irs-client, ~50 milicore untuk irs-client-loadgen
Hasilnya terlihat logis, karena proksi klien menerima lalu lintas dua kali lebih banyak dibandingkan proksi loadgen: untuk setiap permintaan keluar dari loadgen, klien memiliki satu permintaan masuk dan satu permintaan keluar.
Istio/Utusan: ~155 milicore untuk irs-client, ~75 milicore untuk irs-client-loadgen
Kami melihat hasil serupa untuk sidecar Istio.
Namun secara umum, proxy Istio/Envoy mengkonsumsi sekitar 50% lebih banyak sumber daya CPUdaripada Linkerd.
Kami melihat skema yang sama di sisi server:
Linkerd: ~50 milicore untuk server irs
Istio/Utusan: ~80 milicore untuk server irs
Di sisi server, sespan Istio/Envoy dikonsumsi sekitar 60% lebih banyak sumber daya CPUdaripada Linkerd.
Kesimpulan
Proksi Istio Envoy menggunakan CPU 50+% lebih banyak daripada Linkerd pada beban kerja simulasi kami. Panel kontrol Linkerd mengkonsumsi sumber daya yang jauh lebih sedikit dibandingkan Istio, terutama untuk komponen inti.
Kami masih memikirkan cara mengurangi biaya-biaya ini. Jika Anda punya ide, silakan bagikan!
Sumber: www.habr.com