Βέλτιστες πρακτικές Kubernetes. Ρύθμιση αιτημάτων και ορίων πόρων

Βέλτιστες πρακτικές Kubernetes. Δημιουργία μικρών δοχείων
Βέλτιστες πρακτικές Kubernetes. Οργάνωση του Kubernetes με χώρο ονομάτων
Βέλτιστες πρακτικές Kubernetes. Επικύρωση του Kubernetes Liveness με τεστ ετοιμότητας και ζωντάνιας

Για κάθε πόρο του Kubernetes, μπορείτε να διαμορφώσετε δύο τύπους απαιτήσεων - Αιτήματα και Όρια. Το πρώτο περιγράφει τις ελάχιστες απαιτήσεις για τη διαθεσιμότητα των ελεύθερων πόρων κόμβου που είναι απαραίτητοι για τη λειτουργία ενός κοντέινερ ή μιας ομάδας, ενώ το δεύτερο περιορίζει αυστηρά τους διαθέσιμους πόρους στο κοντέινερ.

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

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

Βέλτιστες πρακτικές Kubernetes. Ρύθμιση αιτημάτων και ορίων πόρων

Ένα κοντέινερ μπορεί να αυξήσει την υπολογιστική του ισχύ μόνο μέχρι ένα ορισμένο όριο, μετά το οποίο θα περιοριστεί. Ας δούμε πώς λειτουργεί. Έτσι, υπάρχουν δύο τύποι πόρων - επεξεργαστής και μνήμης. Ο χρονοπρογραμματιστής Kubernetes χρησιμοποιεί δεδομένα σχετικά με αυτούς τους πόρους για να καταλάβει πού θα εκτελούνται οι ομάδες σας. Μια τυπική προδιαγραφή πόρων για ένα pod μοιάζει με αυτό.

Βέλτιστες πρακτικές Kubernetes. Ρύθμιση αιτημάτων και ορίων πόρων

Κάθε κοντέινερ σε ένα λοβό μπορεί να ορίσει τα δικά του ερωτήματα και όρια, όλα είναι πρόσθετα. Οι πόροι του επεξεργαστή ορίζονται σε millicore. Εάν το κοντέινερ σας χρειάζεται δύο πλήρεις πυρήνες για να λειτουργήσει, ορίζετε την τιμή στα 2000m. Εάν το δοχείο χρειάζεται μόνο την ισχύ του 1/4 του πυρήνα, η τιμή θα είναι 250 m. Λάβετε υπόψη ότι εάν εκχωρήσετε μια τιμή πόρου CPU μεγαλύτερη από τον αριθμό των πυρήνων του μεγαλύτερου κόμβου, το pod σας δεν θα προγραμματιστεί να ξεκινήσει καθόλου. Μια παρόμοια κατάσταση θα συμβεί εάν έχετε ένα Pod που χρειάζεται τέσσερις πυρήνες και το σύμπλεγμα Kubernetes αποτελείται μόνο από δύο κύριες εικονικές μηχανές.

Εκτός εάν η εφαρμογή σας έχει σχεδιαστεί ειδικά για να εκμεταλλεύεται πολλούς πυρήνες (προγράμματα όπως πολύπλοκοι επιστημονικοί υπολογιστές και λειτουργίες βάσης δεδομένων έρχονται στο μυαλό), τότε η καλύτερη πρακτική είναι να ορίσετε τα αιτήματα CPU σε 1 ή χαμηλότερα και στη συνέχεια να εκτελέσετε περισσότερα αντίγραφα σε επεκτασιμότητα. Αυτή η λύση θα δώσει στο σύστημα μεγαλύτερη ευελιξία και αξιοπιστία.

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

Οι πόροι μνήμης ορίζονται σε byte. Συνήθως η τιμή στις ρυθμίσεις μετριέται σε mebibyte Mib, αλλά μπορείτε να ορίσετε οποιαδήποτε τιμή, από byte έως petabyte. Εδώ ισχύει η ίδια κατάσταση όπως και με την CPU - εάν υποβάλετε αίτημα για ποσότητα μνήμης μεγαλύτερη από την ποσότητα μνήμης στους κόμβους σας, δεν θα προγραμματιστεί η εκτέλεση αυτού του pod. Αλλά σε αντίθεση με τους πόρους της CPU, η μνήμη δεν συμπιέζεται επειδή δεν υπάρχει τρόπος περιορισμού της χρήσης της. Επομένως, η εκτέλεση του κοντέινερ θα σταματήσει μόλις υπερβεί τη μνήμη που του έχει εκχωρηθεί.

