Συντάχθηκε 10-07-2026 10:57
Τόπος:
Σύνδεσμος τηλεδιάσκεψης
Έναρξη: 14/07/2026 15:00
Λήξη: 14/07/2026 16:00
ΠΟΛΥΤΕΧΝΕΙΟ ΚΡΗΤΗΣ
Σχολή Ηλεκτρολόγων Μηχανικών και Μηχανικών Υπολογιστών
Πρόγραμμα Προπτυχιακών Σπουδών
ΠΑΡΟΥΣΙΑΣΗ ΔΙΠΛΩΜΑΤΙΚΗΣ ΕΡΓΑΣΙΑΣ
ΔΗΜΟΠΟΥΛΟΥ ΘΕΟΔΩΡΟΥ
με θέμα
Δυναμικός Προγραμματισμός Υπηρεσιών σε Πολλαπλές Περιοχές Υπολογιστικού Νέφους
Adaptive Service Scheduling Across Multiple Cloud Regions
Εξεταστική Επιτροπή
Καθηγητής Ευριπίδης Πετράκης (Επιβλέπων)
Καθηγητής Μιχαήλ Λαγουδάκης
Αναπληρωτής Καθηγητής Βασίλειος Σαμολαδάς
Περίληψη
Η διαχείριση φορτίου εργασίας μικροϋπηρεσιών σε γεωγραφικά κατανεμημένους Kubernetes clusters παρουσιάζει προκλήσεις τις οποίες τα εργαλεία μονού cluster δεν μπορούν να αντιμετωπίσουν: ο Horizontal Pod Autoscaler δεν έχει ορατότητα μεταξύ διαφορετικών cluster, και οι στατικές πολιτικές διαχείρησης κίνησης του Istio δεν μπορούν να προσαρμοστούν σε πραγματικό χρόνο στις μεταβολές της κατανομής του φορτίου. Η παρούσα διπλωματική εργασία επεκτείνει το StornX - ένα πλαίσιο διαχείρισης κίνησης και αυτόματης κλιμάκωσης για μονούς Kubernetes clusters που εισήγαγε ο Λαζίδης (2026) - σε ένα ομοσπονδιακό περιβάλλον δύο clusters που έχει δημιουργηθεί στο AWS EKS, υλοποιώντας άμεσα την πρόταση του Λαζίδη για επέκταση σε πολλαπλές περιοχές.
Η πλατφόρμα αποτελείται από δύο clusters σε χωριστές περιοχές AWS (eu-west-1 και eu-north-1), ομοσπονδιακά συνδεδεμένους μέσω Karmada και διασυνδεδεμένους μέσω πλέγματος υπηρεσιων Istio πολλαπλών clusters με shared root CA και east-west gateways. Δύο αναπτύξεις αυτής της υποδομής αξιολογούνται συγκριτικά. Στην αναφορική ανάπτυξη, το FederatedHPA διαχειρίζεται την αυτόματη κλιμάκωση μεταξύ clusters μέσω του karmada-metrics-adapter, ενώ στατικά DestinationRules τοπικότητας διέπουν την ανακατεύθυνση κίνησης. Στην ανάπτυξη StornX, ένα ανεξάρτητο instance StornX ανά cluster αντικαθιστά και τα δύο: το OptiBalancer επαναϋπολογίζει δυναμικά τα βάρη τοπικότητας των Istio DestinationRule κάθε 60 δευτερόλεπτα από μετρικές Prometheus (χρήση CPU, καθυστέρηση P95, ρυθμός αιτημάτων ανά υπηρεσία και καθυστέρηση δικτύου μεταξύ κόμβων), ενώ το OptiScaler διαχειρίζεται την αυτόματη κλιμάκωση εντός cluster με τοπολογικά ενήμερη τοποθέτηση αντιγράφων. Ως φόρτος εργασίας χρησιμοποιείται η εφαρμογή αναφοράς Google Online Boutique, η οποία διαδίδεται και στα δύο clusters μέσω Karmada.
Και οι δύο αναπτύξεις υποβάλλονται σε δύο σενάρια αποτυχίας. Το σενάριο 1 οδηγεί το eu-north σε οργανική υπερφόρτωση μέσω ασύμμετρης παραγωγής φόρτου. Το σενάριο 2 προσομοιώνει πλήρη αποτυχία ζώνης διαθεσιμότητας εκκενώνοντας όλους τους κόμβους στο eu-north-1a.
Abstract
Managing microservice workloads across geographically distributed Kubernetes clusters introduces challenges that single-cluster tooling cannot address: the Horizontal Pod Autoscaler has no cross-cluster visibility, and static Istio traffic policies cannot adapt in real time to shifts in load distribution. This thesis extends StornX — a single-cluster Kubernetes traffic management and autoscaling framework introduced by Lazidis (2026) — to a federated two-cluster environment built on AWS EKS, directly realising Lazidis's suggestion for multi-region extension.
The platform consists of two clusters in separate AWS regions (eu-west-1 and eu-north-1), federated by Karmada and connected via Istio multi-cluster service mesh with a shared root CA and east-west gateways. Two deployments of this infrastructure are evaluated against each other. In the baseline deployment, FederatedHPA manages cross-cluster autoscaling through the karmada-metrics-adapter and static locality DestinationRules govern traffic failover. In the StornX deployment, an independent StornX instance per cluster replaces both: OptiBalancer dynamically recomputes Istio DestinationRule locality weights every 60 seconds from Prometheus metrics (CPU utilisation, P95 latency, per-service request rate, and inter-node network latency), while OptiScaler handles intra-cluster autoscaling with topology-aware replica placement. The Google Online Boutique benchmark application, propagated to both clusters by Karmada, serves as the workload.
Both deployments are subjected to two failure scenarios. Scenario 1 drives eu-north into organic overload through asymmetric load generation. Scenario 2 simulates a full availability zone failure by draining all nodes in eu-north-1a.
