Cube-on-cube, metacluster, κηρήθρες, διανομή πόρων

Ρύζι. 1. Οικοσύστημα Kubernetes στο Alibaba Cloud

Από το 2015, η Alibaba Cloud Container Service for Kubernetes (ACK) είναι μία από τις ταχύτερα αναπτυσσόμενες υπηρεσίες cloud στο Alibaba Cloud. Εξυπηρετεί πολλούς πελάτες και υποστηρίζει επίσης την εσωτερική υποδομή της Alibaba και τις άλλες υπηρεσίες cloud της εταιρείας.

Όπως συμβαίνει με παρόμοιες υπηρεσίες κοντέινερ από παγκοσμίου επιπέδου παρόχους cloud, οι κορυφαίες προτεραιότητές μας είναι η αξιοπιστία και η διαθεσιμότητα. Ως εκ τούτου, έχει δημιουργηθεί μια επεκτάσιμη και παγκοσμίως προσβάσιμη πλατφόρμα για δεκάδες χιλιάδες συμπλέγματα Kubernetes.

Σε αυτό το άρθρο, θα μοιραστούμε την εμπειρία μας από τη διαχείριση ενός μεγάλου αριθμού συμπλεγμάτων Kubernetes στην υποδομή cloud, καθώς και την αρχιτεκτονική της υποκείμενης πλατφόρμας.

Είσοδος

Το Kubernetes έχει γίνει το de facto πρότυπο για μια ποικιλία φόρτων εργασίας στο cloud. Όπως φαίνεται στο Σχ. 1 παραπάνω, όλο και περισσότερες εφαρμογές του Alibaba Cloud εκτελούνται πλέον σε συμπλέγματα Kubernetes: κρατικές και χωρίς πολιτεία εφαρμογές, καθώς και διαχειριστές εφαρμογών. Η διαχείριση της Kubernetes ήταν πάντα ένα ενδιαφέρον και σοβαρό θέμα συζήτησης για μηχανικούς που κατασκευάζουν και συντηρούν υποδομές. Όταν πρόκειται για παρόχους cloud όπως το Alibaba Cloud, το θέμα της κλιμάκωσης έρχεται στο προσκήνιο. Πώς να διαχειριστείτε τα συμπλέγματα Kubernetes σε αυτήν την κλίμακα; Έχουμε ήδη καλύψει τις βέλτιστες πρακτικές για τη διαχείριση τεράστιων συμπλεγμάτων Kubernetes 10 κόμβων. Φυσικά, αυτό είναι ένα ενδιαφέρον πρόβλημα κλιμάκωσης. Υπάρχει όμως και μια άλλη κλίμακα: η ποσότητα οι ίδιες οι συστάδες.

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

Ρύζι. 2. Προβλήματα διαχείρισης ενός τεράστιου αριθμού συμπλεγμάτων Kubernetes

Ποιες είναι οι κύριες προκλήσεις της διαχείρισης clusters σε αυτήν την κλίμακα; Όπως φαίνεται στο σχήμα, υπάρχουν τέσσερα ζητήματα που πρέπει να αντιμετωπιστούν:

• Ανομοιογένεια

Το ACK θα πρέπει να υποστηρίζει διάφορους τύπους συμπλεγμάτων, συμπεριλαμβανομένων των τυπικών, χωρίς διακομιστή, Edge, Windows και πολλών άλλων. Τα διαφορετικά συμπλέγματα απαιτούν διαφορετικές επιλογές, στοιχεία και μοντέλα φιλοξενίας. Ορισμένοι πελάτες χρειάζονται βοήθεια με την προσαρμογή για τις συγκεκριμένες περιπτώσεις τους.

• Διάφορα μεγέθη συμπλέγματος

Τα συμπλέγματα ποικίλλουν σε μέγεθος: από μερικούς κόμβους με πολλούς λοβούς έως δεκάδες χιλιάδες κόμβους με χιλιάδες λοβούς. Οι απαιτήσεις σε πόρους ποικίλλουν επίσης πολύ. Η ακατάλληλη κατανομή πόρων μπορεί να επηρεάσει την απόδοση ή ακόμη και να προκαλέσει αποτυχία.

• Διαφορετικές εκδόσεις

Το Kubernetes εξελίσσεται πολύ γρήγορα. Κάθε λίγους μήνες κυκλοφορούν νέες εκδόσεις. Οι πελάτες είναι πάντα πρόθυμοι να δοκιμάσουν νέες δυνατότητες. Θέλουν λοιπόν να τοποθετήσουν το δοκιμαστικό φορτίο στις νέες εκδόσεις του Kubernetes και το φορτίο παραγωγής στις σταθερές. Για να ανταποκριθεί σε αυτήν την απαίτηση, η ACK πρέπει να παραδίδει συνεχώς νέες εκδόσεις του Kubernetes στους πελάτες, διατηρώντας παράλληλα σταθερές εκδόσεις.

