Οι διακοπές τελείωσαν και επιστρέφουμε με τη δεύτερη ανάρτησή μας στη σειρά Istio Service Mesh.
Το σημερινό θέμα είναι ο διακόπτης κυκλώματος, που μεταφράζεται στα ρωσικά ηλεκτρολόγος μηχανικός σημαίνει "αποκοπή κυκλώματος", στην κοινή γλώσσα - "διακοπή κυκλώματος". Μόνο στο Ίστιο αυτό το μηχάνημα δεν αποσυνδέει βραχυκυκλωμένο ή υπερφορτωμένο κύκλωμα, αλλά ελαττωματικά δοχεία.
Πώς αυτό θα έπρεπε να λειτουργεί ιδανικά
Όταν οι μικροϋπηρεσίες διαχειρίζονται από την Kubernetes, για παράδειγμα εντός της πλατφόρμας OpenShift, κλιμακώνονται αυτόματα προς τα πάνω και προς τα κάτω ανάλογα με το φορτίο. Επειδή οι microservices εκτελούνται σε pods, μπορεί να υπάρχουν πολλές περιπτώσεις μιας microservice με κοντέινερ σε ένα τελικό σημείο και το Kubernetes θα δρομολογεί αιτήματα και θα φορτώνει την ισορροπία μεταξύ τους. Και - ιδανικά - όλα αυτά θα πρέπει να λειτουργούν τέλεια.
Θυμόμαστε ότι οι μικροϋπηρεσίες είναι μικρές και εφήμερες. Το εφήμερο, που εδώ σημαίνει την ευκολία εμφάνισης και εξαφάνισης, συχνά υποτιμάται. Η γέννηση και ο θάνατος μιας άλλης περίπτωσης μιας microservice σε ένα pod είναι αρκετά αναμενόμενα πράγματα, το OpenShift και το Kubernetes το χειρίζονται καλά και όλα λειτουργούν υπέροχα - αλλά και πάλι στη θεωρία.
Πώς λειτουργεί πραγματικά
Τώρα φανταστείτε ότι μια συγκεκριμένη περίπτωση μιας μικρουπηρεσίας, δηλαδή ένα δοχείο, έχει καταστεί άχρηστη: είτε δεν ανταποκρίνεται (σφάλμα 503), είτε, το πιο δυσάρεστο, ανταποκρίνεται, αλλά πολύ αργά. Με άλλα λόγια, γίνεται glitchy ή δεν ανταποκρίνεται σε αιτήματα, αλλά δεν αφαιρείται αυτόματα από την πισίνα. Τι πρέπει να γίνει σε αυτή την περίπτωση; Να προσπαθήσω ξανά; Πρέπει να το αφαιρέσω από το σχέδιο δρομολόγησης; Και τι σημαίνει "πολύ αργό" - πόσοι είναι σε αριθμούς και ποιος τους καθορίζει; Ίσως απλά να το κάνετε ένα διάλειμμα και να προσπαθήσετε ξανά αργότερα; Αν ναι, πόσο αργότερα;
Τι είναι το Pool Ejection στο Ίστιο
Και εδώ το Istio έρχεται στη διάσωση με τα μηχανήματα προστασίας Circuit Breaker, τα οποία απομακρύνουν προσωρινά τα ελαττωματικά δοχεία από τη δεξαμενή πόρων δρομολόγησης και εξισορρόπησης φορτίου, εφαρμόζοντας τη διαδικασία Pool Ejection.
Χρησιμοποιώντας μια στρατηγική ανίχνευσης ακραίων τιμών, το Istio εντοπίζει τις ομάδες καμπυλών που είναι εκτός γραμμής και τις αφαιρεί από τη δεξαμενή πόρων για ένα καθορισμένο χρονικό διάστημα, που ονομάζεται παράθυρο ύπνου.
Για να δείξουμε πώς λειτουργεί αυτό στο Kubernetes στην πλατφόρμα OpenShift, ας ξεκινήσουμε με ένα στιγμιότυπο οθόνης μικροϋπηρεσιών που λειτουργούν κανονικά από το παράδειγμα στο αποθετήριο . Εδώ έχουμε δύο pods, v1 και v2, το καθένα από ένα δοχείο. Όταν δεν χρησιμοποιούνται κανόνες δρομολόγησης Istio, το Kubernetes ορίζει από προεπιλογή ομοιόμορφα ισορροπημένη δρομολόγηση κυκλικής διαδρομής:
Προετοιμασία για συντριβή
Πριν κάνετε το Pool Ejection, πρέπει να δημιουργήσετε έναν κανόνα δρομολόγησης Istio. Ας υποθέσουμε ότι θέλουμε να διανείμουμε αιτήματα μεταξύ ομάδων σε αναλογία 50/50. Επιπλέον, θα αυξήσουμε τον αριθμό των κοντέινερ v2 από ένα σε δύο, ως εξής:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Τώρα ορίζουμε έναν κανόνα δρομολόγησης έτσι ώστε η κυκλοφορία να κατανέμεται μεταξύ των pods σε αναλογία 50/50.
Δείτε πώς φαίνεται το αποτέλεσμα αυτού του κανόνα:
Μπορείτε να βρείτε σφάλμα στο γεγονός ότι αυτή η οθόνη δεν είναι 50/50, αλλά 14:9, αλλά με τον καιρό η κατάσταση θα βελτιωθεί.
Κάνοντας ένα σφάλμα
Τώρα ας απενεργοποιήσουμε ένα από τα δύο κοντέινερ v2, έτσι ώστε να έχουμε ένα υγιές κοντέινερ v1, ένα υγιές κοντέινερ v2 και ένα ελαττωματικό κοντέινερ v2:
Διόρθωση του σφάλματος
Λοιπόν, έχουμε ένα ελαττωματικό δοχείο και ήρθε η ώρα για το Pool Ejection. Χρησιμοποιώντας μια πολύ απλή διαμόρφωση, θα εξαιρέσουμε αυτό το αποτυχημένο κοντέινερ από τυχόν σχήματα δρομολόγησης για 15 δευτερόλεπτα με την ελπίδα ότι θα επιστρέψει σε υγιή κατάσταση (είτε επανεκκίνηση είτε επαναφορά της απόδοσης). Αυτό είναι αυτό που μοιάζει με αυτό το config και τα αποτελέσματα της δουλειάς του:
Όπως μπορείτε να δείτε, το αποτυχημένο κοντέινερ v2 δεν χρησιμοποιείται πλέον για αιτήματα δρομολόγησης επειδή έχει αφαιρεθεί από το pool. Αλλά μετά από 15 δευτερόλεπτα θα επιστρέψει αυτόματα στην πισίνα. Στην πραγματικότητα, μόλις δείξαμε πώς λειτουργεί το Pool Ejection.
Ας αρχίσουμε να χτίζουμε αρχιτεκτονική
Το Pool Ejection, σε συνδυασμό με τις δυνατότητες παρακολούθησης του Istio, σας επιτρέπει να ξεκινήσετε τη δημιουργία ενός πλαισίου για την αυτόματη αντικατάσταση ελαττωματικών δοχείων για τη μείωση, αν όχι την εξάλειψη, του χρόνου διακοπής λειτουργίας και των αστοχιών.
Η NASA έχει ένα δυνατό σύνθημα - Η αποτυχία δεν είναι επιλογή, ο συγγραφέας του οποίου θεωρείται ο διευθυντής πτήσης . Μπορεί να μεταφραστεί στα ρωσικά ως "Η αποτυχία δεν είναι επιλογή" και το νόημα εδώ είναι ότι όλα μπορούν να λειτουργήσουν εάν έχετε αρκετή θέληση. Ωστόσο, στην πραγματική ζωή, οι αποτυχίες δεν συμβαίνουν απλώς, είναι αναπόφευκτες, παντού και σε όλα. Και πώς να τα αντιμετωπίσουμε στην περίπτωση των microservices; Κατά τη γνώμη μας, είναι καλύτερο να βασιστείτε όχι στη δύναμη της θέλησης, αλλά στις δυνατότητες των εμπορευματοκιβωτίων, , Και .
Το Istio, όπως γράψαμε παραπάνω, εφαρμόζει την έννοια των αυτόματων διακοπτών, η οποία έχει αποδειχθεί καλά στον φυσικό κόσμο. Και ακριβώς όπως ένας ηλεκτρικός διακόπτης κυκλώματος απενεργοποιεί ένα προβληματικό τμήμα ενός κυκλώματος, το λογισμικό Istio Circuit Breaker ανοίγει τη σύνδεση μεταξύ μιας ροής αιτημάτων και ενός προβληματικού κοντέινερ όταν κάτι δεν πάει καλά με το τελικό σημείο, για παράδειγμα, όταν ο διακομιστής κατέρρευσε ή άρχισε να Κόψτε ταχύτητα.
Επιπλέον, στη δεύτερη περίπτωση υπάρχουν μόνο περισσότερα προβλήματα, καθώς τα φρένα ενός εμπορευματοκιβωτίου όχι μόνο προκαλούν έναν καταρράκτη καθυστερήσεων στις υπηρεσίες πρόσβασης σε αυτό και, ως αποτέλεσμα, μειώνουν την απόδοση του συστήματος στο σύνολό του, αλλά δημιουργούν και επαναλαμβανόμενες αιτήματα σε μια ήδη αργή υπηρεσία, η οποία μόνο επιδεινώνει την κατάσταση .
Διακόπτης κυκλώματος στη θεωρία
Το Circuit Breaker είναι ένας διακομιστής μεσολάβησης που ελέγχει τη ροή των αιτημάτων σε ένα τελικό σημείο. Όταν αυτό το σημείο σταματήσει να λειτουργεί ή, ανάλογα με τις καθορισμένες ρυθμίσεις, αρχίσει να επιβραδύνεται, ο διακομιστής μεσολάβησης διακόπτει τη σύνδεση με το κοντέινερ. Στη συνέχεια, η κυκλοφορία ανακατευθύνεται σε άλλα εμπορευματοκιβώτια, απλώς λόγω εξισορρόπησης φορτίου. Η σύνδεση παραμένει ανοιχτή για ένα δεδομένο παράθυρο ύπνου, ας πούμε δύο λεπτά, και μετά θεωρείται μισάνοιχτη. Μια προσπάθεια αποστολής του επόμενου αιτήματος καθορίζει την περαιτέρω κατάσταση της σύνδεσης. Εάν όλα είναι εντάξει με την υπηρεσία, η σύνδεση επιστρέφει στην κατάσταση λειτουργίας και κλείνει ξανά. Εάν εξακολουθεί να υπάρχει κάποιο πρόβλημα με την υπηρεσία, η σύνδεση αποσυνδέεται και το παράθυρο αναστολής λειτουργίας ενεργοποιείται ξανά. Δείτε πώς φαίνεται ένα απλοποιημένο διάγραμμα κατάστασης διακόπτη κυκλώματος:
Είναι σημαντικό να σημειωθεί εδώ ότι όλα αυτά συμβαίνουν στο επίπεδο, ας πούμε, της αρχιτεκτονικής του συστήματος. Έτσι, κάποια στιγμή θα πρέπει να διδάξετε τις εφαρμογές σας να λειτουργούν με το Circuit Breaker, όπως να παρέχετε μια προεπιλεγμένη τιμή ως απάντηση ή, αν είναι δυνατόν, να αγνοήσετε την ύπαρξη της υπηρεσίας. Χρησιμοποιείται μοτίβο διαφράγματος για αυτό, αλλά είναι πέρα από το πεδίο εφαρμογής αυτού του άρθρου.
Διακόπτης κυκλώματος στην πράξη
Για παράδειγμα, θα τρέξουμε δύο εκδόσεις της microservice της σύστασής μας στο OpenShift. Η έκδοση 1 θα λειτουργήσει καλά, αλλά στο v2 θα δημιουργήσουμε μια καθυστέρηση για να προσομοιώσουμε επιβραδύνσεις στον διακομιστή. Για να δείτε τα αποτελέσματα, χρησιμοποιήστε το εργαλείο :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Όλα δείχνουν να λειτουργούν, αλλά με ποιο κόστος; Με την πρώτη ματιά, έχουμε 100% διαθεσιμότητα, αλλά ρίξτε μια πιο προσεκτική ματιά - η μέγιστη διάρκεια συναλλαγής είναι έως και 12 δευτερόλεπτα. Αυτό είναι ξεκάθαρα ένα εμπόδιο και πρέπει να επεκταθεί.
Για να γίνει αυτό, θα χρησιμοποιήσουμε το Istio για να εξαλείψουμε τις κλήσεις σε αργά κοντέινερ. Έτσι φαίνεται η αντίστοιχη διαμόρφωση χρησιμοποιώντας τον διακόπτη κυκλώματος:
Η τελευταία γραμμή με την παράμετρο httpMaxRequestsPerConnection σηματοδοτεί ότι η σύνδεση με πρέπει να αποσυνδεθεί όταν προσπαθείτε να δημιουργήσετε μια άλλη - μια δεύτερη - σύνδεση εκτός από την υπάρχουσα. Δεδομένου ότι το κοντέινερ μας προσομοιώνει μια αργή εξυπηρέτηση, τέτοιες καταστάσεις θα προκύπτουν περιοδικά και, στη συνέχεια, το Istio θα επιστρέψει ένα σφάλμα 503, αλλά αυτό θα δείξει το siege:
Εντάξει, έχουμε διακόπτη κυκλώματος, τι ακολουθεί;
Έτσι, εφαρμόσαμε αυτόματο κλείσιμο χωρίς να αγγίξουμε καθόλου τον πηγαίο κώδικα των ίδιων των υπηρεσιών. Χρησιμοποιώντας το Circuit Breaker και τη διαδικασία Pool Ejection που περιγράφεται παραπάνω, μπορούμε να αφαιρέσουμε τα δοχεία φρένων από το resource pool μέχρι να επιστρέψουν στο κανονικό και να ελέγξουμε την κατάστασή τους σε μια καθορισμένη συχνότητα - στο παράδειγμά μας, αυτή είναι δύο λεπτά (παράμετρος SleepWindow).
Λάβετε υπόψη ότι η ικανότητα μιας εφαρμογής να ανταποκρίνεται σε ένα σφάλμα 503 εξακολουθεί να ορίζεται στο επίπεδο του πηγαίου κώδικα. Υπάρχουν πολλές στρατηγικές για τη χρήση του διακόπτη κυκλώματος, ανάλογα με την κατάσταση.
Στην επόμενη ανάρτηση: Θα μιλήσουμε για την ανίχνευση και την παρακολούθηση που είναι ήδη ενσωματωμένη ή προστίθεται εύκολα στο Istio, καθώς και για τον τρόπο εισαγωγής σφαλμάτων σκόπιμα στο σύστημα.
Πηγή: www.habr.com