Προγραμματισμός

Προς Istio και πέρα ​​από αυτό: Azure's Service Mesh Interface

Η σύγχρονη ανάπτυξη εφαρμογών cloud, τουλάχιστον στο Azure, έχει σχεδόν εξαρτηθεί από το Kubernetes. Τεχνολογίες όπως το Virtual Kubelets, το AKS (Azure Kubernetes Service) και το Azure Service Fabric Mesh είναι το κλειδί για τη δημιουργία επεκτάσιμων κατανεμημένων εφαρμογών στο Azure, χρησιμοποιώντας κοντέινερ για την ανάπτυξη και διαχείριση μικροσυσκευών.

Κοιτάζοντας τα εργαλεία Kubernetes της Azure, είναι σαφές ότι η Microsoft κάνει πολλή δουλειά μέσα και γύρω από το Cloud Native Computing Foundation, δουλεύοντας σε όλες τις πτυχές του ανοιχτού κώδικα. Δεν πρέπει να εκπλαγούμε. Η Microsoft προσέλαβε έναν από τους ιδρυτές του έργου Kubernetes και στη συνέχεια απέκτησε τη Deis, έναν σημαντικό προμηθευτή. Η ομάδα Deis βρίσκεται πίσω από μία από τις τελευταίες συνεισφορές Azure στο οικοσύστημα Kubernetes, το Service Mesh Interface (SMI).

Παρουσιάζουμε πλέγματα υπηρεσιών

Ίσως είναι καλύτερο να εξηγήσετε πρώτα τι είναι ένα πλέγμα υπηρεσιών και γιατί είναι σημαντικό για οποιαδήποτε εφαρμογή που βασίζεται στο Kubernetes.

Οι σύγχρονες αρχιτεκτονικές πληροφορικής αφορούν στην αφαίρεση. Με τις υπηρεσίες cloud δεν χρειάζεται πλέον να σκεφτόμαστε το υποκείμενο υλικό. Εάν χρησιμοποιούμε το IaaS, ορίζουμε εικονικές μηχανές για να φιλοξενήσουμε τον κωδικό μας. Με το PaaS είμαστε ακόμη πιο μακριά από το υλικό, χρησιμοποιώντας τις υπηρεσίες και τα API που επιλέξαμε, επιλέγοντας ένα κατάλληλο επίπεδο απόδοσης για τις εφαρμογές και τους προϋπολογισμούς μας. Με αρχιτεκτονικές που βασίζονται σε κοντέινερ, όπως το Kubernetes, βρισκόμαστε σε κάποιο σημείο μεταξύ των δύο: χρησιμοποιώντας υπηρεσίες όπως το AKS μπορούμε να καθορίσουμε τις υποκείμενες εικονικές μηχανές, οι οποίες στη συνέχεια φιλοξενούν τις κονσόλες των κοντέινερ μας και κλιμακώνονται με αλλαγές στον υπολογισμό και τη μνήμη (και τώρα με το KEDA (αυτόματη κλιμάκωση βάσει συμβάντων με βάση το Kubernetes), κατά την παραλαβή των συμβάντων).

Αυτή είναι μόνο μια πτυχή της αφαίρεσης. Οι μικροϋπηρεσίες Kubernetes είναι, στην καρδιά, ανιθαγενείς. χρησιμοποιούν εξωτερικό χώρο αποθήκευσης και βρίσκονται στην κορυφή φυσικών ή εικονικών δικτύων. Είναι η πτυχή του δικτύου για την εκτέλεση του Kubernetes που είναι ίσως το πιο δύσκολο: Καθώς οι υπηρεσίες εξαντλούνται και μειώνονται, πρέπει να τροποποιήσετε το δίκτυό σας ώστε να ταιριάζει με τις αλλαγές στην εφαρμογή σας. Αλλά πώς διατηρείτε τις υπηρεσίες συνδεδεμένες όταν μια διεπαφή και ένα πίσω μέρος μιας εφαρμογής ενδέχεται να κλιμακώνονται με διαφορετικούς ρυθμούς;

