Πώς οι προτεραιότητες pod στο Kubernetes προκάλεσαν διακοπές στα Grafana Labs

Σημείωση. μετάφρ.: Παρουσιάζουμε στην προσοχή σας τεχνικές λεπτομέρειες σχετικά με τους λόγους της πρόσφατης διακοπής λειτουργίας στην υπηρεσία cloud που διατηρούν οι δημιουργοί του Grafana. Αυτό είναι ένα κλασικό παράδειγμα του πώς ένα νέο και φαινομενικά εξαιρετικά χρήσιμο χαρακτηριστικό που έχει σχεδιαστεί για τη βελτίωση της ποιότητας της υποδομής... μπορεί να προκαλέσει βλάβη, εάν δεν προβλέπετε τις πολυάριθμες αποχρώσεις της εφαρμογής του στην πραγματικότητα της παραγωγής. Είναι υπέροχο όταν εμφανίζονται υλικά όπως αυτό που σας επιτρέπουν να μάθετε όχι μόνο από τα λάθη σας. Λεπτομέρειες υπάρχουν στη μετάφραση αυτού του κειμένου από τον αντιπρόεδρο του προϊόντος από τα Grafana Labs.

Πώς οι προτεραιότητες pod στο Kubernetes προκάλεσαν διακοπές στα Grafana Labs

Την Παρασκευή 19 Ιουλίου, η υπηρεσία Hosted Prometheus στο Grafana Cloud σταμάτησε να λειτουργεί για περίπου 30 λεπτά. Ζητώ συγγνώμη από όλους τους πελάτες που επηρεάστηκαν από τη διακοπή. Η δουλειά μας είναι να παρέχουμε τα εργαλεία παρακολούθησης που χρειάζεστε και καταλαβαίνουμε ότι η μη διαθεσιμότητα τους μπορεί να κάνει τη ζωή σας πιο δύσκολη. Λαμβάνουμε αυτό το περιστατικό εξαιρετικά σοβαρά. Αυτό το σημείωμα εξηγεί τι συνέβη, πώς αντιδράσαμε και τι κάνουμε για να διασφαλίσουμε ότι δεν θα συμβεί ξανά.

Ιστορικό

Η υπηρεσία Grafana Cloud Hosted Prometheus βασίζεται σε Φλοιός — Έργο CNCF για τη δημιουργία μιας οριζόντιας κλιμάκωσης, υψηλής διαθεσιμότητας, υπηρεσίας Prometheus πολλαπλών ενοικιαστών. Η αρχιτεκτονική Cortex αποτελείται από ένα σύνολο μεμονωμένων μικροϋπηρεσιών, καθεμία από τις οποίες εκτελεί τη δική της λειτουργία: αναπαραγωγή, αποθήκευση, ερωτήματα κ.λπ. Το Cortex βρίσκεται υπό ενεργό ανάπτυξη και προσθέτει συνεχώς νέες δυνατότητες και βελτιώνει την απόδοση. Αναπτύσσουμε τακτικά νέες εκδόσεις Cortex σε συμπλέγματα, ώστε οι πελάτες να μπορούν να επωφεληθούν από αυτές τις δυνατότητες - ευτυχώς, το Cortex μπορεί να ενημερώνεται χωρίς διακοπές λειτουργίας.

Για απρόσκοπτες ενημερώσεις, η υπηρεσία Ingester Cortex απαιτεί ένα επιπλέον αντίγραφο Ingester κατά τη διαδικασία ενημέρωσης. (Σημείωση. μετάφρ.: Ingester - το βασικό συστατικό του φλοιού. Η δουλειά του είναι να συλλέγει μια συνεχή ροή δειγμάτων, να τα ομαδοποιεί σε κομμάτια Prometheus και να τα αποθηκεύει σε μια βάση δεδομένων όπως το DynamoDB, το BigTable ή το Cassandra.) Αυτό επιτρέπει στους παλιούς χρήστες να προωθούν τα τρέχοντα δεδομένα σε νέους χρήστες. Αξίζει να σημειωθεί ότι οι ingesters απαιτούν πόρους. Για να λειτουργήσουν, πρέπει να έχετε 4 πυρήνες και 15 GB μνήμης ανά pod, δηλ. Το 25% της επεξεργαστικής ισχύος και της μνήμης του βασικού μηχανήματος στην περίπτωση των συμπλεγμάτων Kubernetes. Γενικά, έχουμε συνήθως πολύ περισσότερους αχρησιμοποίητους πόρους στο σύμπλεγμα από 4 πυρήνες και 15 GB μνήμης, επομένως μπορούμε εύκολα να περιστρέψουμε αυτά τα πρόσθετα ingesters κατά τις αναβαθμίσεις.

