ProHoster > Blog > διαχείριση > Η εμπειρία μας στην ανάπτυξη ενός προγράμματος οδήγησης CSI στο Kubernetes για το Yandex.Cloud

Η εμπειρία μας στην ανάπτυξη ενός προγράμματος οδήγησης CSI στο Kubernetes για το Yandex.Cloud

Η εμπειρία μας στην ανάπτυξη ενός προγράμματος οδήγησης CSI στο Kubernetes για το Yandex.Cloud

Είμαστε στην ευχάριστη θέση να ανακοινώσουμε ότι το Flant επεκτείνει τη συνεισφορά του στα εργαλεία ανοιχτού κώδικα για Kubernetes με την κυκλοφορία έκδοση alpha του προγράμματος οδήγησης CSI (Διασύνδεση αποθήκευσης κοντέινερ) για Yandex.Cloud.

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

Εισαγωγή

Γιατί είναι αυτό?

Μέσα στην εταιρεία μας, από την αρχή της χρήσης του Kubernetes στην παραγωγή (δηλαδή εδώ και αρκετά χρόνια), αναπτύσσουμε το δικό μας εργαλείο (deckhouse), το οποίο, παρεμπιπτόντως, σχεδιάζουμε επίσης να διαθέσουμε σύντομα ως έργο ανοιχτού κώδικα . Με τη βοήθειά του, διαμορφώνουμε και διαμορφώνουμε ομοιόμορφα όλα τα συμπλέγματά μας, και αυτή τη στιγμή υπάρχουν ήδη περισσότερα από 100 από αυτά, σε μια μεγάλη ποικιλία διαμορφώσεων υλικού και σε όλες τις διαθέσιμες υπηρεσίες cloud.

Τα συμπλέγματα που χρησιμοποιούν deckhouse διαθέτουν όλα τα απαραίτητα στοιχεία για τη λειτουργία: εξισορροπητές, παρακολούθηση με εύχρηστα γραφήματα, μετρήσεις και ειδοποιήσεις, έλεγχο ταυτότητας χρήστη μέσω εξωτερικών παρόχων για πρόσβαση σε όλους τους πίνακες εργαλείων κ.λπ. Δεν έχει νόημα να εγκαταστήσετε ένα τέτοιο «άντληση» συμπλέγματος σε μια διαχειριζόμενη λύση, καθώς αυτό είναι συχνά είτε αδύνατο είτε θα οδηγήσει στην ανάγκη απενεργοποίησης των μισών εξαρτημάτων.

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

Τι είναι και για ποιον;

Έτσι, έχουμε ήδη μιλήσει για τη σύγχρονη προσέγγιση αποθήκευσης στο Kubernetes: πώς λειτουργεί το CSI; и πώς ήρθε η κοινότητα σε αυτή την προσέγγιση.

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

Πήραμε ως βάση για την ανάπτυξη Πρόγραμμα οδήγησης CSI για το cloud DigitalOcean και μερικές ιδέες από προγράμματα οδήγησης για GCP, καθώς η αλληλεπίδραση με το API αυτών των cloud (Google και Yandex) έχει πολλές ομοιότητες. Ειδικότερα, το API και GCP, και στις Yandex επιστροφή ενός αντικειμένου Operation για παρακολούθηση της κατάστασης των μακροχρόνιων λειτουργιών (για παράδειγμα, δημιουργία νέου δίσκου). Για να αλληλεπιδράσετε με το Yandex.Cloud API, χρησιμοποιήστε Yandex.Cloud Go SDK.

Το αποτέλεσμα της δουλειάς που έγινε κυκλοφόρησε στο GitHub και μπορεί να είναι χρήσιμο για όσους, για κάποιο λόγο, χρησιμοποιούν τη δική τους εγκατάσταση Kubernetes σε εικονικές μηχανές Yandex.Cloud (αλλά όχι ένα έτοιμο διαχειριζόμενο σύμπλεγμα) και θέλουν να χρησιμοποιήσουν (παραγγελία) δίσκους μέσω CSI.

Реализация

Βασικά χαρακτηριστικά

Επί του παρόντος, το πρόγραμμα οδήγησης υποστηρίζει τις ακόλουθες λειτουργίες:

  • Ταξινόμηση δίσκων σε όλες τις ζώνες του συμπλέγματος σύμφωνα με την τοπολογία των κόμβων του συμπλέγματος.
  • Αφαίρεση δίσκων που είχαν παραγγείλει προηγουμένως.
  • Αλλαγή μεγέθους εκτός σύνδεσης για δίσκους (Yandex.Cloud δεν υποστηρίζουν αυξάνοντας τους δίσκους που είναι τοποθετημένοι στην εικονική μηχανή). Για πληροφορίες σχετικά με το πώς έπρεπε να τροποποιηθεί το πρόγραμμα οδήγησης για να γίνει η αλλαγή μεγέθους όσο το δυνατόν πιο ανώδυνη, δείτε παρακάτω.

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

Η κύρια δυσκολία και πώς να την ξεπεράσετε

