Διαδικασία αναβάθμισης για το σύμπλεγμα Kubernetes
Σε κάποιο σημείο, όταν χρησιμοποιείτε ένα σύμπλεγμα Kubernetes, υπάρχει ανάγκη ενημέρωσης των κόμβων που εκτελούνται. Αυτό μπορεί να περιλαμβάνει ενημερώσεις πακέτων, ενημερώσεις πυρήνα ή ανάπτυξη νέων εικόνων εικονικής μηχανής. Στην ορολογία Kubernetes αυτό ονομάζεται .
Αυτή η ανάρτηση είναι μέρος μιας σειράς 4 αναρτήσεων:
- Αυτή η ανάρτηση.
- Σωστός τερματισμός λοβών σε ένα σύμπλεγμα Kubernetes
- Καθυστερημένος τερματισμός ενός pod όταν διαγραφεί
- Πώς να αποφύγετε το χρόνο διακοπής λειτουργίας του συμπλέγματος Kubernetes χρησιμοποιώντας το PodDisruptionBudgets
(περίπου αναμένονται μεταφράσεις των υπόλοιπων άρθρων της σειράς στο εγγύς μέλλον)
Σε αυτό το άρθρο, θα περιγράψουμε όλα τα εργαλεία που παρέχει το Kubernetes για την επίτευξη μηδενικού χρόνου διακοπής λειτουργίας για τους κόμβους που εκτελούνται στο σύμπλεγμα σας.
Ορισμός προβλήματος
Θα ακολουθήσουμε μια αφελή προσέγγιση στην αρχή, θα εντοπίσουμε προβλήματα και θα αξιολογήσουμε τους πιθανούς κινδύνους αυτής της προσέγγισης και θα δημιουργήσουμε γνώσεις για να λύσουμε καθένα από τα προβλήματα που αντιμετωπίζουμε σε όλο τον κύκλο. Το αποτέλεσμα είναι μια διαμόρφωση που χρησιμοποιεί άγκιστρα κύκλου ζωής, ανιχνευτές ετοιμότητας και προϋπολογισμούς διακοπής Pod για την επίτευξη του στόχου μηδενικού χρόνου διακοπής λειτουργίας.
Για να ξεκινήσουμε το ταξίδι μας, ας πάρουμε ένα συγκεκριμένο παράδειγμα. Ας υποθέσουμε ότι έχουμε ένα σύμπλεγμα Kubernetes δύο κόμβων, στο οποίο εκτελείται μια εφαρμογή με δύο ομάδες που βρίσκονται πίσω Service:
Ας ξεκινήσουμε με δύο pods με το Nginx και το Service να τρέχουν στους δύο κόμβους συμπλέγματος Kubernetes.
Θέλουμε να ενημερώσουμε την έκδοση πυρήνα δύο κόμβων εργαζομένων στο σύμπλεγμα μας. Πώς το κάνουμε αυτό; Μια απλή λύση θα ήταν να εκκινήσετε νέους κόμβους με την ενημερωμένη διαμόρφωση και στη συνέχεια να κλείσετε τους παλιούς κόμβους κατά την εκκίνηση των νέων. Αν και αυτό θα λειτουργήσει, θα υπάρχουν μερικά προβλήματα με αυτήν την προσέγγιση:
- Όταν απενεργοποιείτε τους παλιούς κόμβους, τα pods που εκτελούνται σε αυτούς θα απενεργοποιούνται επίσης. Τι θα συμβεί αν οι λοβοί πρέπει να καθαριστούν για χαριτωμένο τερματισμό; Το σύστημα εικονικοποίησης που χρησιμοποιείτε ενδέχεται να μην περιμένει να ολοκληρωθεί η διαδικασία εκκαθάρισης.
- Τι γίνεται αν απενεργοποιήσετε όλους τους κόμβους ταυτόχρονα; Θα έχετε αξιοπρεπή χρόνο διακοπής λειτουργίας ενώ τα pods μετακινούνται σε νέους κόμβους.
Χρειαζόμαστε έναν τρόπο για να μεταφέρουμε με χάρη τα pods από παλιούς κόμβους διασφαλίζοντας παράλληλα ότι καμία από τις διεργασίες εργασίας μας δεν εκτελείται ενώ κάνουμε αλλαγές στον κόμβο. Ή όταν κάνουμε μια πλήρη αντικατάσταση του συμπλέγματος, όπως στο παράδειγμα (αντικαθιστούμε δηλαδή εικόνες VM), θέλουμε να μεταφέρουμε εφαρμογές που τρέχουν από παλιούς κόμβους σε νέους. Και στις δύο περιπτώσεις, θέλουμε να αποτρέψουμε τον προγραμματισμό νέων ομάδων σε παλιούς κόμβους και, στη συνέχεια, να αφαιρέσουμε όλες τις εκτελούμενες ομάδες από αυτούς. Για να πετύχουμε αυτούς τους στόχους μπορούμε να χρησιμοποιήσουμε την εντολή kubectl drain.
Ανακατανομή όλων των λοβών από έναν κόμβο
Η λειτουργία αποστράγγισης σάς επιτρέπει να αναδιανείμετε όλα τα pods από έναν κόμβο. Κατά την εκτέλεση του drain, ο κόμβος επισημαίνεται ως μη προγραμματισμένος (σημαία NoSchedule). Αυτό αποτρέπει την εμφάνιση νέων λοβών σε αυτό. Στη συνέχεια, η αποστράγγιση αρχίζει να απομακρύνει τους λοβούς από τον κόμβο, κλείνει τα δοχεία που τρέχουν αυτήν τη στιγμή στον κόμβο, στέλνοντας ένα σήμα TERM δοχεία σε λοβό.
αν και kubectl drain θα κάνει πολύ καλή δουλειά στην απομάκρυνση των λοβών, υπάρχουν δύο άλλοι παράγοντες που μπορούν να προκαλέσουν την αποτυχία της λειτουργίας αποστράγγισης:
- Η αίτησή σας πρέπει να μπορεί να τερματιστεί με χάρη κατά την υποβολή
TERMσήμα. Όταν τα pods εξωθούνται, το Kubernetes στέλνει ένα σήμαTERMκοντέινερ και περιμένει να σταματήσουν για συγκεκριμένο χρονικό διάστημα, μετά από το οποίο, αν δεν έχουν σταματήσει, τα τερματίζει αναγκαστικά. Σε κάθε περίπτωση, εάν το κοντέινερ σας δεν αντιλαμβάνεται σωστά το σήμα, μπορείτε και πάλι να σβήσετε τα pods εσφαλμένα εάν εκτελούνται αυτήν τη στιγμή (για παράδειγμα, μια συναλλαγή βάσης δεδομένων βρίσκεται σε εξέλιξη). - Χάνετε όλα τα pods που περιέχουν την εφαρμογή σας. Ενδέχεται να μην είναι διαθέσιμο όταν εκκινούνται νέα κοντέινερ σε νέους κόμβους ή εάν τα pod σας αναπτύσσονται χωρίς ελεγκτές, ενδέχεται να μην επανεκκινηθούν καθόλου.
Αποφυγή χρόνου διακοπής λειτουργίας
Για να ελαχιστοποιηθεί ο χρόνος διακοπής λειτουργίας από εκούσια διακοπή, όπως από μια λειτουργία αποστράγγισης σε έναν κόμβο, το Kubernetes παρέχει τις ακόλουθες επιλογές χειρισμού αστοχιών:
Στην υπόλοιπη σειρά, θα χρησιμοποιήσουμε αυτές τις δυνατότητες του Kubernetes για να μετριαστεί ο αντίκτυπος της μετεγκατάστασης pod. Για να διευκολύνουμε την παρακολούθηση της κύριας ιδέας, θα χρησιμοποιήσουμε το παραπάνω παράδειγμά μας με την ακόλουθη διαμόρφωση πόρων:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15
ports:
- containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
targetPort: 80
port: 80Αυτή η διαμόρφωση είναι ένα ελάχιστο παράδειγμα Deployment, το οποίο διαχειρίζεται τα nginx pods στο σύμπλεγμα. Επιπλέον, η διαμόρφωση περιγράφει τον πόρο Service, το οποίο μπορεί να χρησιμοποιηθεί για πρόσβαση σε pods nginx σε ένα σύμπλεγμα.
Καθ' όλη τη διάρκεια του κύκλου, θα επεκτείνουμε επαναληπτικά αυτήν τη διαμόρφωση, ώστε τελικά να περιλαμβάνει όλες τις δυνατότητες που παρέχει η Kubernetes για τη μείωση του χρόνου διακοπής λειτουργίας.
Για μια πλήρως εφαρμοσμένη και δοκιμασμένη έκδοση των ενημερώσεων συμπλέγματος Kubernetes για μηδενικό χρόνο διακοπής λειτουργίας στο AWS και πέραν αυτού, επισκεφθείτε .
Διαβάστε επίσης άλλα άρθρα στο ιστολόγιό μας:
Πηγή: www.habr.com