Πίσω στο 2016 είμαστε στο Buffer , και τώρα περίπου 60 κόμβοι (στο AWS) και 1500 κοντέινερ εργάζονται στο σύμπλεγμα k8s που διαχειρίζεται . Ωστόσο, μεταφερθήκαμε στις microservices μέσω δοκιμής και λάθους, και ακόμη και μετά από αρκετά χρόνια εργασίας με τα k8 εξακολουθούμε να αντιμετωπίζουμε νέα προβλήματα. Σε αυτή την ανάρτηση θα μιλήσουμε για περιορισμοί επεξεργαστή: γιατί πιστεύαμε ότι ήταν καλή πρακτική και γιατί τελικά δεν ήταν τόσο καλές.
Περιορισμοί επεξεργαστή και στραγγαλισμός
Όπως πολλοί άλλοι χρήστες του Kubernetes, . Χωρίς μια τέτοια ρύθμιση, τα κοντέινερ σε έναν κόμβο μπορούν να καταλάβουν όλη την ισχύ του επεξεργαστή, κάτι που με τη σειρά του προκαλεί σημαντικές διαδικασίες Kubernetes (για παράδειγμα kubelet) θα σταματήσει να ανταποκρίνεται σε αιτήματα. Έτσι, η ρύθμιση ορίων CPU είναι ένας καλός τρόπος για να προστατεύσετε τους κόμβους σας.
Τα όρια του επεξεργαστή ορίζουν ένα κοντέινερ στο μέγιστο χρόνο CPU που μπορεί να χρησιμοποιήσει για μια συγκεκριμένη περίοδο (η προεπιλογή είναι 100 ms) και το κοντέινερ δεν θα υπερβεί ποτέ αυτό το όριο. Στο Kubernetes για στραγγαλισμός δοχείο και να μην υπερβεί το όριο, χρησιμοποιείται ειδικό εργαλείο , αλλά αυτά τα τεχνητά όρια CPU καταλήγουν να βλάπτουν την απόδοση και να αυξάνουν τον χρόνο απόκρισης των κοντέινερ σας.
Τι μπορεί να συμβεί αν δεν θέσουμε όρια επεξεργαστή;
Δυστυχώς, εμείς οι ίδιοι έπρεπε να αντιμετωπίσουμε αυτό το πρόβλημα. Κάθε κόμβος έχει μια διαδικασία υπεύθυνη για τη διαχείριση των κοντέινερ kubelet, και σταμάτησε να ανταποκρίνεται σε αιτήματα. Ο κόμβος, όταν συμβεί αυτό, θα μεταβεί στην κατάσταση NotReady, και τα κοντέινερ από αυτό θα ανακατευθυνθούν κάπου αλλού και θα δημιουργήσουν τα ίδια προβλήματα σε νέους κόμβους. Δεν είναι το ιδανικό σενάριο, τουλάχιστον.
Εκδήλωση του προβλήματος στραγγαλισμού και απόκρισης
Η βασική μέτρηση για την παρακολούθηση κοντέινερ είναι trottling, δείχνει πόσες φορές έχει στραγγαλιστεί το κοντέινερ σας. Παρατηρήσαμε με ενδιαφέρον την παρουσία στραγγαλισμού σε ορισμένα κοντέινερ, ανεξάρτητα από το αν το φορτίο του επεξεργαστή ήταν ακραίο ή όχι. Για παράδειγμα, ας ρίξουμε μια ματιά σε ένα από τα κύρια API μας:
Όπως μπορείτε να δείτε παρακάτω, έχουμε θέσει το όριο σε 800m (0.8 ή 80% πυρήνα) και οι μέγιστες τιμές στην καλύτερη δυνατή προσέγγιση 200m (20% πυρήνας). Φαίνεται ότι πριν σβήσουμε την υπηρεσία έχουμε ακόμα αρκετή ισχύ επεξεργαστή, ωστόσο...
Μπορεί να έχετε παρατηρήσει ότι ακόμη και όταν το φορτίο του επεξεργαστή είναι κάτω από τα καθορισμένα όρια - σημαντικά χαμηλότερο - εξακολουθεί να εμφανίζεται στραγγαλισμός.
Αντιμέτωποι με αυτό, σύντομα ανακαλύψαμε αρκετούς πόρους (, , ) σχετικά με την πτώση της απόδοσης και του χρόνου απόκρισης των υπηρεσιών λόγω στραγγαλισμού.
Γιατί βλέπουμε στραγγαλισμό σε χαμηλό φορτίο CPU; Η σύντομη έκδοση είναι: "υπάρχει ένα σφάλμα στον πυρήνα του Linux που προκαλεί περιττό στραγγαλισμό κοντέινερ με καθορισμένα όρια επεξεργαστή." Εάν ενδιαφέρεστε για τη φύση του προβλήματος, μπορείτε να διαβάσετε την παρουσίαση ( и επιλογές) από τον Dave Chiluk.
Κατάργηση περιορισμών CPU (με εξαιρετική προσοχή)
Μετά από μακροχρόνιες συζητήσεις, αποφασίσαμε να καταργήσουμε τους περιορισμούς επεξεργαστών από όλες τις υπηρεσίες που επηρέαζαν άμεσα ή έμμεσα την κρίσιμη λειτουργικότητα των χρηστών μας.
Η απόφαση δεν ήταν εύκολη γιατί εκτιμούμε ιδιαίτερα τη σταθερότητα του cluster μας. Στο παρελθόν, έχουμε ήδη πειραματιστεί με την αστάθεια του συμπλέγματός μας και στη συνέχεια οι υπηρεσίες κατανάλωσαν πάρα πολλούς πόρους και επιβράδυναν τη δουλειά ολόκληρου του κόμβου τους. Τώρα όλα ήταν κάπως διαφορετικά: είχαμε ξεκάθαρη κατανόηση του τι περιμέναμε από τα clusters μας, καθώς και μια καλή στρατηγική για την εφαρμογή των προγραμματισμένων αλλαγών.
Επαγγελματική αλληλογραφία για ένα πιεστικό ζήτημα.
Πώς να προστατεύσετε τους κόμβους σας όταν αίρονται οι περιορισμοί;
Απομόνωση «απεριόριστων» υπηρεσιών:
Στο παρελθόν, έχουμε ήδη δει ορισμένους κόμβους να μπαίνουν σε κατάσταση notReady, κυρίως λόγω υπηρεσιών που κατανάλωσαν πάρα πολλούς πόρους.
Αποφασίσαμε να τοποθετήσουμε τέτοιες υπηρεσίες σε χωριστούς (με "ετικέτες") κόμβους έτσι ώστε να μην παρεμβαίνουν σε "σχετικές" υπηρεσίες. Ως αποτέλεσμα, επισημαίνοντας ορισμένους κόμβους και προσθέτοντας την παράμετρο ανοχής σε «άσχετες» υπηρεσίες, επιτύχαμε μεγαλύτερο έλεγχο στο σύμπλεγμα και έγινε πιο εύκολο για εμάς να εντοπίσουμε προβλήματα με τους κόμβους. Για να πραγματοποιήσετε παρόμοιες διαδικασίες μόνοι σας, μπορείτε να εξοικειωθείτε .
Εκχώρηση ενός σωστού αιτήματος επεξεργαστή και μνήμης:
Ο μεγαλύτερος φόβος μας ήταν ότι η διαδικασία θα κατανάλωνε πάρα πολλούς πόρους και ο κόμβος θα σταματούσε να ανταποκρίνεται σε αιτήματα. Εφόσον τώρα (χάρη στο Datadog) μπορούσαμε να παρακολουθούμε ξεκάθαρα όλες τις υπηρεσίες στο σύμπλεγμα μας, ανέλυσα αρκετούς μήνες λειτουργίας εκείνων που σχεδιάζαμε να χαρακτηρίσουμε ως «άσχετες». Απλώς ορίζω τη μέγιστη χρήση της CPU με ένα περιθώριο 20%, και έτσι εκχωρώ χώρο στον κόμβο σε περίπτωση που το k8s προσπαθήσει να εκχωρήσει άλλες υπηρεσίες στον κόμβο.
Όπως μπορείτε να δείτε στο γράφημα, το μέγιστο φορτίο στον επεξεργαστή έχει φτάσει 242m Πυρήνες CPU (0.242 πυρήνες επεξεργαστή). Για ένα αίτημα επεξεργαστή, αρκεί να πάρετε έναν αριθμό ελαφρώς μεγαλύτερο από αυτήν την τιμή. Λάβετε υπόψη ότι δεδομένου ότι οι υπηρεσίες επικεντρώνονται στο χρήστη, οι τιμές φορτίου αιχμής συμπίπτουν με την κίνηση.
Κάντε το ίδιο με τη χρήση μνήμης και τα ερωτήματα και το voila - είστε έτοιμοι! Για μεγαλύτερη ασφάλεια, μπορείτε να προσθέσετε οριζόντια αυτόματη κλιμάκωση pod. Έτσι, κάθε φορά που το φορτίο πόρων είναι υψηλό, η αυτόματη κλιμάκωση θα δημιουργεί νέα pods και τα kubernetes θα τα διανέμουν σε κόμβους με ελεύθερο χώρο. Σε περίπτωση που δεν υπάρχει χώρος στο ίδιο το σύμπλεγμα, μπορείτε να ορίσετε στον εαυτό σας μια ειδοποίηση ή να διαμορφώσετε την προσθήκη νέων κόμβων μέσω της αυτόματης κλιμάκωσής τους.
Από τα μειονεκτήματα, αξίζει να σημειωθεί ότι χάσαμε στο "", δηλ. αριθμός κοντέινερ που εκτελούνται σε έναν κόμβο. Μπορεί επίσης να έχουμε πολλές «χαλαρώσεις» σε χαμηλή πυκνότητα κυκλοφορίας και υπάρχει επίσης πιθανότητα να φτάσετε σε υψηλό φορτίο επεξεργαστή, αλλά οι κόμβοι αυτόματης κλιμάκωσης θα βοηθήσουν με το τελευταίο.
Ευρήματα
Είμαι στην ευχάριστη θέση να δημοσιεύσω αυτά τα εξαιρετικά αποτελέσματα από πειράματα των τελευταίων εβδομάδων. Έχουμε ήδη δει σημαντικές βελτιώσεις ως προς την απόκριση σε όλες τις τροποποιημένες υπηρεσίες:
Πετύχαμε τα καλύτερα αποτελέσματα στην αρχική μας σελίδα (), εκεί η υπηρεσία επιταχύνθηκε είκοσι δύο φορές!
Διορθώθηκε το σφάλμα του πυρήνα του Linux;
Ναι, διανομές έκδοση 4.19 και νεότερη.
Ωστόσο, κατά την ανάγνωση για τη δεύτερη Σεπτεμβρίου 2020 εξακολουθούμε να συναντάμε αναφορές για ορισμένα έργα Linux με παρόμοιο σφάλμα. Πιστεύω ότι ορισμένες διανομές Linux εξακολουθούν να έχουν αυτό το σφάλμα και απλώς εργάζονται για να το διορθώσουν.
Εάν η έκδοση διανομής σας είναι χαμηλότερη από 4.19, θα συνιστούσα να κάνετε ενημέρωση στην πιο πρόσφατη, αλλά σε κάθε περίπτωση θα πρέπει να προσπαθήσετε να αφαιρέσετε τους περιορισμούς του επεξεργαστή και να δείτε εάν ο περιορισμός επιμένει. Παρακάτω μπορείτε να δείτε μια μερική λίστα με υπηρεσίες διαχείρισης Kubernetes και διανομές Linux:
- Debian: επιδιόρθωση ενσωματωμένη στην τελευταία έκδοση της διανομής, και φαίνεται αρκετά φρέσκο (). Ορισμένες προηγούμενες εκδόσεις ενδέχεται επίσης να διορθωθούν.
- Ubuntu: επιδιόρθωση ενσωματωμένη στην τελευταία έκδοση
- Το EKS έχει διορθώσει ακόμα . Εάν η έκδοσή σας είναι χαμηλότερη από αυτήν, θα πρέπει να ενημερώσετε το AMI.
- κόπς: у
kops 1.18+Η κύρια εικόνα κεντρικού υπολογιστή θα είναι το Ubuntu 20.04. Εάν η έκδοση του kops σας είναι παλαιότερη, ίσως χρειαστεί να περιμένετε για μια επιδιόρθωση. Εμείς οι ίδιοι περιμένουμε τώρα. - GKE (Google Cloud): Ενσωματωμένη διόρθωση , ωστόσο υπάρχουν προβλήματα με το γκάζι .
Τι πρέπει να κάνετε εάν η επιδιόρθωση διόρθωσε το πρόβλημα στραγγαλισμού;
Δεν είμαι σίγουρος ότι το πρόβλημα έχει λυθεί πλήρως. Όταν φτάσουμε στην έκδοση του πυρήνα με την επιδιόρθωση, θα δοκιμάσω το σύμπλεγμα και θα ενημερώσω την ανάρτηση. Αν κάποιος έχει ήδη ενημερώσει, θα με ενδιέφερε να διαβάσω τα αποτελέσματά σας.
Συμπέρασμα
- Εάν εργάζεστε με κοντέινερ Docker υπό Linux (ανεξάρτητα από το Kubernetes, το Mesos, το Swarm ή άλλα), τα κοντέινερ σας ενδέχεται να χάσουν την απόδοση λόγω στραγγαλισμού.
- Δοκιμάστε να ενημερώσετε στην πιο πρόσφατη έκδοση της διανομής σας με την ελπίδα ότι το σφάλμα έχει ήδη διορθωθεί.
- Η κατάργηση των ορίων του επεξεργαστή θα λύσει το πρόβλημα, αλλά αυτή είναι μια επικίνδυνη τεχνική που πρέπει να χρησιμοποιείται με εξαιρετική προσοχή (είναι καλύτερα να ενημερώσετε πρώτα τον πυρήνα και να συγκρίνετε τα αποτελέσματα).
- Εάν έχετε αφαιρέσει τα όρια της CPU, παρακολουθήστε προσεκτικά τη χρήση της CPU και της μνήμης και βεβαιωθείτε ότι οι πόροι της CPU υπερβαίνουν την κατανάλωσή σας.
- Μια ασφαλής επιλογή θα ήταν η αυτόματη κλίμακα pods για τη δημιουργία νέων pods σε περίπτωση υψηλού φορτίου υλικού, έτσι ώστε το kubernetes να τα εκχωρεί σε ελεύθερους κόμβους.
Ελπίζω αυτή η ανάρτηση να σας βοηθήσει να βελτιώσετε την απόδοση των συστημάτων κοντέινερ σας.
PS ο συγγραφέας αλληλογραφεί με αναγνώστες και σχολιαστές (στα αγγλικά).
Πηγή: www.habr.com