• Συμμόρφωση με την ασφάλεια

Τα συμπλέγματα κατανέμονται σε διαφορετικές περιοχές. Ως εκ τούτου, πρέπει να συμμορφώνονται με διάφορες απαιτήσεις ασφαλείας και επίσημους κανονισμούς. Για παράδειγμα, ένα σύμπλεγμα στην Ευρώπη πρέπει να είναι συμβατό με το GDPR, ενώ ένα χρηματοοικονομικό σύννεφο στην Κίνα πρέπει να διαθέτει πρόσθετα επίπεδα προστασίας. Αυτές οι απαιτήσεις είναι υποχρεωτικές και είναι απαράδεκτο να τις αγνοούμε, καθώς αυτό δημιουργεί τεράστιους κινδύνους για τους πελάτες της πλατφόρμας cloud.

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

Σχέδιο

Κύβος σε κύβο και κηρήθρα

Σε αντίθεση με μια κεντρική ιεραρχία, η αρχιτεκτονική που βασίζεται σε κυψέλες χρησιμοποιείται συνήθως για την κλιμάκωση μιας πλατφόρμας πέρα ​​από ένα μόνο κέντρο δεδομένων ή για την επέκταση του πεδίου εφαρμογής της ανάκτησης από καταστροφές.

Κάθε περιοχή στο Alibaba Cloud αποτελείται από πολλές ζώνες (AZ) και συνήθως αντιστοιχεί σε ένα συγκεκριμένο κέντρο δεδομένων. Σε μια μεγάλη περιοχή (π.χ. Huangzhou), υπάρχουν συχνά χιλιάδες συμπλέγματα πελατών Kubernetes που εκτελούν το ACK.

Το ACK διαχειρίζεται αυτά τα συμπλέγματα Kubernetes χρησιμοποιώντας το ίδιο το Kubernetes, που σημαίνει ότι έχουμε ένα metacluster Kubernetes που τρέχει για τη διαχείριση των συμπλεγμάτων πελάτη Kubernetes. Αυτή η αρχιτεκτονική ονομάζεται επίσης "kube-on-kube" (KoK). Η αρχιτεκτονική KoK απλοποιεί τη διαχείριση των συμπλεγμάτων πελατών επειδή η ανάπτυξη συμπλέγματος είναι απλή και ντετερμινιστική. Το πιο σημαντικό, μπορούμε να επαναχρησιμοποιήσουμε τις εγγενείς λειτουργίες του Kubernetes. Για παράδειγμα, διαχείριση διακομιστών API μέσω ανάπτυξης, χρήση του τελεστή etcd για τη διαχείριση πολλαπλών etcds. Μια τέτοια επανάληψη πάντα φέρνει ιδιαίτερη ευχαρίστηση.

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

Αυτό το μοντέλο σάς επιτρέπει να διαχειρίζεστε το Kubernetes αποτελεσματικά, ευέλικτα και αξιόπιστα.

Σχεδιασμός πόρων Metacluster

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

Ας πάρουμε για παράδειγμα πόρους δικτύου. Στην αρχιτεκτονική KoK, τα στοιχεία του Kubernetes από τα συμπλέγματα πελατών αναπτύσσονται ως pods σε ένα metacluster. Χρησιμοποιούμε Terway (Εικ. 3) είναι ένα πρόσθετο υψηλής απόδοσης που αναπτύχθηκε από την Alibaba Cloud για διαχείριση δικτύου εμπορευματοκιβωτίων. Παρέχει ένα πλούσιο σύνολο πολιτικών ασφαλείας και σας επιτρέπει να συνδέεστε με τα εικονικά ιδιωτικά σύννεφα (VPC) των πελατών μέσω της διεπαφής ελαστικής δικτύωσης Alibaba Cloud (ENI). Για να διανείμουμε αποτελεσματικά τους πόρους δικτύου σε κόμβους, pods και υπηρεσίες σε ένα metacluster, πρέπει να παρακολουθούμε προσεκτικά τη χρήση τους εντός του metacluster των εικονικών ιδιωτικών σύννεφων. Όταν οι πόροι δικτύου τελειώνουν, δημιουργείται ένα νέο κελί.

Για να προσδιορίσουμε τον βέλτιστο αριθμό συμπλεγμάτων πελατών σε κάθε metacluster, λαμβάνουμε επίσης υπόψη το κόστος, τις απαιτήσεις πυκνότητας, το όριο πόρων, τις απαιτήσεις αξιοπιστίας και τα στατιστικά στοιχεία. Η απόφαση για τη δημιουργία ενός νέου metacluster λαμβάνεται με βάση όλες αυτές τις πληροφορίες. Λάβετε υπόψη ότι τα μικρά συμπλέγματα μπορούν να επεκταθούν πολύ στο μέλλον, επομένως η κατανάλωση πόρων αυξάνεται ακόμη και αν ο αριθμός των συμπλεγμάτων παραμένει αμετάβλητος. Συνήθως αφήνουμε αρκετό ελεύθερο χώρο για να αναπτυχθεί κάθε σύμπλεγμα.

