Γεια σε όλους! Ονομάζομαι Oleg Sidorenkov, εργάζομαι στην DomClick ως επικεφαλής ομάδας υποδομής. Χρησιμοποιούμε το Cube για πώληση για περισσότερα από τρία χρόνια και σε αυτό το διάστημα ζήσαμε πολλές διαφορετικές ενδιαφέρουσες στιγμές μαζί του. Σήμερα θα σας πω πώς, με τη σωστή προσέγγιση, μπορείτε να αποσπάσετε ακόμη περισσότερη απόδοση από τη βανίλια Kubernetes για το σύμπλεγμα σας. Έτοιμοι, συνεχίστε!
Όλοι γνωρίζετε πολύ καλά ότι το Kubernetes είναι ένα επεκτάσιμο σύστημα ανοιχτού κώδικα για ενορχήστρωση κοντέινερ. Λοιπόν, ή 5 δυαδικά αρχεία που κάνουν μαγικά διαχειρίζοντας τον κύκλο ζωής των μικροϋπηρεσιών σας σε περιβάλλον διακομιστή. Επιπλέον, αυτό είναι ένα αρκετά ευέλικτο εργαλείο που μπορεί να συναρμολογηθεί σαν κατασκευαστής Lego για μέγιστη προσαρμογή για διαφορετικές εργασίες.
Και όλα φαίνονται να είναι καλά: ρίξτε τους διακομιστές στο σύμπλεγμα, όπως τα καυσόξυλα σε μια εστία και μην ξέρετε τη θλίψη. Αλλά αν είστε για το περιβάλλον, τότε θα σκεφτείτε: «Πώς μπορώ να κρατήσω τη φωτιά στη σόμπα και να μετανιώσω για το δάσος;». Με άλλα λόγια, πώς να βρούμε τρόπους βελτίωσης των υποδομών και μείωσης του κόστους.
1. Παρακολουθήστε τους πόρους της ομάδας και της εφαρμογής
Μία από τις πιο μπανάλ αλλά αποτελεσματικές μεθόδους είναι η εισαγωγή αιτημάτων/ορίων. Διαχωρίστε τις εφαρμογές κατά χώρους ονομάτων και τους χώρους ονομάτων ανά ομάδες ανάπτυξης. Ρυθμίστε την εφαρμογή πριν από την ανάπτυξη τιμών για την κατανάλωση χρόνου επεξεργαστή, μνήμης, εφήμερης αποθήκευσης.
resources:
requests:
memory: 2Gi
cpu: 250m
limits:
memory: 4Gi
cpu: 500mΑπό την εμπειρία, καταλήξαμε στο συμπέρασμα: δεν αξίζει να διογκώνουμε τα αιτήματα από όρια περισσότερο από δύο φορές. Το μέγεθος του συμπλέγματος υπολογίζεται βάσει αιτημάτων και αν ορίσετε την εφαρμογή σε μια διαφορά στους πόρους, για παράδειγμα, κατά 5-10 φορές, τότε φανταστείτε τι θα συμβεί στον κόμβο σας όταν γεμίσει με λοβούς και λάβει ξαφνικά φορτίο. Τίποτα καλό. Τουλάχιστον, στραγγαλισμός, και ως μέγιστο, αποχαιρετήστε τον εργάτη και αποκτήστε ένα κυκλικό φορτίο στους υπόλοιπους κόμβους αφού αρχίσουν να κινούνται οι λοβοί.
Επιπλέον, με τη βοήθεια limitranges μπορείτε να ορίσετε τιμές πόρων για το κοντέινερ στην αρχή - ελάχιστο, μέγιστο και προεπιλεγμένο:
➜ ~ kubectl describe limitranges --namespace ops
Name: limit-range
Namespace: ops
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container cpu 50m 10 100m 100m 2
Container ephemeral-storage 12Mi 8Gi 128Mi 4Gi -
Container memory 64Mi 40Gi 128Mi 128Mi 2Θυμηθείτε να περιορίσετε τους πόρους του χώρου ονομάτων έτσι ώστε μια εντολή να μην μπορεί να λάβει όλους τους πόρους του συμπλέγματος:
➜ ~ kubectl describe resourcequotas --namespace ops
Name: resource-quota
Namespace: ops
Resource Used Hard
-------- ---- ----
limits.cpu 77250m 80
limits.memory 124814367488 150Gi
pods 31 45
requests.cpu 53850m 80
requests.memory 75613234944 150Gi
services 26 50
services.loadbalancers 0 0
services.nodeports 0 0Όπως μπορείτε να δείτε από την περιγραφή resourcequotas, εάν η εντολή ops θέλει να αναπτύξει pods που θα καταναλώνουν άλλες 10 cpu, τότε ο προγραμματιστής δεν θα επιτρέψει να γίνει αυτό και θα εμφανίσει ένα σφάλμα:
Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10Για να λύσετε ένα παρόμοιο πρόβλημα, μπορείτε να γράψετε ένα εργαλείο, για παράδειγμα, όπως , το οποίο μπορεί να αποθηκεύσει και να δεσμεύσει την κατάσταση των πόρων εντολών.
2. Επιλέξτε την καλύτερη αποθήκευση αρχείων
Εδώ θα ήθελα να θίξω το θέμα των επίμονων τόμων και το υποσύστημα δίσκου των εργαζομένων κόμβων Kubernetes. Ελπίζω ότι κανείς δεν χρησιμοποιεί το "Cube" στον σκληρό δίσκο στην παραγωγή, αλλά μερικές φορές ακόμη και ένας κανονικός SSD δεν είναι ήδη αρκετός. Αντιμετωπίσαμε ένα τέτοιο πρόβλημα που τα αρχεία καταγραφής σκότωναν το δίσκο με λειτουργίες I/O και δεν υπάρχουν πολλές λύσεις εδώ:
-
Χρησιμοποιήστε SSD υψηλής απόδοσης ή μεταβείτε στο NVMe (αν διαχειρίζεστε το δικό σας υλικό).
-
Μειώστε το επίπεδο καταγραφής.
-
Κάντε "έξυπνη" εξισορρόπηση λοβών που βιάζουν το δίσκο (
podAntiAffinity).
Το παραπάνω στιγμιότυπο οθόνης δείχνει τι συμβαίνει στο nginx-ingress-controller με έναν δίσκο όταν είναι ενεργοποιημένο το access_logs (~12k logs/sec). Μια τέτοια κατάσταση, φυσικά, μπορεί να οδηγήσει σε υποβάθμιση όλων των εφαρμογών σε αυτόν τον κόμβο.
Όσο για τα φωτοβολταϊκά, αλίμονο, δεν τα έχω δοκιμάσει όλα. Επίμονοι όγκοι. Χρησιμοποιήστε την καλύτερη επιλογή που σας ταιριάζει. Έχει συμβεί ιστορικά στη χώρα μας ένα μικρό μέρος των υπηρεσιών να χρειάζεται τόμους RWX και πριν από πολύ καιρό άρχισαν να χρησιμοποιούν αποθήκευση NFS για αυτήν την εργασία. Φθηνό και ... αρκετό. Φυσικά, φάγαμε σκατά μαζί του - να είστε υγιείς, αλλά μάθαμε πώς να τον συντονίζουμε και το κεφάλι του δεν πονάει πλέον. Και αν είναι δυνατόν, μεταβείτε στην αποθήκευση αντικειμένων S3.
3. Δημιουργήστε βελτιστοποιημένες εικόνες
Είναι καλύτερο να χρησιμοποιείτε εικόνες βελτιστοποιημένες για κοντέινερ, έτσι ώστε το Kubernetes να μπορεί να τις ανακτήσει πιο γρήγορα και να τις εκτελέσει πιο αποτελεσματικά.
Βελτιστοποίηση σημαίνει ότι οι εικόνες:
-
περιέχει μόνο μία εφαρμογή ή εκτελεί μόνο μία λειτουργία.
-
μικρό μέγεθος, επειδή οι μεγάλες εικόνες μεταδίδονται χειρότερα μέσω του δικτύου.
-
έχουν καταληκτικά σημεία υγείας και ετοιμότητας που μπορεί να χρησιμοποιήσει η Kubernetes για να αναλάβει δράση σε περίπτωση διακοπής λειτουργίας.
-
Χρησιμοποιήστε λειτουργικά συστήματα φιλικά προς το κοντέινερ (όπως το Alpine ή το CoreOS) που είναι πιο ανθεκτικά σε σφάλματα διαμόρφωσης.
-
χρησιμοποιήστε εκδόσεις πολλών σταδίων, ώστε να μπορείτε να αναπτύξετε μόνο μεταγλωττισμένες εφαρμογές και όχι τις συνοδευτικές πηγές.
Υπάρχουν πολλά εργαλεία και υπηρεσίες που σας επιτρέπουν να ελέγχετε και να βελτιστοποιείτε τις εικόνες εν κινήσει. Είναι σημαντικό να τα διατηρείτε πάντα ενημερωμένα και ασφαλή. Ως αποτέλεσμα, λαμβάνετε:
-
Μειωμένος φόρτος δικτύου σε ολόκληρο το σύμπλεγμα.
-
Μειωμένος χρόνος εκκίνησης κοντέινερ.
-
Μικρότερο μέγεθος ολόκληρου του μητρώου Docker.
4. Χρησιμοποιήστε μια προσωρινή μνήμη DNS
Αν μιλάμε για υψηλά φορτία, τότε χωρίς να ρυθμίσετε το σύστημα DNS του συμπλέγματος, η ζωή είναι αρκετά άθλια. Μια φορά κι έναν καιρό, οι προγραμματιστές Kubernetes υποστήριζαν τη λύση kube-dns. Εφαρμόστηκε και στη χώρα μας, αλλά αυτό το λογισμικό δεν συντονίστηκε ιδιαίτερα και δεν έδωσε την απαιτούμενη απόδοση, αν και, όπως φαίνεται, η εργασία είναι απλή. Μετά εμφανίστηκαν τα coredns, στα οποία μεταβήκαμε και δεν ξέραμε τη θλίψη, αργότερα έγινε η προεπιλεγμένη υπηρεσία DNS στα K8. Κάποια στιγμή, μεγαλώσαμε μέχρι τις 40 χιλιάδες rps στο σύστημα DNS, και αυτή η λύση επίσης δεν ήταν αρκετή. Αλλά, από μια τυχερή ευκαιρία, βγήκε το Nodelocaldns, γνωστός και ως κόμβος τοπική κρυφή μνήμη, γνωστός και ως .
Γιατί το χρησιμοποιούμε; Υπάρχει ένα σφάλμα στον πυρήνα του Linux που, όταν πολλαπλές προσβάσεις μέσω conntrack NAT μέσω UDP, οδηγεί σε μια συνθήκη κούρσας για εγγραφή στους πίνακες conntrack και χάνεται μέρος της κίνησης μέσω NAT (κάθε διαδρομή μέσω της Υπηρεσίας είναι NAT). Το Nodelocaldns λύνει αυτό το πρόβλημα με την απαλλαγή από το NAT και την αναβάθμιση σε συνδεσιμότητα TCP σε ανάντη DNS, καθώς και την προσωρινή αποθήκευση ερωτημάτων ανάντη DNS τοπικά (συμπεριλαμβανομένης μιας σύντομης αρνητικής προσωρινής μνήμης 5 δευτερολέπτων).
5. Κλιμάκωση λοβών οριζόντια και κάθετα αυτόματα
Μπορείτε να πείτε με σιγουριά ότι όλες οι μικροϋπηρεσίες σας είναι έτοιμες για διπλάσια έως τριπλάσια αύξηση του φορτίου; Πώς να κατανείμετε σωστά τους πόρους στις εφαρμογές σας; Η διατήρηση μερικών pod σε λειτουργία πέραν του φόρτου εργασίας μπορεί να είναι περιττή και η διατήρησή τους πίσω με την πλάτη ενέχει τον κίνδυνο διακοπής λειτουργίας από μια ξαφνική αύξηση της επισκεψιμότητας στην υπηρεσία. Ο χρυσός μέσος βοηθά στην επίτευξη του ξόρκι του πολλαπλασιασμού όπως υπηρεσίες όπως и .
VPA σας επιτρέπει να αυξήσετε αυτόματα τα αιτήματα/όρια των κοντέινερ σας σε μια ομάδα με βάση την πραγματική χρήση. Πώς μπορεί να είναι χρήσιμο; Εάν έχετε Pods που για κάποιο λόγο δεν μπορούν να κλιμακωθούν οριζόντια (κάτι που δεν είναι απολύτως αξιόπιστο), τότε μπορείτε να δοκιμάσετε να εμπιστευτείτε το VPA για να αλλάξει τους πόρους του. Το χαρακτηριστικό του είναι ένα σύστημα συστάσεων που βασίζεται σε ιστορικά και τρέχοντα δεδομένα από τον διακομιστή μετρήσεων, οπότε αν δεν θέλετε να αλλάξετε αυτόματα αιτήματα/όρια, μπορείτε απλώς να παρακολουθείτε τους προτεινόμενους πόρους για τα κοντέινερ σας και να βελτιστοποιήσετε τις ρυθμίσεις για εξοικονόμηση CPU και μνήμης στο σύμπλεγμα.
Η εικόνα ελήφθη από https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231
Ο προγραμματιστής στο Kubernetes βασίζεται πάντα σε αιτήματα. Όποια τιμή κι αν βάλετε εκεί, ο προγραμματιστής θα αναζητήσει έναν κατάλληλο κόμβο με βάση αυτό. Η οριακή τιμή απαιτείται από το kublet για να γνωρίζει πότε πρέπει να πετάξει ή να σκοτώσει ένα λοβό. Και δεδομένου ότι η μόνη σημαντική παράμετρος είναι η τιμή των αιτημάτων, το VPA θα συνεργαστεί με αυτήν. Κάθε φορά που κλιμακώνετε την εφαρμογή σας κατακόρυφα, ορίζετε ποια θα πρέπει να είναι τα αιτήματα. Και τι θα γίνει τότε με τα όρια; Αυτή η παράμετρος θα κλιμακωθεί επίσης αναλογικά.
Για παράδειγμα, εδώ είναι οι τυπικές ρυθμίσεις pod:
resources:
requests:
memory: 250Mi
cpu: 200m
limits:
memory: 500Mi
cpu: 350mΗ μηχανή συστάσεων καθορίζει ότι η εφαρμογή σας χρειάζεται 300m CPU και 500Mi για να λειτουργήσει σωστά. Θα λάβετε αυτές τις ρυθμίσεις:
resources:
requests:
memory: 500Mi
cpu: 300m
limits:
memory: 1000Mi
cpu: 525mΌπως αναφέρθηκε παραπάνω, πρόκειται για αναλογική κλιμάκωση με βάση την αναλογία αιτημάτων/ορίων στο μανιφέστο:
-
CPU: 200m → 300m: αναλογία 1:1.75;
-
Μνήμη: 250 Mi → 500 Mi: αναλογία 1:2.
σε σχέση με το ΗΡΑ, τότε ο μηχανισμός λειτουργίας είναι πιο διαφανής. Τα όρια ορίζονται για μετρήσεις όπως ο επεξεργαστής και η μνήμη και εάν ο μέσος όρος όλων των αντιγράφων υπερβαίνει το όριο, τότε η εφαρμογή κλιμακώνεται κατά +1 ομάδα έως ότου η τιμή πέσει κάτω από το όριο ή έως ότου επιτευχθεί ο μέγιστος αριθμός αντιγράφων.
Η εικόνα ελήφθη από https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231
Εκτός από τις συνήθεις μετρήσεις όπως η CPU και η Μνήμη, μπορείτε να ορίσετε όρια στις προσαρμοσμένες μετρήσεις Prometheus και να εργαστείτε μαζί τους, εάν πιστεύετε ότι αυτός είναι ο πιο ακριβής τρόπος για να καθορίσετε πότε θα κλιμακώσετε την εφαρμογή σας. Μόλις η εφαρμογή σταθεροποιηθεί κάτω από το καθορισμένο όριο μέτρησης, το HPA θα αρχίσει να μειώνει τα pods στον ελάχιστο αριθμό αντιγράφων ή μέχρι το φορτίο να φτάσει το καθορισμένο όριο.
6. Μην ξεχνάτε το Node Affinity και το Pod Affinity
Δεν εκτελούνται όλοι οι κόμβοι στο ίδιο υλικό και δεν χρειάζεται όλα τα pod να εκτελούν εφαρμογές με ένταση υπολογιστών. Το Kubernetes σάς επιτρέπει να καθορίσετε την εξειδίκευση των κόμβων και των λοβών χρησιμοποιώντας Συγγένεια κόμβου и Pod Affinity.
Εάν έχετε κόμβους που είναι κατάλληλοι για λειτουργίες έντασης υπολογισμού, τότε για μέγιστη απόδοση, είναι προτιμότερο να συνδέσετε εφαρμογές στους κατάλληλους κόμβους. Για να το κάνετε αυτό, χρησιμοποιήστε nodeSelector με ετικέτα κόμβου.
Ας υποθέσουμε ότι έχετε δύο κόμβους: ο ένας με CPUType=HIGHFREQ και ένας μεγάλος αριθμός γρήγορων πυρήνων, ένας άλλος με MemoryType=HIGHMEMORY περισσότερη μνήμη και ταχύτερη απόδοση. Ο ευκολότερος τρόπος είναι να αντιστοιχίσετε μια ανάπτυξη pod σε έναν κόμβο HIGHFREQμε προσθήκη στην ενότητα spec ένας επιλογέας όπως αυτός:
…
nodeSelector:
CPUType: HIGHFREQΈνας πιο δαπανηρός και συγκεκριμένος τρόπος για να γίνει αυτό είναι να χρησιμοποιήσετε nodeAffinity στον τομέα affinity Ενότητα spec. Υπάρχουν δύο επιλογές:
-
requiredDuringSchedulingIgnoredDuringExecution: σκληρή ρύθμιση (ο προγραμματιστής θα αναπτύξει pods μόνο σε συγκεκριμένους κόμβους (και πουθενά αλλού)). -
preferredDuringSchedulingIgnoredDuringExecution: μαλακή ρύθμιση (ο προγραμματιστής θα προσπαθήσει να αναπτύξει σε συγκεκριμένους κόμβους και αν αποτύχει, θα προσπαθήσει να αναπτυχθεί στον επόμενο διαθέσιμο κόμβο).
Μπορείτε να καθορίσετε μια συγκεκριμένη σύνταξη για τη διαχείριση ετικετών κόμβων, για παράδειγμα, In, NotIn, Exists, DoesNotExist, Gt ή Lt. Ωστόσο, να θυμάστε ότι πολύπλοκες μέθοδοι σε μεγάλες λίστες ετικετών θα επιβραδύνουν τη λήψη αποφάσεων σε κρίσιμες καταστάσεις. Με άλλα λόγια, μην περιπλέκεσαι υπερβολικά.
Όπως αναφέρθηκε παραπάνω, το Kubernetes σάς επιτρέπει να ορίσετε τη σύνδεση των τρεχόντων pods. Δηλαδή, μπορείτε να κάνετε ορισμένα pods να λειτουργούν μαζί με άλλα pods στην ίδια ζώνη διαθεσιμότητας (σχετική για σύννεφα) ή κόμβους.
В podAffinity περιθώρια affinity Ενότητα spec είναι διαθέσιμα τα ίδια πεδία όπως στην περίπτωση του nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. Η μόνη διαφορά είναι ότι matchExpressions θα συνδέσει τα pods σε έναν κόμβο που εκτελεί ήδη ένα pod με αυτήν την ετικέτα.
Περισσότερα Kubernetes προσφέρει ένα πεδίο podAntiAffinity, το οποίο, αντίθετα, δεν συνδέει ένα pod σε έναν κόμβο με συγκεκριμένα pods.
Περί εκφράσεων nodeAffinity Η ίδια συμβουλή μπορεί να δοθεί: προσπαθήστε να διατηρήσετε τους κανόνες απλούς και λογικούς, μην προσπαθήσετε να υπερφορτώσετε την προδιαγραφή του pod με ένα περίπλοκο σύνολο κανόνων. Είναι πολύ εύκολο να δημιουργήσετε έναν κανόνα που δεν ταιριάζει με τις συνθήκες του συμπλέγματος, επιβαρύνοντας επιπλέον τον προγραμματιστή και υποβαθμίζοντας τη συνολική απόδοση.
7. Κηλίδες & Ανοχές
Υπάρχει ένας άλλος τρόπος διαχείρισης του προγραμματιστή. Εάν έχετε ένα μεγάλο σύμπλεγμα με εκατοντάδες κόμβους και χιλιάδες μικροϋπηρεσίες, είναι πολύ δύσκολο να αποτρέψετε τη φιλοξενία ορισμένων ομάδων από συγκεκριμένους κόμβους.
Σε αυτό βοηθάει ο μηχανισμός των κηλίδων -απαγορευτικοί κανόνες. Για παράδειγμα, μπορείτε να αποτρέψετε ορισμένους κόμβους από το να εκτελούν pods σε συγκεκριμένα σενάρια. Για να εφαρμόσετε χρώση σε έναν συγκεκριμένο κόμβο, χρησιμοποιήστε την επιλογή taint στο kubectl. Καθορίστε το κλειδί και την τιμή και, στη συνέχεια, κηλιδώστε σαν NoSchedule ή NoExecute:
$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoScheduleΑξίζει επίσης να σημειωθεί ότι ο μηχανισμός χρώσης υποστηρίζει τρία κύρια αποτελέσματα: NoSchedule, NoExecute и PreferNoSchedule.
-
NoScheduleσημαίνει ότι μέχρι να υπάρξει αντίστοιχη καταχώρηση στην προδιαγραφή podtolerations, δεν μπορεί να αναπτυχθεί στον κόμβο (σε αυτό το παράδειγμαnode10). -
PreferNoSchedule- απλοποιημένη έκδοσηNoSchedule. Σε αυτήν την περίπτωση, ο προγραμματιστής θα προσπαθήσει να μην εκχωρήσει ομάδες που δεν έχουν αντίστοιχη καταχώριση.tolerationsανά κόμβο, αλλά αυτό δεν είναι δύσκολο όριο. Εάν δεν υπάρχουν πόροι στο σύμπλεγμα, τότε τα pods θα αρχίσουν να αναπτύσσονται σε αυτόν τον κόμβο. -
NoExecute- αυτό το φαινόμενο ενεργοποιεί την άμεση εκκένωση των λοβών που δεν έχουν αντίστοιχη καταχώρισηtolerations.
Περιέργως, αυτή η συμπεριφορά μπορεί να αναιρεθεί χρησιμοποιώντας τον μηχανισμό ανοχής. Αυτό είναι βολικό όταν υπάρχει ένας "απαγορευμένος" κόμβος και πρέπει να τοποθετήσετε μόνο υπηρεσίες υποδομής σε αυτόν. Πως να το κάνεις? Επιτρέπονται μόνο εκείνα τα λοβό για τα οποία υπάρχει κατάλληλη ανοχή.
Δείτε πώς θα μοιάζει το spec του pod:
spec:
tolerations:
- key: "node-role.kubernetes.io/ingress"
operator: "Equal"
value: "true"
effect: "NoSchedule"Αυτό δεν σημαίνει ότι κατά την επόμενη αναδιάταξη, το pod θα χτυπήσει ακριβώς αυτόν τον κόμβο, αυτός δεν είναι ο μηχανισμός Node Affinity και nodeSelector. Αλλά συνδυάζοντας πολλά χαρακτηριστικά, μπορείτε να επιτύχετε μια πολύ ευέλικτη ρύθμιση χρονοπρογραμματιστή.
8. Ορίστε την προτεραιότητα ανάπτυξης pod
Ακριβώς επειδή έχετε διαμορφώσει τις συνδέσεις pod-to-node δεν σημαίνει ότι όλα τα pod θα πρέπει να αντιμετωπίζονται με την ίδια προτεραιότητα. Για παράδειγμα, μπορεί να θέλετε να αναπτύξετε ορισμένα Pods πριν από άλλα.
Το Kubernetes προσφέρει διαφορετικούς τρόπους για να ορίσετε την Προτεραιότητα Pod και την Προκαταβολή. Η ρύθμιση αποτελείται από πολλά μέρη: αντικείμενο PriorityClass και περιγραφές πεδίων priorityClassName στην προδιαγραφή λοβού. Εξετάστε ένα παράδειγμα:
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"Δημιουργούμε PriorityClass, δώστε του όνομα, περιγραφή και τιμή. Όσο πιο ψηλά value, τόσο μεγαλύτερη είναι η προτεραιότητα. Η τιμή μπορεί να είναι οποιοσδήποτε ακέραιος αριθμός 32 bit μικρότερος ή ίσος με 1. Οι υψηλότερες τιμές δεσμεύονται για ομάδες κρίσιμων για την αποστολή συστήματος, οι οποίες συνήθως δεν μπορούν να προβλεφθούν. Η απομάκρυνση θα συμβεί μόνο εάν το λοβό υψηλής προτεραιότητας δεν έχει πού να γυρίσει, τότε ορισμένα από τα λοβά από έναν συγκεκριμένο κόμβο θα εκκενωθούν. Εάν αυτός ο μηχανισμός είναι πολύ άκαμπτος για εσάς, τότε μπορείτε να προσθέσετε την επιλογή preemptionPolicy: Never, και μετά δεν θα υπάρχει προνόμιο, το pod θα είναι το πρώτο στην ουρά και θα περιμένει τον προγραμματιστή να βρει δωρεάν πόρους για αυτό.
Στη συνέχεια, δημιουργούμε ένα pod, στο οποίο καθορίζουμε το όνομα priorityClassName:
apiVersion: v1
kind: Pod
metadata:
name: static-web
labels:
role: myrole
spec:
containers:
- name: web
image: nginx
ports:
- name: web
containerPort: 80
protocol: TCP
priorityClassName: high-priority
Μπορείτε να δημιουργήσετε όσες τάξεις προτεραιότητας θέλετε, αν και συνιστάται να μην παρασυρθείτε με αυτό (ας πούμε, περιοριστείτε σε χαμηλή, μεσαία και υψηλή προτεραιότητα).
Έτσι, εάν είναι απαραίτητο, μπορείτε να αυξήσετε την αποτελεσματικότητα της ανάπτυξης κρίσιμων υπηρεσιών, όπως nginx-ingress-controller, coredns κ.λπ.
9. Βελτιστοποιήστε το σύμπλεγμα ETCD σας
Το ETCD μπορεί να ονομαστεί ο εγκέφαλος ολόκληρου του συμπλέγματος. Είναι πολύ σημαντικό να διατηρείται η λειτουργία αυτής της βάσης δεδομένων σε υψηλό επίπεδο, αφού η ταχύτητα των λειτουργιών στον «Κύβο» εξαρτάται από αυτό. Μια αρκετά τυπική, και ταυτόχρονα, μια καλή λύση θα ήταν να διατηρηθεί ένα σύμπλεγμα ETCD στους κύριους κόμβους προκειμένου να υπάρχει μια ελάχιστη καθυστέρηση στον kube-apiserver. Εάν αυτό δεν είναι δυνατό, τότε τοποθετήστε το ETCD όσο το δυνατόν πιο κοντά, με καλό εύρος ζώνης μεταξύ των συμμετεχόντων. Προσέξτε επίσης πόσοι κόμβοι από το ETCD μπορούν να πέσουν χωρίς να βλάψουν το σύμπλεγμα.
Λάβετε υπόψη ότι μια υπερβολική αύξηση του αριθμού των συμμετεχόντων στο σύμπλεγμα μπορεί να αυξήσει την ανοχή σφαλμάτων σε βάρος της απόδοσης, όλα πρέπει να είναι με μέτρο.
Αν μιλάμε για τη ρύθμιση της υπηρεσίας, τότε υπάρχουν μερικές συστάσεις:
-
Έχετε καλό υλικό, με βάση το μέγεθος του συμπλέγματος (μπορείτε να διαβάσετε ).
-
Προσαρμόστε μερικές παραμέτρους, εάν έχετε απλώσει ένα σύμπλεγμα μεταξύ ενός ζεύγους DC ή το δίκτυό σας και οι δίσκοι σας αφήνουν πολλά να είναι επιθυμητά (μπορείτε να διαβάσετε ).
Συμπέρασμα
Αυτό το άρθρο περιγράφει τα σημεία με τα οποία προσπαθεί να συμμορφωθεί η ομάδα μας. Αυτή δεν είναι μια αναλυτική περιγραφή των ενεργειών, αλλά επιλογές που μπορούν να είναι χρήσιμες για τη βελτιστοποίηση των γενικών εξόδων ενός συμπλέγματος. Είναι σαφές ότι κάθε σύμπλεγμα είναι μοναδικό με τον δικό του τρόπο και οι λύσεις συντονισμού μπορεί να διαφέρουν πολύ, επομένως θα ήταν ενδιαφέρον να λάβουμε σχόλια από εσάς: πώς παρακολουθείτε το σύμπλεγμα Kubernetes, πώς βελτιώνετε την απόδοσή του. Μοιραστείτε την εμπειρία σας στα σχόλια, θα είναι ενδιαφέρον να το μάθετε.
Πηγή: www.habr.com