Συντάχθηκε 08-07-2022 14:20
Τόπος:
Σύνδεσμος τηλεδιάσκεψης
Έναρξη: 14/07/2022 11:00
Λήξη: 14/07/2022 12:00
ΠΟΛΥΤΕΧΝΕΙΟ ΚΡΗΤΗΣ
Σχολή Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών
Πρόγραμμα Προπτυχιακών Σπουδών
ΠΑΡΟΥΣΙΑΣΗ ΔΙΠΛΩΜΑΤΙΚΗΣ ΕΡΓΑΣΙΑΣ
ΣΚΕΥΑΚΗΣ ΒΑΣΙΛΕΙΟΣ
με θέμα
ΑΣΑΦΕΙΣ ΣΤΡΑΤΗΓΙΚΕΣ ΤΟΠΟΘΕΤΗΣΗΣ ΥΠΗΡΕΣΙΩΝ ΣΕ ΠΕΡΙΒΑΛΛΟΝ KUBERNETES
FUZZY SERVICE PLACEMENT STRATEGIES IN KUBERNETES
Εξεταστική Επιτροπή
Καθηγητής Ευριπίδης Πετράκης (επιβλέπων)
Καθηγητής Αντώνιος Δεληγιαννάκης
Αναπληρωτής Καθηγητής Βασίλειος Σαμολαδάς
Περίληψη
Η διαρκώς αυξανόμενη χρήση αρχιτεκτονικών μικρο-υπηρεσιών για την ανάπτυξη σύγχρονων εφαρμογών έχει οδηγήσει στην ανάγκη υλοποίησης εργαλείων για τον συντονισμό και τη διαχείριση μικρο-υπηρεσιών, όπως το Kubernetes. Ένα σύμπλεγμα Kubernetes (cluster) μπορεί να φιλοξενήσει έναν πεπερασμένο αριθμό από κόμβους (Εικονικά Μηχανήματα). Οι μικρο-υπηρεσίες της εφαρμογής ομαδοποιούνται σε "pods", τα οποία τοποθετούνται στους κόμβους (nodes) του συμπλέγματος. Η προκαθορισμένη στρατηγική τοποθέτησης στο Kubernetes είναι στατική και δεν προσαρμόζεται στον φόρτο εργασίας της εφαρμογής, οπότε είναι υποβέλτιστη. Τα "pods" πρέπει να τοποθετηθούν στους κόμβους του συμπλέγματος με τέτοιο τρόπο, ώστε να ελαχιστοποιείται η επικοινωνία μεταξύ των κόμβων. Με αυτόν τον τρόπο το κόστος της υποδομής βελτιώνεται και ο χρόνος απόκρισης μειώνεται, καθώς η επικοινωνία μεταξύ υπηρεσιών τοποθετημένων σε διαφορετικούς κόμβους (egress traffic) είναι πιο αργή σε σχέση με την επικοινωνία υπηρεσιών στον ίδιο κόμβο (ingress traffic). Οι σύγχρονες εφαρμογές περιέχουν αντίγραφα (replicas) μικρο-υπηρεσίων, ώστε ο φόρτος εργασίας μιας μικρο-υπηρεσίας να μοιράζεται μεταξύ αντιγράφων της. Στην παρούσα εργασία το πρόβλημα της τοποθέτησης των υπηρεσιών εξετάζεται ως ένα πρόβλημα διχοτόμησης ενός γράφου, με σκοπό τη βελτιστοποίηση του κόστους της υποδομής και του χρόνου απόκρισης των εφαρμογών. Η διχοτόμηση του γράφου πρέπει να είναι ασαφής (fuzzy), ώστε να επιτρέπει σε κόμβους του γράφου (μικρο-υπηρεσίες) να ανήκουν σε ένα ή περισσότερα διαμερίσματα (κόμβους του συμπλέγματος). Η απόδοση της ασαφούς στρατηγικής ελέγχθηκε σε πραγματικά σενάρια χρησιμοποιώντας δύο εφαρμογές (ένα ηλεκτρονικό κατάστημα και μια IoT εφαρμογή), οι οποίες υλοποιήθηκαν στο περιβάλλον Kubernetes της υποδομής νέφους της Google (Google Cloud Platform). Όπως αποδείχθηκε από τα αποτελέσματα των πειραμάτων, η προτεινόμενη ασαφής στρατηγική μπορεί να μειώσει σημαντικά την επικοινωνία μεταξύ των κόμβων και τον χρόνο απόκρισης της εφαρμογής, ενώ μπορεί να επιτύχει την εξοικονόμηση κόστους προηγούμενων συναφών εργασιών.
Abstract
The continuous rise of microservices-based architectures in application development provided the need for tools that orchestrate containerized applications deployed in cloud infrastructures, such as Kubernetes. A Kubernetes Cluster hosts a finite number of Nodes (VMs), and the application's services are packed in Pods and placed in the Kubernetes Nodes. The default Kubernetes Service Placement is static and does not adapt to workload changes, so the default placement solutions are sub-optimal. Pods must be placed in their respective Nodes in a way that minimizes Node-to-Node (egress) traffic. That way, the infrastructure cost is optimized, and the response time of the requests is minimized since egress traffic is slower than ingress. Modern application workloads require some high-utilized services to run in more than one instance. In this work, the service placement problem is handled as a graph clustering one, aiming to optimize the application by both cost and response time. The graph clustering needs to be fuzzy, to allow a graph's node (Kubernetes Pod) to belong in more than one partition (Nodes). Two applications were deployed in the Kubernetes infrastructure of the Google Cloud Platform to support our fuzzy service placement solution in real use cases (an e-commerce eShop and an IoT architecture). The experimental results demonstrate that our fuzzy placement solution can significantly reduce both the total requested traffic between Nodes and the response time of the applications' requests compared to the placement using the default Kubernetes Scheduler's method. At the same time, our solution can maintain the monetary cost savings of previous related work on cost-optimization in Kubernetes.