Η έλλειψη δυνατότητας αύξησης δίσκων σε πραγματικό χρόνο στο Yandex.Cloud API είναι ένας περιορισμός που περιπλέκει τη λειτουργία αλλαγής μεγέθους για PV (Μόνιμος όγκος): σε αυτήν την περίπτωση, είναι απαραίτητο να σταματήσει η εφαρμογή pod που χρησιμοποιεί το δίσκο, και αυτό μπορεί να προκαλέσει διακοπή λειτουργίας εφαρμογών.

Σύμφωνα με Προδιαγραφές CSI, εάν ο ελεγκτής CSI αναφέρει ότι μπορεί να αλλάξει το μέγεθος των δίσκων μόνο "εκτός σύνδεσης" (VolumeExpansion.OFFLINE), τότε η διαδικασία αύξησης του δίσκου θα πρέπει να γίνει ως εξής:

Εάν το πρόσθετο έχει μόνο VolumeExpansion.OFFLINE Η δυνατότητα επέκτασης και ο όγκος είναι επί του παρόντος δημοσιευμένοι ή διαθέσιμοι σε έναν κόμβο τότε ControllerExpandVolume ΠΡΕΠΕΙ να κληθεί ΜΟΝΟ μετά από οποιοδήποτε:

  • Το πρόσθετο έχει ελεγκτή PUBLISH_UNPUBLISH_VOLUME ικανότητα και ControllerUnpublishVolume έχει γίνει επιτυχής επίκληση.

Ή ΑΛΛΙΩΣ

  • Το πρόσθετο ΔΕΝ έχει ελεγκτή PUBLISH_UNPUBLISH_VOLUME δυνατότητα, το πρόσθετο έχει κόμβο STAGE_UNSTAGE_VOLUME ικανότητα, και NodeUnstageVolume ολοκληρώθηκε με επιτυχία.

Ή ΑΛΛΙΩΣ

  • Το πρόσθετο ΔΕΝ έχει ελεγκτή PUBLISH_UNPUBLISH_VOLUME ικανότητα, ούτε κόμβος STAGE_UNSTAGE_VOLUME ικανότητα, και NodeUnpublishVolume ολοκληρώθηκε με επιτυχία.

Αυτό ουσιαστικά σημαίνει ότι πρέπει να αποσυνδέσετε τον δίσκο από την εικονική μηχανή πριν τον επεκτείνετε.

Ωστόσο, δυστυχώς εφαρμογή Η προδιαγραφή CSI μέσω sidecars δεν πληροί αυτές τις απαιτήσεις:

  • Σε ένα κοντέινερ πλαισίων csi-attacher, η οποία θα πρέπει να είναι υπεύθυνη για την ύπαρξη του απαιτούμενου κενού μεταξύ των στηριγμάτων, αυτή η λειτουργία απλά δεν εφαρμόζεται στην αλλαγή μεγέθους εκτός σύνδεσης. Ξεκίνησε μια συζήτηση για αυτό εδώ.
  • Τι ακριβώς είναι ένα κοντέινερ sidecar σε αυτό το πλαίσιο; Το ίδιο το πρόσθετο CSI δεν αλληλεπιδρά με το Kubernetes API, αλλά ανταποκρίνεται μόνο σε κλήσεις gRPC που του αποστέλλονται από κοντέινερ sidecar. Αργότερο αναπτύσσονται από την κοινότητα Kubernetes.

Στην περίπτωσή μας (πρόσθετο CSI), η λειτουργία αύξησης του δίσκου μοιάζει με αυτό:

  1. Λαμβάνουμε μια κλήση gRPC ControllerExpandVolume;
  2. Προσπαθούμε να αυξήσουμε το δίσκο στο API, αλλά λαμβάνουμε ένα σφάλμα σχετικά με την αδυναμία εκτέλεσης της λειτουργίας επειδή ο δίσκος είναι προσαρτημένος.
  3. Αποθηκεύουμε το αναγνωριστικό δίσκου σε έναν χάρτη που περιέχει τους δίσκους για τους οποίους πρέπει να εκτελεστεί η λειτουργία αύξησης. Παρακάτω, για συντομία, θα ονομάσουμε αυτόν τον χάρτη ως volumeResizeRequired;
  4. Αφαιρέστε με μη αυτόματο τρόπο το pod που χρησιμοποιεί το δίσκο. Η Kubernetes θα την επανεκκινήσει. Έτσι ώστε ο δίσκος να μην έχει χρόνο για τοποθέτηση (ControllerPublishVolume) πριν ολοκληρώσουμε τη λειτουργία αύξησης κατά την προσπάθεια προσάρτησης, ελέγχουμε ότι ο συγκεκριμένος δίσκος είναι ακόμα μέσα volumeResizeRequired και να επιστρέψει ένα σφάλμα?
  5. Το πρόγραμμα οδήγησης CSI προσπαθεί να εκτελέσει ξανά τη λειτουργία αλλαγής μεγέθους. Εάν η λειτουργία ήταν επιτυχής, αφαιρέστε το δίσκο από volumeResizeRequired;
  6. Επειδή Το αναγνωριστικό δίσκου λείπει από volumeResizeRequired, ControllerPublishVolume περνά με επιτυχία, ο δίσκος τοποθετείται, το pod ξεκινά.