Βέλτιστες πρακτικές Kubernetes. Ρύθμιση αιτημάτων και ορίων πόρων

Είναι σημαντικό να θυμάστε ότι δεν μπορείτε να διαμορφώσετε αιτήματα που υπερβαίνουν τους πόρους που μπορούν να παρέχουν οι κόμβοι σας. Οι προδιαγραφές κοινών πόρων για τις εικονικές μηχανές GKE μπορείτε να βρείτε στους συνδέσμους κάτω από αυτό το βίντεο.

Σε έναν ιδανικό κόσμο, οι προεπιλεγμένες ρυθμίσεις του κοντέινερ θα ήταν επαρκείς για τη διατήρηση της ομαλής λειτουργίας των ροών εργασίας. Αλλά ο πραγματικός κόσμος δεν είναι έτσι, οι άνθρωποι μπορούν εύκολα να ξεχάσουν να ρυθμίσουν τη χρήση των πόρων ή οι χάκερ θα θέτουν αιτήματα και περιορισμούς που υπερβαίνουν τις πραγματικές δυνατότητες της υποδομής. Για να αποτρέψετε την εμφάνιση τέτοιων σεναρίων, μπορείτε να ρυθμίσετε τις παραμέτρους των ορίων πόρων ResourceQuota και LimitRange.

Μόλις δημιουργηθεί ένας χώρος ονομάτων, μπορεί να αποκλειστεί χρησιμοποιώντας quotas. Για παράδειγμα, εάν έχετε τους χώρους ονομάτων prod και dev, το μοτίβο είναι ότι δεν υπάρχουν καθόλου ποσοστώσεις παραγωγής και πολύ αυστηρές ποσοστώσεις ανάπτυξης. Αυτό επιτρέπει στον παραγωγό, σε περίπτωση απότομης αύξησης της επισκεψιμότητας, να αναλάβει ολόκληρο τον διαθέσιμο πόρο, αποκλείοντας πλήρως τον προγραμματιστή.

Το όριο πόρων μπορεί να μοιάζει με αυτό. Σε αυτό το παράδειγμα υπάρχουν 4 ενότητες - αυτές είναι οι 4 κατώτατες γραμμές κώδικα.

Βέλτιστες πρακτικές Kubernetes. Ρύθμιση αιτημάτων και ορίων πόρων

Ας δούμε το καθένα από αυτά. Το Requests.cpu είναι ο μέγιστος αριθμός συνδυασμένων αιτημάτων CPU που μπορούν να προέρχονται από όλα τα κοντέινερ στον χώρο ονομάτων. Σε αυτό το παράδειγμα, θα μπορούσατε να έχετε 50 κοντέινερ με 10 εκατ. αιτήματα, πέντε κοντέινερ με 100 εκατ. αιτήματα ή μόνο ένα κοντέινερ με 500 εκατ. αιτήματα. Εφόσον ο συνολικός αριθμός των requests.cpu ενός δεδομένου χώρου ονομάτων είναι μικρότερος από 500 μέτρα, όλα θα πάνε καλά.

Memory requested requests.memory είναι ο μέγιστος αριθμός αιτημάτων συνδυασμένης μνήμης που μπορούν να έχουν όλα τα κοντέινερ στον χώρο ονομάτων. Όπως και στην προηγούμενη περίπτωση, μπορείτε να έχετε 50 κοντέινερ 2 mib, πέντε κοντέινερ των 20 mib ή ένα μεμονωμένο κοντέινερ 100 mib, εφόσον η συνολική ποσότητα μνήμης που ζητείται στον χώρο ονομάτων είναι μικρότερη από 100 mebibyte.

Το Limits.cpu είναι η μέγιστη συνδυασμένη ποσότητα ισχύος CPU που μπορούν να χρησιμοποιήσουν όλα τα κοντέινερ στον χώρο ονομάτων. Μπορούμε να θεωρήσουμε ότι αυτό είναι το όριο των αιτημάτων ισχύος του επεξεργαστή.

