Είναι καλός ο Kafka στο Kubernetes;

Χαιρετισμούς, Χαμπρ!

Κάποτε ήμασταν οι πρώτοι που εισαγάγαμε το θέμα στη ρωσική αγορά Κάφκα και συνεχίστε ακολουθήστε για την ανάπτυξή του. Συγκεκριμένα, βρήκαμε το θέμα της αλληλεπίδρασης μεταξύ του Κάφκα και Kubernetes. Παρατηρήσιμο (και αρκετά προσεκτικό) άρθρο αυτό το θέμα δημοσιεύτηκε στο ιστολόγιο Confluent τον περασμένο Οκτώβριο υπό τη συγγραφή της Gwen Shapira. Σήμερα θα θέλαμε να επιστήσουμε την προσοχή σας σε ένα πιο πρόσφατο άρθρο από τον Απρίλιο του Johann Gyger, ο οποίος, αν και όχι χωρίς ερωτηματικό στον τίτλο, εξετάζει το θέμα με πιο ουσιαστικό τρόπο, συνοδεύοντας το κείμενο με ενδιαφέροντες συνδέσμους. Συγχωρέστε μας τη δωρεάν μετάφραση του «chaos monkey» αν μπορείτε!

Εισαγωγή

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

Ο Κάφκα, από την άλλη, ουσιαστικά λειτουργεί ως κατανεμημένη βάση δεδομένων. Έτσι, όταν εργάζεστε, πρέπει να έχετε να κάνετε με το κράτος, και είναι πολύ πιο βαρύ από μια microservice. Το Kubernetes υποστηρίζει φόρτωση κατάστασης, αλλά όπως επισημαίνει η Kelsey Hightower σε δύο tweets, θα πρέπει να αντιμετωπίζονται με προσοχή:

Μερικοί άνθρωποι πιστεύουν ότι εάν βάλετε το Kubernetes σε έναν κρατικό φόρτο εργασίας, γίνεται μια πλήρως διαχειριζόμενη βάση δεδομένων που ανταγωνίζεται το RDS. Αυτό είναι λάθος. Ίσως, εάν δουλέψετε αρκετά σκληρά, προσθέσετε επιπλέον στοιχεία και προσελκύσετε μια ομάδα μηχανικών SRE, θα μπορέσετε να δημιουργήσετε RDS πάνω από το Kubernetes.

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

Λοιπόν, πρέπει να τρέχετε τον Kafka στο Kubernetes; Αντίθετη ερώτηση: θα λειτουργήσει καλύτερα ο Κάφκα χωρίς τον Kubernetes; Γι' αυτό θέλω να επισημάνω σε αυτό το άρθρο πώς ο Κάφκα και ο Kubernetes αλληλοσυμπληρώνονται και ποιες παγίδες μπορεί να προκύψουν με τον συνδυασμό τους.

Χρόνος ολοκλήρωσης

Ας μιλήσουμε για το βασικό πράγμα - το ίδιο το περιβάλλον χρόνου εκτέλεσης

διαδικασία

Οι μεσίτες Kafka είναι φιλικοί προς τη CPU. Το TLS μπορεί να εισάγει κάποια γενικά έξοδα. Ωστόσο, οι πελάτες Kafka μπορεί να έχουν μεγαλύτερη ένταση CPU εάν χρησιμοποιούν κρυπτογράφηση, αλλά αυτό δεν επηρεάζει τους μεσίτες.

Μνήμη

Οι μεσίτες του Κάφκα τρώνε τη μνήμη. Το μέγεθος σωρού JVM περιορίζεται συνήθως στα 4-5 GB, αλλά θα χρειαστείτε επίσης πολλή μνήμη συστήματος, καθώς ο Kafka χρησιμοποιεί πολύ την προσωρινή μνήμη σελίδας. Στο Kubernetes, ορίστε πόρους κοντέινερ και ζητήστε ανάλογα όρια.

Αποθήκευση δεδομένων

Η αποθήκευση δεδομένων σε κοντέινερ είναι εφήμερη - τα δεδομένα χάνονται κατά την επανεκκίνηση. Για δεδομένα Kafka μπορείτε να χρησιμοποιήσετε έναν τόμο emptyDir, και το αποτέλεσμα θα είναι παρόμοιο: τα δεδομένα του μεσίτη σας θα χαθούν μετά την ολοκλήρωση. Τα μηνύματά σας μπορούν ακόμα να αποθηκευτούν σε άλλους μεσίτες ως αντίγραφα. Επομένως, μετά από επανεκκίνηση, ο μεσίτης που απέτυχε πρέπει πρώτα να αναπαράγει όλα τα δεδομένα και αυτή η διαδικασία μπορεί να διαρκέσει πολύ χρόνο.