Ωστόσο, συμβαίνει συχνά ότι κατά την κανονική λειτουργία κανένα από τα μηχανήματα δεν έχει αυτό το 25% των αχρησιμοποίητων πόρων. Ναι, δεν προσπαθούμε καν: η CPU και η μνήμη θα είναι πάντα χρήσιμες για άλλες διεργασίες. Για να λύσουμε αυτό το πρόβλημα, αποφασίσαμε να χρησιμοποιήσουμε Προτεραιότητες του Kubernetes Pod. Η ιδέα είναι να δοθεί στους Ingesters υψηλότερη προτεραιότητα από άλλες μικροϋπηρεσίες (χωρίς ιθαγένεια). Όταν χρειάζεται να εκτελέσουμε ένα επιπλέον (N+1) Ingester, μετατοπίζουμε προσωρινά άλλα, μικρότερα pods. Αυτά τα pods μεταφέρονται σε δωρεάν πόρους σε άλλα μηχανήματα, αφήνοντας μια αρκετά μεγάλη «τρύπα» για να τρέξει ένα επιπλέον Ingester.

Την Πέμπτη, 18 Ιουλίου, παρουσιάσαμε τέσσερα νέα επίπεδα προτεραιότητας στα clusters μας: κρίσιμη, ψηλός, μέσος όρος и χαμηλός. Δοκιμάστηκαν σε ένα εσωτερικό σύμπλεγμα χωρίς κίνηση πελατών για περίπου μία εβδομάδα. Από προεπιλογή, ελήφθησαν ομάδες χωρίς καθορισμένη προτεραιότητα μέσος όρος προτεραιότητα, η τάξη ορίστηκε για Ingesters με υψηλό προτεραιότητα. Κρίσιμος δεσμεύτηκε για παρακολούθηση (Prometheus, Alertmanager, node-exporter, kube-state-metrics κ.λπ.). Η διαμόρφωση μας είναι ανοιχτή και μπορείτε να δείτε το PR εδώ.

Συντριβή

Την Παρασκευή, 19 Ιουλίου, ένας από τους μηχανικούς παρουσίασε ένα νέο αποκλειστικό σύμπλεγμα Cortex για έναν μεγάλο πελάτη. Η διαμόρφωση για αυτό το σύμπλεγμα δεν περιελάμβανε νέες προτεραιότητες ομάδων, επομένως σε όλες τις νέες ομάδες εκχωρήθηκε μια προεπιλεγμένη προτεραιότητα - μέσος όρος.

Το σύμπλεγμα Kubernetes δεν είχε αρκετούς πόρους για το νέο σύμπλεγμα Cortex και το υπάρχον σύμπλεγμα παραγωγής Cortex δεν ενημερώθηκε (Οι εισαγωγείς έμειναν χωρίς высокого προτεραιότητα). Δεδομένου ότι οι Ingesters του νέου συμπλέγματος είχαν από προεπιλογή μέσος όρος προτεραιότητας, και τα υπάρχοντα pods στην παραγωγή λειτούργησαν χωρίς προτεραιότητα, τα Ingesters του νέου cluster αντικατέστησαν τα Ingesters από το υπάρχον Cluster παραγωγής Cortex.

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

Τα ingesters έχουν κατάσταση και αποθηκεύουν δεδομένα για τις προηγούμενες 12 ώρες. Αυτό μας επιτρέπει να τα συμπιέσουμε πιο αποτελεσματικά πριν τα γράψουμε σε μακροχρόνια αποθήκευση. Για να το επιτύχει αυτό, ο Cortex μοιράζει δεδομένα σε σειρές χρησιμοποιώντας έναν κατανεμημένο πίνακα κατακερματισμού (DHT) και αναπαράγει κάθε σειρά σε τρεις απορρόφησης χρησιμοποιώντας τη συνοχή απαρτίας τύπου Dynamo. Το Cortex δεν εγγράφει δεδομένα στους χρήστες που απορροφούν τα οποία είναι απενεργοποιημένα. Έτσι, όταν ένας μεγάλος αριθμός Ingesters εγκαταλείπει το DHT, ο Cortex δεν μπορεί να παράσχει επαρκή αναπαραγωγή των καταχωρήσεων και καταρρέουν.

Ανίχνευση και αποκατάσταση

Νέες ειδοποιήσεις Prometheus με βάση τον "προϋπολογισμό σφάλματος" (με βάση τον προϋπολογισμό σφαλμάτων — οι λεπτομέρειες θα εμφανιστούν σε επόμενο άρθρο) άρχισε να ηχεί το ξυπνητήρι 4 λεπτά μετά την έναρξη του τερματισμού λειτουργίας. Μέσα στα επόμενα πέντε λεπτά περίπου, εκτελέσαμε κάποια διαγνωστικά και κλιμακώσαμε το υποκείμενο σύμπλεγμα Kubernetes για να φιλοξενήσουμε τόσο τα νέα όσο και τα υπάρχοντα συμπλέγματα παραγωγής.

