Pengenalan
Kita di dalam mula menggunakan Istio sebagai jaringan perkhidmatan. Pada dasarnya, semuanya baik-baik saja, kecuali satu perkara: ianya mahal.
Π untuk Istio ia berkata:
Dengan Istio 1.1, proksi menggunakan kira-kira 0,6 vCPU (teras maya) setiap 1000 permintaan sesaat.
Untuk rantau pertama dalam jaringan perkhidmatan (2 proksi pada setiap sisi sambungan), kami akan mempunyai 1200 teras hanya untuk proksi, pada kadar satu juta permintaan sesaat. Menurut kalkulator kos Google, ia adalah kira-kira $40/bulan/teras untuk konfigurasi n1-standard-64, iaitu, rantau ini sahaja akan menelan kos lebih daripada 50 ribu dolar sebulan untuk 1 juta permintaan sesaat.
Ivan Sim () kelewatan mesh perkhidmatan tahun lepas dan menjanjikan perkara yang sama untuk memori dan pemproses, tetapi ia tidak berjaya:
Nampaknya, values-istio-test.yaml akan meningkatkan permintaan CPU dengan serius. Jika saya telah membuat pengiraan dengan betul, anda memerlukan kira-kira 24 teras CPU untuk panel kawalan dan 0,5 CPU untuk setiap proksi. Saya tidak mempunyai sebanyak itu. Saya akan mengulangi ujian apabila lebih banyak sumber diperuntukkan kepada saya.
Saya ingin melihat sendiri betapa serupa prestasi Istio dengan rangkaian perkhidmatan sumber terbuka yang lain: .
Pemasangan jaringan perkhidmatan
Pertama sekali, saya memasangnya dalam kelompok :
$ 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 kerana ia menjadikan bootstrap mesh perkhidmatan lebih mudah. Saya tidak perlu berbuat banyak. Kami tidak menggunakan SuperGloo dalam pengeluaran, tetapi ia sesuai untuk tugasan sedemikian. Saya terpaksa menggunakan secara literal beberapa arahan untuk setiap mesh perkhidmatan. Saya menggunakan dua kluster untuk pengasingan - masing-masing satu untuk Istio dan Linkerd.
Percubaan telah dijalankan pada Enjin Google Kubernetes. Saya menggunakan Kubernetes 1.12.7-gke.7 dan kumpulan nod n1-standard-4 dengan penskalaan nod automatik (minimum 4, maksimum 16).
Kemudian saya memasang kedua-dua jejaring perkhidmatan dari baris arahan.
Linkerd 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 |
+---------+------------+---------+---------------------------+Gelung ranap itu mengambil masa beberapa minit, dan kemudian panel kawalan menjadi stabil.
(Nota: SuperGloo hanya menyokong Istio 1.0.x buat masa ini. Saya mengulangi percubaan dengan Istio 1.1.3, tetapi tidak melihat sebarang perbezaan yang ketara.)
Menyediakan Istio Automatic Deployment
Untuk membuat Istio memasang Envoy kereta sisi, kami menggunakan penyuntik kereta sisi β MutatingAdmissionWebhook. Kami tidak akan membincangkannya dalam artikel ini. Biar saya katakan bahawa ini ialah pengawal yang memantau akses semua pod baharu dan secara dinamik menambah sidecar dan initContainer, yang bertanggungjawab untuk tugasan iptables.
Kami di Shopify menulis pengawal akses kami sendiri untuk melaksanakan sidecars, tetapi untuk penanda aras ini saya menggunakan pengawal yang disertakan dengan Istio. Pengawal menyuntik sidecars secara lalai apabila terdapat jalan pintas dalam ruang nama 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 labeledMenyediakan penggunaan Linkerd automatik
Untuk menyediakan pembenaman kereta sampingan 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 membina simulator toleransi kesalahan yang dipanggil Istio untuk bereksperimen dengan trafik unik untuk Shopify. Kami memerlukan alat untuk mencipta topologi tersuai yang akan mewakili bahagian tertentu graf perkhidmatan kami, dikonfigurasikan secara dinamik untuk memodelkan beban kerja tertentu.
Infrastruktur Shopify mengalami beban berat semasa jualan kilat. Pada masa yang sama, Shopify . Pelanggan besar kadangkala memberi amaran tentang jualan kilat yang dirancang. Orang lain melakukannya tanpa diduga untuk kita pada bila-bila masa siang atau malam.
Kami mahu simulator daya tahan kami memodelkan aliran kerja yang sepadan dengan topologi dan beban kerja yang telah mengatasi infrastruktur Shopify pada masa lalu. Tujuan utama menggunakan jaringan perkhidmatan ialah kami memerlukan kebolehpercayaan dan toleransi kesalahan pada peringkat rangkaian, dan adalah penting bagi kami bahawa jaringan perkhidmatan secara berkesan mengatasi beban yang sebelum ini mengganggu perkhidmatan.
Di tengah-tengah simulator toleransi kesalahan ialah nod pekerja, yang bertindak sebagai nod jaringan perkhidmatan. Nod pekerja boleh dikonfigurasikan secara statik pada permulaan atau secara dinamik melalui API REST. Kami menggunakan konfigurasi dinamik nod pekerja untuk mencipta aliran kerja dalam bentuk ujian regresi.
Berikut adalah contoh proses sedemikian:
- Kami melancarkan 10 pelayan sebagai
barperkhidmatan yang mengembalikan respons200/OKselepas 100 ms. - Kami melancarkan 10 pelanggan - setiap satu menghantar 100 permintaan sesaat kepada
bar. - Setiap 10 saat kami mengalih keluar 1 pelayan dan memantau ralat
5xxpada klien.
Pada akhir aliran kerja, kami memeriksa log dan metrik dan menyemak sama ada ujian itu lulus. Dengan cara ini kami belajar tentang prestasi jaringan perkhidmatan kami dan menjalankan ujian regresi untuk menguji andaian kami tentang toleransi kesalahan.
(Nota: Kami sedang memikirkan tentang sumber terbuka simulator toleransi kesalahan Istio, tetapi belum bersedia untuk berbuat demikian.)
Simulator toleransi kesalahan Istio untuk penanda aras mesh perkhidmatan
Kami menyediakan beberapa nod simulator yang berfungsi:
irs-client-loadgen: 3 replika yang menghantar 100 permintaan sesaat setiapirs-client.irs-client: 3 replika yang menerima permintaan, tunggu 100ms dan majukan permintaan keirs-server.irs-server: 3 replika yang kembali200/OKselepas 100 ms.
Dengan konfigurasi ini, kita boleh mengukur aliran trafik yang stabil antara 9 titik akhir. Sidecar masuk irs-client-loadgen ΠΈ irs-server menerima 100 permintaan sesaat, dan irs-client β 200 (masuk dan keluar).
Kami menjejaki penggunaan sumber melalui kerana kami tidak mempunyai kluster Prometheus.
Penemuan
Panel kawalan
Pertama, kami memeriksa penggunaan CPU.
Panel kawalan Linkerd ~22 milicore
Panel kawalan Istio: ~750 milicore
Panel kawalan Istio menggunakan lebih kurang 35 kali lebih banyak sumber CPUdaripada Linkerd. Sudah tentu, semuanya dipasang secara lalai, dan istio-telemetri menggunakan banyak sumber pemproses di sini (ia boleh dilumpuhkan dengan melumpuhkan beberapa fungsi). Jika kita mengalih keluar komponen ini, kita masih mendapat lebih daripada 100 milicore, iaitu 4 kali lebih banyakdaripada Linkerd.
Proksi kereta sampingan
Kami kemudiannya menguji penggunaan proksi. Perlu ada hubungan linear dengan bilangan permintaan, tetapi untuk setiap kereta sampingan terdapat beberapa overhed yang mempengaruhi lengkung.
Linkerd: ~100 milicores untuk irs-client, ~50 milicores untuk irs-client-loadgen
Hasilnya kelihatan logik, kerana proksi pelanggan menerima trafik dua kali lebih banyak daripada proksi loadgen: untuk setiap permintaan keluar daripada loadgen, pelanggan mempunyai satu masuk dan satu keluar.
Istio/Envoy: ~155 milicores untuk irs-client, ~75 milicores untuk irs-client-loadgen
Kami melihat hasil yang serupa untuk kereta sampingan Istio.
Tetapi secara umum, proksi Istio/Utusan menggunakan lebih kurang 50% lebih banyak sumber CPUdaripada Linkerd.
Kami melihat skema yang sama di sisi pelayan:
Linkerd: ~50 milicore untuk irs-server
Istio/Utusan: ~80 milicore untuk irs-server
Di bahagian pelayan, kereta sampingan Istio/Envoy menggunakan lebih kurang 60% lebih banyak sumber CPUdaripada Linkerd.
Kesimpulan
Proksi Istio Envoy menggunakan 50+% lebih CPU daripada Linkerd pada beban kerja simulasi kami. Panel kawalan Linkerd menggunakan lebih sedikit sumber daripada Istio, terutamanya untuk komponen teras.
Kami masih memikirkan bagaimana untuk mengurangkan kos ini. Jika anda mempunyai idea, sila kongsi!
Sumber: www.habr.com