Συντάχθηκε 10-02-2026 10:57
Ενημερώθηκε:
10-02-2026 11:11
Τόπος:
Σύνδεσμος τηλεδιάσκεψης
Έναρξη: 17/02/2026 10:00
Λήξη: 17/02/2026 11:00
ΠΟΛΥΤΕΧΝΕΙΟ ΚΡΗΤΗΣ
Σχολή Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών
Πρόγραμμα Μεταπτυχιακών (Διδακτορικών) Σπουδών
ΠΑΡΟΥΣΙΑΣΗ ΜΕΤΑΠΤΥΧΙΑΚΗΣ ΕΡΓΑΣΙΑΣ
Αποστόλου Λαζίδη
με θέμα
Βέλτιστη Ανάθεση Υπολογιστικών Κόμβων και Δρομολόγηση Επικοινωνίας με Επίγνωση Καθυστέρησης στο Kubernetes
Latency Optimized Node and Traffic Scheduling in Kubernetes
Εξεταστική Επιτροπή
Καθηγητής Ευριπίδης Πετράκης (επιβλέπων)
Καθηγητής Μιχαήλ Λαγουδάκης
Αναπληρωτής Καθηγητής Βασίλειος Σαμολαδάς
Περίληψη
Οι μικροϋπηρεσίες σε containers αποτελούν το πρότυπο για την ανάπτυξη σύγχρονων εφαρμογών, προσφέροντας βελτιωμένη απομόνωση σφαλμάτων, δυνατότητα κλιμάκωσης και υψηλή ανθεκτικότητα. Για να διασφαλιστεί η ανοχή σε σφάλματα, οι μικροϋπηρεσίες πρέπει να κλιμακώνονται οριζόντια με την ανάπτυξη πολλαπλών αντιγράφων, ενώ η υψηλή διαθεσιμότητα επιτυγχάνεται με την τοποθέτησή τους σε πολλαπλούς εξυπηρετητές. Το Kubernetes αποτελεί ένα ισχυρό εργαλείο ενορχήστρωσης που διαχειρίζεται τον κύκλο ζωής των εφαρμογών σε containers, παρέχοντας λειτουργίες αυτόματης κλιμάκωσης, αυτόματης αποκατάστασης και ανακάλυψης υπηρεσιών. O Horizontal Pod Autoscaler (HPA) είναι το εργαλείο του Kubernetes για την αναπαραγωγή αντιγράφων των μικροϋπηρεσιών σε containers (Pods). Τα Pods σε μια εφαρμογή επικοινωνούν μεταξύ τους. Κατά την κλιμάκωση, ιδανικά πρέπει να τοποθετούνται βάσει της συχνότητας της μεταξύ τους επικοινωνίας, ώστε να ελαχιστοποιείται η καθυστέρηση μεταξύ των κόμβων (Nodes). Η μείωση της επικοινωνίας μεταξύ απομακρυσμένων κόμβων μπορεί να βελτιώσει σημαντικά τον χρόνο απόκρισης και να μειώσει το κόστος υποδομής όταν το Kubernetes τρέχει σε έναν πάροχο cloud. Ωστόσο, ο HPA βασίζεται στον προεπιλεγμένο Kubernetes Scheduler για την τοποθέτηση των νέων Pods στους κόμβους, κάτι που μπορεί να οδηγήσει σε μη βέλτιστη κατανομή, καθώς ο Scheduler δεν λαμβάνει υπόψη τα πρότυπα επικοινωνίας των Pods (inter/intra-node ή inter/intra-cluster επικοινωνία). Πέραν της κλιμάκωσης, το Kubernetes βασίζεται εξ ορισμού στα iptables για τη δρομολόγηση των αιτημάτων προς τα κατάλληλα Pods. Ωστόσο, τα iptables χρησιμοποιούνε έναν αλγόριθμο τυχαιότητας και δεν λαμβάνουν υπόψη την καθυστέρηση μεταξύ κόμβων, τη χρήση πόρων των Pods ή τον αριθμό διαθέσιμων αντιγράφων, οδηγώντας σε υπερφορτωμένα Pods και μεγάλες καθυστερήσεις όταν τα αιτήματα εξυπηρετούνται από απομακρυσμένους κόμβους. Για την αντιμετώπιση του προβλήματος της τοποθέτησης των Pods και της αποτελεσματικής κατανομής φορτίου στο Kubernetes, παρουσιάζουμε το StornX. Το StornX είναι ένας μηχανισμός αυτόματης κλιμάκωσης αντιγράφων και δρομολόγησης αιτημάτων που κατανέμει βέλτιστα τα αντίγραφα Pod εντός του Kubernetes cluster και μεταξύ των ζωνών διαθεσιμότητας στη περίπτωση του υπολογιστικού νέφους, βελτιώνει την απόδοση μέσω συντοποθέτησης επιπλέον αντιγράφων και διαχειρίζεται δυναμικά τη κατανομή αιτημάτων χρησιμοποιώντας τα βάρη τοπολογίας του Istio Service Mesh. Δρομολογεί τα αιτήματα σε συντοποθετημένα αντίγραφα και απομακρύνοντάς τα από Pods που φτάνουν τα ορισμένα όρια φόρτου, στελνοντάς τα σε Pods με διαθέσιμους πόρους. Τα πειράματα στο StornX έγιναν στο AWS cloud χρησιμοποιώντας δύο εφαρμογές. Τα πειραματικά αποτελέσματα δείχνουν ότι το StornX μειώνει τον χρόνο απόκρισης, τη χρήση πόρων, τον αριθμό των αντιγράφων και το συνολικό κόστος σε σενάρια stress και load testing. Επιπλέον, εγιναν πειράματα όπου "πέφτει" μία ζώνη διαθεσιμότητας δείχνοντας ότι το StornX ανακάμπτει πιο γρήγορα και διατηρεί καλύτερη απόδοση, κατανέμοντας την κίνηση στα διαθέσιμα αντίγραφα.
Abstract
Containerized microservices have become the defacto standard for building modern applications providing, improved fault isolation, scalability and resilience. To ensure fault-tolerance and maintain good performance under fluctuating workloads, microservices should be scaled horizontally by deploying multiple replicas. High availability is achieved by placing these replicas across multiple servers. Kubernetes is a powerful orchestrator tool that manages the lifecycle of containerized applications, providing features for automated scaling, self-healing, service discovery and seamless deployment. The Horizontal Pod Autoscaler (HPA) is Kubernetes default tool for scaling the containterized microservices, known as Pods. Pods often communicate with each other in applications. During scaling, they should ideally be scheduled based on their communication frequency to minimize cross-Node communication latency. Reducing cross-Node communication can significantly improve response time and minimize cloud costs when the Kubernetes is deployed on a cloud provider. However, HPA relies on the default Kubernetes Scheduler to assign replica Pods to Nodes, which can sometimes lead to sub-optimal placement of replicas across Nodes, because it does not rely on Pods communication patterns (i.e., inter or intra node or inter or intra cluster communication). Aside from scaling, Kubernetes by default relies on iptables to route traffic to appropriate Pods. However, iptables uses a randomized algorithm and does not consider Node-to-Node latency, Pods' resource usage or the number of available replica Pods, resulting in overloaded Pods and long delays when requests are sent to remote Nodes. To address the problem of Kubernetes replica Pod placement and load-balaning, we introduced StornX. StornX is a Kubernetes Pod autoscaler and traffic scheduler that optimal spreads the Pod replicas within a cluster across Availability Zones (AZ), optimizes efficiency by co-locating additional replicas, and dynamically manages traffic distribution using Istio Service Mesh locality weights by directing requests to co-located replicas while also rerouting traffic away from Pods that have reached their threshold limits toward replicas with available resources. StornX is tested on AWS cloud environment with two microservice-based applications. The experimental results reveal that StornX reduces the response time, resource usage, number of replica Pods and reduces the cost in stress and load test scenarios. Furthermore, Availability Zone failure experiments show that StornX recovers faster and with lower performance degradation by dynamically redistributing traffic among the remaining replicas.
Meeting ID: 613 764 0471
Password: 582678