Αυτός είναι ο λόγος για τον οποίο θα πρέπει να χρησιμοποιείτε μακροπρόθεσμη αποθήκευση δεδομένων. Ας είναι μη τοπική μακροχρόνια αποθήκευση με το σύστημα αρχείων XFS ή, ακριβέστερα, ext4. Μην χρησιμοποιείτε το NFS. Σε προειδοποίησα. Οι εκδόσεις NFS v3 ή v4 δεν θα λειτουργήσουν. Εν ολίγοις, ο μεσίτης Kafka θα καταρρεύσει εάν δεν μπορεί να διαγράψει τον κατάλογο δεδομένων λόγω του προβλήματος "ανόητης μετονομασίας" στο NFS. Αν δεν σας έπεισα ακόμα, πολύ προσεκτικά διαβάστε αυτό το άρθρο. Ο χώρος αποθήκευσης δεδομένων θα πρέπει να είναι μη τοπικός, ώστε το Kubernetes να μπορεί να επιλέξει πιο ευέλικτα έναν νέο κόμβο μετά από επανεκκίνηση ή μετεγκατάσταση.

Δικτύου

Όπως συμβαίνει με τα περισσότερα κατανεμημένα συστήματα, η απόδοση του Kafka εξαρτάται σε μεγάλο βαθμό από τη διατήρηση της καθυστέρησης δικτύου στο ελάχιστο και του εύρους ζώνης στο μέγιστο. Μην προσπαθήσετε να φιλοξενήσετε όλους τους μεσίτες στον ίδιο κόμβο, καθώς αυτό θα μειώσει τη διαθεσιμότητα. Εάν ένας κόμβος Kubernetes αποτύχει, ολόκληρο το σύμπλεγμα Kafka θα αποτύχει. Επίσης, μην διασκορπίζετε το σύμπλεγμα Kafka σε ολόκληρα κέντρα δεδομένων. Το ίδιο ισχύει και για το σύμπλεγμα Kubernetes. Ένας καλός συμβιβασμός σε αυτή την περίπτωση είναι να επιλέξετε διαφορετικές ζώνες διαθεσιμότητας.

Διαμόρφωση

Τακτικά μανιφέστα

Ο ιστότοπος Kubernetes έχει πολύ καλός οδηγός σχετικά με τον τρόπο ρύθμισης παραμέτρων του ZooKeeper χρησιμοποιώντας δηλώσεις. Δεδομένου ότι το ZooKeeper είναι μέρος του Kafka, αυτό είναι ένα καλό μέρος για να ξεκινήσετε να εξοικειωθείτε με τις έννοιες του Kubernetes που ισχύουν εδώ. Μόλις το καταλάβετε, μπορείτε να χρησιμοποιήσετε τις ίδιες έννοιες με ένα σύμπλεγμα Κάφκα.

• Κάτω από: Το pod είναι η μικρότερη μονάδα ανάπτυξης στο Kubernetes. Ένα pod περιέχει τον φόρτο εργασίας σας και το ίδιο το pod αντιστοιχεί σε μια διαδικασία στο σύμπλεγμα σας. Ένας λοβός περιέχει ένα ή περισσότερα δοχεία. Κάθε διακομιστής ZooKeeper στο σύνολο και κάθε μεσίτης στο σύμπλεγμα Kafka θα εκτελούνται σε ξεχωριστό pod.
• StatefulSet: Ένα StatefulSet είναι ένα αντικείμενο Kubernetes που χειρίζεται πολλαπλούς φόρτους εργασίας με κατάσταση κατάστασης και τέτοιοι φόρτοι εργασίας απαιτούν συντονισμό. Τα StatefulSets παρέχουν εγγυήσεις σχετικά με την παραγγελία των pod και τη μοναδικότητά τους.
• Ακέφαλες υπηρεσίες: Οι υπηρεσίες σάς επιτρέπουν να αποσυνδέετε τα pods από πελάτες χρησιμοποιώντας ένα λογικό όνομα. Η Kubernetes σε αυτή την περίπτωση είναι υπεύθυνη για την εξισορρόπηση φορτίου. Ωστόσο, όταν χειρίζονται φόρτους εργασίας με κατάσταση κατάστασης, όπως το ZooKeeper και το Kafka, οι πελάτες πρέπει να επικοινωνούν με μια συγκεκριμένη παρουσία. Εδώ είναι χρήσιμες οι υπηρεσίες χωρίς κεφάλι: σε αυτήν την περίπτωση, ο πελάτης θα εξακολουθεί να έχει ένα λογικό όνομα, αλλά δεν θα χρειαστεί να επικοινωνήσετε απευθείας με το pod.
• Μακροπρόθεσμος όγκος αποθήκευσης: Αυτοί οι τόμοι απαιτούνται για τη διαμόρφωση της μη τοπικής μόνιμης αποθήκευσης που αναφέρεται παραπάνω.

