Συντάχθηκε 25-07-2024 13:58
Τόπος:
Σύνδεσμος τηλεδιάσκεψης
Έναρξη: 31/07/2024 10:00
Λήξη: 31/07/2024 13:56
ΠΟΛΥΤΕΧΝΕΙΟ ΚΡΗΤΗΣ
Σχολή Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών
Πρόγραμμα Προπτυχιακών Σπουδών
ΠΑΡΟΥΣΙΑΣΗ ΔΙΠΛΩΜΑΤΙΚΗΣ ΕΡΓΑΣΙΑΣ
Νικολάου Καστρινάκη
με θέμα
Δυναμικές Στρατηγικές Τοποθέτησης Μικροϋπηρεσιών στο Kubernetes
Dynamic Microservice Placement Strategies in Kubernetes
Εξεταστική Επιτροπή
Καθηγητής Ευριπίδης Πετράκης (επιβλέπων)
Επίκουρος Καθηγητής Νικόλαος Γιατράκος
Δρ Χρυσή Τσιναράκη (Σχολή ΗΜΜΥ, ΕΔΙΠ)
Περίληψη
Καθώς οι εφαρμογές κινούνται προς το υπολογιστικό νέφος, οι αρχιτεκτονικές μικροϋπηρεσιών γίνονται όλο και πιο δημοφιλείς. Εκτός των πλεονεκτημάτων που αποφέρουν, οι μικροϋπηρεσίες προσθέτουν πολυπλοκότητα στην σχεδίαση εφαρμογών και φέρνουν μαζί τους νέα προβλήματα. Για την επίλυση αυτών, το Kubernetes δημιουργήθηκε με σκοπό να χειρίζεται εφαρμογές μικροϋπηρεσιών με την αυτοματοποίηση διαχείρησης, κλιμάκωσης και παράταξης αυτών. Οι εφαρμογές στο Kubernetes παρατάσσονται σε συμπλέγματα (clusters), μία συλλογή υπολογιστικών κόμβων (nodes) που διαχειρίζονται από ένα κεντρικό επίπεδο ελέγχου. Οι μικροϋπηρεσίες τοποθετούνται σε μικρές υπολογιστικές μονάδες, ονόματι Pods, τα οποία με τη σειρά τους βρίσκονται μέσα σε έναν κόμβο (node). Ο δρομολογητής (scheduler) του Kubernetes είναι υπεύθυνος για την τοποθέτηση των Pods σε κόμβους (nodes) χρησιμοποιώντας μία σειρά από κανονισμούς φιλτραρίσματος και σκοραρίσματος στην προσπάθεια βέλτιστης τοποθέτησης αυτών στο σύμπλεγμα (cluster). Η τοποθέτηση των Pods σε συγκεκριμένους κόμβους (nodes) είναι βασικό πρόβλημα σε αρχιτεκτονικές μικροϋπηρεσιών, εφόσον η αυξημένη φυσική απόσταση μεταξύ κομματιών της εφαρμογής μπορούν να οδεύσουν σε αυξημένους χρόνους απόκρισης αυτής. Επιπρόσθετα, η επικοινωνία μεταξύ κόμβων, ονόματι και ως egress traffic, χρεώνεται από τους προμηθευτές υπηρεσιών νέφους (cloud providers). Συνεπώς, η τοποθέτηση Pods που επικοινωνούν πολύ μεταξύ τους στους ίδιους κόμβους θεωρείται βέλτιστη για την ελαχιστοποίηση egress traffic, την μείωση κόστους υποδομής και την βελτίωση της επίδοσης της εφαρμογής μέσω μείωσης των χρόνων απόκρισης. Σε παλαιότερες εργασίες, η τοποθέτηση γινόταν χρησιμοποιώντας τεχνικές ομαδοποίησης γράφων για την παραγωγή μίας βέλτιστης τοποθέτησης των μικροϋπηρεσιών στο σύμπλεγμα (cluster). Αν και τα αποτελέσματα ήταν εξαιρετικά, πιθανότατα δεν θα μεταφερόντουσαν σε πιο πρακτικό περιβάλλον, όπου ο φόρτος αλλάζει και η κλιμάκωση Pods λαμβάνει χώρα. Σε αυτή την εργασία, επιδιώκουμε την επίλυση του προβλήματος με μία ευρηματική προσέγγιση. Θα αλλάξουμε την λειτουργικότητα του δρομολογητή (scheduler), προσθέτοντας την δική μας μέθοδο φιλτραρίσματος και πιο σημαντικά μία μέθοδο σκοραρίσματος με γνώση της επικοινωνίας. Ο στόχος μας είναι η βελτίωση όλων των προαναφερόμενων περιοχών με μία μέθοδο που ευθυγραμμίζεται με αρχιτεκτονική μικροϋπηρεσιών και το σχεδιασμό του Kubernetes. Μία εφαρμογή τοποθετήθηκε στο Google Cloud Platform (GCP) χρησιμοποιώντας Kubernetes για την εκτέλεση των πειραμάτων μας. Τα αποτελέσματα δείχνουν πως η μέθοδος με γνώση επικοινωνίας μας είναι πολύ καλύτερη στην βελτίωση επίδοσης της εφαρμογής, μείωση του κόστους υποδομών και ελαχιστοποίησης του egress traffic σε σύγκριση με τον προκαθορισμένο δρομολογητή (default scheduler). Επίσης, αν και είναι ελάχιστα χειρότερη από την MODSOFT-HP, μία μέθοδο fuzzy ομαδοποίησης γράφων, περεταίρω πειράματα με περισσότερους χρήστες και μηχανισμούς κλιμάκωσης που συνδέονται με την μέθοδό μας, μπορεί να αποδείξουν ότι είναι μία συνολικά καλύτερη και πιο πρακτική μέθοδος τοποθέτησης.
Abstract
As applications are moving to the cloud, microservices-based architectures are becoming more and more popular. For all their advantages, microservices add complexity to application design and bring with them a new set of problems. To combat these issues, Kubernetes was created to orchestrate containerized microservices applications by automating management, scaling and deployment. Applications in Kubernetes are deployed in Clusters, a set of Nodes (VMs) that are managed by a centralized control plane. Microservices are placed in Pods and those Pods in turn into Nodes. The Kubernetes Scheduler is responsible for placing Pods in Nodes using a set of filtering and scoring rules to attempt to optimally place it in the Cluster. The placement of Pods in certain Nodes is a key problem in microservices architectures, as the increase in physical distance between parts of an application could lead to latency issues. Furthermore, the Node-to-Node traffic, also called egress traffic, is charged by cloud providers. Therefore, placing Pods that communicate a lot with each other in the same Node is considered optimal to minimize egress traffic, decrease infrastructure costs and improve application performance via minimizing response times. In previous works, this was done using graph clustering techniques to produce an optimal placement for the microservices of the application. While the results were stellar, they would not translate well in a practical setting, where workloads shift and scaling of Pods occurs. In this work, we will attempt to address the problem with a more heuristic approach. We will alter the functionality of the Default Scheduler, by adding our own filtering and more importantly a communication aware scoring method. Our aim is to improve all aforementioned areas with a method that more aligns with microservices architecture and Kubernetes design. One application was deployed in the Google Cloud Platform (GCP) using Kubernetes to perform our experiments. The results show that our communication-aware placement is far better in improving application performance, infrastructure cost and egress traffic compared to the Default Scheduler. Furthermore, while it performs slightly worse than MODSOFT-HP, a fuzzy graph clustering method, further experiments with more users and scaling mechanisms that are connected with our method, could prove it to be a better and more practical method overall.