Τέλος, limits.memory είναι η μέγιστη ποσότητα κοινόχρηστης μνήμης που μπορούν να χρησιμοποιήσουν όλα τα κοντέινερ στον χώρο ονομάτων. Αυτό είναι ένα όριο για τις συνολικές αιτήσεις μνήμης.
Έτσι, από προεπιλογή, τα κοντέινερ σε ένα σύμπλεγμα Kubernetes τρέχουν με απεριόριστους υπολογιστικούς πόρους. Με τα ποσοστά πόρων, οι διαχειριστές συμπλέγματος μπορούν να περιορίσουν την κατανάλωση πόρων και τη δημιουργία πόρων με βάση τον χώρο ονομάτων. Σε έναν χώρο ονομάτων, ένα pod ή κοντέινερ μπορεί να καταναλώσει όση ισχύ και μνήμη CPU καθορίζεται από το όριο πόρων του χώρου ονομάτων. Ωστόσο, υπάρχει ανησυχία ότι ένα pod ή κοντέινερ μπορεί να μονοπωλήσει όλους τους διαθέσιμους πόρους. Για να αποφευχθεί αυτή η κατάσταση, χρησιμοποιείται ένα εύρος ορίων - μια πολιτική για τον περιορισμό της κατανομής πόρων (για ομάδες ή κοντέινερ) στον χώρο ονομάτων.

Το εύρος ορίων παρέχει περιορισμούς που μπορούν:

  • Εξασφαλίστε την ελάχιστη και μέγιστη χρήση υπολογιστικών πόρων για κάθε ενότητα ή κοντέινερ στον χώρο ονομάτων.
  • να επιβάλει ελάχιστα και μέγιστα αιτήματα αποθήκευσης Starage Request για κάθε PersistentVolumeClaim στον χώρο ονομάτων.
  • επιβολή μιας σχέσης μεταξύ ενός αιτήματος και ενός ορίου για έναν πόρο σε έναν χώρο ονομάτων.
  • ορίστε προεπιλεγμένα Αιτήματα/Όρια για υπολογιστικούς πόρους στο χώρο ονομάτων και εισάγετέ τους αυτόματα σε κοντέινερ κατά το χρόνο εκτέλεσης.

Με αυτόν τον τρόπο μπορείτε να δημιουργήσετε ένα εύρος ορίων στον χώρο ονομάτων σας. Σε αντίθεση με ένα όριο, το οποίο ισχύει για ολόκληρο τον χώρο ονομάτων, το Limit Range χρησιμοποιείται για μεμονωμένα κοντέινερ. Αυτό μπορεί να εμποδίσει τους χρήστες να δημιουργήσουν πολύ μικροσκοπικά ή, αντίθετα, γιγαντιαία δοχεία εντός του χώρου ονομάτων. Το εύρος ορίου μπορεί να μοιάζει με αυτό.

Βέλτιστες πρακτικές Kubernetes. Ρύθμιση αιτημάτων και ορίων πόρων

Όπως και στην προηγούμενη περίπτωση, εδώ διακρίνονται 4 ενότητες. Ας δούμε το καθένα.
Η προεπιλεγμένη ενότητα ορίζει τα προεπιλεγμένα όρια για το κοντέινερ στο pod. Εάν ορίσετε αυτές τις τιμές στο ακραίο εύρος, τότε τυχόν κοντέινερ για τα οποία δεν έχουν οριστεί ρητά αυτές οι τιμές θα ακολουθούν τις προεπιλεγμένες τιμές.

Η ενότητα προεπιλεγμένων αιτημάτων defaultRequest διαμορφώνει τα προεπιλεγμένα αιτήματα για το κοντέινερ στο pod. Και πάλι, εάν ορίσετε αυτές τις τιμές στο ακραίο εύρος, τότε όλα τα κοντέινερ που δεν ορίζουν ρητά αυτές τις επιλογές θα είναι προεπιλεγμένα σε αυτές τις τιμές.

Η ενότητα max καθορίζει τα μέγιστα όρια που μπορούν να τεθούν για ένα κοντέινερ στο pod. Οι τιμές στην προεπιλεγμένη ενότητα και τα όρια κοντέινερ δεν μπορούν να οριστούν πάνω από αυτό το όριο. Είναι σημαντικό να σημειωθεί ότι εάν η τιμή έχει οριστεί στο max και δεν υπάρχει προεπιλεγμένη ενότητα, τότε η μέγιστη τιμή γίνεται η προεπιλεγμένη τιμή.