Επί Yolean Παρέχει ένα ολοκληρωμένο σύνολο εκδηλώσεων για να σας βοηθήσει να ξεκινήσετε με τον Κάφκα στο Kubernetes.

Διαγράμματα τιμόνι

Το Helm είναι ένας διαχειριστής πακέτων για ένα Kubernetes που μπορεί να συγκριθεί με διαχειριστές πακέτων λειτουργικού συστήματος όπως yum, apt, Homebrew ή Chocolatey. Διευκολύνει την εγκατάσταση προκαθορισμένων πακέτων λογισμικού που περιγράφονται στα διαγράμματα Helm. Ένα καλά επιλεγμένο γράφημα Helm καθιστά εύκολο το δύσκολο έργο του πώς να ρυθμίσετε σωστά όλες τις παραμέτρους για τη χρήση του Kafka στο Kubernetes. Υπάρχουν πολλά διαγράμματα Κάφκα: βρίσκεται το επίσημο σε κατάσταση θερμοκοιτίδας, υπάρχει ένα από Διασταύρωση, ένα ακόμη - από Bitnami.

Χειριστές

Επειδή το Helm έχει ορισμένες ελλείψεις, ένα άλλο εργαλείο κερδίζει μεγάλη δημοτικότητα: οι χειριστές Kubernetes. Ο χειριστής όχι μόνο συσκευάζει λογισμικό για το Kubernetes, αλλά σας επιτρέπει επίσης να αναπτύξετε τέτοιο λογισμικό και να το διαχειριστείτε.

Στη λίστα καταπληκτικοί χειριστές Αναφέρονται δύο χειριστές για τον Κάφκα. Ενας από αυτούς - Στρίμζη. Με το Strimzi, είναι εύκολο να θέσετε σε λειτουργία το σύμπλεγμα Kafka μέσα σε λίγα λεπτά. Ουσιαστικά δεν απαιτείται διαμόρφωση, επιπλέον, ο ίδιος ο χειριστής παρέχει μερικές ωραίες δυνατότητες, για παράδειγμα, κρυπτογράφηση TLS από σημείο σε σημείο εντός του συμπλέγματος. Το Confluent παρέχει επίσης δικός χειριστής.

Παραγωγικότητα

Είναι σημαντικό να δοκιμάζετε την απόδοση κάνοντας συγκριτική αξιολόγηση της παρουσίας Kafka. Τέτοιες δοκιμές θα σας βοηθήσουν να βρείτε πιθανά σημεία συμφόρησης πριν προκύψουν προβλήματα. Ευτυχώς, ο Kafka παρέχει ήδη δύο εργαλεία δοκιμής απόδοσης: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Αξιοποιήστε τα ενεργά. Για αναφορά, μπορείτε να ανατρέξετε στα αποτελέσματα που περιγράφονται στο αυτή η ανάρτηση Jay Kreps, ή επικεντρωθείτε σε αυτή η κριτική Amazon MSK από τον Stéphane Maarek.

Λειτουργίες

Παρακολούθηση

Η διαφάνεια στο σύστημα είναι πολύ σημαντική - διαφορετικά δεν θα καταλάβετε τι συμβαίνει σε αυτό. Σήμερα υπάρχει μια σταθερή εργαλειοθήκη που παρέχει παρακολούθηση βάσει μετρήσεων στο εγγενές στυλ cloud. Δύο δημοφιλή εργαλεία για το σκοπό αυτό είναι ο Προμηθέας και η Γραφάνα. Ο Prometheus μπορεί να συλλέξει μετρήσεις από όλες τις διαδικασίες Java (Kafka, Zookeeper, Kafka Connect) χρησιμοποιώντας έναν εξαγωγέα JMX - με τον απλούστερο τρόπο. Εάν προσθέσετε μετρήσεις cAdvisor, μπορείτε να κατανοήσετε πληρέστερα πώς χρησιμοποιούνται οι πόροι στο Kubernetes.

