Εισαγωγή
Είμαστε μέσα άρχισε να αναπτύσσει το Istio ως πλέγμα υπηρεσιών. Κατ 'αρχήν, όλα είναι καλά, εκτός από ένα πράγμα: είναι ακριβό.
В για το Istio λέει:
Με το Istio 1.1, ο διακομιστής μεσολάβησης καταναλώνει περίπου 0,6 vCPU (εικονικούς πυρήνες) ανά 1000 αιτήματα ανά δευτερόλεπτο.
Για την πρώτη περιοχή στο πλέγμα υπηρεσιών (2 proxies σε κάθε πλευρά της σύνδεσης), θα έχουμε 1200 πυρήνες μόνο για το διακομιστή μεσολάβησης, με ρυθμό ενός εκατομμυρίου αιτημάτων ανά δευτερόλεπτο. Σύμφωνα με τον υπολογιστή κόστους της Google, είναι περίπου 40 $/μήνα/πυρήνας για τη διαμόρφωση n1-standard-64, δηλαδή μόνο αυτή η περιοχή θα μας κοστίζει περισσότερα από 50 χιλιάδες δολάρια το μήνα για 1 εκατομμύριο αιτήματα ανά δευτερόλεπτο.
Ιβάν Σιμ () καθυστερήσεις πλέγματος υπηρεσιών πέρυσι και υποσχέθηκε το ίδιο για τη μνήμη και τον επεξεργαστή, αλλά δεν λειτούργησε:
Προφανώς, το values-istio-test.yaml θα αυξήσει σοβαρά τα αιτήματα CPU. Εάν έχω κάνει σωστά τα μαθηματικά, χρειάζεστε περίπου 24 πυρήνες CPU για τον πίνακα ελέγχου και 0,5 CPU για κάθε διακομιστή μεσολάβησης. Δεν έχω τόσα πολλά. Θα επαναλάβω τις δοκιμές όταν μου διατεθούν περισσότεροι πόροι.
Ήθελα να δω μόνος μου πόσο παρόμοια είναι η απόδοση του Istio με ένα άλλο πλέγμα υπηρεσίας ανοιχτού κώδικα: .
Εγκατάσταση πλέγματος σέρβις
Πρώτα απ 'όλα, το εγκατέστησα σε ένα σύμπλεγμα :
$ 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!Χρησιμοποίησα το SuperGloo επειδή διευκολύνει πολύ την εκκίνηση του πλέγματος υπηρεσίας. Δεν χρειάστηκε να κάνω πολλά. Δεν χρησιμοποιούμε το SuperGloo στην παραγωγή, αλλά είναι ιδανικό για μια τέτοια εργασία. Έπρεπε να χρησιμοποιήσω κυριολεκτικά μερικές εντολές για κάθε πλέγμα υπηρεσίας. Χρησιμοποίησα δύο ομάδες για απομόνωση - ένα για το Istio και το Linkerd.
Το πείραμα διεξήχθη στο Google Kubernetes Engine. Χρησιμοποίησα Kubernetes 1.12.7-gke.7 και μια δεξαμενή κόμβων n1-standard-4 με αυτόματη κλιμάκωση κόμβων (ελάχιστο 4, μέγιστο 16).
Στη συνέχεια, εγκατέστησα και τα δύο πλέγματα υπηρεσιών από τη γραμμή εντολών.
Πρώτος σύνδεσμος:
$ 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 |
+---------+--------------+---------+---------------------------+Τότε Ίστιο:
$ 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 κράτησε λίγα λεπτά και στη συνέχεια οι πίνακες ελέγχου σταθεροποιήθηκαν.
(Σημείωση: Το SuperGloo υποστηρίζει μόνο Istio 1.0.x προς το παρόν. Επανέλαβα το πείραμα με το Istio 1.1.3, αλλά δεν παρατήρησα κάποια αξιοσημείωτη διαφορά.)
Ρύθμιση Istio Automatic Deployment
Για να κάνουμε το Istio να εγκαταστήσει το sidecar Envoy, χρησιμοποιούμε το sidecar injector − MutatingAdmissionWebhook. Δεν θα μιλήσουμε για αυτό σε αυτό το άρθρο. Επιτρέψτε μου απλώς να πω ότι πρόκειται για έναν ελεγκτή που παρακολουθεί την πρόσβαση σε όλα τα νέα pod και προσθέτει δυναμικά ένα sidecar και το initContainer, το οποίο είναι υπεύθυνο για εργασίες iptables.
Εμείς στο Shopify γράψαμε τον δικό μας ελεγκτή πρόσβασης για την εφαρμογή sidecars, αλλά για αυτό το σημείο αναφοράς χρησιμοποίησα τον ελεγκτή που συνοδεύει το Istio. Ο ελεγκτής εισάγει sidecars από προεπιλογή όταν υπάρχει συντόμευση στο χώρο ονομάτων 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 labeledΡύθμιση αυτόματης ανάπτυξης Linkerd
Για να ρυθμίσουμε την ενσωμάτωση του Linkerd sidecar, χρησιμοποιούμε σχολιασμούς (τους πρόσθεσα χειροκίνητα μέσω 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: ActiveIstio Fault Tolerance Simulator
Κατασκευάσαμε έναν προσομοιωτή ανοχής σφαλμάτων που ονομάζεται Istio για να πειραματιστούμε με την κυκλοφορία μοναδική για το Shopify. Χρειαζόμασταν ένα εργαλείο για τη δημιουργία μιας προσαρμοσμένης τοπολογίας που θα αντιπροσώπευε ένα συγκεκριμένο τμήμα του γραφήματος υπηρεσιών μας, δυναμικά διαμορφωμένο για να μοντελοποιεί συγκεκριμένους φόρτους εργασίας.
Η υποδομή του Shopify είναι υπό βαρύ φορτίο κατά τη διάρκεια των flash πωλήσεων. Ταυτόχρονα, Shopify . Οι μεγάλοι πελάτες προειδοποιούν μερικές φορές για μια προγραμματισμένη πώληση flash. Άλλοι τα κάνουν απροσδόκητα για εμάς οποιαδήποτε στιγμή της ημέρας ή της νύχτας.
Θέλαμε ο προσομοιωτής ανθεκτικότητας να μοντελοποιεί ροές εργασίας που ταιριάζουν με τις τοπολογίες και τους φόρτους εργασίας που έχουν κατακλύσει την υποδομή του Shopify στο παρελθόν. Ο κύριος σκοπός της χρήσης ενός πλέγματος υπηρεσιών είναι ότι χρειαζόμαστε αξιοπιστία και ανοχή σφαλμάτων σε επίπεδο δικτύου και είναι σημαντικό για εμάς το πλέγμα εξυπηρέτησης να αντιμετωπίζει αποτελεσματικά φορτία που προηγουμένως διέκοψαν τις υπηρεσίες.
Στην καρδιά του προσομοιωτή ανοχής σφαλμάτων βρίσκεται ένας κόμβος εργάτη, ο οποίος λειτουργεί ως κόμβος πλέγματος υπηρεσιών. Ο κόμβος εργαζόμενος μπορεί να διαμορφωθεί στατικά κατά την εκκίνηση ή δυναμικά μέσω ενός REST API. Χρησιμοποιούμε δυναμική διαμόρφωση κόμβων εργαζομένων για να δημιουργήσουμε ροές εργασίας με τη μορφή δοκιμών παλινδρόμησης.
Ακολουθεί ένα παράδειγμα μιας τέτοιας διαδικασίας:
- Ξεκινάμε 10 διακομιστές ως
barυπηρεσία που επιστρέφει μια απάντηση200/OKμετά από 100 ms. - Εκκινούμε 10 πελάτες - ο καθένας στέλνει 100 αιτήματα ανά δευτερόλεπτο σε
bar. - Κάθε 10 δευτερόλεπτα αφαιρούμε 1 σφάλματα διακομιστή και παρακολούθησης
5xxστον πελάτη.
Στο τέλος της ροής εργασίας, εξετάζουμε τα αρχεία καταγραφής και τις μετρήσεις και ελέγχουμε αν η δοκιμή πέρασε. Με αυτόν τον τρόπο μαθαίνουμε για την απόδοση του πλέγματος εξυπηρέτησης και εκτελούμε μια δοκιμή παλινδρόμησης για να ελέγξουμε τις υποθέσεις μας σχετικά με την ανοχή σφαλμάτων.
(Σημείωση: Σκεφτόμαστε να προμηθευτούμε τον προσομοιωτή ανοχής σφαλμάτων Istio, αλλά δεν είμαστε έτοιμοι να το κάνουμε ακόμα.)
Προσομοιωτής ανοχής σφαλμάτων Istio για σημείο αναφοράς πλέγματος σέρβις
Δημιουργήσαμε αρκετούς κόμβους εργασίας του προσομοιωτή:
irs-client-loadgen: 3 αντίγραφα που στέλνουν 100 αιτήματα ανά δευτερόλεπτο ανάirs-client.irs-client: 3 αντίγραφα που λαμβάνουν το αίτημα, περιμένετε 100 ms και προωθήστε το αίτημα στοirs-server.irs-server: 3 αντίγραφα που επιστρέφουν200/OKμετά από 100 ms.
Με αυτήν τη διαμόρφωση, μπορούμε να μετρήσουμε μια σταθερή ροή κυκλοφορίας μεταξύ 9 τελικών σημείων. Πλαϊνά αυτοκίνητα μέσα irs-client-loadgen и irs-server λάβετε 100 αιτήματα ανά δευτερόλεπτο και irs-client — 200 (εισερχόμενες και εξερχόμενες).
Παρακολουθούμε τη χρήση των πόρων μέσω γιατί δεν έχουμε σύμπλεγμα Προμηθέα.
Ευρήματα
Πίνακες ελέγχου
Αρχικά, εξετάσαμε την κατανάλωση της CPU.
Πίνακας ελέγχου Linkerd ~22 millicore
Πίνακας ελέγχου Istio: ~750 millicore
Ο πίνακας ελέγχου Istio χρησιμοποιεί περίπου 35 φορές περισσότεροι πόροι CPUπαρά Linkerd. Φυσικά, όλα είναι εγκατεστημένα από προεπιλογή και η istio-telemetry καταναλώνει πολλούς πόρους επεξεργαστή εδώ (μπορεί να απενεργοποιηθεί απενεργοποιώντας ορισμένες λειτουργίες). Αν αφαιρέσουμε αυτό το συστατικό, παίρνουμε ακόμα περισσότερα από 100 millicore, δηλαδή 4 φορές περισσότεροπαρά Linkerd.
Πλευρικό διακομιστή μεσολάβησης
Στη συνέχεια δοκιμάσαμε τη χρήση ενός διακομιστή μεσολάβησης. Θα πρέπει να υπάρχει μια γραμμική σχέση με τον αριθμό των αιτημάτων, αλλά για κάθε sidecar υπάρχει κάποια επιβάρυνση που επηρεάζει την καμπύλη.
Linkerd: ~100 millicore για irs-client, ~50 millicores για irs-client-loadgen
Τα αποτελέσματα φαίνονται λογικά, επειδή ο διακομιστής μεσολάβησης πελάτη λαμβάνει διπλάσια κίνηση από τον διακομιστή μεσολάβησης loadgen: για κάθε εξερχόμενο αίτημα από το loadgen, ο πελάτης έχει ένα εισερχόμενο και ένα εξερχόμενο.
Istio/Envoy: ~155 millicores για irs-client, ~75 millicores για irs-client-loadgen
Παρόμοια αποτελέσματα βλέπουμε και για τα πλαϊνά κάρτερ Ιστίου.
Γενικά όμως οι πληρεξούσιοι του Ιστιο/Απεσταλμένου καταναλώνουν περίπου 50% περισσότερους πόρους CPUπαρά Linkerd.
Βλέπουμε το ίδιο σχήμα στην πλευρά του διακομιστή:
Linkerd: ~50 millicore για irs-server
Istio/Envoy: ~80 millicore για irs-server
Από την πλευρά του διακομιστή, το sidecar Istio/Envoy καταναλώνει περίπου 60% περισσότερους πόρους CPUπαρά Linkerd.
Συμπέρασμα
Ο διακομιστής μεσολάβησης Istio Envoy καταναλώνει 50+% περισσότερη CPU από το Linkerd στον προσομοιωμένο φόρτο εργασίας μας. Ο πίνακας ελέγχου Linkerd καταναλώνει πολύ λιγότερους πόρους από το Istio, ειδικά για τα βασικά στοιχεία.
Εξακολουθούμε να σκεφτόμαστε πώς να μειώσουμε αυτά τα κόστη. Αν έχετε ιδέες, κοινοποιήστε!
Πηγή: www.habr.com