Ρύζι. 3. Αρχιτεκτονική δικτύου Terway

Κλιμάκωση στοιχείων οδηγού σε συμπλέγματα πελατών

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

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

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

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

Ρύζι. 4. Έξυπνη εναλλαγή τύπου πολλαπλών σταδίων

Εξέλιξη των ομάδων πελατών σε κλίμακα

Οι προηγούμενες ενότητες κάλυψαν ορισμένες πτυχές της διαχείρισης μεγάλου αριθμού συμπλεγμάτων Kubernetes. Ωστόσο, υπάρχει ένα άλλο πρόβλημα που πρέπει να λυθεί: η εξέλιξη των συστάδων.

Το Kubernetes είναι το «Linux» του κόσμου του cloud. Ενημερώνεται συνεχώς και γίνεται πιο αρθρωτό. Πρέπει να παρέχουμε συνεχώς νέες εκδόσεις στους πελάτες μας, να διορθώνουμε τρωτά σημεία και να ενημερώνουμε υπάρχοντα συμπλέγματα, καθώς και να διαχειριζόμαστε μεγάλο αριθμό σχετικών στοιχείων (CSI, CNI, Device Plugin, Scheduler Plugin και πολλά άλλα).

Ας πάρουμε ως παράδειγμα τη διαχείριση στοιχείων Kubernetes. Αρχικά, αναπτύξαμε ένα κεντρικό σύστημα για την καταχώριση και τη διαχείριση όλων αυτών των συνδεδεμένων στοιχείων.

Ρύζι. 5. Εύκαμπτα και βύσματα εξαρτήματα

Πριν προχωρήσετε, πρέπει να βεβαιωθείτε ότι η ενημέρωση ήταν επιτυχής. Για να γίνει αυτό, έχουμε αναπτύξει ένα σύστημα ελέγχου της λειτουργικότητας των εξαρτημάτων. Ο έλεγχος πραγματοποιείται πριν και μετά την ενημέρωση.

Ρύζι. 6. Προκαταρκτικός έλεγχος στοιχείων συστάδας

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

Για παράδειγμα, ο ελεγκτής BroadcastJob έχει σχεδιαστεί για να ενημερώνει στοιχεία σε κάθε εργαζόμενο μηχάνημα ή να ελέγχει τους κόμβους σε κάθε μηχάνημα. Η εργασία Broadcast εκτελεί ένα pod σε κάθε κόμβο στο σύμπλεγμα, όπως ένα DaemonSet. Ωστόσο, το DaemonSet διατηρεί πάντα το pod σε λειτουργία για μεγάλο χρονικό διάστημα, ενώ το BroadcastJob το καταρρέει. Ο ελεγκτής Broadcast εκκινεί επίσης pods σε κόμβους που έχουν συνδεθεί πρόσφατα και αρχικοποιεί τους κόμβους με τα απαραίτητα στοιχεία. Τον Ιούνιο του 2019 ανοίξαμε τον πηγαίο κώδικα της μηχανής αυτοματισμού OpenKruise, τον οποίο χρησιμοποιούμε οι ίδιοι στην εταιρεία.

Ρύζι. 7. Το OpenKurise οργανώνει την εκτέλεση της εργασίας Broadcast σε όλους τους κόμβους

Για να βοηθήσουμε τους πελάτες να επιλέξουν τις σωστές διαμορφώσεις συμπλέγματος, παρέχουμε επίσης ένα σύνολο προκαθορισμένων προφίλ, συμπεριλαμβανομένων των προφίλ χωρίς διακομιστή, Edge, Windows και Bare Metal. Καθώς το τοπίο διευρύνεται και οι ανάγκες των πελατών μας μεγαλώνουν, θα προσθέσουμε περισσότερα προφίλ για να απλοποιήσουμε την κουραστική διαδικασία εγκατάστασης.

Ρύζι. 8. Προηγμένα και ευέλικτα προφίλ συμπλέγματος για διάφορα σενάρια

Παγκόσμια παρατηρησιμότητα σε κέντρα δεδομένων