Εκεί μπαίνουν τα πλέγματα των υπηρεσιών. Είναι ένα νέο επίπεδο αφαίρεσης, που ξεπερνά τον κώδικά σας από το υποκείμενο δίκτυο, εκμεταλλευόμενοι τις δυνατότητες ενός σύγχρονου δικτύου που καθορίζεται από λογισμικό. Ενεργώντας ως ένα σύνολο διακομιστών μεσολάβησης που αναπτύσσονται με τον κωδικό σας, ένα πλέγμα εξυπηρέτησης διαχειρίζεται την επικοινωνία από υπηρεσία σε υπηρεσία χωρίς τον κωδικό σας να χρειάζεται καμία ενημέρωση για το υποκείμενο δίκτυο. Μπορείτε να σκεφτείτε ένα πλέγμα εξυπηρέτησης ως ένα αυτοματοποιημένο επίπεδο ελέγχου για τη δικτύωση της εφαρμογής σας, διαχειρίζοντας το υποκείμενο επίπεδο ελέγχου καθώς το Kubernetes κλιμακώνει τον κώδικά σας πάνω και κάτω.

Ένα δίκτυο που καθορίζεται από λογισμικό για μικροϋπηρεσίες

Ίσως η καλύτερη ιδέα ως τρόπος υλοποίησης έξυπνης, εξισορρόπησης καθυστέρησης, κλιμακούμενης εξισορρόπησης φορτίου παράλληλα με την ανακάλυψη υπηρεσίας, ένα πλέγμα υπηρεσιών είναι βασικά ένας κατανεμημένος δρομολογητής με δυναμικούς κανόνες δρομολόγησης που διαχειρίζονται ως μέρος μιας ανάπτυξης του Kubernetes. Μπορείτε να ορίσετε πρόσθετους κανόνες. Για παράδειγμα, η διατήρηση των συστημάτων παραγωγής και δοκιμών ξεχωριστά ή ο χειρισμός μιας ανάπτυξης μιας νέας έκδοσης και η αλλαγή μεταξύ των εκδόσεων κοντέινερ. Κάθε ομάδα δεδομένων σε μια εφαρμογή έχει μια παρουσία πλέγματος υπηρεσίας που λειτουργεί ως πλαϊνό αυτοκίνητο, με την ανακάλυψη υπηρεσίας και άλλα κρατικά στοιχεία που εκτελούνται εκτός των υπηρεσιών σας.

Με ένα πλέγμα υπηρεσιών πιέζετε τη νοημοσύνη σε ένα νέο επίπεδο δικτύου, επομένως δεν χρειάζεται να το τοποθετήσετε στις μικροϋπηρεσίες σας. Θέλετε να κρυπτογραφήσετε μια σύνδεση; Αυτή είναι μια δουλειά για το πλέγμα υπηρεσιών σας Θέλετε να εξουσιοδοτήσετε πελάτες; Μια άλλη εργασία για το πλέγμα υπηρεσίας.

Πάρα πολλά μάτια

Ο συνδυασμός μιας ανάπτυξης Kubernetes με ένα πλέγμα εξυπηρέτησης έχει πολύ νόημα. Ωστόσο, υπάρχει ένα ακόμη μεγάλο πρόβλημα: Ποιο χρησιμοποιείτε; Απεσταλμένος? Istio; Λίνκντερ; Aspen Mesh; Εάν επιλέξατε ένα, τι να εμποδίσετε μια ομάδα ανάπτυξης σε άλλο μέρος της επιχείρησής σας να επιλέξει άλλη; Τότε τι θα συμβεί εάν η εταιρεία σας αποφασίσει να τυποποιήσει σε μια συγκεκριμένη πλατφόρμα;

Αυτό είναι το πρόβλημα που η Microsoft θέλει να λύσει με το Service Mesh Interface. Αντί για κάθε πλέγμα υπηρεσίας που έχει το δικό του σύνολο API, το SMI είναι ένας τρόπος για την εφαρμογή κοινών API που λειτουργούν σε διαφορετικά πλέγματα υπηρεσιών, διαχειρίζοντας αυτό το νέο έξυπνο δίκτυο. Αντί να κλειδώσετε τον κώδικά σας σε ένα συγκεκριμένο πλέγμα υπηρεσίας και τα API του, μπορείτε να γράψετε κώδικα που αντιμετωπίζει τις περισσότερες κοινές περιπτώσεις χρήσης μέσω ενός κοινού API. Εάν πρέπει να ανταλλάξετε ένα πλέγμα υπηρεσιών - εάν αλλάξετε πάροχους ή βρείτε κάποιο που λειτουργεί καλύτερα - δεν χρειάζεται να αλλάξετε τον κωδικό σας, αρκεί το πλέγμα υπηρεσίας να εφαρμόζει το SMI. Το μόνο που χρειάζεται να κάνετε είναι να αλλάξετε το sidecars πλέγματος υπηρεσιών σας και να επανατοποθετήσετε τον κωδικό σας.

