27 Απριλίου στο συνέδριο , ως μέρος της ενότητας "DevOps", δόθηκε η αναφορά "Αυτόματη κλιμάκωση και διαχείριση πόρων στο Kubernetes". Μιλάει για το πώς μπορείτε να χρησιμοποιήσετε τα K8 για να εξασφαλίσετε υψηλή διαθεσιμότητα των εφαρμογών σας και να εξασφαλίσετε κορυφαία απόδοση.
Κατά την παράδοση, είμαστε στην ευχάριστη θέση να παρουσιάσουμε (44 λεπτά, πολύ πιο κατατοπιστικό από το άρθρο) και η κύρια περίληψη σε μορφή κειμένου. Πηγαίνω!
Ας αναλύσουμε λέξη προς λέξη το θέμα της έκθεσης και ας ξεκινήσουμε από το τέλος.
Kubernetes
Ας υποθέσουμε ότι έχουμε κοντέινερ Docker στον οικοδεσπότη μας. Για τι? Για να εξασφαλιστεί η επαναληψιμότητα και η απομόνωση, η οποία με τη σειρά της επιτρέπει την απλή και καλή ανάπτυξη, CI/CD. Έχουμε πολλά τέτοια οχήματα με κοντέινερ.
Τι παρέχει η Kubernetes σε αυτή την περίπτωση;
- Σταματάμε να σκεφτόμαστε αυτά τα μηχανήματα και αρχίζουμε να δουλεύουμε με το «σύννεφο» συστάδα δοχείων ή λοβούς (ομάδες δοχείων).
- Επιπλέον, δεν σκεφτόμαστε καν μεμονωμένες ομάδες, αλλά διαχειριζόμαστε περισσότεραоμεγαλύτερες ομάδες. Τέτοιος πρωτόγονα υψηλού επιπέδου επιτρέψτε μας να πούμε ότι υπάρχει ένα πρότυπο για την εκτέλεση ενός συγκεκριμένου φόρτου εργασίας και εδώ είναι ο απαιτούμενος αριθμός παρουσιών για την εκτέλεση του. Εάν στη συνέχεια αλλάξουμε το πρότυπο, όλες οι παρουσίες θα αλλάξουν.
- Με δηλωτικό API Αντί να εκτελέσουμε μια ακολουθία συγκεκριμένων εντολών, περιγράφουμε τη «δομή του κόσμου» (στο YAML), η οποία δημιουργείται από τον Kubernetes. Και πάλι: όταν αλλάξει η περιγραφή, θα αλλάξει και η πραγματική της εμφάνιση.
Έλεγχος των αναγκών
CPU
Ας τρέξουμε nginx, php-fpm και mysql στον διακομιστή. Αυτές οι υπηρεσίες θα έχουν στην πραγματικότητα ακόμη περισσότερες διεργασίες που εκτελούνται, καθεμία από τις οποίες απαιτεί υπολογιστικούς πόρους:
(οι αριθμοί στη διαφάνεια είναι «παπαγάλοι», η αφηρημένη ανάγκη κάθε διαδικασίας για υπολογιστική ισχύ)
Για να διευκολυνθεί η εργασία με αυτό, είναι λογικό να συνδυάζονται διεργασίες σε ομάδες (για παράδειγμα, όλες οι διεργασίες nginx σε μια ομάδα "nginx"). Ένας απλός και προφανής τρόπος για να γίνει αυτό είναι να τοποθετήσετε κάθε ομάδα σε ένα δοχείο:
Για να συνεχίσετε, πρέπει να θυμάστε τι είναι ένα κοντέινερ (στο Linux). Η εμφάνισή τους έγινε δυνατή χάρη σε τρία βασικά χαρακτηριστικά στον πυρήνα, που εφαρμόστηκαν εδώ και πολύ καιρό: , и . Και η περαιτέρω ανάπτυξη διευκολύνθηκε από άλλες τεχνολογίες (συμπεριλαμβανομένων των βολικών "κελυφών" όπως το Docker):
Στο πλαίσιο της έκθεσης, μας ενδιαφέρει μόνο ομάδες, γιατί οι ομάδες ελέγχου είναι το μέρος της λειτουργικότητας των κοντέινερ (Docker κ.λπ.) που υλοποιεί τη διαχείριση πόρων. Οι διαδικασίες συνδυασμένες σε ομάδες, όπως θέλαμε, είναι ομάδες ελέγχου.
Ας επιστρέψουμε στις απαιτήσεις CPU για αυτές τις διεργασίες και τώρα για ομάδες διεργασιών:
(Επαναλαμβάνω ότι όλοι οι αριθμοί είναι μια αφηρημένη έκφραση της ανάγκης για πόρους)
Ταυτόχρονα, η ίδια η CPU έχει έναν συγκεκριμένο πεπερασμένο πόρο (στο παράδειγμα αυτό είναι 1000), που μπορεί να λείπει από όλους (το άθροισμα των αναγκών όλων των ομάδων είναι 150+850+460=1460). Τι θα γίνει σε αυτή την περίπτωση;
Ο πυρήνας αρχίζει να διανέμει πόρους και το κάνει «δίκαια», δίνοντας τον ίδιο αριθμό πόρων σε κάθε ομάδα. Αλλά στην πρώτη περίπτωση, υπάρχουν περισσότερα από αυτά που χρειάζονται (333>150), επομένως το πλεόνασμα (333-150=183) παραμένει στο αποθεματικό, το οποίο επίσης κατανέμεται εξίσου μεταξύ δύο άλλων δοχείων:
Ως αποτέλεσμα: το πρώτο κοντέινερ είχε αρκετούς πόρους, το δεύτερο - δεν είχε αρκετούς πόρους, το τρίτο - δεν είχε αρκετούς πόρους. Αυτό είναι αποτέλεσμα πράξεων "τίμιος" προγραμματιστής στο Linux - . Η λειτουργία του μπορεί να ρυθμιστεί χρησιμοποιώντας την ανάθεση βάρη καθένα από τα δοχεία. Για παράδειγμα, όπως αυτό:
Ας δούμε την περίπτωση έλλειψης πόρων στο δεύτερο κοντέινερ (php-fpm). Όλοι οι πόροι κοντέινερ κατανέμονται εξίσου μεταξύ των διεργασιών. Ως αποτέλεσμα, η κύρια διαδικασία λειτουργεί καλά, αλλά όλοι οι εργαζόμενοι επιβραδύνουν, λαμβάνοντας λιγότερο από το μισό από αυτό που χρειάζονται:
Αυτός είναι ο τρόπος με τον οποίο λειτουργεί ο προγραμματιστής CFS. Θα ονομάσουμε περαιτέρω τα βάρη που εκχωρούμε σε δοχεία αιτήσεων. Γιατί συμβαίνει αυτό - δείτε περαιτέρω.
Ας δούμε την όλη κατάσταση από την άλλη πλευρά. Όπως γνωρίζετε, όλοι οι δρόμοι οδηγούν στη Ρώμη, και στην περίπτωση ενός υπολογιστή, στην CPU. Μία CPU, πολλές εργασίες - χρειάζεστε ένα φανάρι. Ο απλούστερος τρόπος διαχείρισης πόρων είναι το «φανάρι»: έδωσαν σε μια διεργασία σταθερό χρόνο πρόσβασης στην CPU, μετά στην επόμενη κ.λπ.
Αυτή η προσέγγιση ονομάζεται σκληρές ποσοστώσεις (σκληρός περιορισμός). Ας το θυμόμαστε απλά ως όρια. Ωστόσο, εάν διανείμετε όρια σε όλα τα κοντέινερ, προκύπτει ένα πρόβλημα: η mysql οδηγούσε κατά μήκος του δρόμου και κάποια στιγμή τελείωσε η ανάγκη της για CPU, αλλά όλες οι άλλες διεργασίες αναγκάζονται να περιμένουν έως ότου η CPU αδρανής.
Ας επιστρέψουμε στον πυρήνα του Linux και στην αλληλεπίδρασή του με την CPU - η συνολική εικόνα είναι η εξής:
Το cgroup έχει δύο ρυθμίσεις - ουσιαστικά αυτές είναι δύο απλές "ανατροπές" που σας επιτρέπουν να προσδιορίσετε:
- βάρος για το δοχείο (αιτήματα) είναι μερίδια;
- ποσοστό του συνολικού χρόνου CPU για εργασία σε εργασίες κοντέινερ (όρια) είναι ποσοστό.
Πώς να μετρήσετε την CPU;
Υπάρχουν διάφοροι τρόποι:
- Τι είναι παπαγάλοι, κανείς δεν ξέρει - πρέπει να διαπραγματεύεστε κάθε φορά.
- Το ενδιαφέρον πιο ξεκάθαρο, αλλά σχετικό: το 50% ενός διακομιστή με 4 πυρήνες και με 20 πυρήνες είναι εντελώς διαφορετικά πράγματα.
- Μπορείτε να χρησιμοποιήσετε αυτά που έχουν ήδη αναφερθεί βάρη, που το Linux γνωρίζει, αλλά είναι και σχετικά.
- Η πιο κατάλληλη επιλογή είναι η μέτρηση των υπολογιστικών πόρων δευτερόλεπτα. Εκείνοι. σε δευτερόλεπτα χρόνου επεξεργαστή σε σχέση με δευτερόλεπτα πραγματικού χρόνου: δόθηκε 1 δευτερόλεπτο χρόνου επεξεργαστή ανά 1 πραγματικό δευτερόλεπτο - αυτός είναι ένας ολόκληρος πυρήνας CPU.
Για να είναι ακόμα πιο εύκολο να μιλήσουν, άρχισαν να μετρούν απευθείας πυρήνες, που σημαίνει από αυτούς τον ίδιο χρόνο CPU σε σχέση με τον πραγματικό. Δεδομένου ότι το Linux καταλαβαίνει τα βάρη, αλλά όχι τόσο πολύ χρόνο/πυρήνες CPU, χρειαζόταν ένας μηχανισμός για τη μετάφραση από το ένα στο άλλο.
Ας εξετάσουμε ένα απλό παράδειγμα με έναν διακομιστή με 3 πυρήνες CPU, όπου σε τρία pods θα δοθούν βάρη (500, 1000 και 1500) που μετατρέπονται εύκολα στα αντίστοιχα μέρη των πυρήνων που τους εκχωρούνται (0,5, 1 και 1,5).
Εάν πάρετε έναν δεύτερο διακομιστή, όπου θα υπάρχουν διπλάσιοι πυρήνες (6), και τοποθετήσετε τους ίδιους λοβούς εκεί, η κατανομή των πυρήνων μπορεί εύκολα να υπολογιστεί πολλαπλασιάζοντας απλά με το 2 (1, 2 και 3, αντίστοιχα). Αλλά μια σημαντική στιγμή εμφανίζεται όταν ένα τέταρτο pod εμφανίζεται σε αυτόν τον διακομιστή, του οποίου το βάρος, για λόγους ευκολίας, θα είναι 3000. Αφαιρεί μέρος των πόρων της CPU (τους μισούς πυρήνες) και για τα υπόλοιπα pods υπολογίζονται εκ νέου (μειώνονται στο μισό):
Kubernetes και πόροι CPU
Στο Kubernetes, οι πόροι της CPU συνήθως μετρώνται σε milliadrax, δηλ. Ως βασικό βάρος λαμβάνονται 0,001 πυρήνες. (Το ίδιο πράγμα στην ορολογία Linux/cgroups ονομάζεται μερίδιο CPU, αν και, πιο συγκεκριμένα, 1000 millicores = 1024 μερίδια CPU.) Το K8s διασφαλίζει ότι δεν τοποθετεί περισσότερα pods στον διακομιστή από ό,τι υπάρχουν πόροι CPU για το άθροισμα των βαρών όλων των pods.
Πώς συμβαίνει αυτό; Όταν προσθέτετε έναν διακομιστή σε ένα σύμπλεγμα Kubernetes, αναφέρεται πόσους πυρήνες CPU έχει διαθέσιμους. Και όταν δημιουργείτε ένα νέο pod, ο προγραμματιστής Kubernetes γνωρίζει πόσους πυρήνες θα χρειαστεί αυτό το pod. Έτσι, το pod θα εκχωρηθεί σε έναν διακομιστή όπου υπάρχουν αρκετοί πυρήνες.
Τι θα συμβεί αν όχι προσδιορίζεται το αίτημα (δηλαδή το pod δεν έχει καθορισμένο αριθμό πυρήνων που χρειάζεται); Ας καταλάβουμε πώς το Kubernetes μετράει γενικά τους πόρους.
Για ένα pod, μπορείτε να καθορίσετε τόσο αιτήματα (χρονοπρογραμματιστής CFS) όσο και όρια (θυμάστε το φανάρι;):
- Εάν καθορίζονται ίσα, τότε στο pod εκχωρείται μια κλάση QoS εγγυημένη. Αυτός ο αριθμός πυρήνων που είναι πάντα διαθέσιμος είναι εγγυημένος.
- Εάν το αίτημα είναι μικρότερο από το όριο - κλάση QoS διαρρηγμένος. Εκείνοι. Αναμένουμε ένα pod, για παράδειγμα, να χρησιμοποιεί πάντα 1 πυρήνα, αλλά αυτή η τιμή δεν αποτελεί περιορισμό για αυτόν: μερικές φορές Το pod μπορεί να χρησιμοποιήσει περισσότερα (όταν ο διακομιστής έχει δωρεάν πόρους για αυτό).
- Υπάρχει επίσης μια τάξη QoS καλύτερη προσπάθεια — περιλαμβάνει τις ίδιες ομάδες για τις οποίες δεν προσδιορίζεται το αίτημα. Οι πόροι τους δίνονται τελευταίοι.
Μνήμη
Με τη μνήμη, η κατάσταση είναι παρόμοια, αλλά ελαφρώς διαφορετική - τελικά, η φύση αυτών των πόρων είναι διαφορετική. Σε γενικές γραμμές, η αναλογία έχει ως εξής:
Ας δούμε πώς υλοποιούνται τα αιτήματα στη μνήμη. Αφήστε τα pod να ζουν στον διακομιστή, αλλάζοντας την κατανάλωση μνήμης, έως ότου ένα από αυτά γίνει τόσο μεγάλο ώστε να εξαντληθεί η μνήμη του. Σε αυτήν την περίπτωση, εμφανίζεται ο δολοφόνος OOM και σκοτώνει τη μεγαλύτερη διαδικασία:
Αυτό δεν μας ταιριάζει πάντα, επομένως είναι δυνατό να ρυθμίσουμε ποιες διαδικασίες είναι σημαντικές για εμάς και δεν πρέπει να σκοτωθούν. Για να το κάνετε αυτό, χρησιμοποιήστε την παράμετρο oom_score_adj.
Ας επιστρέψουμε στις κλάσεις QoS της CPU και ας σχεδιάσουμε μια αναλογία με τις τιμές oom_score_adj που καθορίζουν τις προτεραιότητες κατανάλωσης μνήμης για τα pods:
- Η χαμηλότερη τιμή oom_score_adj για μια ομάδα - -998 - σημαίνει ότι μια τέτοια ομάδα θα πρέπει να σκοτωθεί τελευταία, αυτό εγγυημένη.
- Το υψηλότερο - 1000 - είναι καλύτερη προσπάθεια, τέτοιοι λοβοί σκοτώνονται πρώτα.
- Για να υπολογίσετε τις υπόλοιπες τιμές (διαρρηγμένος) υπάρχει μια φόρμουλα, η ουσία της οποίας συνοψίζεται στο γεγονός ότι όσο περισσότερους πόρους έχει ζητήσει ένα pod, τόσο λιγότερο πιθανό είναι να σκοτωθεί.
Η δεύτερη "συστροφή" - limit_in_bytes - για όρια. Με αυτό, όλα είναι απλούστερα: απλώς εκχωρούμε τη μέγιστη ποσότητα εκδοθείσας μνήμης και εδώ (σε αντίθεση με την CPU) δεν τίθεται θέμα πώς να τη μετρήσετε (μνήμη).
Σε συνολικά
Κάθε pod στο Kubernetes δίνεται requests и limits - και οι δύο παράμετροι για CPU και μνήμη:
- Βάσει αιτημάτων, λειτουργεί ο χρονοπρογραμματιστής Kubernetes, ο οποίος διανέμει τα pods μεταξύ των διακομιστών.
- Με βάση όλες τις παραμέτρους, προσδιορίζεται η κλάση QoS του pod.
- Τα σχετικά βάρη υπολογίζονται με βάση τα αιτήματα της CPU.
- ο προγραμματιστής CFS έχει ρυθμιστεί με βάση αιτήματα CPU.
- Το OOM killer έχει ρυθμιστεί βάσει αιτημάτων μνήμης.
- ένα "φανάρι" έχει διαμορφωθεί με βάση τα όρια της CPU.
- Με βάση τα όρια μνήμης, διαμορφώνεται ένα όριο για την cgroup.
Γενικά, αυτή η εικόνα απαντά σε όλες τις ερωτήσεις σχετικά με το πώς συμβαίνει το κύριο μέρος της διαχείρισης πόρων στο Kubernetes.
Αυτόματη κλιμάκωση
K8s cluster-autoscaler
Ας φανταστούμε ότι ολόκληρο το σύμπλεγμα είναι ήδη κατειλημμένο και πρέπει να δημιουργηθεί ένα νέο pod. Ενώ το pod δεν μπορεί να εμφανιστεί, παραμένει σε κατάσταση εκκρεμής. Για να εμφανιστεί, μπορούμε να συνδέσουμε έναν νέο διακομιστή στο σύμπλεγμα ή να... εγκαταστήσουμε το cluster-autoscaler, το οποίο θα το κάνει για εμάς: να παραγγείλετε μια εικονική μηχανή από τον πάροχο cloud (χρησιμοποιώντας ένα αίτημα API) και να τη συνδέσουμε στο σύμπλεγμα , μετά την οποία θα προστεθεί το pod.
Πρόκειται για αυτόματη κλιμάκωση του συμπλέγματος Kubernetes, το οποίο λειτουργεί εξαιρετικά (από την εμπειρία μας). Ωστόσο, όπως και αλλού, υπάρχουν κάποιες αποχρώσεις εδώ...
Όσο αυξήσαμε το μέγεθος του συμπλέγματος, όλα ήταν εντάξει, αλλά τι συμβαίνει όταν το σύμπλεγμα άρχισε να απελευθερώνεται? Το πρόβλημα είναι ότι η μετεγκατάσταση pods (για την απελευθέρωση κεντρικών υπολογιστών) είναι πολύ τεχνικά δύσκολη και δαπανηρή από άποψη πόρων. Η Kubernetes χρησιμοποιεί μια εντελώς διαφορετική προσέγγιση.
Εξετάστε ένα σύμπλεγμα 3 διακομιστών που διαθέτει Deployment. Έχει 6 pods: τώρα υπάρχουν 2 για κάθε διακομιστή. Για κάποιο λόγο θέλαμε να απενεργοποιήσουμε έναν από τους διακομιστές. Για να το κάνουμε αυτό θα χρησιμοποιήσουμε την εντολή kubectl drain, οι οποίες:
- θα απαγορεύσει την αποστολή νέων pods σε αυτόν τον διακομιστή.
- θα διαγράψει τα υπάρχοντα pod στο διακομιστή.
Δεδομένου ότι το Kubernetes είναι υπεύθυνο για τη διατήρηση του αριθμού των λοβών (6), απλά θα αναδημιουργήσει σε άλλους κόμβους, αλλά όχι σε αυτόν που είναι απενεργοποιημένος, καθώς έχει ήδη επισημανθεί ως μη διαθέσιμος για τη φιλοξενία νέων ομάδων. Αυτός είναι ένας θεμελιώδης μηχανικός για την Kubernetes.
Ωστόσο, υπάρχει και εδώ μια απόχρωση. Σε παρόμοια κατάσταση, για το StatefulSet (αντί για το Deployment), οι ενέργειες θα είναι διαφορετικές. Τώρα έχουμε ήδη μια εφαρμογή κατάστασης - για παράδειγμα, τρία pod με MongoDB, ένα από τα οποία έχει κάποιο είδος προβλήματος (τα δεδομένα έχουν καταστραφεί ή άλλο σφάλμα που εμποδίζει την σωστή εκκίνηση του pod). Και πάλι αποφασίζουμε να απενεργοποιήσουμε έναν διακομιστή. Τι θα συμβεί?
MongoDB θα μπορούσε πεθάνει επειδή χρειάζεται απαρτία: για ένα σύμπλεγμα τριών εγκαταστάσεων, πρέπει να λειτουργούν τουλάχιστον δύο. Ωστόσο, αυτό δεν συμβαίνει - χάρη σε PodDisruptionBudget. Αυτή η παράμετρος καθορίζει τον ελάχιστο απαιτούμενο αριθμό λοβών εργασίας. Γνωρίζοντας ότι ένα από τα pods MongoDB δεν λειτουργεί πλέον και βλέποντας ότι το PodDisruptionBudget έχει οριστεί για MongoDB minAvailable: 2, Το Kubernetes δεν θα σας επιτρέψει να διαγράψετε ένα pod.
Κατώτατη γραμμή: για να λειτουργήσει σωστά η κίνηση (και μάλιστα η εκ νέου δημιουργία) των pod κατά την απελευθέρωση του cluster, είναι απαραίτητο να διαμορφώσετε το PodDisruptionBudget.
Οριζόντια κλιμάκωση
Ας εξετάσουμε μια άλλη κατάσταση. Υπάρχει μια εφαρμογή που εκτελείται ως Deployment στο Kubernetes. Η επισκεψιμότητα των χρηστών έρχεται στις ομάδες του (για παράδειγμα, υπάρχουν τρία από αυτά) και μετράμε έναν συγκεκριμένο δείκτη σε αυτά (ας πούμε, το φορτίο της CPU). Όταν το φορτίο αυξάνεται, το καταγράφουμε σε ένα χρονοδιάγραμμα και αυξάνουμε τον αριθμό των ομάδων για τη διανομή αιτημάτων.
Σήμερα στο Kubernetes αυτό δεν χρειάζεται να γίνει χειροκίνητα: διαμορφώνεται μια αυτόματη αύξηση/μείωση του αριθμού των pods ανάλογα με τις τιμές των δεικτών μέτρησης φορτίου.
Τα βασικά ερωτήματα εδώ είναι: τι ακριβώς να μετρήσω и πώς να ερμηνεύσω λαμβανόμενες τιμές (για τη λήψη απόφασης σχετικά με την αλλαγή του αριθμού των λοβών). Μπορείτε να μετρήσετε πολλά:
Πώς να το κάνετε αυτό τεχνικά - συλλέξτε μετρήσεις κ.λπ. — Μίλησα αναλυτικά στην έκθεση για . Και η κύρια συμβουλή για την επιλογή των βέλτιστων παραμέτρων είναι πείραμα!
Υπάρχει (Κορεσμός χρήσης και σφάλματα), η έννοια του οποίου έχει ως εξής. Σε ποια βάση έχει νόημα η κλίμακα, για παράδειγμα, php-fpm; Με βάση το γεγονός ότι οι εργαζόμενοι εξαντλούνται, αυτό είναι χρησιμοποίηση. Και αν εξαντληθούν οι εργαζόμενοι και δεν γίνουν δεκτές νέες συνδέσεις, αυτό είναι ήδη κορεσμός. Και οι δύο αυτές παράμετροι πρέπει να μετρηθούν και ανάλογα με τις τιμές πρέπει να γίνει κλιμάκωση.
Αντί για ένα συμπέρασμα
Η αναφορά έχει μια συνέχεια: σχετικά με την κατακόρυφη κλίμακα και τον τρόπο επιλογής των σωστών πόρων. Θα μιλήσω για αυτό σε μελλοντικά βίντεο - Εγγραφείτε για να μην χάσετε!
Βίντεο και διαφάνειες
Βίντεο από την παράσταση (44 λεπτά):
Παρουσίαση της έκθεσης:
PS
Άλλες αναφορές για το Kubernetes στο ιστολόγιό μας:
- «» (Andrey Polovov; 8 Απριλίου 2019 στο Saint HighLoad++);
- «» (Dmitry Stolyarov, 8 Νοεμβρίου 2018 στο HighLoad++);
- «» (Dmitry Stolyarov; 28 Μαΐου 2018 στο RootConf);
- «» (Dmitry Stolyarov, 7 Νοεμβρίου 2017 στο HighLoad++);
- «» (Dmitry Stolyarov, 6 Ιουνίου 2017 στο RootConf).
Πηγή: www.habr.com