Όλα φαίνονται αρκετά απλά, αλλά όπως πάντα υπάρχουν παγίδες. Μεγεθύνει τους δίσκους εξωτερικός-resizer, το οποίο σε περίπτωση λάθους κατά τη λειτουργία χρησιμοποιεί ουρά με εκθετική αύξηση του χρόνου λήξης έως και 1000 δευτερόλεπτα:

func DefaultControllerRateLimiter() RateLimiter {
  return NewMaxOfRateLimiter(
  NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
  // 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
  &BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
  )
}

Αυτό μπορεί περιοδικά να έχει ως αποτέλεσμα την παράταση της λειτουργίας επέκτασης δίσκου για 15+ λεπτά και, επομένως, το αντίστοιχο pod να μην είναι διαθέσιμο.

Η μόνη επιλογή που μας επέτρεψε πολύ εύκολα και ανώδυνα να μειώσουμε τον πιθανό χρόνο διακοπής λειτουργίας ήταν η χρήση της έκδοσης του εξωτερικού συστήματος αλλαγής μεγέθους με μέγιστο χρονικό όριο σε 5 δευτερόλεπτα:

workqueue.NewItemExponentialFailureRateLimiter(5*time.Millisecond, 5*time.Second)

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

Πώς να αρχίσετε να το χρησιμοποιείτε;

Το πρόγραμμα οδήγησης υποστηρίζεται σε Kubernetes έκδοση 1.15 και νεότερη. Για να λειτουργήσει ο οδηγός, πρέπει να πληρούνται οι ακόλουθες προϋποθέσεις:

  • Σημαία --allow-privileged οριστεί σε τιμή true για διακομιστή API και kubelet.
  • Περιλαμβάνεται --feature-gates=VolumeSnapshotDataSource=true,KubeletPluginsWatcher=true,CSINodeInfo=true,CSIDriverRegistry=true για διακομιστή API και kubelet.
  • Διάδοση μονταρίσματος (μοντάρισμα πολλαπλασιασμού) πρέπει να είναι ενεργοποιημένη στο σύμπλεγμα. Όταν χρησιμοποιείτε το Docker, ο δαίμονας πρέπει να ρυθμιστεί ώστε να επιτρέπει κοινές προσαρτήσεις.

Όλα τα απαραίτητα βήματα για την ίδια την εγκατάσταση περιγράφεται στο README. Η εγκατάσταση περιλαμβάνει τη δημιουργία αντικειμένων στο Kubernetes από μανιφέστα.

Για να λειτουργήσει ο οδηγός θα χρειαστείτε τα εξής:

  • Καθορίστε το αναγνωριστικό καταλόγου στο μανιφέστο (folder-id) Yandex.Cloud (δείτε τεκμηρίωση);
  • Για να αλληλεπιδράσει με το Yandex.Cloud API, το πρόγραμμα οδήγησης CSI χρησιμοποιεί έναν λογαριασμό υπηρεσίας. Στο μανιφέστο, το Secret πρέπει να περάσει εξουσιοδοτημένα κλειδιά από τον λογαριασμό υπηρεσίας. Στην τεκμηρίωση περιγράφεται, πώς να δημιουργήσετε έναν λογαριασμό υπηρεσίας και να λάβετε κλειδιά.

Ολα για όλα - δοκιμάστε το, και θα χαρούμε να λάβουμε σχόλια και νέα θέματααν αντιμετωπίσετε κάποιο πρόβλημα!

Περαιτέρω υποστήριξη

Ως αποτέλεσμα, θα θέλαμε να σημειώσουμε ότι εφαρμόσαμε αυτό το πρόγραμμα οδήγησης CSI όχι από μεγάλη επιθυμία να διασκεδάσουμε γράφοντας εφαρμογές στο Go, αλλά λόγω επείγουσας ανάγκης εντός της εταιρείας. Δεν μας φαίνεται πρακτικό να διατηρήσουμε τη δική μας εφαρμογή, επομένως εάν η Yandex δείξει ενδιαφέρον και αποφασίσει να συνεχίσει να υποστηρίζει το πρόγραμμα οδήγησης, θα χαρούμε να του μεταφέρουμε το αποθετήριο.

Επιπλέον, η Yandex έχει πιθανώς τη δική της εφαρμογή του προγράμματος οδήγησης CSI στο διαχειριζόμενο σύμπλεγμα Kubernetes, το οποίο μπορεί να κυκλοφορήσει σε Open Source. Βλέπουμε επίσης αυτή την επιλογή ανάπτυξης ως ευνοϊκή - η κοινότητα θα μπορεί να χρησιμοποιήσει ένα δοκιμασμένο πρόγραμμα οδήγησης από έναν πάροχο υπηρεσιών και όχι από μια εταιρεία τρίτων.

PS

Διαβάστε επίσης στο blog μας:

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο