Γεια σου Χαμπρ!
Εκπροσωπούμε την ομάδα της πλατφόρμας Exness. Προηγουμένως, οι συνάδελφοί μας έγραψαν ήδη ένα άρθρο σχετικά . Σήμερα θέλουμε να μοιραστούμε την εμπειρία μας από τη μετάβαση των υπηρεσιών στο Kubernetes.
Αρχικά, σας προσφέρουμε μερικούς αριθμούς για καλύτερη κατανόηση του τι θα συζητηθεί:
- Το τμήμα ανάπτυξής μας αποτελείται από 100+ άτομα, συμπεριλαμβανομένων περισσότερων από 10 διαφορετικών ομάδων με αυτάρκεις διαδικασίες QA, DevOps και Scrum. Στοίβα ανάπτυξης - Python, PHP, C++, Java και Golang.
- Το μέγεθος των περιβαλλόντων δοκιμής και παραγωγής είναι περίπου 2000 δοχεία το καθένα. Εκτελούν το Rancher v1.6 με δική τους εικονικοποίηση και με VMware.
Κίνητρο
Όπως λένε, τίποτα δεν διαρκεί για πάντα και η Rancher ανακοίνωσε το τέλος της υποστήριξης για την έκδοση 1.6 πριν από πολύ καιρό. Ναι, σε περισσότερα από τρία χρόνια μάθαμε πώς να το προετοιμάζουμε και να λύνουμε προβλήματα που προκύπτουν, αλλά όλο και πιο συχνά ερχόμαστε αντιμέτωποι με προβλήματα που δεν θα διορθωθούν ποτέ. Το Rancher 1.6 διαθέτει επίσης ένα αποστεωμένο σύστημα για την έκδοση δικαιωμάτων, όπου μπορείτε είτε να κάνετε σχεδόν τα πάντα είτε τίποτα.
Αν και η ιδιόκτητη εικονικοποίηση παρείχε μεγαλύτερο έλεγχο στην αποθήκευση δεδομένων και την ασφάλειά της, επέβαλε λειτουργικά κόστη που ήταν δύσκολο να γίνουν αποδεκτά δεδομένης της συνεχούς ανάπτυξης της εταιρείας, του αριθμού των έργων και των απαιτήσεων για αυτά.
Θέλαμε να ακολουθήσουμε τα πρότυπα IaC και, εάν είναι απαραίτητο, να αποκτήσουμε χωρητικότητα γρήγορα, σε οποιαδήποτε γεωγραφική τοποθεσία και χωρίς κλειδαριά προμηθευτή, και επίσης να μπορέσουμε να την εγκαταλείψουμε γρήγορα.
Πρώτα βήματα
Πρώτα απ 'όλα, θέλαμε να βασιστούμε σε σύγχρονες τεχνολογίες και λύσεις που θα επέτρεπαν στις ομάδες να έχουν ταχύτερο κύκλο ανάπτυξης και να ελαχιστοποιήσουν το λειτουργικό κόστος για την αλληλεπίδραση με την πλατφόρμα που παρέχει ισχύ.
Φυσικά, το πρώτο πράγμα που μας ήρθε στο μυαλό ήταν το Kubernetes, αλλά δεν ενθουσιαστήκαμε και κάναμε μια μικρή έρευνα για να δούμε αν ήταν η σωστή επιλογή. Αξιολογήσαμε μόνο λύσεις ανοιχτού κώδικα και σε μια άδικη μάχη, η Kubernetes κέρδισε άνευ όρων.
Στη συνέχεια ήρθε το ζήτημα της επιλογής ενός εργαλείου για τη δημιουργία συμπλεγμάτων. Συγκρίναμε τις πιο δημοφιλείς λύσεις: kops, kubespray, kubeadm.
Αρχικά, το kubeadm μας φαινόταν πολύ περίπλοκο μονοπάτι, μάλλον σαν ένα είδος εφευρέτη ενός «ποδήλατου» και τα κόπη δεν είχαν αρκετή ευελιξία.
Και ο νικητής ήταν:
Αρχίσαμε να πειραματιζόμαστε με τη δική μας εικονικοποίηση και το AWS, προσπαθώντας να αναδημιουργήσουμε κάτι περίπου παρόμοιο με το προηγούμενο μοτίβο διαχείρισης πόρων, όπου όλοι μοιράζονταν το ίδιο «cluster». Και τώρα έχουμε το πρώτο μας σύμπλεγμα από 10 μικρές εικονικές μηχανές, μερικές από τις οποίες βρίσκονται στο AWS. Αρχίσαμε να προσπαθούμε να μεταφέρουμε ομάδες εκεί, όλα φαίνονταν «καλά» και η ιστορία μπορούσε να τελειώσει, αλλά...
Πρώτα προβλήματα
Το Ansible είναι αυτό πάνω στο οποίο είναι χτισμένο το kubespray, δεν είναι ένα εργαλείο που σας επιτρέπει να ακολουθείτε το IaC: κατά την έναρξη/παροπλισμό κόμβων, κάτι πήγαινε στραβά συνεχώς και απαιτούνταν κάποιο είδος παρέμβασης, και όταν χρησιμοποιούσατε διαφορετικά λειτουργικά συστήματα, το playbook συμπεριφερόταν διαφορετικά. διαφορετικά . Καθώς ο αριθμός των ομάδων και των κόμβων στο σύμπλεγμα μεγάλωνε, αρχίσαμε να παρατηρούμε ότι το βιβλίο παιχνιδιού χρειαζόταν όλο και περισσότερο χρόνο για να ολοκληρωθεί, και ως αποτέλεσμα, το ρεκόρ μας ήταν 3,5 ώρες, τι γίνεται με το δικό σας; 🙂
Και φαίνεται ότι το kubespray είναι απλώς Ansible, και όλα είναι ξεκάθαρα με την πρώτη ματιά, αλλά:
Στην αρχή του ταξιδιού, το καθήκον ήταν να εκτοξεύονται χωρητικότητες μόνο σε AWS και σε εικονικοποίηση, αλλά στη συνέχεια, όπως συμβαίνει συχνά, οι απαιτήσεις άλλαξαν.
Υπό το πρίσμα αυτού, έγινε σαφές ότι το παλιό μας μοτίβο συνδυασμού πόρων σε ένα σύστημα ενορχήστρωσης δεν ήταν κατάλληλο - στην περίπτωση που τα cluster είναι πολύ απομακρυσμένα και τα διαχειρίζονται διαφορετικοί πάροχοι.
Περαιτέρω περισσότερα. Όταν όλες οι ομάδες εργάζονται στο ίδιο σύμπλεγμα, διάφορες υπηρεσίες με λανθασμένα εγκατεστημένους NodeSelectors θα μπορούσαν να μεταβούν στον "ξένο" κεντρικό υπολογιστή μιας άλλης ομάδας και να χρησιμοποιήσουν πόρους εκεί, και αν ορίστηκε ρήξη, υπήρχαν συνεχή αιτήματα ότι η μία ή η άλλη υπηρεσία δεν λειτουργούσε. δεν κατανέμεται σωστά λόγω ανθρώπινου παράγοντα. Ένα άλλο πρόβλημα ήταν ο υπολογισμός του κόστους, ειδικά λαμβάνοντας υπόψη τα προβλήματα στη διανομή υπηρεσιών μεταξύ των κόμβων.
Μια ξεχωριστή ιστορία ήταν η έκδοση δικαιωμάτων στους υπαλλήλους: κάθε ομάδα ήθελε να είναι «στο κεφάλι» του cluster και να το διαχειριστεί πλήρως, κάτι που θα μπορούσε να προκαλέσει πλήρη κατάρρευση, αφού οι ομάδες είναι βασικά ανεξάρτητες μεταξύ τους.
Τι πρέπει να κάνω;
Λαμβάνοντας υπόψη τα παραπάνω και τις επιθυμίες των ομάδων να είναι πιο ανεξάρτητες, καταλήξαμε σε ένα απλό συμπέρασμα: μία ομάδα - ένα cluster.
Λοιπόν έχουμε ένα δεύτερο:
Και μετά το τρίτο σύμπλεγμα:
Μετά αρχίσαμε να σκεφτόμαστε: ας πούμε ότι σε ένα χρόνο οι ομάδες μας θα έχουν περισσότερα από ένα cluster; Σε διαφορετικές γεωγραφικές περιοχές, για παράδειγμα, ή υπό τον έλεγχο διαφορετικών παρόχων; Και μερικοί από αυτούς θα θέλουν να είναι σε θέση να αναπτύξουν γρήγορα ένα προσωρινό σύμπλεγμα για ορισμένες δοκιμές.
Full Kubernetes θα ερχόταν! Αυτό είναι ένα είδος MultiKubernetes, αποδεικνύεται.
Ταυτόχρονα, όλοι θα χρειαστεί να διατηρήσουμε με κάποιο τρόπο όλα αυτά τα clusters, να μπορούμε να διαχειριστούμε εύκολα την πρόσβαση σε αυτά, καθώς και να δημιουργήσουμε νέα και να παροπλίσουμε τα παλιά χωρίς χειροκίνητη παρέμβαση.
Έχει περάσει αρκετός καιρός από την αρχή του ταξιδιού μας στον κόσμο των Kubernetes και αποφασίσαμε να επανεξετάσουμε τις διαθέσιμες λύσεις. Αποδείχθηκε ότι υπάρχει ήδη στην αγορά - Rancher 2.2.
Στο πρώτο στάδιο της έρευνάς μας, τα Rancher Labs είχαν ήδη κάνει την πρώτη έκδοση της έκδοσης 2, αλλά παρόλο που θα μπορούσε να αυξηθεί πολύ γρήγορα με την εκτόξευση ενός κοντέινερ χωρίς εξωτερικές εξαρτήσεις με μερικές παραμέτρους ή χρησιμοποιώντας το επίσημο διάγραμμα HELM, φαινόταν ακατέργαστο σε εμάς, και δεν γνωρίζαμε αν θα μπορούσαμε να βασιστούμε σε αυτήν την απόφαση εάν θα αναπτυχθεί ή θα εγκαταλειφθεί γρήγορα. Το παράδειγμα cluster = clicks στην ίδια τη διεπαφή χρήστη δεν μας ταίριαζε και δεν θέλαμε να δεσμευτούμε με το RKE, καθώς είναι ένα αρκετά στενά εστιασμένο εργαλείο.
Η έκδοση Rancher 2.2 είχε ήδη μια πιο λειτουργική εμφάνιση και, μαζί με τις προηγούμενες, είχε μια σειρά από ενδιαφέροντα χαρακτηριστικά εκτός συσκευασίας, όπως ενσωμάτωση με πολλούς εξωτερικούς παρόχους, ένα ενιαίο σημείο διανομής δικαιωμάτων και αρχεία kubeconfig, εκκίνηση ενός kubectl εικόνα με τα δικαιώματά σας στη διεπαφή χρήστη, ένθετοι χώροι ονομάτων που ονομάζονται έργα.
Υπήρχε επίσης μια κοινότητα που είχε ήδη δημιουργηθεί γύρω από το Rancher 2 και ένας πάροχος που ονομάζεται HashiCorp Terraform δημιουργήθηκε για να το διαχειριστεί, ο οποίος μας βοήθησε να συγκεντρώσουμε τα πάντα.
Τι συνέβη
Ως αποτέλεσμα, καταλήξαμε με ένα μικρό σύμπλεγμα που εκτελεί το Rancher, προσβάσιμο σε όλα τα άλλα συμπλέγματα, καθώς και πολλά συμπλέγματα συνδεδεμένα με αυτό, πρόσβαση σε οποιοδήποτε από τα οποία μπορεί να παραχωρηθεί τόσο απλά όσο η προσθήκη ενός χρήστη στον κατάλογο ldap, ανεξάρτητα από πού βρίσκεται και ποιους πόρους παρόχου χρησιμοποιεί.
Χρησιμοποιώντας το gitlab-ci και το Terraform, δημιουργήθηκε ένα σύστημα που σας επιτρέπει να δημιουργήσετε ένα σύμπλεγμα οποιασδήποτε διαμόρφωσης σε παρόχους cloud ή τη δική μας υποδομή και να τους συνδέσετε στο Rancher. Όλα αυτά γίνονται σε στυλ IaC, όπου κάθε σύμπλεγμα περιγράφεται από ένα αποθετήριο και η κατάστασή του εκδίδεται. Ταυτόχρονα, οι περισσότερες λειτουργικές μονάδες συνδέονται από εξωτερικά αποθετήρια, έτσι ώστε το μόνο που μένει είναι να περάσουν μεταβλητές ή να περιγράψουν την προσαρμοσμένη διαμόρφωση για περιπτώσεις, κάτι που βοηθά στη μείωση του ποσοστού επανάληψης κώδικα.
Φυσικά, το ταξίδι μας απέχει πολύ από το να τελειώσει και υπάρχουν ακόμα πολλές ενδιαφέρουσες εργασίες μπροστά, όπως ένα μόνο σημείο εργασίας με αρχεία καταγραφής και μετρήσεις οποιωνδήποτε συμπλεγμάτων, πλέγμα υπηρεσιών, gitops για τη διαχείριση φορτίων σε ένα πολυσυστάδα και πολλά άλλα. Ελπίζουμε να βρείτε ενδιαφέρουσα την εμπειρία μας!
Το άρθρο γράφτηκε από τους A. Antipov, A. Ganush, Platform Engineers.
Πηγή: www.habr.com