Το Strimzi έχει ένα πολύ βολικό παράδειγμα ταμπλό Grafana για τον Kafka. Οπτικοποιεί βασικές μετρήσεις, για παράδειγμα, σχετικά με τομείς που δεν αναπαράγονται ελάχιστα ή εκείνους που είναι εκτός σύνδεσης. Όλα είναι πολύ ξεκάθαρα εκεί. Αυτές οι μετρήσεις συμπληρώνονται από πληροφορίες σχετικά με τη χρήση πόρων και την απόδοση, καθώς και από δείκτες σταθερότητας. Έτσι, έχετε τη βασική παρακολούθηση συστάδων Kafka χωρίς τίποτα!

Πηγή: streamzi.io/docs/master/#kafka_dashboard

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

Ξύλευση

Η καταγραφή είναι μια άλλη κρίσιμη εργασία. Βεβαιωθείτε ότι όλα τα κοντέινερ στην εγκατάσταση του Kafka είναι συνδεδεμένα stdout и stderr, και επίσης βεβαιωθείτε ότι το σύμπλεγμα Kubernetes συγκεντρώνει όλα τα αρχεία καταγραφής σε μια κεντρική υποδομή καταγραφής, π.χ. Ελαστική αναζήτηση.

Λειτουργική δοκιμή

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

Κυκλοφορεί ενημερώσεις

Το StatefulSets υποστηρίζει αυτόματες ενημερώσεις: εάν επιλέξετε τη στρατηγική RollingUpdate, καθεμία κάτω από το Kafka θα ενημερωθεί με τη σειρά. Με αυτόν τον τρόπο, ο χρόνος διακοπής λειτουργίας μπορεί να μειωθεί στο μηδέν.

Κλιμάκωση

Η κλιμάκωση ενός συμπλέγματος Κάφκα δεν είναι εύκολη υπόθεση. Ωστόσο, το Kubernetes καθιστά πολύ εύκολη την κλιμάκωση των pods σε έναν συγκεκριμένο αριθμό αντιγράφων, πράγμα που σημαίνει ότι μπορείτε να ορίσετε δηλωτικά όσους μεσίτες Kafka θέλετε. Το πιο δύσκολο πράγμα σε αυτήν την περίπτωση είναι η εκ νέου αντιστοίχιση τομέων μετά την κλιμάκωση ή πριν από τη μείωση της κλίμακας. Και πάλι, το Kubernetes θα σας βοηθήσει με αυτό το έργο.

διαχείριση

Εργασίες που σχετίζονται με τη διαχείριση του συμπλέγματος Kafka, όπως η δημιουργία θεμάτων και η εκ νέου αντιστοίχιση τομέων, μπορούν να γίνουν χρησιμοποιώντας υπάρχοντα σενάρια φλοιού ανοίγοντας τη διεπαφή της γραμμής εντολών στα pod σας. Ωστόσο, αυτή η λύση δεν είναι πολύ όμορφη. Το Strimzi υποστηρίζει τη διαχείριση θεμάτων χρησιμοποιώντας διαφορετικό τελεστή. Υπάρχει κάποιο περιθώριο βελτίωσης εδώ.

Δημιουργία αντιγράφων ασφαλείας και ανάκτηση

Τώρα η διαθεσιμότητα του Kafka θα εξαρτηθεί και από τη διαθεσιμότητα του Kubernetes. Εάν το σύμπλεγμα Kubernetes σας αποτύχει, τότε στο χειρότερο σενάριο, το σύμπλεγμα Kafka θα αποτύχει επίσης. Σύμφωνα με το νόμο του Murphy, αυτό θα συμβεί σίγουρα και θα χάσετε δεδομένα. Για να μειώσετε αυτόν τον τύπο κινδύνου, έχετε μια καλή ιδέα δημιουργίας αντιγράφων ασφαλείας. Μπορείτε να χρησιμοποιήσετε το MirrorMaker, μια άλλη επιλογή είναι να χρησιμοποιήσετε το S3 για αυτό, όπως περιγράφεται σε αυτό Θέση από το Zalando.

Συμπέρασμα

Όταν εργάζεστε με μικρού έως μεσαίου μεγέθους συμπλέγματα Kafka, σίγουρα αξίζει να χρησιμοποιείτε το Kubernetes, καθώς παρέχει πρόσθετη ευελιξία και απλοποιεί την εμπειρία χειριστή. Εάν έχετε πολύ σημαντικές μη λειτουργικές απαιτήσεις καθυστέρησης και/ή απόδοσης, τότε ίσως είναι καλύτερο να εξετάσετε κάποια άλλη επιλογή ανάπτυξης.

Πηγή: www.habr.com