Η έκθεση είναι αφιερωμένη στα πρακτικά ζητήματα της ανάπτυξης ενός χειριστή στο Kubernetes, του σχεδιασμού της αρχιτεκτονικής του και των βασικών αρχών λειτουργίας του.
Στο πρώτο μέρος της έκθεσης θα εξετάσουμε:
- τι είναι ένας χειριστής στο Kubernetes και γιατί χρειάζεται;
- πώς ακριβώς ο χειριστής απλοποιεί τη διαχείριση πολύπλοκων συστημάτων.
- τι μπορεί ο χειριστής και τι δεν μπορεί ο χειριστής.
Στη συνέχεια, στραφούμε σε μια συζήτηση για την εσωτερική δομή του χειριστή. Εξετάστε την αρχιτεκτονική και τη λειτουργία του χειριστή βήμα προς βήμα. Ας το δούμε αναλυτικά:
- αλληλεπίδραση μεταξύ του χειριστή και της Kubernetes.
- ποιες λειτουργίες αναλαμβάνει ο χειριστής και τι αναθέτει στην Kubernetes.
Εξετάστε το ενδεχόμενο διαχείρισης θραυσμάτων και αντιγράφων βάσεων δεδομένων στο Kubernetes.
Στη συνέχεια, θα συζητήσουμε θέματα αποθήκευσης δεδομένων:
- πώς να εργαστείτε με το Persistent Storage από την πλευρά ενός χειριστή.
- παγίδες της χρήσης τοπικού αποθηκευτικού χώρου.
Στο τελευταίο μέρος της έκθεσης, θα εξετάσουμε πρακτικά παραδείγματα της εφαρμογής με την υπηρεσία Amazon ή Google Cloud. Η αναφορά βασίζεται στο παράδειγμα της εμπειρίας ανάπτυξης και λειτουργίας του χειριστή για το ClickHouse.
Βίντεο:
Το όνομά μου είναι Vladislav Klimenko. Σήμερα ήθελα να μιλήσω για την εμπειρία μας στην ανάπτυξη και λειτουργία ενός χειριστή, και αυτός είναι ένας εξειδικευμένος χειριστής για τη διαχείριση συμπλεγμάτων βάσεων δεδομένων. Για παράδειγμα για τη διαχείριση του συμπλέγματος ClickHouse.
Γιατί έχουμε την ευκαιρία να μιλήσουμε για τον χειριστή και το ClickHouse;
- Υποστηρίζουμε και αναπτύσσουμε το ClickHouse.
- Αυτή τη στιγμή προσπαθούμε σιγά σιγά να συνεισφέρουμε στην ανάπτυξη του ClickHouse. Και είμαστε οι δεύτεροι μετά το Yandex όσον αφορά τον όγκο των αλλαγών που έγιναν στο ClickHouse.
- Προσπαθούμε να κάνουμε επιπλέον έργα για το οικοσύστημα ClickHouse.
Θα ήθελα να μιλήσω για ένα από αυτά τα έργα. Πρόκειται για τον τελεστή ClickHouse για Kubernetes.
Στην έκθεσή μου, θα ήθελα να θίξω δύο θέματα:
- Το πρώτο θέμα είναι πώς λειτουργεί ο χειριστής της βάσης δεδομένων ClickHouse στο Kubernetes.
- Το δεύτερο θέμα είναι πώς λειτουργεί οποιοσδήποτε χειριστής, δηλαδή πώς αλληλεπιδρά με το Kubernetes.
Ωστόσο, αυτές οι δύο ερωτήσεις θα διασταυρωθούν σε όλη την έκθεσή μου.
Ποιος θα ενδιαφερόταν να ακούσει τι προσπαθώ να πω;
- Το πιο ενδιαφέρον θα είναι εκείνοι που εκμεταλλεύονται τους χειριστές.
- Ή για όσους θέλουν να φτιάξουν το δικό τους για να καταλάβουν πώς λειτουργεί στο εσωτερικό, πώς αλληλεπιδρά ο χειριστής με το Kubernetes και ποιες παγίδες μπορεί να εμφανιστούν.
Προκειμένου να κατανοήσουμε καλύτερα τι πρόκειται να συζητήσουμε σήμερα, θα ήταν ωραίο να γνωρίζουμε πώς λειτουργεί το Kubernetes και να έχουμε ένα βασικό υπόβαθρο στο cloud computing.
Τι είναι το ClickHouse; Αυτή είναι μια βάση δεδομένων στήλης με λεπτομέρειες στην ηλεκτρονική επεξεργασία αναλυτικών ερωτημάτων. Και είναι εντελώς ανοιχτού κώδικα.
Και είναι σημαντικό για εμάς να γνωρίζουμε μόνο δύο πράγματα. Πρέπει να ξέρετε ότι αυτή είναι μια βάση δεδομένων, οπότε αυτό που θα σας πω θα ισχύει σχεδόν σε οποιαδήποτε βάση δεδομένων. Και το γεγονός ότι το ClickHouse DBMS κλιμακώνεται πολύ καλά, δίνει σχεδόν γραμμική επεκτασιμότητα. Και επομένως, η κατάσταση συμπλέγματος είναι μια φυσική κατάσταση για το ClickHouse. Και μας ενδιαφέρει περισσότερο να συζητήσουμε πώς να εξυπηρετήσουμε το σύμπλεγμα ClickHouse στο Kubernetes.
Γιατί χρειάζεται εκεί; Γιατί δεν μπορούμε να συνεχίσουμε να το λειτουργούμε μόνοι μας; Και οι απαντήσεις είναι εν μέρει τεχνικές και εν μέρει οργανωτικές.
- Στην πράξη, αντιμετωπίζουμε όλο και περισσότερο μια κατάσταση όπου στις μεγάλες εταιρείες σχεδόν όλα τα εξαρτήματα βρίσκονται ήδη στο Kubernetes. Οι βάσεις δεδομένων παραμένουν εκτός.
- Και όλο και πιο συχνά τίθεται το ερώτημα: «Μπορεί να τοποθετηθεί μέσα;». Ως εκ τούτου, οι μεγάλες εταιρείες προσπαθούν να παράγουν τη μέγιστη ενοποίηση της διαχείρισης προκειμένου να μπορούν γρήγορα να διαχειρίζονται τις αποθήκες δεδομένων τους.
- Και αυτό βοηθάει ιδιαίτερα αν χρειάζεστε τη μέγιστη ευκαιρία να επαναλάβετε το ίδιο πράγμα σε ένα νέο μέρος, δηλαδή τη μέγιστη φορητότητα.
Πόσο εύκολο ή δύσκολο είναι; Αυτό, φυσικά, μπορεί να γίνει με το χέρι. Αλλά αυτό δεν είναι τόσο εύκολο, γιατί προσθέτουμε την πολυπλοκότητα της διαχείρισης του ίδιου του Kubernetes, αλλά ταυτόχρονα επιβάλλονται οι ιδιαιτερότητες του ClickHouse. Και αποδεικνύεται μια τέτοια συσσώρευση.
Και όλα μαζί, αυτό δίνει ένα αρκετά μεγάλο σύνολο τεχνολογιών, η διαχείριση των οποίων γίνεται ήδη αρκετά δύσκολη, επειδή το Kubernetes φέρνει τα καθημερινά ζητήματά του σε λειτουργία και το ClickHouse φέρνει τα προβλήματά του στην καθημερινή λειτουργία. Ειδικά αν έχουμε πολλά ClickHouses και πρέπει να κάνουμε συνεχώς κάτι με αυτά.
Το ClickHouse με δυναμική διαμόρφωση έχει αρκετά μεγάλο αριθμό ζητημάτων που δημιουργούν σταθερό φορτίο στα DevOps:
- Όταν θέλουμε να αλλάξουμε κάτι στο ClickHouse, για παράδειγμα, να προσθέσουμε ένα αντίγραφο, ένα θραύσμα, τότε πρέπει να διαχειριστούμε τη διαμόρφωση.
- Στη συνέχεια, αλλάξτε το σχήμα δεδομένων, επειδή το ClickHouse έχει μια συγκεκριμένη μέθοδο κοινής χρήσης. Εκεί είναι απαραίτητο να διαμορφώσετε το σχήμα δεδομένων, να ορίσετε διαμορφώσεις.
- Πρέπει να ρυθμίσετε την παρακολούθηση.
- Συλλογή κορμών για νέα θραύσματα, για νέα αντίγραφα.
- Φροντίστε για την αποκατάσταση.
- Και επανεκκίνηση.
Είναι τέτοιες εργασίες ρουτίνας που θα ήθελα πολύ να διευκολύνω στη λειτουργία.
Το ίδιο το Kubernetes βοηθάει πολύ στη λειτουργία, αλλά σε βασικά πράγματα του συστήματος.
Το Kubernetes είναι εξαιρετικό στη διευκόλυνση και την αυτοματοποίηση πραγμάτων όπως:
- Ανάκτηση.
- Επανεκκίνηση.
- Διαχείριση αποθήκευσης.
Αυτό είναι καλό, αυτή είναι η σωστή κατεύθυνση, αλλά είναι εντελώς εκτός επαφής με τον τρόπο λειτουργίας ενός συμπλέγματος βάσεων δεδομένων.
Θέλω περισσότερα, θέλω ολόκληρη η βάση δεδομένων να λειτουργεί για εμάς στο Kubernetes.
Θα ήθελα να πάρω κάτι σαν ένα μεγάλο μαγικό κόκκινο κουμπί που πατάτε και έχετε ένα σύμπλεγμα που αναπτύσσεται και διατηρείται σε όλο τον κύκλο ζωής με καθημερινές εργασίες που πρέπει να επιλυθούν. Το σύμπλεγμα ClickHouse στο Kubernetes.
Και προσπαθήσαμε να φτιάξουμε μια λύση που θα διευκόλυνε τη δουλειά. Αυτός είναι ο τελεστής ClickHouse για Kubernetes από το Altinity.
Ένας χειριστής είναι ένα πρόγραμμα του οποίου η κύρια αποστολή είναι να διαχειρίζεται άλλα προγράμματα, δηλαδή είναι διαχειριστής.
Και περιέχει πρότυπα συμπεριφοράς. Μπορείτε να το ονομάσετε κωδικοποιημένη γνώση για τη θεματική περιοχή.
Και το κύριο καθήκον του είναι να διευκολύνει τη ζωή των DevOps και να μειώσει τη μικροδιαχείριση, έτσι ώστε αυτός (DevOps) να σκέφτεται ήδη με όρους υψηλού επιπέδου, δηλαδή να μην κάνει μικροδιαχείριση, ώστε να μην ρυθμίζει με μη αυτόματο τρόπο όλες τις Λεπτομέριες.
Και μόνο ο χειριστής είναι ένας βοηθός ρομπότ που παλεύει με μικροεργασίες και βοηθά τα DevOps.
Γιατί χρειάζεται χειριστής; Διαπρέπει σε δύο τομείς:
- Όταν ένας ειδικός του ClickHouse δεν έχει αρκετή εμπειρία, αλλά είναι ήδη απαραίτητο να λειτουργήσει το ClickHouse, ο χειριστής διευκολύνει τη λειτουργία και σας επιτρέπει να χειριστείτε ένα σύμπλεγμα ClickHouse με μια μάλλον περίπλοκη διαμόρφωση, χωρίς να υπεισέρχεται σε πολλές λεπτομέρειες σχετικά με τον τρόπο λειτουργίας του. . Απλώς του αναθέτετε καθήκοντα υψηλού επιπέδου και λειτουργεί.
- Και η δεύτερη εργασία στην οποία αποδίδει καλύτερα είναι όταν είναι απαραίτητο να αυτοματοποιηθεί ένας μεγάλος αριθμός τυπικών εργασιών. Αφαιρεί μικροεργασίες από τα sysadmin.
Αυτό χρειάζεται περισσότερο είτε από αυτούς που μόλις ξεκινούν το ταξίδι τους, είτε από εκείνους που πρέπει να κάνουν πολύ αυτοματισμό.
Πώς διαφέρει η προσέγγιση που βασίζεται σε χειριστή από άλλα συστήματα; Υπάρχει Helm. Βοηθά επίσης να εγκαταστήσετε το ClickHouse, μπορείτε να σχεδιάσετε γραφήματα πηδαλίου, τα οποία θα εγκαταστήσουν ακόμη και ένα ολόκληρο σύμπλεγμα ClickHouse. Ποια είναι λοιπόν η διαφορά μεταξύ του χειριστή και του ίδιου, για παράδειγμα, Helm;
Η κύρια θεμελιώδης διαφορά είναι ότι το Helm έχει να κάνει με τη διαχείριση πακέτων και ο χειριστής προχωρά ένα βήμα παραπέρα. Αυτή είναι η υποστήριξη ολόκληρου του κύκλου ζωής. Δεν πρόκειται μόνο για εγκατάσταση, είναι καθημερινές εργασίες που περιλαμβάνουν κλιμάκωση, διαμοιρασμό, δηλαδή ό,τι πρέπει να γίνει κατά τη διάρκεια του κύκλου ζωής (εάν είναι απαραίτητο, αφαίρεση επίσης) - όλα αποφασίζονται από τον χειριστή. Προσπαθεί να αυτοματοποιήσει και να εξυπηρετήσει ολόκληρο τον κύκλο ζωής του λογισμικού. Αυτή είναι η θεμελιώδης διαφορά του από άλλες λύσεις που παρουσιάζονται.
Αυτό ήταν το εισαγωγικό μέρος, ας προχωρήσουμε.
Πώς χτίζουμε τον χειριστή μας; Προσπαθούμε να προσεγγίσουμε το ζήτημα προκειμένου να διαχειριστούμε το σύμπλεγμα ClickHouse ως ενιαίο πόρο.
Εδώ έχουμε τα δεδομένα εισαγωγής στην αριστερή πλευρά της εικόνας. Αυτό είναι το YAML με προδιαγραφή συμπλέγματος, το οποίο κλασικά περνάει μέσω kubectl στο Kubernetes. Εκεί το σηκώνει ο χειριστής μας, κάνει τα μαγικά του. Και ως αποτέλεσμα, έχουμε ένα τέτοιο σχέδιο. Αυτή είναι η υλοποίηση του ClickHouse στο Kubernetes.
Και μετά θα δούμε σιγά σιγά πώς λειτουργεί ο χειριστής, ποιες τυπικές εργασίες μπορούν να επιλυθούν. Θα εξετάσουμε μόνο τυπικές εργασίες, γιατί έχουμε περιορισμένο χρόνο. Και δεν θα ειπωθεί για όλα όσα μπορεί να αποφασίσει ο χειριστής.
Ας ξεκινήσουμε από την πρακτική. Το έργο μας είναι εντελώς ανοιχτού κώδικα, οπότε μπορείτε να δείτε πώς λειτουργεί στο GitHub. Και μπορείτε να προχωρήσετε από τις σκέψεις, εάν θέλετε απλώς να ξεκινήσετε, τότε μπορείτε να ξεκινήσετε με τον Οδηγό Γρήγορης Εκκίνησης.
Εάν θέλετε να καταλάβετε λεπτομερώς, τότε προσπαθούμε να διατηρήσουμε την τεκμηρίωση σε μια περισσότερο ή λιγότερο αξιοπρεπή μορφή.
Ας ξεκινήσουμε με ένα πρακτικό πρόβλημα. Η πρώτη εργασία με την οποία όλοι θέλουμε να ξεκινήσουμε είναι να εκτελέσουμε το πρώτο παράδειγμα με κάποιο τρόπο. Πώς να εκκινήσετε το ClickHouse με τη βοήθεια ενός χειριστή, χωρίς καν να ξέρετε πώς λειτουργεί; Γράφουμε ένα μανιφέστο, γιατί όλη η επικοινωνία με τα k8 είναι επικοινωνία μέσω εκδηλώσεων.
Εδώ είναι ένα τόσο περίπλοκο μανιφέστο. Αυτό που τονίσαμε με κόκκινο είναι αυτό στο οποίο πρέπει να εστιάσουμε. Ζητάμε από τον χειριστή να δημιουργήσει ένα σύμπλεγμα με το όνομα demo.
Προς το παρόν, αυτά είναι βασικά παραδείγματα. Η αποθήκευση δεν έχει ακόμη περιγραφεί, αλλά θα επιστρέψουμε στην αποθήκευση λίγο αργότερα. Προς το παρόν, θα παρατηρήσουμε την ανάπτυξη του συμπλέγματος σε δυναμική.
Δημιουργήσαμε αυτό το μανιφέστο. Το τροφοδοτούμε στον χειριστή μας. Δούλεψε, έκανε μαγικά.
Κοιτάμε την κονσόλα. Τρία στοιχεία παρουσιάζουν ενδιαφέρον - αυτά είναι το Pod, δύο Service-a, StatefulSet.
Ο χειριστής έχει δουλέψει και μπορούμε να δούμε τι ακριβώς δημιούργησε.
Δημιουργεί κάτι τέτοιο. Έχουμε StatefulSet, Pod, ConfigMap για κάθε αντίγραφο, ConfigMap για ολόκληρο το σύμπλεγμα. Απαραίτητα υπηρεσίες ως σημεία εισόδου στο σύμπλεγμα.
Οι υπηρεσίες είναι η κεντρική υπηρεσία Load Balancer και είναι δυνατή για κάθε αντίγραφο, για κάθε θραύσμα.
Εδώ είναι το βασικό μας σύμπλεγμα μοιάζει κάπως έτσι. Είναι από έναν μόνο κόμβο.
Ας πάμε παρακάτω, θα περιπλέκουμε. Πρέπει να θρυμματίσετε το σύμπλεγμα.
Τα καθήκοντά μας μεγαλώνουν, η δυναμική αρχίζει. Θέλουμε να προσθέσουμε ένα κομμάτι. Παρακολουθούμε την εξέλιξη. Αλλάζουμε τις προδιαγραφές μας. Δηλώνουμε ότι θέλουμε δύο θραύσματα.
Αυτό είναι το ίδιο αρχείο που αναπτύσσουμε δυναμικά με την ανάπτυξη του συστήματος. Δεν υπάρχει αποθήκευση, η αποθήκευση θα συζητηθεί περαιτέρω, αυτό είναι ένα ξεχωριστό θέμα.
Τροφοδοτούμε τον χειριστή YAML και βλέπουμε τι συμβαίνει.
Ο χειριστής σκέφτηκε και έφτιαξε τις παρακάτω οντότητες. Έχουμε ήδη δύο Pods, τρεις Υπηρεσίες και, ξαφνικά, 2 StatefulSets. Γιατί 2 StatefulSets;
Στο διάγραμμα ήταν έτσι - αυτή είναι η αρχική μας κατάσταση, όταν είχαμε ένα λοβό.
Έγινε έτσι. Μέχρι στιγμής, όλα είναι απλά, έχουν αντιγραφεί.
Και γιατί το StatefulSet έγινε δύο; Εδώ πρέπει να παρεκκλίνουμε και να συζητήσουμε το ερώτημα πώς διαχειρίζονται τα Pods στο Kubernetes.
Υπάρχει ένα τέτοιο αντικείμενο που ονομάζεται StatefulSet, το οποίο σας επιτρέπει να δημιουργήσετε ένα σύνολο Pods από ένα πρότυπο. Ο βασικός παράγοντας εδώ είναι το Πρότυπο. Και μπορείτε να εκτελέσετε πολλά Pods σε ένα StatefulSet σύμφωνα με ένα πρότυπο. Και η φράση κλειδί εδώ είναι "ένα πρότυπο πολλά Pods".
Και υπήρχε ένας μεγάλος πειρασμός να γίνει ολόκληρο το σύμπλεγμα, συσκευάζοντάς το σε ένα StatefulSet. Θα λειτουργήσει, δεν υπάρχει πρόβλημα σε αυτό. Υπάρχει όμως μια προειδοποίηση. Αν θέλουμε να συγκεντρώσουμε ένα ετερογενές σύμπλεγμα, δηλαδή από διάφορες εκδόσεις του ClickHouse, τότε αρχίζουν οι ερωτήσεις μας. Ναι, το StatefulSet μπορεί να κάνει μια κυλιόμενη ενημέρωση, αλλά εκεί μπορείτε να διαθέσετε μια νέα έκδοση, εξηγώντας ότι δεν χρειάζεται να δοκιμάσετε περισσότερους από τόσους κόμβους ταυτόχρονα.
Αλλά αν προεκτείνουμε την εργασία και πούμε ότι θέλουμε να δημιουργήσουμε ένα εντελώς ετερογενές σύμπλεγμα και δεν θέλουμε να αλλάξουμε από την παλιά έκδοση σε μια νέα χρησιμοποιώντας μια κυλιόμενη ενημέρωση, αλλά απλώς θέλουμε να δημιουργήσουμε ένα ετερογενές σύμπλεγμα τόσο από άποψη διαφορετικών εκδόσεων του ClickHouse και όσον αφορά τον διαφορετικό χώρο αποθήκευσης. Θέλουμε, για παράδειγμα, να φτιάξουμε μερικά αντίγραφα σε ξεχωριστούς δίσκους, σε αργούς, γενικά, να δημιουργήσουμε εντελώς ένα ετερογενές σύμπλεγμα. Και λόγω του γεγονότος ότι το StatefulSet δημιουργεί μια τυποποιημένη λύση από ένα πρότυπο, επομένως δεν υπάρχει τρόπος να γίνει αυτό.
Μετά από σκέψη, αποφασίστηκε να κάνουμε έτσι. Έχουμε κάθε αντίγραφο στο δικό του StatefulSet. Υπάρχουν ορισμένα μειονεκτήματα σε αυτή τη λύση, αλλά στην πράξη όλα περικλείουν πλήρως τον χειριστή. Και υπάρχουν πολλά οφέλη. Μπορούμε να δημιουργήσουμε ένα εντελώς τέτοιο σύμπλεγμα όπως θέλουμε, για παράδειγμα, ένα απολύτως ετερογενές. Επομένως, σε ένα σύμπλεγμα στο οποίο έχουμε δύο θραύσματα με ένα αντίγραφο, θα έχουμε 2 StatefulSets και 2 Pods ακριβώς επειδή επιλέξαμε αυτήν την προσέγγιση λόγω των παραπάνω λόγων για τη δυνατότητα δημιουργίας ενός ετερογενούς συμπλέγματος.
Ας επιστρέψουμε στις πρακτικές εργασίες. Στο σύμπλεγμα μας, πρέπει να διαμορφώσουμε τους χρήστες, π.χ. πρέπει να κάνετε κάποια διαμόρφωση του ClickHouse στο Kubernetes. Ο χειριστής παρέχει όλες τις δυνατότητες για αυτό.
Μπορούμε να γράψουμε ό,τι θέλουμε απευθείας στο YAML. Όλες οι επιλογές διαμόρφωσης αντιστοιχίζονται απευθείας από αυτό το YAML σε ρυθμίσεις παραμέτρων ClickHouse, οι οποίες στη συνέχεια αναπτύσσονται σε όλο το σύμπλεγμα.
Μπορείτε επίσης να γράψετε έτσι. Αυτό είναι για παράδειγμα. Ο κωδικός πρόσβασης μπορεί να κρυπτογραφηθεί. Υποστηρίζονται απολύτως όλες οι επιλογές διαμόρφωσης του ClickHouse. Εδώ είναι μόνο ένα παράδειγμα.
Η διαμόρφωση συμπλέγματος διανέμεται ως ConfigMap. Στην πράξη, η ενημέρωση ConfigMap δεν πραγματοποιείται αμέσως, επομένως εάν υπάρχει ένα μεγάλο σύμπλεγμα, τότε η διαδικασία προώθησης της διαμόρφωσης διαρκεί κάποιο χρόνο. Αλλά όλα αυτά είναι πολύ βολικά στη χρήση.
Ας περιπλέκουμε το έργο. Το σύμπλεγμα αναπτύσσεται. Θέλουμε να αναπαράγουμε δεδομένα. Δηλαδή, έχουμε ήδη δύο θραύσματα, ένα αντίγραφο το καθένα, και οι χρήστες έχουν ρυθμιστεί. Μεγαλώνουμε και θέλουμε να κάνουμε αναπαραγωγή.
Τι χρειαζόμαστε για την αναπαραγωγή;
Χρειαζόμαστε ZooKeeper. Στο ClickHouse, η αναπαραγωγή δημιουργείται χρησιμοποιώντας το ZooKeeper. Το ZooKeeper είναι απαραίτητο έτσι ώστε διαφορετικά αντίγραφα του ClickHouse να έχουν συναίνεση σχετικά με το ποια μπλοκ δεδομένων βρίσκονται σε ποιο ClickHouse.
Το ZooKeeper μπορεί να χρησιμοποιηθεί από οποιονδήποτε. Εάν μια επιχείρηση διαθέτει εξωτερικό ZooKeeper, τότε μπορεί να χρησιμοποιηθεί. Εάν όχι, τότε μπορείτε να εγκαταστήσετε από το αποθετήριο μας. Υπάρχει ένα πρόγραμμα εγκατάστασης που διευκολύνει όλο αυτό το θέμα.
Και το σχήμα αλληλεπίδρασης ολόκληρου του συστήματος αποδεικνύεται έτσι. Έχουμε το Kubernetes ως πλατφόρμα. Εκτελεί την πρόταση ClickHouse. ZooKeeper Φωτογράφισα εδώ. Και ο χειριστής αλληλεπιδρά τόσο με το ClickHouse όσο και με το ZooKeeper. Δηλαδή, προκύπτει μια αλληλεπίδραση.
Και όλα αυτά είναι απαραίτητα για το ClickHouse για την επιτυχή αναπαραγωγή δεδομένων σε k8s.
Ας δούμε τώρα την ίδια την εργασία, πώς θα μοιάζει το μανιφέστο για αναπαραγωγή.
Προσθέτουμε δύο ενότητες στο μανιφέστο μας. Το πρώτο είναι πού μπορείτε να πάρετε το ZooKeeper, το οποίο μπορεί να είναι είτε εντός του Kubernetes είτε εξωτερικό. Αυτή είναι απλώς μια περιγραφή. Και παραγγέλνουμε αντίγραφα. Εκείνοι. θέλουμε δύο αντίγραφα. Συνολικά, θα πρέπει να έχουμε 4 pods στην έξοδο. Θυμόμαστε για την αποθήκευση, θα επιστρέψει λίγο πιο πέρα. Το Storage είναι ένα ξεχωριστό τραγούδι.
Ήταν έτσι.
Γίνεται έτσι. Προστίθενται αντίγραφα. Το 4ο δεν ταίριαξε, πιστεύουμε ότι μπορεί να είναι πολλοί. Και το ZooKeeper προστίθεται στο πλάι. Τα μοτίβα γίνονται πιο περίπλοκα.
Και ήρθε η ώρα να προσθέσετε την επόμενη εργασία. Θα προσθέσουμε Μόνιμη αποθήκευση.
Για τη Μόνιμη αποθήκευση έχουμε διάφορες επιλογές.
Εάν τρέχουμε σε έναν πάροχο cloud, για παράδειγμα, χρησιμοποιώντας Amazon, Google, τότε υπάρχει μεγάλος πειρασμός να χρησιμοποιήσουμε το cloud storage. Είναι πολύ βολικό, είναι καλό.
Και υπάρχει μια δεύτερη επιλογή. Αυτό είναι για τοπική αποθήκευση, όταν έχουμε τοπικούς δίσκους σε κάθε κόμβο. Αυτή η επιλογή είναι πολύ πιο δύσκολη στην εφαρμογή, αλλά ταυτόχρονα είναι και πιο παραγωγική.
Ας δούμε τι έχουμε σχετικά με την αποθήκευση cloud.
Υπάρχουν πλεονεκτήματα. Είναι πολύ εύκολο να διαμορφωθεί. Απλώς παραγγέλνουμε από έναν πάροχο cloud που παρακαλούμε να μας δώσει χώρο αποθήκευσης τάδε χωρητικότητα, τέτοια και τέτοια κατηγορία. Τα μαθήματα ζωγραφίζονται από τους παρόχους ανεξάρτητα.
Και υπάρχει ένα μειονέκτημα. Για μερικούς, αυτό είναι μια απαράδεκτη έλλειψη. Φυσικά, θα υπάρξουν κάποιες επικαλύψεις επιδόσεων. Είναι πολύ βολικό στη χρήση, αξιόπιστο, αλλά υπάρχουν ορισμένα πιθανά μειονεκτήματα στην απόδοση.
Και από τότε Το ClickHouse εστιάζει στην απόδοση, μπορείτε ακόμη να πείτε ότι αποσπά ό,τι είναι δυνατό, έτσι πολλοί πελάτες προσπαθούν να αποσπάσουν τη μέγιστη απόδοση.
Και για να αξιοποιήσουμε στο έπακρο, χρειαζόμαστε τοπική αποθήκευση.
Το Kubernetes παρέχει τρεις αφαιρέσεις για τη χρήση τοπικής αποθήκευσης στο Kubernetes. Αυτό:
- EmptyDir
- HostPath.
- τοπικός
Σκεφτείτε πώς διαφέρουν, πώς μοιάζουν.
Πρώτον, και στις τρεις προσεγγίσεις έχουμε αποθήκευση - αυτοί είναι τοπικοί δίσκοι που βρίσκονται στον ίδιο φυσικό κόμβο k8s. Έχουν όμως κάποιες διαφορές.
Ας ξεκινήσουμε με το απλούστερο, δηλαδή το κενό Διεύθυνση. Τι είναι στην πράξη; Είμαστε εμείς που ζητάμε από το σύστημα κοντέινερ (συνήθως Docker) από τις προδιαγραφές μας να μας παράσχει πρόσβαση σε έναν φάκελο σε έναν τοπικό δίσκο.
Στην πράξη, το docker δημιουργεί έναν προσωρινό φάκελο κάπου στις δικές του διαδρομές, τον αποκαλεί long hash. Και παρέχει μια διεπαφή για πρόσβαση σε αυτό.
Πώς θα αποδώσει από άποψη απόδοσης; Αυτό θα εκτελεστεί με την ταχύτητα του τοπικού δίσκου, δηλ. αυτό είναι πλήρης πρόσβαση στη βίδα σας.
Όμως αυτή η περίπτωση έχει τα μειονεκτήματά της. Το επίμονο σε αυτή την περίπτωση είναι μάλλον αμφίβολο. Με την πρώτη κίνηση του docker με δοχεία, το Persistent χάνεται. Εάν η Kubernetes θέλει να μετακινήσει αυτό το Pod σε άλλο δίσκο για κάποιο λόγο, τότε τα δεδομένα θα χαθούν.
Αυτή η προσέγγιση είναι καλή για δοκιμές, επειδή δείχνει ήδη κανονική ταχύτητα, αλλά αυτή η επιλογή δεν είναι κατάλληλη για κάτι σοβαρό.
Επομένως, υπάρχει μια δεύτερη προσέγγιση. Αυτό είναι το hostPath. Αν κοιτάξετε την προηγούμενη διαφάνεια και αυτή, μπορείτε να δείτε μόνο μία διαφορά. Ο φάκελος μας άφησε το docker απευθείας στον κόμβο Kubernetes. Εδώ είναι λίγο πιο γρήγορα. Γράφουμε απευθείας τη διαδρομή στο τοπικό σύστημα αρχείων όπου θα θέλαμε να αποθηκεύσουμε τα δεδομένα μας.
Αυτή η μέθοδος έχει πλεονεκτήματα. Αυτό είναι ήδη ένα πραγματικό Persistent, και μάλιστα κλασικό. Θα έχουμε δεδομένα καταγεγραμμένα στο δίσκο σε κάποια διεύθυνση.
Υπάρχουν και μειονεκτήματα. Αυτή είναι η πολυπλοκότητα της διαχείρισης. Οι Kubernetes μας μπορεί να θέλουν να μετακινήσουν το Pod σε άλλο φυσικό κόμβο. Εδώ μπαίνει στο παιχνίδι το DevOps. Πρέπει να εξηγήσει σωστά σε ολόκληρο το σύστημα ότι μπορείτε να μετακινήσετε αυτά τα pods μόνο σε τέτοιους κόμβους στους οποίους έχετε τοποθετήσει κάτι κατά μήκος αυτών των μονοπατιών, και όχι περισσότερους από έναν κόμβο τη φορά. Είναι αρκετά δύσκολο.
Ειδικά για αυτούς τους σκοπούς, έχουμε φτιάξει πρότυπα στον χειριστή μας για να κρύψουμε όλη αυτή την πολυπλοκότητα. Και θα μπορούσατε απλώς να πείτε: "Θέλω να έχω μία παρουσία του ClickHouse ανά φυσικό κόμβο και κατά μήκος αυτού και ενός τέτοιου μονοπατιού."
Αλλά αυτή η ανάγκη δεν είναι μόνο για εμάς, επομένως οι κύριοι από την ίδια την Kubernetes καταλαβαίνουν επίσης ότι οι άνθρωποι θέλουν να έχουν πρόσβαση σε φυσικούς δίσκους, επομένως παρέχουν ένα τρίτο επίπεδο.
Λέγεται τοπικό. Δεν υπάρχει ουσιαστικά καμία διαφορά από την προηγούμενη διαφάνεια. Μόνο νωρίτερα ήταν απαραίτητο να πραγματοποιήσουμε με το χέρι ότι δεν μπορούμε να μεταφέρουμε αυτά τα pods από κόμβο σε κόμβο, επειδή πρέπει να συνδεθούν κατά μήκος αυτού και του άλλου μονοπατιού στον τοπικό φυσικό δίσκο και τώρα όλη αυτή η γνώση είναι ενσωματωμένη στο ίδιο το Kubernetes. Και αποδεικνύεται πολύ πιο εύκολο να διαμορφωθεί.
Ας επιστρέψουμε στο πρακτικό μας πρόβλημα. Ας επιστρέψουμε στο πρότυπο YAML. Εδώ έχουμε πραγματικό χώρο αποθήκευσης. Επιστρέψαμε σε αυτό. Ρυθμίσαμε το κλασικό πρότυπο VolumeClaim όπως στα k8s. Και περιγράφουμε τι είδους αποθήκευση θέλουμε.
Μετά από αυτό, το k8s θα ζητήσει αποθήκευση. Διαθέστε το σε εμάς στο StatefulSet. Και στο τέλος, θα βγει στη διάθεση του ClickHouse.
Είχαμε αυτό το σχέδιο. Το Persistent Storage μας ήταν κόκκινο, κάτι που φαινόταν να υπονοεί ότι έπρεπε να γίνει.
Και γίνεται πράσινο. Τώρα το σχήμα συμπλέγματος ClickHouse στο k8s έχει οριστικοποιηθεί πλήρως. Έχουμε θραύσματα, αντίγραφα, ZooKeeper, έχουμε πραγματικό Persistent, το οποίο υλοποιείται με τον ένα ή τον άλλο τρόπο. Το σχέδιο είναι ήδη πλήρως λειτουργικό.
Συνεχίζουμε να ζούμε. Το σύμπλεγμα μας μεγαλώνει. Και ο Aleksey προσπαθεί και κυκλοφορεί μια νέα έκδοση του ClickHouse.
Προκύπτει μια πρακτική εργασία - να δοκιμάσουμε τη νέα έκδοση του ClickHouse στο σύμπλεγμα μας. Και, φυσικά, δεν θέλω να τα κυκλοφορήσω όλα, θέλω να βάλω μια νέα έκδοση κάπου στη μακρινή γωνία σε ένα αντίγραφο, ή ίσως όχι μια νέα έκδοση, αλλά δύο ταυτόχρονα, επειδή βγαίνουν συχνά.
Τι μπορούμε να πούμε για αυτό;
Εδώ έχουμε ακριβώς μια τέτοια ευκαιρία. Αυτά είναι πρότυπα pod. Μπορείτε να βάψετε, ο χειριστής μας σας επιτρέπει πλήρως να δημιουργήσετε ένα ετερογενές σύμπλεγμα. Εκείνοι. διαμορφώστε, ξεκινώντας από όλα τα αντίγραφα σε μια δέσμη, τελειώνοντας με κάθε προσωπικό αντίγραφο, ποια έκδοση θέλουμε ClickHouse, ποια έκδοση θέλουμε αποθήκευση. Μπορούμε να διαμορφώσουμε πλήρως το σύμπλεγμα σε μια τέτοια διαμόρφωση που χρειαζόμαστε.
Ας πάμε λίγο βαθύτερα. Πριν από αυτό, μιλήσαμε για το πώς λειτουργεί ο χειριστής ClickHouse σε σχέση με τις ιδιαιτερότητες του ClickHouse.
Τώρα θα ήθελα να πω λίγα λόγια για το πώς λειτουργεί οποιοσδήποτε χειριστής γενικά, καθώς και πώς αλληλεπιδρά με τα K8.
Εξετάστε την αλληλεπίδραση με τα K8 για αρχή. Τι συμβαίνει όταν κάνουμε εφαρμογή kubectl; Μέσω του API, τα αντικείμενά μας εμφανίζονται σε κ.λπ.
Για παράδειγμα, τα βασικά αντικείμενα Kubernetes: pod, StatefulSet, service και ούτω καθεξής μέσα από τη λίστα.
Ωστόσο, τίποτα φυσικό δεν συμβαίνει ακόμα. Αυτά τα αντικείμενα πρέπει να υλοποιηθούν σε ένα σύμπλεγμα.
Εδώ μπαίνει ο ελεγκτής. Ο ελεγκτής είναι ένα ειδικό εξάρτημα k8s που μπορεί να υλοποιήσει αυτές τις περιγραφές. Ξέρει πώς και τι να κάνει σωματικά. Ξέρει πώς να τρέχει κοντέινερ, τι πρέπει να ρυθμίσει εκεί για να λειτουργήσει ο διακομιστής.
Και υλοποιεί τα αντικείμενά μας στα K8.
Αλλά δεν θέλουμε να λειτουργούμε μόνο με pods, StatefulSets, θέλουμε να δημιουργήσουμε ένα ClickHouseInstallation, δηλαδή ένα αντικείμενο τύπου ClickHouse, για να λειτουργήσουμε με αυτό ως σύνολο. Μέχρι στιγμής δεν υπάρχει τέτοιο ενδεχόμενο.
Το K8s όμως έχει το εξής ωραίο. Θέλουμε να έχουμε κάπου μια τόσο περίπλοκη οντότητα, στην οποία το σύμπλεγμα μας θα συγκεντρώνεται από pods και StatefulSet.
Και τι πρέπει να γίνει για αυτό; Αρχικά, ο Προσαρμοσμένος ορισμός πόρων εισέρχεται στη σκηνή. Τι είναι? Αυτή είναι μια περιγραφή για τα K8 ότι θα έχετε έναν άλλο τύπο δεδομένων που θέλουμε να προσθέσουμε στο pod, το StatefulSet, έναν προσαρμοσμένο πόρο που θα είναι πολύπλοκος στο εσωτερικό του. Αυτή είναι μια περιγραφή της δομής δεδομένων.
Το στέλνουμε και εκεί μέσω της εφαρμογής kubectl. Ο Kubernetes το πήρε με χαρά.
Και τώρα στον αποθηκευτικό χώρο μας, το αντικείμενο στο etcd έχει την ευκαιρία να γράψει έναν προσαρμοσμένο πόρο που ονομάζεται ClickHouseInstallation.
Αλλά προς το παρόν δεν θα γίνει τίποτα άλλο. Δηλαδή, εάν τώρα δημιουργήσουμε ένα αρχείο YAML που θεωρήσαμε με περιγραφή του θραύσματος, αντίγραφα και πούμε "kubectl ισχύει", τότε η Kubernetes θα το δεχτεί, θα το βάλει σε etcd και θα πει: "Τέλεια, αλλά δεν ξέρω τι να το κάνεις. Δεν ξέρω πώς να διατηρήσω το ClickHouseInstallation."
Συνεπώς, χρειαζόμαστε κάποιον να βοηθήσει την Kubernetes να εξυπηρετήσει τον νέο τύπο δεδομένων. Στα αριστερά, έχουμε έναν ελεγκτή αποθέματος Kubernetes που λειτουργεί με τύπους δεδομένων μετοχών. Και στα δεξιά, θα πρέπει να έχουμε έναν προσαρμοσμένο ελεγκτή που μπορεί να λειτουργήσει με προσαρμοσμένους τύπους δεδομένων.
Και κατά άλλον τρόπο λέγεται τελεστής. Το έβγαλα συγκεκριμένα εδώ για το Kubernetes, γιατί μπορεί να εκτελεστεί και εκτός K8. Τις περισσότερες φορές, φυσικά, όλες οι εντολές εκτελούνται στο Kubernetes, αλλά τίποτα δεν το εμποδίζει να στέκεται έξω, επομένως εδώ αναδεικνύεται ειδικά.
Και ήδη, με τη σειρά του, ο προσαρμοσμένος ελεγκτής, γνωστός και ως χειριστής, αλληλεπιδρά με το Kubernetes μέσω του API. Ξέρει ήδη πώς να αλληλεπιδρά με το API. Και ξέρει ήδη πώς να υλοποιήσει ένα περίπλοκο σχέδιο που θέλουμε να φτιάξουμε από έναν προσαρμοσμένο πόρο. Αυτό ακριβώς κάνει ο χειριστής.
Πώς λειτουργεί ο χειριστής; Ας ρίξουμε μια ματιά στη δεξιά πλευρά για να δούμε πώς το κάνει. Θα μάθουμε πώς ο χειριστής υλοποιεί όλα αυτά και πώς λαμβάνει χώρα περαιτέρω αλληλεπίδραση με τα K8.
Ο χειριστής είναι το πρόγραμμα. Είναι προσανατολισμένη σε εκδηλώσεις. Ο χειριστής εγγράφεται σε συμβάντα χρησιμοποιώντας το Kubernetes API. Το Kubernetes API έχει σημεία εισόδου όπου μπορείτε να εγγραφείτε σε εκδηλώσεις. Και αν αλλάξει κάτι στα K8, τότε το Kubernetes στέλνει συμβάντα σε όλους, π.χ. όσοι έχουν εγγραφεί σε αυτό το σημείο API θα λαμβάνουν ειδοποιήσεις.
Ο χειριστής εγγράφεται σε συμβάντα και πρέπει να κάνει κάποιου είδους αντίδραση. Το καθήκον του είναι να ανταποκρίνεται σε αναδυόμενα γεγονότα.
Τα συμβάντα δημιουργούνται από ορισμένες ενημερώσεις. Το αρχείο YAML έρχεται με μια περιγραφή του ClickHouseInstallation. Πήγε στο etcd μέσω kubectl application. Ένα συμβάν λειτούργησε εκεί, ως αποτέλεσμα, αυτό το συμβάν ήρθε στον χειριστή ClickHouse. Ο χειριστής έλαβε αυτήν την περιγραφή. Και κάτι πρέπει να κάνει. Εάν ήρθε μια ενημέρωση στο αντικείμενο ClickHouseInstallation, τότε πρέπει να ενημερώσετε το σύμπλεγμα. Και το καθήκον του χειριστή είναι να ενημερώσει το σύμπλεγμα.
Τι κάνει? Αρχικά, πρέπει να καταρτίσουμε ένα σχέδιο δράσης για το τι θα κάνουμε με αυτήν την ενημέρωση. Οι ενημερώσεις μπορεί να είναι πολύ μικρές, π.χ. μικρό στην εκτέλεση YAML, αλλά μπορεί να οδηγήσει σε πολύ μεγάλες αλλαγές στο σύμπλεγμα. Επομένως, ο χειριστής δημιουργεί ένα σχέδιο και στη συνέχεια το τηρεί.
Αρχίζει, σύμφωνα με αυτό το σχέδιο, να βράζει αυτή τη δομή μέσα για να υλοποιήσει λοβούς, υπηρεσίες, δηλ. να κάνει αυτό που είναι το κύριο καθήκον του. Είναι σαν να δημιουργείτε ένα σύμπλεγμα ClickHouse στο Kubernetes.
Τώρα ας αγγίξουμε ένα τόσο ενδιαφέρον πράγμα. Αυτός είναι ένας καταμερισμός ευθύνης μεταξύ της Kubernetes και του χειριστή, δηλ. τι κάνει το Kubernetes, τι κάνει ο χειριστής και πώς αλληλεπιδρούν μεταξύ τους.
Η Kubernetes είναι υπεύθυνη για τα πράγματα του συστήματος, π.χ. για ένα βασικό σύνολο αντικειμένων που μπορεί να ερμηνευθεί ως σύστημα-πεδίο. Η Kubernetes ξέρει πώς να ξεκινάει τα pods, πώς να επανεκκινεί τα κοντέινερ, πώς να κάνει προσάρτηση τόμων, πώς να λειτουργεί με το ConfigMap, π.χ. οτιδήποτε μπορεί να ονομαστεί σύστημα.
Οι χειριστές λειτουργούν σε θεματικούς τομείς. Κάθε χειριστής είναι φτιαγμένος για την θεματική του περιοχή. Φτιάξαμε για το ClickHouse.
Και ο χειριστής αλληλεπιδρά ακριβώς όσον αφορά την περιοχή θέματος, όπως η προσθήκη ενός αντιγράφου, η δημιουργία ενός σχήματος, η ρύθμιση της παρακολούθησης. Υπάρχει ένας τέτοιος διαχωρισμός.
Ας δούμε ένα πρακτικό παράδειγμα για το πώς συμβαίνει αυτός ο διαχωρισμός ανησυχιών όταν κάνουμε μια ενέργεια προσθήκης αντιγράφου.
Η εργασία έρχεται στον χειριστή - να προσθέσει ένα αντίγραφο. Τι κάνει ο χειριστής; Ο χειριστής θα υπολογίσει ότι είναι απαραίτητο να δημιουργηθεί ένα νέο StatefulSet, στο οποίο είναι απαραίτητο να περιγραφούν τέτοια ή τέτοια πρότυπα, αξίωση όγκου.
Τα ετοίμασε όλα και τα περνάει στα K8. Λέει ότι χρειάζεται ConfigMap, StatefulSet, Volume. Το Kubernetes λειτουργεί. Υλοποιεί τις βασικές μονάδες με τις οποίες λειτουργεί.
Και τότε ο ClickHouse-operator μπαίνει ξανά στο παιχνίδι. Έχει ήδη ένα φυσικό λοβό στο οποίο μπορείτε ήδη να κάνετε κάτι. Και το ClickHouse-operator λειτουργεί και πάλι από την άποψη της θεματικής περιοχής. Εκείνοι. Συγκεκριμένα, το ClickHouse, για να συμπεριλάβετε ένα αντίγραφο σε ένα σύμπλεγμα, πρέπει πρώτα να διαμορφώσετε το σχήμα δεδομένων που υπάρχει σε αυτό το σύμπλεγμα. Και, δεύτερον, αυτή η παρατήρηση πρέπει να συμπεριληφθεί στην παρακολούθηση για να μπορεί να εντοπιστεί με σαφήνεια. Ο χειριστής το έχει ήδη ρυθμίσει.
Και μόνο μετά από αυτό μπαίνει στο παιχνίδι το ίδιο το ClickHouse, δηλ. άλλη οντότητα ανώτερου επιπέδου. Αυτή είναι ήδη μια βάση δεδομένων. Έχει το δικό του παράδειγμα, το επόμενο διαμορφωμένο αντίγραφο, το οποίο είναι έτοιμο να ενταχθεί στο σύμπλεγμα.
Αποδεικνύεται ότι η αλυσίδα εκτέλεσης και ο διαχωρισμός των ευθυνών κατά την προσθήκη ενός αντιγράφου είναι αρκετά μεγάλη.
Συνεχίζουμε τις πρακτικές μας εργασίες. Εάν το σύμπλεγμα υπάρχει ήδη, τότε μπορείτε να μετεγκαταστήσετε τη διαμόρφωση.
Το κάναμε έτσι ώστε να είναι δυνατή η μετάβαση στο υπάρχον xml, το οποίο κατανοεί το ClickHouse.
Μπορείτε να ρυθμίσετε το ClickHouse. Η ανάπτυξη μόνο σε ζώνες είναι αυτό για το οποίο μίλησα όταν εξηγούσα το hostPath, τον τοπικό χώρο αποθήκευσης. Αυτός είναι ο τρόπος με τον οποίο μπορείτε να κάνετε σωστά την ανάπτυξη ζωνών.
Το επόμενο πρακτικό έργο είναι η παρακολούθηση.
Εάν το σύμπλεγμα μας αλλάξει, τότε πρέπει να διαμορφώνουμε περιοδικά την παρακολούθηση.
Ας ρίξουμε μια ματιά στο διάγραμμα. Έχουμε ήδη εξετάσει τα πράσινα βέλη εδώ. Τώρα ας δούμε τα κόκκινα βέλη. Αυτός είναι ο τρόπος με τον οποίο θέλουμε να παρακολουθούμε το σύμπλεγμα μας. Πώς οι μετρήσεις από το σύμπλεγμα ClickHouse μπαίνουν στον Προμηθέα και μετά στο Γραφάνα.
Ποιο είναι το πρόβλημα με την παρακολούθηση; Γιατί αυτό παρουσιάζεται ως κάποιου είδους επίτευγμα; Η δυσκολία βρίσκεται στη δυναμική. Όταν έχουμε ένα σύμπλεγμα και είναι στατικό, τότε μπορείτε να ρυθμίσετε την παρακολούθηση μία φορά και να μην ασχολείστε άλλο.
Αλλά αν έχουμε πολλά clusters, ή κάτι αλλάζει συνεχώς, τότε η διαδικασία είναι δυναμική. Και η συνεχής αναδιαμόρφωση της παρακολούθησης είναι σπατάλη πόρων και χρόνου. ακόμα και απλώς τεμπέλης. Αυτό πρέπει να αυτοματοποιηθεί. Η δυσκολία βρίσκεται στη δυναμική της διαδικασίας. Και ο χειριστής το αυτοματοποιεί πολύ καλά.
Πώς αναπτύχθηκε το σύμπλεγμα μας; Στην αρχή ήταν έτσι.
Τότε ήταν έτσι.
Τελικά έγινε έτσι.
Και η παρακολούθηση γίνεται αυτόματα από τον χειριστή. Ενιαίο σημείο εισόδου.
Και κοιτάμε μόνο την έξοδο στο ταμπλό της Grafana, πώς βράζει η ζωή του συμπλέγματός μας μέσα.
Παρεμπιπτόντως, ο πίνακας εργαλείων Grafana διανέμεται επίσης με τον χειριστή μας απευθείας στον πηγαίο κώδικα. Μπορείτε να συνδεθείτε και να χρησιμοποιήσετε. Αυτό το στιγμιότυπο οθόνης μου δόθηκε από τους DevOps μας.
Πού θα θέλαμε να πάμε μετά; Αυτό:
- Ανάπτυξη αυτοματισμού δοκιμών. Το κύριο καθήκον είναι η αυτοματοποιημένη δοκιμή νέων εκδόσεων.
- Θέλουμε επίσης πραγματικά να αυτοματοποιήσουμε την ενσωμάτωση με το ZooKeeper. Και υπάρχουν σχέδια για ενσωμάτωση με το ZooKeeper-operator. Εκείνοι. Ένας χειριστής έχει γραφτεί για το ZooKeeper και είναι λογικό οι δύο χειριστές να αρχίσουν να ενσωματώνονται για να δημιουργήσουν μια πιο βολική λύση.
- Θέλουμε να κάνουμε πιο σύνθετους ελέγχους ζωής.
- Τόνισα με πράσινο χρώμα ότι έχουμε κληρονομιά προτύπων καθ' οδόν - ΟΛΟΚΛΗΡΩΜΕΝΟ, δηλαδή με την επόμενη έκδοση του χειριστή, θα έχουμε ήδη κληρονομιά προτύπων. Αυτό είναι ένα ισχυρό εργαλείο που σας επιτρέπει να δημιουργήσετε σύνθετες διαμορφώσεις από κομμάτια.
- Και θέλουμε να αυτοματοποιήσουμε πολύπλοκες εργασίες. Το κύριο είναι το Re-sharding.
Ας κάνουμε μερικά ενδιάμεσα αποτελέσματα.
Τι παίρνουμε ως αποτέλεσμα; Και αξίζει ή όχι; Χρειάζεται καν να προσπαθήσω να σύρω τη βάση δεδομένων στο Kubernetes και να εφαρμόσω τον τελεστή γενικά και τον τελεστή Alitnity ειδικότερα.
Στην έξοδο παίρνουμε:
- Απλοποιήστε και αυτοματοποιήστε δραματικά τη διαμόρφωση, την ανάπτυξη και τη συντήρηση.
- Άμεση ενσωματωμένη παρακολούθηση.
- Και έτοιμα προς χρήση κωδικοποιημένα πρότυπα για περίπλοκες καταστάσεις. Ήδη η ενέργεια του τύπου για την προσθήκη αντιγράφου δεν χρειάζεται να γίνει με το χέρι. Αυτό γίνεται από τον χειριστή.
Μένει μόνο το τελευταίο ερώτημα. Έχουμε ήδη μια βάση δεδομένων στο Kubernetes, εικονικοποίηση. Τι γίνεται με την απόδοση μιας τέτοιας λύσης, ειδικά αφού το ClickHouse είναι βελτιστοποιημένο για απόδοση;
Η απάντηση είναι όλα καλά! Δεν θα περιγράψω λεπτομερώς, αυτό είναι το θέμα μιας ξεχωριστής έκθεσης.
Αλλά υπάρχει ένα τέτοιο έργο όπως το TSBS. Ποιο είναι το κύριο καθήκον του; Αυτό είναι ένα τεστ απόδοσης βάσης δεδομένων. Αυτή είναι μια προσπάθεια σύγκρισης ζεστού με ζεστό, απαλό με απαλό.
Πώς λειτουργεί; Δημιουργείται ένα σύνολο δεδομένων. Στη συνέχεια, αυτό το σύνολο δεδομένων στο ίδιο σύνολο δοκιμών εκτελείται σε διαφορετικές βάσεις δεδομένων. Και κάθε βάση δεδομένων λύνει ένα πρόβλημα με τον τρόπο που μπορεί. Και μετά μπορείτε να συγκρίνετε τα αποτελέσματα.
Υποστηρίζει ήδη μια μεγάλη δέσμη βάσεων δεδομένων. Έχω εντοπίσει τρεις βασικούς. Αυτό:
- timescaledb.
- InfluxDB.
- clickhouse.
Έγινε επίσης σύγκριση με άλλη παρόμοια λύση. Σύγκριση με το RedShift. Η σύγκριση έγινε στο Amazon. Το ClickHouse είναι επίσης πολύ μπροστά από όλους σε αυτό το θέμα.
Τι συμπεράσματα μπορούν να εξαχθούν από αυτά που είπα;
- Το DB στο Kubernetes είναι δυνατό. Πιθανώς, μπορείτε να κάνετε τα πάντα, αλλά γενικά φαίνεται ότι μπορείτε. Το ClickHouse στο Kubernetes είναι σίγουρα δυνατό με τη βοήθεια του χειριστή μας.
- Ο χειριστής βοηθά στην αυτοματοποίηση των διαδικασιών και διευκολύνει πραγματικά τη ζωή.
- Η απόδοση είναι φυσιολογική.
- Και, μας φαίνεται ότι μπορεί και πρέπει να χρησιμοποιηθεί.
Ανοιχτός κώδικας - ελάτε μαζί μας!
Όπως είπα, ο χειριστής είναι ένα προϊόν εντελώς ανοιχτού κώδικα, οπότε θα ήταν πολύ καλό να το χρησιμοποιούσε ο μέγιστος αριθμός ατόμων. Πάρε μέρος τώρα! Σας περιμένουμε όλους!
Ευχαριστώ σε όλους!
ερωτήσεις
Ευχαριστώ για την αναφορά! Το όνομά μου είναι Anton. Είμαι από το SEMrush. Αναρωτιέμαι τι συμβαίνει με την καταγραφή. Ακούμε για παρακολούθηση, αλλά τίποτα για καταγραφή, αν μιλάμε για ολόκληρο το σύμπλεγμα. Για παράδειγμα, έχουμε ένα σύμπλεγμα σε υλικό. Και χρησιμοποιούμε κεντρική καταγραφή, τη συλλέγουμε σε ένα κοινό σωρό με τυπικά μέσα. Και μετά από εκεί παίρνουμε δεδομένα που μας ενδιαφέρουν.
Καλή ερώτηση, δηλαδή σύνδεση στη λίστα εργασιών. Ο χειριστής μας δεν το αυτοματοποιεί ακόμη. Εξακολουθεί να αναπτύσσεται, το έργο είναι ακόμα αρκετά νέο. Κατανοούμε την ανάγκη για υλοτομία. Αυτό είναι επίσης ένα πολύ σημαντικό θέμα. Και μάλλον δεν είναι λιγότερο σημαντικό από την παρακολούθηση. Αλλά πρώτη στη λίστα για εφαρμογή ήταν η παρακολούθηση. Θα γίνει υλοτομία. Φυσικά, προσπαθούμε να αυτοματοποιήσουμε όλες τις πτυχές της ζωής του συμπλέγματος. Επομένως, η απάντηση είναι ότι αυτή τη στιγμή ο χειριστής, δυστυχώς, δεν ξέρει πώς να το κάνει αυτό, αλλά είναι στα σχέδια, θα το κάνουμε. Εάν θέλετε να συμμετάσχετε, κάντε αίτημα, παρακαλώ.
Γειά σου! Ευχαριστώ για την αναφορά! Έχω μια τυπική ερώτηση σχετικά με τους Persistent Volumes. Όταν δημιουργούμε μια διαμόρφωση με αυτόν τον τελεστή, πώς ο χειριστής καθορίζει σε ποιον κόμβο έχουμε κάποιο δίσκο ή φάκελο; Πρέπει πρώτα να του εξηγήσουμε ότι, παρακαλώ, τοποθετήστε το ClickHouse μας ακριβώς σε αυτούς τους κόμβους που έχουν δίσκο;
Από όσο καταλαβαίνω, αυτή η ερώτηση αποτελεί συνέχεια του τοπικού αποθηκευτικού χώρου, ειδικά του τμήματος του hostPath. Αυτό είναι σαν να εξηγούμε σε ολόκληρο το σύστημα ότι το pod πρέπει να εκκινηθεί σε αυτόν και τον άλλον κόμβο, στον οποίο έχουμε έναν φυσικά συνδεδεμένο δίσκο, ο οποίος είναι τοποθετημένος κατά μήκος της τάδε διαδρομής. Αυτή είναι μια ολόκληρη ενότητα που έθιξα πολύ επιφανειακά γιατί η απάντηση εκεί είναι αρκετά μεγάλη.
Εν συντομία, μοιάζει με αυτό. Φυσικά, πρέπει να κάνουμε προβλέψεις για αυτούς τους όγκους. Προς το παρόν, δεν υπάρχει δυναμική διάταξη στον τοπικό χώρο αποθήκευσης, επομένως τα DevOps πρέπει να κόψουν τους δίσκους μόνοι τους, ορίστε αυτοί οι τόμοι. Και πρέπει να εξηγήσουν την παροχή Kubernetes, ότι θα έχετε Persistent τόμους της συγκεκριμένης και μιας τέτοιας κατηγορίας, η οποία βρίσκεται σε τέτοιους κόμβους. Στη συνέχεια, θα είναι απαραίτητο να εξηγήσουμε στο Kubernetes ότι τα pods που απαιτούν μια τέτοια τοπική τάξη αποθήκευσης πρέπει να προγραμματίζονται σύμφωνα με ετικέτες μόνο σε τέτοιους κόμβους. Για τους σκοπούς αυτούς, ο χειριστής έχει τη δυνατότητα να εκχωρήσει κάποιο είδος ετικέτας και μία ανά παρουσία κεντρικού υπολογιστή. Και αποδεικνύεται ότι τα pods θα δρομολογούνται από την Kubernetes για να τρέχουν μόνο σε κόμβους που πληρούν τις απαιτήσεις, ετικέτες, με απλά λόγια. Οι διαχειριστές εκχωρούν ετικέτες, κάνουν την προμήθεια δίσκων με το χέρι. Και μετά κλιμακώνεται.
Και μόνο η τρίτη επιλογή τοπικό βοηθά στο να είναι λίγο πιο εύκολο. Όπως έχω ήδη τονίσει, πρόκειται για μια επίπονη εργασία συντονισμού, η οποία τελικά βοηθά στη μέγιστη απόδοση.
Έχω μια δεύτερη ερώτηση σχετικά με αυτό. Το Kubernetes σχεδιάστηκε με τέτοιο τρόπο που δεν έχει σημασία για εμάς αν θα χάσουμε έναν κόμβο ή όχι. Τι πρέπει να κάνουμε σε αυτή την περίπτωση εάν έχουμε χάσει τον κόμβο όπου κρέμεται το θραύσμα μας;
Ναι, η Kubernetes είχε αρχικά τοποθετηθεί ότι η σχέση μας με τους λοβούς μας είναι σαν τα βοοειδή, αλλά εδώ κάθε δίσκος γίνεται κάτι σαν κατοικίδιο. Υπάρχει τέτοιο πρόβλημα που δεν μπορούμε απλώς να τα πετάξουμε. Και η ανάπτυξη του Kubernetes πηγαίνει προς την κατεύθυνση που είναι αδύνατο να το αντιμετωπίσουμε εντελώς φιλοσοφικά, ως έναν εντελώς απορριπτόμενο πόρο.
Τώρα μια πρακτική ερώτηση. Τι να κάνετε εάν χάσατε τον κόμβο στον οποίο βρισκόταν ο δίσκος; Εδώ το πρόβλημα λύνεται σε υψηλότερο επίπεδο. Στην περίπτωση του ClickHouse, έχουμε αντίγραφα που λειτουργούν σε υψηλότερο επίπεδο, δηλ. σε επίπεδο ClickHouse.
Ποια είναι η διάθεση; Το DevOps είναι υπεύθυνο για τη διασφάλιση ότι τα δεδομένα δεν θα χαθούν. Πρέπει να ρυθμίσει σωστά την αναπαραγωγή και να διασφαλίσει ότι η αναπαραγωγή εκτελείται. Στο αντίγραφο σε επίπεδο ClickHouse, τα δεδομένα πρέπει να είναι διπλά. Αυτό δεν είναι το καθήκον που επιλύει ο χειριστής. Και όχι το έργο που λύνει ο ίδιος ο Kubernetes. Αυτό είναι σε επίπεδο ClickHouse.
Τι να κάνετε εάν ο σιδερένιος κόμβος σας έχει πέσει; Και αποδεικνύεται ότι θα χρειαστεί να τοποθετήσετε το δεύτερο, να μετακινήσετε σωστά το δίσκο σε αυτό, να εφαρμόσετε ετικέτες. Και μετά από αυτό, θα ικανοποιήσει τις απαιτήσεις ότι το Kubernetes σε αυτό μπορεί να εκτελέσει μια παρουσία pod. Η Kubernetes θα το λανσάρει. Ο αριθμός των ομάδων σας δεν επαρκεί για τον καθορισμένο. Θα περάσει από τον κύκλο που έδειξα. Και στο υψηλότερο επίπεδο, το ClickHouse θα καταλάβει ότι έχουμε εισαγάγει ένα αντίγραφο, είναι ακόμα κενό και πρέπει να ξεκινήσουμε τη μεταφορά δεδομένων σε αυτό. Εκείνοι. αυτή η διαδικασία εξακολουθεί να είναι ελάχιστα αυτοματοποιημένη.
Ευχαριστώ για την αναφορά! Όταν συμβαίνουν κάθε είδους άσχημα πράγματα, ο χειριστής κολλάει και επανεκκινείται, και εκείνη τη στιγμή φτάνουν τα γεγονότα, το επεξεργάζεστε με κάποιο τρόπο;
Τι θα συμβεί αν ο χειριστής κολλήσει και επανεκκινήσει, σωστά;
Ναί. Και εκείνη τη στιγμή ήρθαν τα γεγονότα.
Το καθήκον του τι πρέπει να κάνετε σε αυτήν την περίπτωση κατανέμεται εν μέρει μεταξύ του χειριστή και της Kubernetes. Το Kubernetes έχει τη δυνατότητα να επαναλαμβάνει ένα γεγονός που έχει συμβεί. Επαναλαμβάνει. Και το καθήκον του χειριστή είναι να βεβαιωθεί ότι όταν το αρχείο καταγραφής συμβάντων αναπαράχθηκε ξανά σε αυτό, αυτά τα συμβάντα είναι ανίκανα. Και για να μην μας σπάσει το σύστημά μας η επανάληψη του ίδιου γεγονότος. Και ο χειριστής μας αντιμετωπίζει αυτό το έργο.
Γειά σου! Ευχαριστώ για την αναφορά! Ντμίτρι Ζαβιάλοφ, εταιρεία Smedov. Σχεδιάζεται η προσθήκη επιλογών προσαρμογής με χαπροξί στον χειριστή; Κάποιος άλλος εξισορροπητής είναι ενδιαφέρον εκτός από τον τυπικό, έτσι ώστε να είναι έξυπνος και να καταλαβαίνει ότι το ClickHouse είναι πραγματικό εκεί.
Μιλάς για Ingress;
Ναι, αντικαταστήστε το Ingress με απροσεξία. Σε χαπροξία, μπορείτε να καθορίσετε την τοπολογία συμπλέγματος όπου έχει αντίγραφα.
Μέχρι στιγμής, δεν το έχουμε σκεφτεί. Εάν το χρειάζεστε και μπορείτε να εξηγήσετε γιατί είναι απαραίτητο, τότε θα είναι δυνατό να το εφαρμόσετε, ειδικά εάν θέλετε να συμμετάσχετε. Θα χαρούμε να εξετάσουμε την επιλογή. Η σύντομη απάντηση είναι όχι, αυτή τη στιγμή δεν έχουμε τέτοια λειτουργικότητα. Ευχαριστώ για την συμβουλή, θα ρίξουμε μια ματιά σε αυτό. Και αν εξηγήσετε επίσης την περίπτωση χρήσης και γιατί είναι απαραίτητο στην πράξη, για παράδειγμα, να δημιουργήσετε προβλήματα στο GitHub, τότε θα είναι υπέροχο.
Εχει ήδη.
Πρόστιμο. Είμαστε ανοιχτοί σε οποιεσδήποτε προτάσεις. Και η χαπροξία μπαίνει στη λίστα εργασιών. Η λίστα εργασιών αυξάνεται, δεν συρρικνώνεται ακόμη. Αλλά αυτό είναι καλό, σημαίνει ότι το προϊόν είναι σε ζήτηση.
Πηγή: www.habr.com