Όπως φαίνεται στο παρακάτω σχ. 9, η υπηρεσία cloud της Alibaba Cloud Container έχει αναπτυχθεί σε είκοσι περιοχές σε όλο τον κόσμο. Δεδομένης αυτής της κλίμακας, ένας από τους βασικούς στόχους του ACK είναι να παρακολουθεί εύκολα την κατάσταση λειτουργίας των συμπλεγμάτων, έτσι ώστε εάν ένα σύμπλεγμα πελατών αντιμετωπίσει πρόβλημα, να μπορούμε να ανταποκριθούμε γρήγορα στην κατάσταση. Με άλλα λόγια, πρέπει να βρείτε μια λύση που θα σας επιτρέπει να συλλέγετε αποτελεσματικά και με ασφάλεια στατιστικά στοιχεία σε πραγματικό χρόνο από ομάδες πελατών σε όλες τις περιοχές - και να παρουσιάζετε οπτικά τα αποτελέσματα.

Ρύζι. 9. Παγκόσμια ανάπτυξη της υπηρεσίας Alibaba Cloud Container σε είκοσι περιοχές

Όπως πολλά συστήματα παρακολούθησης Kubernetes, χρησιμοποιούμε τον Prometheus ως κύριο εργαλείο μας. Για κάθε metacluster, οι πράκτορες Prometheus συλλέγουν τις ακόλουθες μετρήσεις:

• Μετρήσεις λειτουργικού συστήματος όπως πόροι κεντρικού υπολογιστή (CPU, μνήμη, δίσκος κ.λπ.) και εύρος ζώνης δικτύου.
• Μετρήσεις για το σύστημα διαχείρισης metacluster και συμπλέγματος πελατών, όπως kube-apiserver, kube-controller-manager και kube-scheduler.
• Μετρικές από kubernetes-state-metrics και cadvisor.
• μετρήσεις etcd όπως ο χρόνος εγγραφής στο δίσκο, το μέγεθος της βάσης δεδομένων, η απόδοση των συνδέσεων μεταξύ κόμβων κ.λπ.

Οι παγκόσμιες στατιστικές συλλέγονται χρησιμοποιώντας ένα τυπικό μοντέλο συγκέντρωσης πολλαπλών επιπέδων. Τα δεδομένα παρακολούθησης από κάθε metacluster συγκεντρώνονται πρώτα σε κάθε περιοχή και στη συνέχεια αποστέλλονται σε έναν κεντρικό διακομιστή που δείχνει τη συνολική εικόνα. Όλα λειτουργούν μέσω του μηχανισμού της ομοσπονδίας. Ένας διακομιστής Prometheus σε κάθε κέντρο δεδομένων συλλέγει μετρήσεις από αυτό το κέντρο δεδομένων και ο κεντρικός διακομιστής Prometheus είναι υπεύθυνος για τη συγκέντρωση δεδομένων παρακολούθησης. Το AlertManager συνδέεται με το κεντρικό Prometheus και στέλνει ειδοποιήσεις όπως απαιτείται μέσω DingTalk, email, SMS κ.λπ. Οπτικοποίηση - Χρήση Grafana.

Στο Σχήμα 10, το σύστημα παρακολούθησης μπορεί να χωριστεί σε τρία επίπεδα:

• Επίπεδο ορίου

Το στρώμα που βρίσκεται πιο μακριά από το κέντρο. Ο διακομιστής Prometheus Edge εκτελείται σε κάθε metacluster, συλλέγοντας μετρήσεις από συμπλέγματα meta και πελατών εντός του ίδιου τομέα δικτύου.

• Επίπεδο καταρράκτη

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

• Κεντρικό επίπεδο

Ο κεντρικός διακομιστής Prometheus συνδέεται με όλους τους διακομιστές cascade και εκτελεί την τελική συγκέντρωση δεδομένων. Για αξιοπιστία, δύο κεντρικές περιπτώσεις Prometheus ανυψώθηκαν σε διαφορετικές ζώνες, συνδεδεμένες με τους ίδιους διακομιστές καταρράκτη.

Ρύζι. 10. Παγκόσμια πολυεπίπεδη αρχιτεκτονική παρακολούθησης βασισμένη στον μηχανισμό της ομοσπονδίας Prometheus

Περίληψη

Οι λύσεις cloud που βασίζονται στο Kubernetes συνεχίζουν να μεταμορφώνουν τον κλάδο μας. Η υπηρεσία κοντέινερ Alibaba Cloud παρέχει ασφαλή, αξιόπιστη και υψηλής απόδοσης φιλοξενία - είναι ένα από τα καλύτερα φιλοξενία cloud Kubernetes. Η ομάδα του Alibaba Cloud πιστεύει ακράδαντα στις αρχές του Ανοιχτού Κώδικα και της κοινότητας ανοιχτού κώδικα. Σίγουρα θα συνεχίσουμε να μοιραζόμαστε τις γνώσεις μας στον τομέα της λειτουργίας και διαχείρισης τεχνολογιών cloud.

Πηγή: www.habr.com