Γεια σου Χαμπρ!
Θυμίζουμε ότι έχουμε κυκλοφορήσει άλλο ένα εξαιρετικά ενδιαφέρον και χρήσιμο άρθρο σχετικά με τα μοτίβα Kubernetes. Όλα ξεκίνησαν με το "«Ο Μπρένταν Μπερνς, και παρεμπιπτόντως, έχουμε δουλειά σε αυτό το τμήμα . Σήμερα σας προσκαλούμε να διαβάσετε ένα άρθρο από το ιστολόγιο MinIO που περιγράφει συνοπτικά τις τάσεις και τις ιδιαιτερότητες των μοτίβων αποθήκευσης δεδομένων στο Kubernetes.
Το Kubernetes έχει αλλάξει ριζικά τα παραδοσιακά πρότυπα ανάπτυξης και ανάπτυξης εφαρμογών. Τώρα μια ομάδα μπορεί να αναπτύξει, να δοκιμάσει και να αναπτύξει μια εφαρμογή μέσα σε λίγες μέρες—σε πολλά περιβάλλοντα, όλα μέσα σε συμπλέγματα Kubernetes. Με τις προηγούμενες γενιές τεχνολογίας, αυτό το είδος εργασίας συνήθως θα διαρκούσε εβδομάδες, αν όχι μήνες.
Αυτή η επιτάχυνση καθίσταται δυνατή από την αφαίρεση που παρέχει το Kubernetes—δηλαδή από το γεγονός ότι το ίδιο το Kubernetes χειρίζεται τις λεπτομέρειες χαμηλού επιπέδου φυσικών ή εικονικών μηχανών, επιτρέποντας στους χρήστες να δηλώσουν, μεταξύ άλλων παραμέτρων, τον επιθυμητό επεξεργαστή, την επιθυμητή ποσότητα μνήμης, τον αριθμό των περιπτώσεων κοντέινερ. Με μια τεράστια κοινότητα που υποστηρίζει το Kubernetes και την υιοθέτησή του να επεκτείνεται συνεχώς, το Kubernetes είναι μακράν ο ηγέτης μεταξύ των πλατφορμών ενορχήστρωσης κοντέινερ.
Καθώς αυξάνεται η υιοθέτηση του Kubernetes, αυξάνεται και η σύγχυση σχετικά με τα μοτίβα αποθήκευσης..
Καθώς όλοι ανταγωνίζονται για ένα κομμάτι της πίτας Kubernetes (δηλαδή αποθήκευση δεδομένων), όταν πρόκειται για αποθήκευση δεδομένων, το σήμα πνίγεται από πολύ θόρυβο.
Το Kubernetes είναι ένα σύγχρονο μοντέλο για την ανάπτυξη, την ανάπτυξη και τη διαχείριση εφαρμογών. Αυτό το σύγχρονο μοντέλο αποσυνδέει την αποθήκευση δεδομένων από τον υπολογισμό. Για να κατανοήσετε πλήρως αυτήν την αποσύνδεση στο πλαίσιο του Kubernetes, πρέπει επίσης να κατανοήσετε τι είναι οι κρατικές και χωρίς κράτος εφαρμογές και πώς εντάσσεται η αποθήκευση δεδομένων σε αυτό. Εδώ η προσέγγιση REST API που χρησιμοποιείται από το S3 έχει σαφή πλεονεκτήματα σε σχέση με την προσέγγιση POSIX/CSI που είναι τυπική για άλλες λύσεις.
Σε αυτό το άρθρο, θα μιλήσουμε για τα μοτίβα αποθήκευσης στο Kubernetes και θα αγγίξουμε συγκεκριμένα τη συζήτηση για την εφαρμογή ανιθαγενών/κρατικών για να καταλάβουμε πραγματικά ποια είναι η διαφορά και γιατί έχει σημασία. Το υπόλοιπο κείμενο θα εξετάσει τις εφαρμογές και τα μοτίβα αποθήκευσης δεδομένων που χρησιμοποιούν υπό το φως των βέλτιστων πρακτικών για την εργασία με κοντέινερ και Kubernetes.
Εμπορευματοκιβώτια χωρίς ιθαγένεια
Τα δοχεία είναι από τη φύση τους ελαφριά και εφήμερα. Μπορούν εύκολα να σταματήσουν, να διαγραφούν ή να αναπτυχθούν σε άλλο κόμβο – όλα αυτά μέσα σε λίγα δευτερόλεπτα. Σε ένα μεγάλο σύστημα ενορχήστρωσης κοντέινερ, τέτοιες λειτουργίες συμβαίνουν συνεχώς και οι χρήστες δεν παρατηρούν καν τέτοιες αλλαγές. Ωστόσο, οι μετακινήσεις είναι δυνατές μόνο εάν το κοντέινερ δεν έχει εξαρτήσεις από τον κόμβο στον οποίο βρίσκεται. Αυτά τα δοχεία λέγεται ότι λειτουργούν. ανιθαγενης.
Stateful Containers
Εάν ένα κοντέινερ αποθηκεύει δεδομένα σε τοπικά συνδεδεμένες συσκευές (ή σε συσκευή μπλοκ), η αποθήκευση δεδομένων στην οποία βρίσκεται θα πρέπει να μετακινηθεί σε έναν νέο κόμβο μαζί με το ίδιο το κοντέινερ σε περίπτωση αποτυχίας. Αυτό είναι σημαντικό γιατί διαφορετικά η εφαρμογή που εκτελείται στο κοντέινερ δεν θα μπορεί να λειτουργήσει σωστά, καθώς χρειάζεται πρόσβαση στα δεδομένα που είναι αποθηκευμένα στην τοπική αποθήκευση. Αυτά τα δοχεία λέγεται ότι λειτουργούν. κρατική.
Από καθαρά τεχνική άποψη, τα κοντέινερ με κατάσταση κατάστασης μπορούν επίσης να μετακινηθούν σε άλλους κόμβους. Αυτό επιτυγχάνεται συνήθως μέσω κατανεμημένων συστημάτων αρχείων ή μπλοκ αποθήκευσης δικτύου που συνδέεται σε όλους τους κόμβους που εκτελούν κοντέινερ. Με αυτόν τον τρόπο, τα κοντέινερ έχουν πρόσβαση σε τόμους για μόνιμη αποθήκευση δεδομένων και οι πληροφορίες αποθηκεύονται σε δίσκους που βρίσκονται σε όλο το δίκτυο. Θα ονομάσω αυτή τη μέθοδο "κρατική προσέγγιση κοντέινερ», και στο υπόλοιπο άρθρο θα το αναφέρω ως τέτοιο για λόγους συνέπειας.
Σε μια τυπική προσέγγιση κοντέινερ με κατάσταση κατάστασης, όλες οι ομάδες εφαρμογών συνδέονται σε ένα ενιαίο κατανεμημένο σύστημα αρχείων, δημιουργώντας ένα είδος κοινόχρηστου χώρου αποθήκευσης όπου βρίσκονται όλα τα δεδομένα της εφαρμογής. Ενώ είναι δυνατές ορισμένες παραλλαγές, αυτή είναι μια προσέγγιση υψηλού επιπέδου.
Τώρα, ας δούμε γιατί η προσέγγιση του stateful container είναι ένα αντί-μοτίβο σε έναν εγγενή κόσμο του cloud.
Σχεδίαση εφαρμογών με επίκεντρο το σύννεφο
Παραδοσιακά, οι εφαρμογές χρησιμοποιούν βάσεις δεδομένων για την αποθήκευση πληροφοριών με δομημένο τρόπο και τοπικούς δίσκους ή κατανεμημένα συστήματα αρχείων για την απόρριψη όλων των μη δομημένων ή ακόμη και ημιδομημένων δεδομένων. Καθώς ο όγκος των μη δομημένων δεδομένων μεγάλωνε, οι προγραμματιστές συνειδητοποίησαν ότι το POSIX ήταν πολύ φλύαρο, είχε σημαντικά έξοδα και τελικά εμπόδιζε την απόδοση της εφαρμογής όταν κλιμακώθηκε σε πραγματικά μεγάλες κλίμακες.
Αυτό είναι που συνέβαλε κυρίως στην εμφάνιση ενός νέου προτύπου αποθήκευσης δεδομένων, δηλαδή της αποθήκευσης προσανατολισμένης στο cloud, που λειτουργεί κυρίως με βάση το REST API και απαλλάσσει την εφαρμογή από την επαχθή συντήρηση της τοπικής αποθήκευσης δεδομένων. Σε αυτήν την περίπτωση, η εφαρμογή μεταβαίνει ουσιαστικά σε κατάσταση χωρίς κατάσταση (αφού η κατάσταση βρίσκεται σε απομακρυσμένη αποθήκευση). Οι σύγχρονες εφαρμογές κατασκευάζονται από την αρχή λαμβάνοντας υπόψη αυτόν τον παράγοντα. Κατά κανόνα, κάθε σύγχρονη εφαρμογή που επεξεργάζεται δεδομένα του ενός ή του άλλου είδους (logs, metadata, blobs, κ.λπ.) βασίζεται σε ένα παράδειγμα προσανατολισμένο στο cloud, όπου η κατάσταση μεταφέρεται σε ένα σύστημα λογισμικού που έχει διατεθεί ειδικά για την αποθήκευσή του.
Η κρατική προσέγγιση κοντέινερ αναγκάζει ολόκληρο αυτό το παράδειγμα να επιστρέψει ακριβώς από εκεί που ξεκίνησε!
Χρησιμοποιώντας τις διεπαφές POSIX για την αποθήκευση δεδομένων, οι εφαρμογές συμπεριφέρονται σαν να είχαν κατάσταση κατάστασης, και έτσι εγκαταλείπουν τις πιο σημαντικές αρχές της εγγενούς σχεδίασης στο cloud, όπως η δυνατότητα να αλλάζει το μέγεθος των νημάτων εργασίας μιας εφαρμογής ανάλογα με το εισερχόμενο φορτίο, να μετακινείται σε νέο κόμβο μόλις αποτύχει ο τρέχων κόμβος κ.λπ.
Εξετάζοντας αυτή την κατάσταση πιο προσεκτικά, διαπιστώνουμε ότι βρισκόμαστε ξανά αντιμέτωποι με το δίλημμα POSIX εναντίον REST API κατά την επιλογή ενός χώρου αποθήκευσης δεδομένων, ΑΛΛΑ με την πρόσθετη όξυνση των προβλημάτων POSIX λόγω της κατανεμημένης φύσης των περιβαλλόντων Kubernetes. Προπαντός,
- Το POSIX είναι φλύαρο: Η σημασιολογία POSIX απαιτεί κάθε λειτουργία να συσχετίζεται με μεταδεδομένα και περιγραφείς αρχείων που βοηθούν στη διατήρηση της κατάστασης της λειτουργίας. Αυτό έχει ως αποτέλεσμα σημαντικά κόστη που δεν έχουν πραγματική αξία. Τα API αποθήκευσης αντικειμένων, ιδιαίτερα το S3 API, έχουν απαλλαγεί από αυτές τις απαιτήσεις, επιτρέποντας σε μια εφαρμογή να καλεί και στη συνέχεια να "ξεχνάει" την κλήση. Η απόκριση από το σύστημα αποθήκευσης υποδεικνύει εάν η ενέργεια ήταν επιτυχής ή όχι. Εάν δεν είναι επιτυχής, η εφαρμογή μπορεί να προσπαθήσει ξανά.
- Περιορισμοί δικτύου: Σε ένα κατανεμημένο σύστημα, υπονοείται ότι μπορεί να υπάρχουν πολλές εφαρμογές που επιχειρούν να εγγράψουν δεδομένα στο ίδιο συνδεδεμένο μέσο αποθήκευσης. Έτσι, όχι μόνο οι εφαρμογές θα ανταγωνίζονται μεταξύ τους για εύρος ζώνης (για αποστολή δεδομένων στα μέσα αποθήκευσης), αλλά και το ίδιο το σύστημα αποθήκευσης θα ανταγωνίζεται για αυτό το εύρος ζώνης στέλνοντας δεδομένα σε φυσικούς δίσκους. Λόγω της ομιλητικότητας του POSIX, ο αριθμός των κλήσεων δικτύου αυξάνεται αρκετές φορές. Από την άλλη πλευρά, το S3 API παρέχει μια σαφή διάκριση μεταξύ των κλήσεων δικτύου μεταξύ εκείνων που προέρχονται από τον πελάτη προς τον διακομιστή και εκείνων που πραγματοποιούνται εντός του διακομιστή.
- Ασφάλεια: Το μοντέλο ασφαλείας POSIX έχει σχεδιαστεί για ενεργή ανθρώπινη συμμετοχή: οι διαχειριστές διαμορφώνουν συγκεκριμένα επίπεδα πρόσβασης για κάθε χρήστη ή ομάδα. Αυτό το παράδειγμα είναι δύσκολο να προσαρμοστεί σε έναν κόσμο που επικεντρώνεται στο σύννεφο. Οι σύγχρονες εφαρμογές εξαρτώνται από μοντέλα ασφαλείας που βασίζονται σε API, όπου τα δικαιώματα πρόσβασης ορίζονται ως ένα σύνολο πολιτικών, λογαριασμών υπηρεσιών, προσωρινών διαπιστευτηρίων κ.λπ.
- Δυνατότητα διαχείρισης: Τα κρατικά εμπορευματοκιβώτια έρχονται με κάποια γενικά έξοδα διαχείρισης. Μιλάμε για συγχρονισμό της παράλληλης πρόσβασης στα δεδομένα, για τη διασφάλιση της συνέπειας των δεδομένων, όλα αυτά απαιτούν προσεκτική εξέταση του ποια πρότυπα πρόσβασης δεδομένων θα χρησιμοποιηθούν. Υπάρχουν πρόσθετα προγράμματα για εγκατάσταση, διαχείριση και διαμόρφωση, για να μην αναφέρουμε την πρόσθετη προσπάθεια ανάπτυξης.
Διεπαφή αποθήκευσης δεδομένων κοντέινερ
Ενώ η διεπαφή αποθήκευσης κοντέινερ (CSI) έχει κάνει εξαιρετική δουλειά βοηθώντας στην εξάπλωση του επιπέδου όγκου Kubernetes, εν μέρει παραδίδοντάς το σε τρίτους προμηθευτές αποθήκευσης, συνέβαλε επίσης ακούσια στην πεποίθηση ότι μια προσέγγιση κοντέινερ με κατάσταση κατάστασης είναι η προτεινόμενη μέθοδος αποθήκευσης δεδομένων στο Kubernetes.
Το CSI αναπτύχθηκε ως πρότυπο για την παροχή αυθαίρετων συστημάτων αποθήκευσης μπλοκ και αρχείων σε εφαρμογές παλαιού τύπου που εκτελούνται στο Kubernetes. Και όπως έδειξε αυτό το άρθρο, η μόνη κατάσταση όπου μια προσέγγιση κοντέινερ με κατάσταση κατάστασης (και το CSI στην τρέχουσα μορφή του) έχει νόημα είναι όταν η ίδια η εφαρμογή είναι ένα παλαιού τύπου σύστημα όπου δεν είναι δυνατή η προσθήκη υποστήριξης για ένα API αποθήκευσης δεδομένων αντικειμένων.
Είναι σημαντικό να κατανοήσουμε ότι χρησιμοποιώντας το CSI στην τρέχουσα μορφή του, δηλαδή την τοποθέτηση τόμων κατά την εργασία με σύγχρονες εφαρμογές, θα συναντήσουμε περίπου τα ίδια προβλήματα που προέκυψαν σε συστήματα όπου η αποθήκευση δεδομένων είναι οργανωμένη σε στυλ POSIX.
Μια πιο ποιοτική προσέγγιση
Σε αυτήν την περίπτωση, είναι σημαντικό να κατανοήσουμε ότι οι περισσότερες εφαρμογές δεν έχουν σχεδιαστεί για να λειτουργούν με ή χωρίς κατάσταση. Αυτή η συμπεριφορά εξαρτάται από τη συνολική αρχιτεκτονική του συστήματος και από τις συγκεκριμένες επιλογές που επιλέγονται κατά τη διάρκεια του σχεδιασμού. Ας μιλήσουμε λίγο για κρατικές εφαρμογές.
Κατ 'αρχήν, όλα τα δεδομένα εφαρμογής μπορούν να χωριστούν σε διάφορους γενικούς τύπους:
- Δεδομένα καταγραφής
- Δεδομένα χρονικής σήμανσης
- Στοιχεία συναλλαγών
- Μεταδεδομένα
- Εικόνες κοντέινερ
- Δεδομένα Blob (δυαδικά μεγάλα αντικείμενα)
Όλοι αυτοί οι τύποι δεδομένων υποστηρίζονται πολύ καλά σε σύγχρονες πλατφόρμες αποθήκευσης δεδομένων και υπάρχουν αρκετές πλατφόρμες εγγενείς στο cloud που έχουν σχεδιαστεί για να παρέχουν δεδομένα σε καθεμία από αυτές τις συγκεκριμένες μορφές. Για παράδειγμα, τα δεδομένα συναλλαγών και τα μεταδεδομένα μπορούν να βρίσκονται σε μια σύγχρονη βάση δεδομένων που είναι εγγενής στο cloud, όπως CockroachDB, YugaByte, κ.λπ. Οι εικόνες κοντέινερ ή τα δεδομένα blob μπορούν να αποθηκευτούν σε ένα μητρώο docker που βασίζεται στο MinIO. Τα δεδομένα χρονοσήμανσης μπορούν να αποθηκευτούν σε μια βάση δεδομένων χρονοσειρών, όπως το InfluxDB κ.λπ. Δεν θα υπεισέλθουμε στις λεπτομέρειες κάθε τύπου δεδομένων και των αντίστοιχων εφαρμογών εδώ, αλλά η γενική ιδέα είναι να αποφευχθεί η μόνιμη αποθήκευση δεδομένων βάσει τοπικής τοποθέτησης δίσκου.
Επιπλέον, είναι συχνά αποτελεσματικό να παρέχεται ένα επίπεδο προσωρινής προσωρινής αποθήκευσης που χρησιμεύει ως προσωρινός χώρος αποθήκευσης αρχείων για εφαρμογές, αλλά οι εφαρμογές δεν πρέπει να εξαρτώνται από αυτό το επίπεδο ως πηγή αλήθειας.
Αποθήκευση για κρατικές εφαρμογές
Αν και είναι χρήσιμο να διατηρούνται εφαρμογές χωρίς κατάσταση στις περισσότερες περιπτώσεις, οι εφαρμογές που έχουν σχεδιαστεί για αποθήκευση δεδομένων—όπως βάσεις δεδομένων, χώροι αποθήκευσης αντικειμένων, χώροι αποθήκευσης κλειδιών-τιμών—θα πρέπει να έχουν κατάσταση κατάστασης. Ας ρίξουμε μια ματιά στο γιατί αυτές οι εφαρμογές αναπτύσσονται στο Kubernetes. Θα χρησιμοποιήσουμε το MinIO ως παράδειγμα, αλλά παρόμοιες αρχές ισχύουν για οποιοδήποτε άλλο μεγάλο σύστημα αποθήκευσης που βασίζεται σε σύννεφο.
Οι εγγενείς εφαρμογές στο cloud έχουν σχεδιαστεί για να εκμεταλλεύονται πλήρως την ευελιξία που είναι εγγενής στα κοντέινερ. Αυτό σημαίνει ότι δεν κάνουν υποθέσεις σχετικά με το περιβάλλον στο οποίο θα αναπτυχθούν. Για παράδειγμα, το MinIO χρησιμοποιεί έναν εσωτερικό μηχανισμό κωδικοποίησης διαγραφής που παρέχει στο σύστημα αρκετή ανθεκτικότητα ώστε να παραμένει λειτουργικό ακόμα και αν οι μισοί δίσκοι αποτύχουν. Το MinIO διαχειρίζεται επίσης την ακεραιότητα και την ασφάλεια των δεδομένων χρησιμοποιώντας το δικό του κατακερματισμό και κρυπτογράφηση από την πλευρά του διακομιστή.
Για τέτοιες εγγενείς εφαρμογές στο cloud, οι τοπικοί μόνιμοι τόμοι (PV) είναι οι πλέον κατάλληλοι ως εφεδρικός χώρος αποθήκευσης. Το τοπικό PV παρέχει τη δυνατότητα αποθήκευσης πρωτογενών δεδομένων, ενώ οι εφαρμογές που εκτελούνται πάνω από αυτά τα φωτοβολταϊκά συλλέγουν ανεξάρτητα πληροφορίες που επιτρέπουν στα δεδομένα να κλιμακώνουν και να διαχειρίζονται τις αυξανόμενες απαιτήσεις δεδομένων.
Αυτή η προσέγγιση είναι πολύ απλούστερη και κλιμακώνεται πολύ καλύτερα από τα φωτοβολταϊκά που βασίζονται σε CSI, τα οποία φέρνουν τα δικά τους επίπεδα διαχείρισης δεδομένων και πλεονασμού στο σύστημα. Το θέμα είναι ότι αυτά τα επίπεδα συνήθως έρχονται σε σύγκρουση με εφαρμογές που έχουν σχεδιαστεί με γνώμονα την κατάσταση.
Μια σίγουρη κίνηση προς την αποσύνδεση δεδομένων από τον υπολογισμό
Σε αυτό το άρθρο, μιλήσαμε για το πώς οι εφαρμογές κινούνται προς τη λειτουργία χωρίς κατάσταση, ή με άλλα λόγια, τον διαχωρισμό της αποθήκευσης δεδομένων από τον υπολογισμό. Εν κατακλείδι, ας δούμε μερικά πραγματικά παραδείγματα αυτής της τάσης.
, μια πολύ γνωστή πλατφόρμα ανάλυσης δεδομένων, έχει παραδοσιακά κρατήσει και έχει αναπτυχθεί στο σύστημα αρχείων HDFS. Ωστόσο, καθώς το Spark μετακινείται σε έναν εγγενή κόσμο του cloud, η πλατφόρμα χρησιμοποιείται ολοένα και περισσότερο χωρίς κρατική χρήση χρησιμοποιώντας το «s3a». Το Spark χρησιμοποιεί s3a για να μεταφέρει την κατάσταση σε άλλα συστήματα, ενώ τα ίδια τα δοχεία Spark είναι εντελώς ανιθαγενή. Άλλοι σημαντικοί επιχειρησιακοί παίκτες στον χώρο ανάλυσης μεγάλων δεδομένων περιλαμβάνουν: , , προχωρούν επίσης προς την εργασία με τον διαχωρισμό της αποθήκευσης δεδομένων και των υπολογισμών πάνω από αυτήν.
Παρόμοια μοτίβα μπορούν επίσης να παρατηρηθούν σε άλλες μεγάλες πλατφόρμες αναλυτικών στοιχείων, όπως το Presto, το Tensorflow to R και το Jupyter. Με τη μεταφόρτωση κατάστασης σε απομακρυσμένα συστήματα αποθήκευσης cloud, γίνεται πολύ πιο εύκολο να διαχειριστείτε και να κλιμακώσετε την εφαρμογή σας. Επιπλέον, προωθεί τη φορητότητα της εφαρμογής σε διάφορα περιβάλλοντα.
Πηγή: www.habr.com
