Δημιούργησα τον Kube Eagle - έναν εξαγωγέα του Προμηθέα. Αποδείχθηκε ότι ήταν ένα ωραίο πράγμα που βοηθά στην καλύτερη κατανόηση των πόρων των μικρομεσαίων συμπλεγμάτων. Στο τέλος, εξοικονόμησα εκατοντάδες δολάρια επειδή επέλεξα τους σωστούς τύπους μηχανημάτων και διαμόρφωσα τα όρια πόρων εφαρμογών για φόρτους εργασίας.
Θα σας πω για τα οφέλη , αλλά πρώτα θα εξηγήσω τι προκάλεσε τη φασαρία και γιατί χρειαζόταν παρακολούθηση υψηλής ποιότητας.
Κατάφερα πολλά συμπλέγματα 4–50 κόμβων. Κάθε σύμπλεγμα περιέχει έως και 200 μικροϋπηρεσίες και εφαρμογές. Για καλύτερη χρήση του υπάρχοντος υλικού, οι περισσότερες αναπτύξεις διαμορφώθηκαν με πόρους RAM και CPU με δυνατότητα εκρήξεως. Με αυτόν τον τρόπο, τα pods μπορούν να λάβουν διαθέσιμους πόρους εάν είναι απαραίτητο και ταυτόχρονα να μην παρεμβαίνουν σε άλλες εφαρμογές σε αυτόν τον κόμβο. Λοιπόν, δεν είναι υπέροχο;
Και παρόλο που το σύμπλεγμα κατανάλωνε σχετικά λίγη CPU (8%) και μνήμη RAM (40%), είχαμε συνεχώς προβλήματα με τα pods να προλαμβάνονται όταν προσπαθούσαν να εκχωρήσουν περισσότερη μνήμη από αυτή που ήταν διαθέσιμη στον κόμβο. Τότε είχαμε μόνο έναν πίνακα ελέγχου για την παρακολούθηση των πόρων του Kubernetes. Σαν αυτό:
Πίνακας ελέγχου Grafana μόνο με μετρήσεις cAdvisor
Με ένα τέτοιο πάνελ, δεν είναι πρόβλημα να δείτε κόμβους που τρώνε πολλή μνήμη και CPU. Το πρόβλημα είναι να καταλάβουμε ποιος είναι ο λόγος. Για να διατηρηθούν τα pod στη θέση τους, θα μπορούσε κανείς φυσικά να ρυθμίσει εγγυημένους πόρους σε όλα τα pod (που ζητούνται πόροι ίσοι με το όριο). Αλλά αυτή δεν είναι η πιο έξυπνη χρήση υλικού. Το σύμπλεγμα είχε αρκετές εκατοντάδες gigabyte μνήμης, ενώ ορισμένοι κόμβοι λιμοκτονούσαν, ενώ άλλοι είχαν αποθεματικό 4–10 GB.
Αποδεικνύεται ότι ο χρονοπρογραμματιστής Kubernetes διένειμε τους φόρτους εργασίας άνισα στους διαθέσιμους πόρους. Ο προγραμματιστής Kubernetes λαμβάνει υπόψη διαφορετικές διαμορφώσεις: κανόνες συνάφειας, κηλίδων και ανοχής, επιλογείς κόμβων που μπορούν να περιορίσουν τους διαθέσιμους κόμβους. Αλλά στην περίπτωσή μου δεν υπήρχε κάτι τέτοιο και τα pods σχεδιάστηκαν ανάλογα με τους πόρους που ζητήθηκαν σε κάθε κόμβο.
Ο κόμβος που έχει τους περισσότερους ελεύθερους πόρους και που ικανοποιεί τις προϋποθέσεις αιτήματος επιλέχθηκε για το pod. Διαπιστώσαμε ότι οι ζητούμενοι πόροι στους κόμβους δεν ταιριάζουν με την πραγματική χρήση και εδώ βοήθησαν το Kube Eagle και οι δυνατότητες παρακολούθησης πόρων του.
Έχω σχεδόν όλα τα συμπλέγματα Kubernetes που παρακολουθούνται μόνο με и . Το Node Exporter παρέχει στατιστικά στοιχεία για τη χρήση εισόδου/εξόδου και δίσκου, CPU και RAM, ενώ το Kube State Metrics εμφανίζει μετρήσεις αντικειμένων Kubernetes, όπως αιτήματα και όρια πόρων CPU και μνήμης.
Πρέπει να συνδυάσουμε τις μετρήσεις χρήσης με τις μετρήσεις αιτημάτων και ορίων στο Grafana και, στη συνέχεια, θα λάβουμε όλες τις πληροφορίες σχετικά με το πρόβλημα. Αυτό ακούγεται απλό, αλλά τα δύο εργαλεία στην πραγματικότητα ονομάζουν τις ετικέτες διαφορετικά και ορισμένες μετρήσεις δεν έχουν καθόλου ετικέτες μεταδεδομένων. Το Kube Eagle κάνει τα πάντα μόνο του και το πάνελ μοιάζει με αυτό:
Καταφέραμε να λύσουμε πολλά προβλήματα με πόρους και να εξοικονομήσουμε εξοπλισμό:
- Ορισμένοι προγραμματιστές δεν γνώριζαν πόσους πόρους χρειάζονταν οι μικροϋπηρεσίες (ή απλώς δεν ασχολήθηκαν). Δεν υπήρχε τρόπος να βρούμε λανθασμένα αιτήματα για πόρους - για αυτό πρέπει να γνωρίζουμε την κατανάλωση συν αιτήματα και όρια. Τώρα βλέπουν τις μετρήσεις του Prometheus, παρακολουθούν την πραγματική χρήση και προσαρμόζουν αιτήματα και όρια.
- Οι εφαρμογές JVM καταλαμβάνουν όση RAM μπορούν να χειριστούν. Ο συλλέκτης απορριμμάτων απελευθερώνει μνήμη μόνο όταν χρησιμοποιείται περισσότερο από 75%. Και δεδομένου ότι οι περισσότερες υπηρεσίες έχουν εκρήξιμη μνήμη, ήταν πάντα κατειλημμένη από το JVM. Επομένως, όλες αυτές οι υπηρεσίες Java κατανάλωναν πολύ περισσότερη μνήμη RAM από την αναμενόμενη.
- Ορισμένες εφαρμογές ζήτησαν υπερβολική μνήμη και ο προγραμματιστής Kubernetes δεν έδωσε αυτούς τους κόμβους σε άλλες εφαρμογές, παρόλο που στην πραγματικότητα ήταν πιο ελεύθεροι από άλλους κόμβους. Ένας προγραμματιστής πρόσθεσε κατά λάθος ένα επιπλέον ψηφίο στο αίτημα και άρπαξε ένα μεγάλο κομμάτι μνήμης RAM: 20 GB αντί για 2. Κανείς δεν το παρατήρησε. Η εφαρμογή είχε 3 αντίγραφα, επομένως επηρεάστηκαν έως και 3 κόμβοι.
- Εισαγάγαμε όρια πόρων, επαναπρογραμματίσαμε τα pods με τα σωστά αιτήματα και αποκτήσαμε μια ιδανική ισορροπία χρήσης υλικού σε όλους τους κόμβους. Μερικοί κόμβοι θα μπορούσαν να είχαν κλείσει εντελώς. Και μετά είδαμε ότι είχαμε λάθος μηχανήματα (προσανατολισμένο στη CPU, όχι στη μνήμη). Αλλάξαμε τον τύπο και διαγράψαμε αρκετούς ακόμα κόμβους.
Αποτελέσματα της
Με πόρους με δυνατότητα εκρήξεως στο σύμπλεγμα, χρησιμοποιείτε το διαθέσιμο υλικό πιο αποτελεσματικά, αλλά ο χρονοπρογραμματιστής Kubernetes προγραμματίζει ομάδες με βάση αιτήματα για πόρους και αυτό είναι γεμάτο. Για να σκοτώσετε δύο πουλιά με μια πέτρα: για να αποφύγετε προβλήματα και να χρησιμοποιήσετε τους πόρους στο έπακρο, χρειάζεστε καλή παρακολούθηση. Γι' αυτό θα είναι χρήσιμο (Προμηθέας εξαγωγέας και ταμπλό Grafana).
Πηγή: www.habr.com