SMI: κοινά API πλέγματος υπηρεσιών

Σε συνεργασία με εταιρείες Kubernetes-ecosystem όπως η Hashicorp και η Buoyant, η Microsoft καθορίζει τα βασικά χαρακτηριστικά για την SMI που υποστηρίζουν κοινά αιτήματα από τους πελάτες της. Στην αρχική έκδοση έχει επικεντρωθεί σε τρεις τομείς: πολιτική κυκλοφορίας, τηλεμετρία κυκλοφορίας και διαχείριση κυκλοφορίας. Αυτές οι τρεις περιοχές ελέγχονται από τα περισσότερα πλέγματα εξυπηρέτησης και η πρόθεση είναι να γίνει μια προδιαγραφή που είναι εύκολο να εφαρμοστεί χωρίς να αλλάξετε την υποκείμενη εφαρμογή.

Κάνοντας το SMI ένα σύνολο τυπικών API, δεν υπάρχει τίποτα που να εμποδίζει τους προμηθευτές πλέγματος υπηρεσιών να συνεχίσουν να προσφέρουν τα δικά τους API ή πρόσθετες λειτουργίες εκτός αυτών που καθορίζονται. Εναλλακτικά, δεν χρειάζεται να κάνουν αλλαγές. τρίτα μέρη μπορούν να δημιουργήσουν επίπεδα μετάφρασης που βρίσκονται μεταξύ των SMI API και των ιδιόκτητων API υπηρεσιών. Δεν θα χρειαστείτε ούτε μια νέα έκδοση του Kubernetes, καθώς τα SMI API εφαρμόζονται ως διακομιστές επέκτασης API και προσαρμοσμένοι ορισμοί πόρων. Μπορείτε να προχωρήσετε και να τα εγκαταστήσετε σε οποιοδήποτε σύμπλεγμα, χρησιμοποιώντας τα υπάρχοντα εργαλεία διαχείρισης. Αυτό θα διευκολύνει το SMI για το Azure και άλλες υπηρεσίες Kubernetes που φιλοξενούνται στο cloud για να τις ενσωματώσουν στις υπάρχουσες διαχειριζόμενες υπηρεσίες Kubernetes.

Είτε θέλετε να χρησιμοποιήσετε το Linkerd ή το Aspen Mesh ή το NSX Service Mesh του VMware, με SMI, θα μπορείτε να επιλέξετε αυτό που προτιμάτε, βελτιώνοντας τη φορητότητα κώδικα και αποφεύγοντας το κλείδωμα σε συγκεκριμένες υπηρεσίες cloud. Στη συνέχεια, υπάρχει η ευκαιρία να αλλάξετε πλέγματα υπηρεσιών χωρίς να επηρεαστεί ο κώδικάς σας. Εάν ένα νέο πλέγμα υπηρεσιών προσφέρει καλύτερη απόδοση, το μόνο που χρειάζεται να κάνετε είναι να αλλάξετε τον αγωγό κατασκευής για να χρησιμοποιήσετε το νέο πλέγμα και, στη συνέχεια, να αναπτύξετε μια ενημερωμένη εφαρμογή.

Είναι ενδιαφέρον να βλέπουμε τη Microsoft να ηγείται σε ένα έργο σαν αυτό, σε συνεργασία με μια ευρεία διατομή της κοινότητας Kubernetes. Ακολουθώντας μια προσέγγιση που δεν εστιάζεται ρητά στη δημιουργία ενός πλέγματος υπηρεσιών, το Azure μπορεί να προσφέρει διαφορετικά πλέγματα υπηρεσιών ως μέρος της διαμόρφωσης του AKS, επιτρέποντάς σας να επιλέξετε το εργαλείο που θέλετε χωρίς να χρειάζεται να αλλάξετε κώδικα.