Ονομάζομαι Viktor Yagofarov και αναπτύσσω την πλατφόρμα Kubernetes στο DomClick ως υπεύθυνος τεχνικής ανάπτυξης στην ομάδα Ops (λειτουργίας). Θα ήθελα να μιλήσω για τη δομή των διαδικασιών Dev <-> Ops μας, τα χαρακτηριστικά λειτουργίας ενός από τα μεγαλύτερα cluster k8s στη Ρωσία, καθώς και τις πρακτικές DevOps/SRE που εφαρμόζει η ομάδα μας.
Ομάδα Επιχειρήσεων
Η ομάδα Ops έχει αυτή τη στιγμή 15 άτομα. Τρεις από αυτούς είναι υπεύθυνοι για το γραφείο, δύο εργάζονται σε διαφορετική ζώνη ώρας και είναι διαθέσιμοι, ακόμη και τη νύχτα. Έτσι, κάποιος από το Ops είναι πάντα στην οθόνη και έτοιμος να ανταποκριθεί σε ένα περιστατικό οποιασδήποτε πολυπλοκότητας. Δεν έχουμε νυχτερινές βάρδιες, κάτι που διατηρεί την ψυχή μας και δίνει σε όλους την ευκαιρία να κοιμούνται αρκετά και να περνούν τον ελεύθερο χρόνο τους όχι μόνο στον υπολογιστή.
Ο καθένας έχει διαφορετικές ικανότητες: δικτυωτές, DBA, ειδικοί στοίβας ELK, διαχειριστές/προγραμματιστές Kubernetes, παρακολούθηση, εικονικοποίηση, ειδικοί υλικού κ.λπ. Ένα πράγμα ενώνει όλους - ο καθένας μπορεί να αντικαταστήσει οποιονδήποτε από εμάς σε κάποιο βαθμό: για παράδειγμα, εισάγετε νέους κόμβους στο σύμπλεγμα k8s, ενημερώστε το PostgreSQL, γράψτε μια διοχέτευση CI/CD + Ansible, αυτοματοποιήστε κάτι στο Python/Bash/Go, συνδέστε το υλικό στο Κέντρο δεδομένων. Οι ισχυρές ικανότητες σε κανέναν τομέα δεν σας εμποδίζουν να αλλάξετε την κατεύθυνση της δραστηριότητάς σας και να αρχίσετε να βελτιώνεστε σε κάποιον άλλο τομέα. Για παράδειγμα, μπήκα σε μια εταιρεία ως ειδικός στην PostgreSQL και τώρα ο κύριος τομέας ευθύνης μου είναι τα συμπλέγματα Kubernetes. Στην ομάδα, κάθε ύψος είναι ευπρόσδεκτο και η αίσθηση της μόχλευσης είναι πολύ ανεπτυγμένη.
Παρεμπιπτόντως, κυνηγάμε. Οι απαιτήσεις για τους υποψηφίους είναι αρκετά τυπικές. Προσωπικά, είναι σημαντικό για μένα ένα άτομο να ταιριάζει στην ομάδα, να μην έχει σύγκρουση, αλλά και να ξέρει να υπερασπίζεται την άποψή του, να θέλει να εξελίσσεται και να μην φοβάται να κάνει κάτι νέο και να προσφέρει τις ιδέες του. Επίσης, απαιτούνται δεξιότητες προγραμματισμού σε γλώσσες scripting, γνώση των βασικών Linux και Αγγλικών. Τα αγγλικά χρειάζονται απλά για να μπορεί κάποιος σε περίπτωση fakap να ψάξει στο google μια λύση στο πρόβλημα σε 10 δευτερόλεπτα και όχι σε 10 λεπτά. Τώρα είναι πολύ δύσκολο να βρεις ειδικούς με βαθιά γνώση του Linux: είναι αστείο, αλλά δύο στους τρεις υποψήφιους δεν μπορούν να απαντήσουν στην ερώτηση «Τι είναι ο μέσος όρος φόρτωσης; Από τι είναι φτιαγμένο;», και η ερώτηση «Πώς να συναρμολογήσετε έναν πυρήνα από ένα πρόγραμμα C» θεωρείται κάτι από τον κόσμο των υπερανθρώπων... ή των δεινοσαύρων. Πρέπει να το αντέξουμε αυτό, αφού συνήθως οι άνθρωποι έχουν πολύ ανεπτυγμένες άλλες ικανότητες, αλλά θα διδάξουμε Linux. Η απάντηση στην ερώτηση "γιατί ένας μηχανικός DevOps πρέπει να τα γνωρίζει όλα αυτά στον σύγχρονο κόσμο των σύννεφων" θα πρέπει να μείνει εκτός του πεδίου εφαρμογής του άρθρου, αλλά με τρεις λέξεις: όλα αυτά είναι απαραίτητα.
Εργαλεία ομάδας
Η ομάδα Εργαλείων παίζει σημαντικό ρόλο στον αυτοματισμό. Το κύριο καθήκον τους είναι να δημιουργούν εύχρηστα εργαλεία γραφικών και CLI για προγραμματιστές. Για παράδειγμα, η εσωτερική μας ανάπτυξη Confer σάς επιτρέπει να ανοίξετε κυριολεκτικά μια εφαρμογή στο Kubernetes με λίγα μόνο κλικ του ποντικιού, να διαμορφώσετε τους πόρους της, τα κλειδιά από το vault κ.λπ. Προηγουμένως, υπήρχε το Jenkins + Helm 2, αλλά έπρεπε να αναπτύξω το δικό μου εργαλείο για να εξαλείψω την αντιγραφή-επικόλληση και να φέρω ομοιομορφία στον κύκλο ζωής του λογισμικού.
Η ομάδα Ops δεν συντάσσει αγωγούς για προγραμματιστές, αλλά μπορεί να συμβουλεύει για τυχόν ζητήματα στο γραπτό της (ορισμένοι άνθρωποι εξακολουθούν να έχουν Helm 3).
DevOps
Όσο για τα DevOps, το βλέπουμε ως εξής:
Οι ομάδες προγραμματιστών γράφουν κώδικα, τον παρουσιάζουν μέσω Confer to dev -> qa/stage -> prod. Η ευθύνη για τη διασφάλιση ότι ο κώδικας δεν επιβραδύνεται και δεν περιέχει σφάλματα ανήκει στις ομάδες Dev και Ops. Κατά τη διάρκεια της ημέρας, ο εφημερεύων από την ομάδα Ops θα πρέπει πρώτα από όλα να ανταποκριθεί σε ένα περιστατικό με την αίτησή του και το βράδυ και τη νύχτα, ο διαχειριστής υπηρεσίας (Ops) θα πρέπει να ξυπνήσει τον προγραμματιστή σε υπηρεσία εάν γνωρίζει σίγουρος ότι το πρόβλημα δεν είναι στις υποδομές. Όλες οι μετρήσεις και οι ειδοποιήσεις στην παρακολούθηση εμφανίζονται αυτόματα ή ημιαυτόματα.
Ο τομέας ευθύνης του Ops ξεκινά από τη στιγμή που η εφαρμογή θα κυκλοφορήσει στην παραγωγή, αλλά η ευθύνη του Dev δεν τελειώνει εκεί - κάνουμε το ίδιο πράγμα και βρισκόμαστε στο ίδιο σκάφος.
Οι προγραμματιστές συμβουλεύουν τους διαχειριστές εάν χρειάζονται βοήθεια για τη σύνταξη μιας μικρουπηρεσίας διαχειριστή (για παράδειγμα, Go backend + HTML5) και οι διαχειριστές συμβουλεύουν τους προγραμματιστές για τυχόν ζητήματα υποδομής ή ζητήματα που σχετίζονται με τα k8s.
Παρεμπιπτόντως, δεν έχουμε καθόλου μονόλιθο, μόνο μικροϋπηρεσίες. Ο αριθμός τους μέχρι στιγμής κυμαίνεται μεταξύ 900 και 1000 στο σύμπλεγμα prod k8s, εάν μετρηθεί με αριθμό αναπτύξεις. Ο αριθμός των λοβών κυμαίνεται μεταξύ 1700 και 2000. Αυτήν τη στιγμή υπάρχουν περίπου 2000 λοβοί στο σύμπλεγμα προϊόντων.
Δεν μπορώ να δώσω ακριβείς αριθμούς, καθώς παρακολουθούμε τις περιττές μικροϋπηρεσίες και τις κόβουμε ημιαυτόματα. Το K8s μας βοηθά να παρακολουθούμε περιττές οντότητες , που εξοικονομεί πολλούς πόρους και χρήματα.
Έλεγχος των αναγκών
Παρακολούθηση
Η καλά δομημένη και ενημερωτική παρακολούθηση γίνεται ο ακρογωνιαίος λίθος στη λειτουργία ενός μεγάλου συμπλέγματος. Δεν έχουμε βρει ακόμη μια καθολική λύση που να καλύπτει το 100% όλων των αναγκών παρακολούθησης, επομένως δημιουργούμε περιοδικά διαφορετικές προσαρμοσμένες λύσεις σε αυτό το περιβάλλον.
- Zabbix. Παλιά καλή παρακολούθηση, η οποία αποσκοπεί κυρίως στην παρακολούθηση της συνολικής κατάστασης της υποδομής. Μας λέει πότε πεθαίνει ένας κόμβος όσον αφορά την επεξεργασία, τη μνήμη, τους δίσκους, το δίκτυο και ούτω καθεξής. Τίποτα υπερφυσικό, αλλά έχουμε επίσης ένα ξεχωριστό DaemonSet agents, με τη βοήθεια του οποίου, για παράδειγμα, παρακολουθούμε την κατάσταση του DNS στο σύμπλεγμα: ψάχνουμε για ηλίθια coredns pods, ελέγχουμε τη διαθεσιμότητα εξωτερικών κεντρικών υπολογιστών. Φαίνεται ότι γιατί να ασχοληθείτε με αυτό, αλλά με μεγάλους όγκους κίνησης, αυτό το στοιχείο είναι ένα σοβαρό σημείο αποτυχίας. εγώ ήδη , πώς δυσκολεύτηκα με την απόδοση DNS σε ένα σύμπλεγμα.
- Χειριστής Προμηθέας. Ένα σύνολο διαφορετικών εξαγωγέων παρέχει μια μεγάλη επισκόπηση όλων των στοιχείων του συμπλέγματος. Στη συνέχεια, τα οπτικοποιούμε όλα αυτά σε μεγάλους πίνακες εργαλείων στη Γραφάνα και χρησιμοποιούμε το alertmanager για ειδοποιήσεις.
Ένα άλλο χρήσιμο εργαλείο για εμάς ήταν . Το γράψαμε αφού αρκετές φορές αντιμετωπίσαμε μια κατάσταση όπου μια ομάδα επικάλυψε τις διαδρομές εισόδου μιας άλλης ομάδας, με αποτέλεσμα 50 φορές λάθη. Τώρα, πριν από την ανάπτυξη στην παραγωγή, οι προγραμματιστές ελέγχουν ότι δεν θα επηρεαστεί κανείς και για την ομάδα μου αυτό είναι ένα καλό εργαλείο για την αρχική διάγνωση προβλημάτων με το Ingresses. Είναι αστείο που στην αρχή ήταν γραμμένο για διαχειριστές και φαινόταν μάλλον «αδέξιο», αλλά αφού οι ομάδες προγραμματιστών ερωτεύτηκαν το εργαλείο, άλλαξε πολύ και άρχισε να μην μοιάζει με «ένας διαχειριστής έφτιαξε ένα web πρόσωπο για διαχειριστές. ” Σύντομα θα εγκαταλείψουμε αυτό το εργαλείο και τέτοιες καταστάσεις θα επικυρωθούν ακόμη και πριν ξεκινήσει ο αγωγός.
Πόροι ομάδας στον Κύβο
Πριν μπούμε στα παραδείγματα, αξίζει να εξηγήσουμε πώς κατανέμουμε πόρους μικροϋπηρεσίες.
Να καταλάβουμε ποιες ομάδες και σε ποιες ποσότητες χρησιμοποιούν τους πόροι (επεξεργαστής, μνήμη, τοπικός SSD), εκχωρούμε κάθε εντολή τη δική της χώρο ονομάτων στον «Κύβο» και να περιορίσει τις μέγιστες δυνατότητές του σε επεξεργαστή, μνήμη και δίσκο, έχοντας προηγουμένως συζητήσει τις ανάγκες των ομάδων. Αντίστοιχα, μια εντολή, γενικά, δεν θα μπλοκάρει ολόκληρο το σύμπλεγμα για ανάπτυξη, εκχωρώντας χιλιάδες πυρήνες και terabyte μνήμης. Η πρόσβαση στον χώρο ονομάτων παρέχεται μέσω AD (χρησιμοποιούμε RBAC). Οι χώροι ονομάτων και τα όριά τους προστίθενται μέσω ενός αιτήματος έλξης στο αποθετήριο GIT και, στη συνέχεια, τα πάντα διατίθενται αυτόματα μέσω του αγωγού Ansible.
Ένα παράδειγμα κατανομής πόρων σε μια ομάδα:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
Αιτήματα και όρια
Κόκκος αρωματικός" Αίτημα είναι ο αριθμός των εγγυημένων δεσμευμένων πόρων για pod (ένα ή περισσότερα δοχεία βάσης) σε ένα σύμπλεγμα. Το όριο είναι ένα μη εγγυημένο μέγιστο. Μπορείτε συχνά να δείτε στα γραφήματα πώς κάποια ομάδα έχει θέσει στον εαυτό της πάρα πολλά αιτήματα για όλες τις εφαρμογές της και δεν μπορεί να αναπτύξει την εφαρμογή στον «Κύβο», καθώς όλα τα αιτήματα κάτω από τον χώρο ονομάτων τους έχουν ήδη «δαπανηθεί».
Η σωστή διέξοδος από αυτήν την κατάσταση είναι να εξετάσετε την πραγματική κατανάλωση πόρων και να τη συγκρίνετε με το ζητούμενο ποσό (Αίτηση).
Στα παραπάνω στιγμιότυπα οθόνης μπορείτε να δείτε ότι οι "Ζητούμενες" CPU αντιστοιχίζονται με τον πραγματικό αριθμό νημάτων και τα Όρια μπορεί να υπερβαίνουν τον πραγματικό αριθμό νημάτων της CPU =)
Τώρα ας δούμε αναλυτικά κάποιο χώρο ονομάτων (διάλεξα το namespace kube-system - τον χώρο ονομάτων του συστήματος για τα στοιχεία του ίδιου του "Cube") και ας δούμε την αναλογία του χρόνου και της μνήμης του επεξεργαστή που χρησιμοποιήθηκε πραγματικά προς το ζητούμενο:
Είναι προφανές ότι δεσμεύεται πολύ περισσότερη μνήμη και CPU για υπηρεσίες συστήματος από ό,τι χρησιμοποιείται στην πραγματικότητα. Στην περίπτωση του συστήματος kube, αυτό είναι δικαιολογημένο: συνέβη ο ελεγκτής εισόδου nginx ή οι nodelocaldns στο αποκορύφωμά τους να χτυπήσουν τη CPU και να καταναλώσουν πολλή μνήμη RAM, οπότε εδώ δικαιολογείται μια τέτοια δέσμευση. Επιπλέον, δεν μπορούμε να βασιστούμε σε γραφήματα για τις τελευταίες 3 ώρες: είναι επιθυμητό να βλέπουμε ιστορικές μετρήσεις για μεγάλο χρονικό διάστημα.
Αναπτύχθηκε ένα σύστημα «συστάσεων». Για παράδειγμα, εδώ μπορείτε να δείτε ποιοι πόροι θα ήταν καλύτερο να αυξήσουν τα «όρια» (η επάνω επιτρεπόμενη γραμμή) έτσι ώστε να μην εμφανίζεται «σταγματισμός»: η στιγμή που ένας πόρος έχει ήδη ξοδέψει CPU ή μνήμη στο κατανεμημένο χρονικό διάστημα και περιμένει μέχρι να «ξεπαγώσει»:
Και εδώ είναι οι λοβοί που πρέπει να περιορίσουν την όρεξή τους:
επί στραγγαλισμός + παρακολούθηση πόρων, μπορείτε να γράψετε περισσότερα από ένα άρθρα, οπότε κάντε ερωτήσεις στα σχόλια. Με λίγα λόγια, μπορώ να πω ότι το έργο της αυτοματοποίησης τέτοιων μετρήσεων είναι πολύ δύσκολο και απαιτεί πολύ χρόνο και εξισορροπητική πράξη με συναρτήσεις «παραθύρου» και «CTE» Prometheus / VictoriaMetrics (αυτοί οι όροι είναι σε εισαγωγικά, αφού υπάρχει σχεδόν τίποτα τέτοιο στο PromQL, και πρέπει να διαιρέσετε τρομακτικά ερωτήματα σε πολλές οθόνες κειμένου και να τα βελτιστοποιήσετε).
Ως αποτέλεσμα, οι προγραμματιστές έχουν εργαλεία για την παρακολούθηση των χώρων ονομάτων τους στο Cube και μπορούν να επιλέξουν μόνοι τους πού και σε ποια ώρα σε ποιες εφαρμογές μπορούν να «κοπούν» οι πόροι τους και σε ποιους διακομιστές μπορεί να δοθεί ολόκληρη η CPU όλη τη νύχτα.
Μεθοδολογίες
Στην παρέα όπως είναι τώρα μοντέρνα, τηρούμε DevOps- και SRE-επαγγελματίας Όταν μια εταιρεία έχει 1000 microservices, περίπου 350 προγραμματιστές και 15 διαχειριστές για ολόκληρη την υποδομή, πρέπει να είσαι "μοντέρνος": πίσω από όλα αυτά τα "baswords" υπάρχει επείγουσα ανάγκη αυτοματοποίησης των πάντων και όλων και οι διαχειριστές δεν πρέπει να αποτελούν εμπόδιο σε διαδικασίες.
Ως Ops, παρέχουμε διάφορες μετρήσεις και πίνακες εργαλείων για προγραμματιστές που σχετίζονται με τα ποσοστά απόκρισης υπηρεσιών και τα σφάλματα.
Χρησιμοποιούμε μεθοδολογίες όπως: , и συνδυάζοντάς τα μεταξύ τους. Προσπαθούμε να ελαχιστοποιήσουμε τον αριθμό των ταμπλό, ώστε με μια ματιά να είναι ξεκάθαρο ποια υπηρεσία είναι αυτή τη στιγμή υποβαθμισμένη (για παράδειγμα, κωδικοί απόκρισης ανά δευτερόλεπτο, χρόνος απόκρισης κατά 99ο εκατοστημόριο) και ούτω καθεξής. Μόλις γίνουν απαραίτητες κάποιες νέες μετρήσεις για γενικούς πίνακες εργαλείων, τις σχεδιάζουμε και τις προσθέτουμε αμέσως.
Δεν έχω σχεδιάσει γραφήματα εδώ και ένα μήνα. Αυτό είναι πιθανώς ένα καλό σημάδι: σημαίνει ότι τα περισσότερα από τα «θέλω» έχουν ήδη πραγματοποιηθεί. Συνέβαινε ότι κατά τη διάρκεια της εβδομάδας σχεδίαζα κάποιο νέο γράφημα τουλάχιστον μία φορά την ημέρα.
Το αποτέλεσμα που προκύπτει είναι πολύτιμο επειδή τώρα οι προγραμματιστές σπάνια πηγαίνουν σε διαχειριστές με ερωτήσεις "πού να δούμε κάποιο είδος μέτρησης".
Εφαρμογή Service Mesh είναι προ των πυλών και θα πρέπει να κάνει τη ζωή πολύ πιο εύκολη για όλους, οι συνάδελφοι από το Tools είναι ήδη κοντά στην εφαρμογή του αφηρημένου «Ιστίου ενός υγιούς ανθρώπου»: ο κύκλος ζωής κάθε αιτήματος HTTP θα είναι ορατός στην παρακολούθηση και θα είναι πάντα δυνατό να κατανοήσουμε «σε ποιο στάδιο χάλασαν τα πάντα» κατά τη διυπηρεσιακή (και όχι μόνο) αλληλεπίδραση. Εγγραφείτε σε νέα από το κέντρο DomClick. =)
Υποστήριξη υποδομής Kubernetes
Ιστορικά, χρησιμοποιούμε την επιδιορθωμένη έκδοση Kubespray — Αποδεκτός ρόλος για την ανάπτυξη, την επέκταση και την ενημέρωση του Kubernetes. Σε κάποιο σημείο, η υποστήριξη για εγκαταστάσεις που δεν ήταν kubeadm κόπηκε από τον κύριο κλάδο και δεν προτάθηκε η διαδικασία μετάβασης σε kubeadm. Ως αποτέλεσμα, η εταιρεία Southbridge έφτιαξε το δικό της πιρούνι (με υποστήριξη kubeadm και μια γρήγορη λύση για κρίσιμα προβλήματα).
Η διαδικασία για την ενημέρωση όλων των συμπλεγμάτων k8s μοιάζει με αυτό:
- Πάρτε Kubespray από το Southbridge, ελέγξτε με το νήμα μας, Merjim.
- Διαθέτουμε την ενημέρωση σε στρες- "Κύβος".
- Διαθέτουμε την ενημέρωση έναν κόμβο τη φορά (στο Ansible αυτό είναι "σειριακό: 1") στο Dev- "Κύβος".
- Ενημερώνουμε Prod το απόγευμα του Σαββάτου ένας κόμβος τη φορά.
Υπάρχουν σχέδια για αντικατάστασή του στο μέλλον Kubespray για κάτι πιο γρήγορο και πήγαινε στο kubeadm.
Συνολικά έχουμε τρεις «Κύβους»: Stress, Dev και Prod. Σχεδιάζουμε να κυκλοφορήσουμε άλλο ένα (ζεστή αναμονή) Prod-“Cube” στο δεύτερο κέντρο δεδομένων. στρες и Dev ζείτε σε «εικονικές μηχανές» (oVirt για το Stress και VMWare cloud για Dev). Prod- Το "Cube" ζει σε "γυμνό μέταλλο": πρόκειται για πανομοιότυπους κόμβους με 32 νήματα CPU, 64-128 GB μνήμης και 300 GB SSD RAID 10 - υπάρχουν 50 από αυτούς συνολικά. Τρεις «λεπτοί» κόμβοι είναι αφιερωμένοι στους «μάστερ» Prod- "Cuba": 16 GB μνήμης, 12 νήματα CPU.
Για τις πωλήσεις, προτιμούμε να χρησιμοποιούμε "γυμνό μέταλλο" και να αποφεύγουμε περιττές στρώσεις όπως OpenStack: δεν χρειαζόμαστε "θορυβώδεις γείτονες" και CPU κλέψουν χρόνο. Και η πολυπλοκότητα της διαχείρισης διπλασιάζεται περίπου στην περίπτωση του in-house OpenStack.
Για CI/CD "Cubic" και άλλα στοιχεία υποδομής χρησιμοποιούμε έναν ξεχωριστό διακομιστή GIT, το Helm 3 (ήταν μια μάλλον επώδυνη μετάβαση από το Helm 2, αλλά είμαστε πολύ ευχαριστημένοι με τις επιλογές ατομικός), Jenkins, Ansible και Docker. Αγαπάμε τα υποκαταστήματα δυνατοτήτων και την ανάπτυξη σε διαφορετικά περιβάλλοντα από ένα αποθετήριο.
Συμπέρασμα
Αυτό είναι, σε γενικές γραμμές, πώς φαίνεται η διαδικασία DevOps στο DomClick από την οπτική γωνία ενός μηχανικού λειτουργιών. Το άρθρο αποδείχθηκε λιγότερο τεχνικό από ό,τι περίμενα: επομένως, ακολουθήστε τις ειδήσεις του DomClick στο Habré: θα υπάρχουν περισσότερα «σκληροπυρηνικά» άρθρα για το Kubernetes και άλλα.
Πηγή: www.habr.com