Μετά από άλλα πέντε λεπτά, οι παλιοί Ingesters έγραψαν με επιτυχία τα δεδομένα τους, τα νέα ξεκίνησαν και τα συμπλέγματα Cortex έγιναν ξανά διαθέσιμα.

Άλλα 10 λεπτά δαπανήθηκαν για τη διάγνωση και τη διόρθωση σφαλμάτων εκτός μνήμης (OOM) από αντίστροφους διακομιστή μεσολάβησης ελέγχου ταυτότητας που βρίσκονται μπροστά από το Cortex. Τα σφάλματα OOM προκλήθηκαν από μια δεκαπλάσια αύξηση του QPS (πιστεύουμε ότι οφείλονται σε υπερβολικά επιθετικά αιτήματα από τους διακομιστές Prometheus του πελάτη).

Επακόλουθο

Ο συνολικός χρόνος διακοπής ήταν 26 λεπτά. Δεν χάθηκαν δεδομένα. Οι χρήστες απορρόφησης έχουν φορτώσει με επιτυχία όλα τα δεδομένα στη μνήμη σε μακροπρόθεσμη αποθήκευση. Κατά τη διάρκεια του τερματισμού, οι διακομιστές Prometheus του πελάτη διαγράφηκαν στην προσωρινή μνήμη (ελάχιστα) ηχογραφήσεις χρησιμοποιώντας νέο API remote_write με βάση το WAL (συγγραφέας Callum Styan από τα Grafana Labs) και επανέλαβε τις αποτυχημένες εγγραφές μετά τη συντριβή.

Πώς οι προτεραιότητες pod στο Kubernetes προκάλεσαν διακοπές στα Grafana Labs
Λειτουργίες εγγραφής συμπλέγματος παραγωγής

Ευρήματα

Είναι σημαντικό να μάθουμε από αυτό το περιστατικό και να λάβουμε τα απαραίτητα μέτρα για να αποφύγουμε την επανάληψή του.

Εκ των υστέρων, δεν θα έπρεπε να έχουμε ορίσει την προεπιλογή μέσος όρος προτεραιότητα έως ότου λάβουν όλα τα ingesters στην παραγωγή ψηλός μια προτεραιότητα. Επιπλέον, ήταν απαραίτητο να τα φροντίσουμε εκ των προτέρων υψηλός προτεραιότητα. Όλα διορθώθηκαν τώρα. Ελπίζουμε η εμπειρία μας να βοηθήσει άλλους οργανισμούς που εξετάζουν το ενδεχόμενο χρήσης προτεραιοτήτων pod στο Kubernetes.

Θα προσθέσουμε ένα επιπλέον επίπεδο ελέγχου σχετικά με την ανάπτυξη τυχόν πρόσθετων αντικειμένων των οποίων οι διαμορφώσεις είναι καθολικές στο σύμπλεγμα. Στο εξής, τέτοιες αλλαγές θα αξιολογούνται βоπερισσότεροι άνθρωποι. Επιπλέον, η τροποποίηση που προκάλεσε τη συντριβή θεωρήθηκε πολύ μικρή για ένα ξεχωριστό έγγραφο έργου - συζητήθηκε μόνο σε ένα τεύχος του GitHub. Από εδώ και στο εξής, όλες αυτές οι αλλαγές στις ρυθμίσεις παραμέτρων θα συνοδεύονται από την κατάλληλη τεκμηρίωση του έργου.

Τέλος, θα αυτοματοποιήσουμε την αλλαγή μεγέθους του αντίστροφου διακομιστή μεσολάβησης ελέγχου ταυτότητας για να αποτρέψουμε την υπερφόρτωση OOM που είδαμε και θα ελέγξουμε τις προεπιλεγμένες ρυθμίσεις του Prometheus που σχετίζονται με την εναλλακτική λύση και την κλιμάκωση για να αποτρέψουμε παρόμοια προβλήματα στο μέλλον.

Η αποτυχία είχε επίσης ορισμένες θετικές συνέπειες: έχοντας λάβει τους απαραίτητους πόρους, ο Cortex ανέκαμψε αυτόματα χωρίς πρόσθετη παρέμβαση. Αποκτήσαμε επίσης πολύτιμη εμπειρία δουλεύοντας με Γραφάνα Λόκι - το νέο μας σύστημα συγκέντρωσης αρχείων καταγραφής - το οποίο βοήθησε να διασφαλιστεί ότι όλοι οι χρήστες που απορροφούν συμπεριφέρθηκαν σωστά κατά τη διάρκεια και μετά την αποτυχία.

ΥΓ από τον μεταφραστή

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

Πηγή: www.habr.com

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