Η ενότητα min καθορίζει τα ελάχιστα αιτήματα που μπορούν να οριστούν για ένα κοντέινερ σε μια ομάδα. Ωστόσο, οι τιμές στην προεπιλεγμένη ενότητα και τα ερωτήματα για το κοντέινερ δεν μπορούν να οριστούν κάτω από αυτό το όριο.

Και πάλι, είναι σημαντικό να σημειωθεί ότι εάν οριστεί αυτή η τιμή, η προεπιλογή δεν είναι, τότε η ελάχιστη τιμή γίνεται η προεπιλεγμένη ερώτηση.

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

Βέλτιστες πρακτικές Kubernetes. Ρύθμιση αιτημάτων και ορίων πόρων

Το Kubernetes θα ελέγξει αν ο Κόμβος 1 έχει αρκετούς πόρους για να εκπληρώσει αιτήματα από τα κοντέινερ pod, και αν δεν έχει, θα προχωρήσει στον επόμενο κόμβο. Εάν κανένας από τους κόμβους του συστήματος δεν είναι σε θέση να ικανοποιήσει τα αιτήματα, οι ομάδες θα μεταβούν στην κατάσταση Εκκρεμότητα. Χρησιμοποιώντας τις δυνατότητες του κινητήρα του Google Kubernetes, όπως η αυτόματη κλιμάκωση κόμβων, το GKE μπορεί να εντοπίσει αυτόματα την κατάσταση αναμονής και να δημιουργήσει αρκετούς επιπλέον επιπλέον κόμβους.

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

Βέλτιστες πρακτικές Kubernetes. Ρύθμιση αιτημάτων και ορίων πόρων

Όπως είπα, όταν πρόκειται για CPU, η Kubernetes θα αρχίσει να περιορίζει τα pods. Κάθε pod θα λάβει όσα ζήτησε, αλλά αν δεν φτάσει το όριο, θα αρχίσει να εφαρμόζεται ο στραγγαλισμός.

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

Ας φανταστούμε ένα σενάριο όπου η μνήμη σας τελειώνει σε ένα μηχάνημα - πώς θα το χειριζόταν αυτό η Kubernetes;

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

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

Σε πολύ σπάνιες περιπτώσεις, το Kubernetes μπορεί να ματαιώσει ομάδες που εξακολουθούν να βρίσκονται εντός του πεδίου εφαρμογής των αιτημάτων τους. Αυτό μπορεί να συμβεί όταν κρίσιμα στοιχεία του συστήματος, όπως ο πράκτορας Kubelet ή το Docker, αρχίσουν να καταναλώνουν περισσότερους πόρους από αυτούς που είχαν δεσμευτεί για αυτά.
Έτσι, στα πρώτα στάδια των μικρών εταιρειών, ένα σύμπλεγμα Kubernetes μπορεί να λειτουργήσει καλά χωρίς να θέτει αιτήματα πόρων και περιορισμούς, αλλά καθώς οι ομάδες και τα έργα σας αρχίζουν να μεγαλώνουν σε μέγεθος, διατρέχετε τον κίνδυνο να αντιμετωπίσετε προβλήματα σε αυτόν τον τομέα. Η προσθήκη ερωτημάτων και περιορισμών στις μονάδες και τους χώρους ονομάτων σας απαιτεί πολύ λίγη επιπλέον προσπάθεια και μπορεί να εξοικονομήσει μεγάλη ταλαιπωρία.

Βέλτιστες πρακτικές Kubernetes. Σωστός τερματισμός τερματισμού λειτουργίας

Μερικές διαφημίσεις 🙂

Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, cloud VPS για προγραμματιστές από 4.99 $, ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: Όλη η αλήθεια για το VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps από 19 $ ή πώς να μοιραστείτε έναν διακομιστή; (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).

Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 Τηλεόραση από 199$ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά Πώς να χτίσετε την υποδομή Corp. κατηγορίας με τη χρήση διακομιστών Dell R730xd E5-2650 v4 αξίας 9000 ευρώ για μια δεκάρα;

Πηγή: www.habr.com

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