Το Kubernetes είναι ένα εξαιρετικό εργαλείο για τη λειτουργία κοντέινερ Docker σε περιβάλλον συμπλέγματος παραγωγής. Ωστόσο, υπάρχουν προβλήματα που η Kubernetes δεν μπορεί να λύσει. Για συχνές αναπτύξεις παραγωγής, χρειαζόμαστε μια πλήρως αυτοματοποιημένη ανάπτυξη Μπλε/Πράσινου για την αποφυγή διακοπής λειτουργίας στη διαδικασία, η οποία πρέπει επίσης να χειρίζεται εξωτερικά αιτήματα HTTP και να εκτελεί εκφορτώσεις SSL. Αυτό απαιτεί ενσωμάτωση με έναν εξισορροπητή φορτίου όπως το ha-proxy. Μια άλλη πρόκληση είναι η ημιαυτόματη κλιμάκωση του ίδιου του συμπλέγματος Kubernetes όταν εκτελείται σε περιβάλλον σύννεφο, για παράδειγμα η μερική κλιμάκωση του συμπλέγματος προς τα κάτω τη νύχτα.
Αν και το Kubernetes δεν διαθέτει αυτές τις δυνατότητες εκτός συσκευασίας, παρέχει ένα API που μπορείτε να χρησιμοποιήσετε για να λύσετε παρόμοια προβλήματα. Εργαλεία για την αυτοματοποιημένη ανάπτυξη Μπλε/Πράσινο και την κλιμάκωση ενός συμπλέγματος Kubernetes αναπτύχθηκαν ως μέρος του έργου Cloud RTI, το οποίο δημιουργήθηκε με βάση ανοιχτού κώδικα.
Αυτό το άρθρο, μια μεταγραφή βίντεο, σας δείχνει πώς να ρυθμίσετε το Kubernetes μαζί με άλλα στοιχεία ανοιχτού κώδικα για να δημιουργήσετε ένα περιβάλλον έτοιμο για παραγωγή που δέχεται κώδικα από μια δέσμευση git χωρίς χρόνο διακοπής της παραγωγής.
Έτσι, αφού έχετε πρόσβαση στις εφαρμογές σας από τον έξω κόσμο, μπορείτε να αρχίσετε να ρυθμίζετε πλήρως τον αυτοματισμό, δηλαδή να τον φέρετε στο στάδιο όπου μπορείτε να εκτελέσετε μια δέσμευση git και να βεβαιωθείτε ότι αυτή η δέσμευση git καταλήγει στην παραγωγή. Φυσικά, κατά την εφαρμογή αυτών των βημάτων, κατά την υλοποίηση της ανάπτυξης, δεν θέλουμε να αντιμετωπίσουμε διακοπές λειτουργίας. Έτσι, οποιοσδήποτε αυτοματισμός στο Kubernetes ξεκινά με το API.
Το Kubernetes δεν είναι ένα εργαλείο που μπορεί να χρησιμοποιηθεί παραγωγικά εκτός συσκευασίας. Φυσικά, μπορείτε να το κάνετε αυτό, να χρησιμοποιήσετε το kubectl και ούτω καθεξής, αλλά και πάλι το API είναι το πιο ενδιαφέρον και χρήσιμο πράγμα σε αυτήν την πλατφόρμα. Χρησιμοποιώντας το API ως σύνολο λειτουργιών, μπορείτε να έχετε πρόσβαση σχεδόν σε οτιδήποτε θέλετε να κάνετε στο Kubernetes. Το ίδιο το kubectl χρησιμοποιεί επίσης το REST API.
Αυτό είναι το REST, ώστε να μπορείτε να χρησιμοποιήσετε οποιαδήποτε γλώσσα ή εργαλείο για να εργαστείτε με αυτό το API, αλλά η ζωή σας θα γίνει πολύ πιο εύκολη από προσαρμοσμένες βιβλιοθήκες. Η ομάδα μου έγραψε 2 τέτοιες βιβλιοθήκες: μία για Java/OSGi και μία για Go. Το δεύτερο δεν χρησιμοποιείται συχνά, αλλά σε κάθε περίπτωση έχετε αυτά τα χρήσιμα πράγματα στη διάθεσή σας. Είναι ένα έργο ανοιχτού κώδικα με μερική άδεια. Υπάρχουν πολλές τέτοιες βιβλιοθήκες για διαφορετικές γλώσσες, οπότε μπορείτε να επιλέξετε αυτές που σας ταιριάζουν περισσότερο.
Επομένως, προτού ξεκινήσετε την αυτοματοποίηση της ανάπτυξής σας, πρέπει να βεβαιωθείτε ότι η διαδικασία δεν θα υπόκειται σε διακοπές λειτουργίας. Για παράδειγμα, η ομάδα μας πραγματοποιεί αναπτύξεις παραγωγής στη μέση της ημέρας, όταν οι χρήστες χρησιμοποιούν τις εφαρμογές στο μέγιστο δυνατό βαθμό, επομένως είναι σημαντικό να αποφύγετε καθυστερήσεις σε αυτήν τη διαδικασία. Για να αποφευχθεί ο χρόνος διακοπής λειτουργίας, χρησιμοποιούνται 2 μέθοδοι: μπλε/πράσινη ανάπτυξη ή κυλιόμενη ενημέρωση. Στην τελευταία περίπτωση, εάν εκτελούνται 5 αντίγραφα της εφαρμογής, ενημερώνονται διαδοχικά το ένα μετά το άλλο. Αυτή η μέθοδος λειτουργεί εξαιρετικά, αλλά δεν είναι κατάλληλη εάν έχετε διαφορετικές εκδόσεις της εφαρμογής που εκτελούνται ταυτόχρονα κατά τη διαδικασία ανάπτυξης. Σε αυτήν την περίπτωση, μπορείτε να ενημερώσετε τη διεπαφή χρήστη ενώ το backend εκτελεί την παλιά έκδοση και η εφαρμογή θα σταματήσει να λειτουργεί. Επομένως, από προγραμματική άποψη, η εργασία σε τέτοιες συνθήκες είναι αρκετά δύσκολη.
Αυτός είναι ένας από τους λόγους για τους οποίους προτιμούμε να χρησιμοποιούμε μπλε/πράσινη ανάπτυξη για να αυτοματοποιήσουμε την ανάπτυξη των εφαρμογών μας. Με αυτήν τη μέθοδο, πρέπει να βεβαιωθείτε ότι μόνο μία έκδοση της εφαρμογής είναι ενεργή κάθε φορά.
Ο μπλε/πράσινος μηχανισμός ανάπτυξης μοιάζει με αυτό. Λαμβάνουμε επισκεψιμότητα για τις εφαρμογές μας μέσω ha-proxy, το οποίο την προωθεί σε εκτελούμενα αντίγραφα της εφαρμογής της ίδιας έκδοσης.
Όταν γίνεται μια νέα ανάπτυξη, χρησιμοποιούμε το Deployer, στο οποίο δίνονται τα νέα στοιχεία και αναπτύσσει τη νέα έκδοση. Η ανάπτυξη μιας νέας έκδοσης μιας εφαρμογής σημαίνει ότι δημιουργείται ένα νέο σύνολο αντιγράφων, μετά το οποίο αυτά τα αντίγραφα της νέας έκδοσης κυκλοφορούν σε ξεχωριστό, νέο pod. Ωστόσο, το ha-proxy δεν γνωρίζει τίποτα γι 'αυτούς και δεν τους δρομολογεί ακόμη φόρτο εργασίας.
Επομένως, πρώτα απ 'όλα, είναι απαραίτητο να πραγματοποιήσετε έναν έλεγχο απόδοσης των νέων εκδόσεων του υγειονομικού ελέγχου για να διασφαλίσετε ότι τα αντίγραφα είναι έτοιμα για τη συντήρηση του φορτίου.
Όλα τα εξαρτήματα ανάπτυξης πρέπει να υποστηρίζουν κάποια μορφή υγειονομικού ελέγχου. Αυτό μπορεί να είναι ένας πολύ απλός έλεγχος κλήσης HTTP, όταν λαμβάνετε έναν κωδικό με κατάσταση 200, ή ένας πιο εις βάθος έλεγχος, στον οποίο ελέγχετε τη σύνδεση των αντιγράφων με τη βάση δεδομένων και άλλες υπηρεσίες, τη σταθερότητα των συνδέσεων δυναμικού περιβάλλοντος , και αν όλα ξεκινούν και λειτουργούν σωστά. Αυτή η διαδικασία μπορεί να είναι αρκετά περίπλοκη.
Αφού το σύστημα επαληθεύσει ότι όλα τα ενημερωμένα αντίγραφα λειτουργούν, το Deployer θα ενημερώσει τη διαμόρφωση και θα περάσει τη σωστή confd, η οποία θα διαμορφώσει εκ νέου το ha-proxy.
Μόνο μετά από αυτό θα κατευθυνθεί η κυκλοφορία στο pod με αντίγραφα της νέας έκδοσης και το παλιό pod θα εξαφανιστεί.
Αυτός ο μηχανισμός δεν είναι χαρακτηριστικό του Kubernetes. Η ιδέα της ανάπτυξης μπλε/πράσινου υπάρχει εδώ και πολύ καιρό και πάντα χρησιμοποιούσε έναν εξισορροπητή φορτίου. Αρχικά, κατευθύνετε όλη την επισκεψιμότητα στην παλιά έκδοση της εφαρμογής και μετά την ενημέρωση, τη μεταφέρετε πλήρως στη νέα έκδοση. Αυτή η αρχή χρησιμοποιείται όχι μόνο στο Kubernetes.
Τώρα θα σας παρουσιάσω ένα νέο στοιχείο ανάπτυξης - Deployer, το οποίο εκτελεί υγειονομικούς ελέγχους, διαμορφώνει εκ νέου τους διακομιστές μεσολάβησης και ούτω καθεξής. Αυτή είναι μια έννοια που δεν ισχύει για τον έξω κόσμο και υπάρχει μέσα στο Kubernetes. Θα σας δείξω πώς μπορείτε να δημιουργήσετε τη δική σας ιδέα Deployer χρησιμοποιώντας εργαλεία ανοιχτού κώδικα.
Έτσι, το πρώτο πράγμα που κάνει ο Deployer είναι να δημιουργήσει έναν ελεγκτή αναπαραγωγής RC χρησιμοποιώντας το Kubernetes API. Αυτό το API δημιουργεί pods και υπηρεσίες για περαιτέρω ανάπτυξη, δηλαδή δημιουργεί ένα εντελώς νέο σύμπλεγμα για τις εφαρμογές μας. Μόλις η RC πειστεί ότι τα αντίγραφα έχουν ξεκινήσει, θα πραγματοποιήσει έλεγχο υγείας για τη λειτουργικότητά τους. Για να γίνει αυτό, ο Deployer χρησιμοποιεί την εντολή GET /health. Εκτελεί τα κατάλληλα στοιχεία σάρωσης και ελέγχει όλα τα στοιχεία που υποστηρίζουν τη λειτουργία του συμπλέγματος.
Αφού όλα τα pods αναφέρουν την υγεία τους, ο Deployer δημιουργεί ένα νέο στοιχείο διαμόρφωσης - etcd κατανεμημένο χώρο αποθήκευσης, ο οποίος χρησιμοποιείται εσωτερικά από την Kubernetes, συμπεριλαμβανομένης της αποθήκευσης της διαμόρφωσης του εξισορροπητή φορτίου. Γράφουμε δεδομένα στο etcd και ένα μικρό εργαλείο που ονομάζεται confd παρακολουθεί etcd για νέα δεδομένα.
Εάν εντοπίσει αλλαγές στην αρχική διαμόρφωση, δημιουργεί ένα νέο αρχείο ρυθμίσεων και το μεταφέρει στο ha-proxy. Σε αυτήν την περίπτωση, το ha-proxy επανεκκινεί χωρίς να χάσει καμία σύνδεση και απευθύνει το φορτίο σε νέες υπηρεσίες που επιτρέπουν τη λειτουργία της νέας έκδοσης των εφαρμογών μας.
Όπως μπορείτε να δείτε, παρά την αφθονία των εξαρτημάτων, δεν υπάρχει τίποτα περίπλοκο εδώ. Απλώς πρέπει να δώσετε περισσότερη προσοχή στο API και κ.λπ. Θέλω να σας πω για τον προγραμματιστή ανοιχτού κώδικα που χρησιμοποιούμε εμείς οι ίδιοι - το Amdatu Kubernetes Deployer.
Είναι ένα εργαλείο για την ενορχήστρωση αναπτύξεων Kubernetes και έχει τα ακόλουθα χαρακτηριστικά:
- Μπλε/Πράσινη ανάπτυξη.
- εγκατάσταση ενός εξωτερικού εξισορροπητή φορτίου.
- διαχείριση περιγραφέων ανάπτυξης·
- διαχείριση της πραγματικής ανάπτυξης·
- έλεγχος της λειτουργικότητας των ελέγχων υγείας κατά την ανάπτυξη·
- εφαρμογή μεταβλητών περιβάλλοντος σε pods.
Αυτός ο Deployer είναι χτισμένος πάνω από το Kubernetes API και παρέχει ένα REST API για διαχείριση λαβών και αναπτύξεων, καθώς και ένα Websocket API για αρχεία καταγραφής ροής κατά τη διαδικασία ανάπτυξης.
Τοποθετεί τα δεδομένα διαμόρφωσης του εξισορροπητή φορτίου σε etcd, ώστε να μην χρειάζεται να χρησιμοποιείτε διακομιστή μεσολάβησης ha με υποστήριξη out-of-the-box, αλλά να χρησιμοποιείτε εύκολα το δικό σας αρχείο διαμόρφωσης εξισορρόπησης φορτίου. Το Amdatu Deployer είναι γραμμένο στο Go, όπως το ίδιο το Kubernetes, και έχει άδεια χρήσης από τον Apache.
Πριν ξεκινήσω να χρησιμοποιώ αυτήν την έκδοση του προγράμματος ανάπτυξης, χρησιμοποίησα τον ακόλουθο περιγραφέα ανάπτυξης, ο οποίος καθορίζει τις παραμέτρους που χρειάζομαι.
Μία από τις σημαντικές παραμέτρους αυτού του κώδικα είναι να ενεργοποιήσει τη σημαία "useHealthCheck". Πρέπει να διευκρινίσουμε ότι πρέπει να γίνει έλεγχος υγιεινής κατά τη διαδικασία ανάπτυξης. Αυτή η ρύθμιση μπορεί να απενεργοποιηθεί όταν η ανάπτυξη χρησιμοποιεί κοντέινερ τρίτων που δεν χρειάζεται να επαληθευτούν. Αυτός ο περιγραφέας υποδεικνύει επίσης τον αριθμό των αντιγράφων και τη διεύθυνση URL διεπαφής που χρειάζεται ο ha-proxy. Στο τέλος βρίσκεται η σημαία προδιαγραφών pod "podspec", η οποία καλεί το Kubernetes για πληροφορίες σχετικά με τη διαμόρφωση της θύρας, την εικόνα κ.λπ. Αυτός είναι ένας αρκετά απλός περιγραφέας JSON.
Ένα άλλο εργαλείο που αποτελεί μέρος του έργου ανοιχτού κώδικα Amdatu είναι το Deploymentctl. Διαθέτει διεπαφή χρήστη για τη διαμόρφωση των αναπτύξεων, αποθηκεύει το ιστορικό ανάπτυξης και περιέχει webhook για επανακλήσεις από τρίτους χρήστες και προγραμματιστές. Δεν μπορείτε να χρησιμοποιήσετε τη διεπαφή χρήστη, καθώς το ίδιο το Amdatu Deployer είναι ένα REST API, αλλά αυτή η διεπαφή μπορεί να κάνει την ανάπτυξη πολύ πιο εύκολη για εσάς χωρίς να περιλαμβάνει κάποιο API. Το Deploymentctl είναι γραμμένο σε OSGi/Vertx χρησιμοποιώντας το Angular 2.
Τώρα θα δείξω τα παραπάνω στην οθόνη χρησιμοποιώντας μια προηχογραφημένη εγγραφή, ώστε να μην χρειάζεται να περιμένετε. Θα αναπτύξουμε μια απλή εφαρμογή Go. Μην ανησυχείτε αν δεν έχετε δοκιμάσει το Go πριν, είναι μια πολύ απλή εφαρμογή, οπότε θα πρέπει να μπορείτε να το καταλάβετε.
Εδώ δημιουργούμε έναν διακομιστή HTTP που ανταποκρίνεται μόνο στο /health, επομένως αυτή η εφαρμογή δοκιμάζει μόνο τον έλεγχο υγείας και τίποτα άλλο. Εάν ο έλεγχος περάσει, χρησιμοποιείται η δομή JSON που φαίνεται παρακάτω. Περιέχει την έκδοση της εφαρμογής που θα αναπτυχθεί από τον προγραμματιστή, το μήνυμα που βλέπετε στην κορυφή του αρχείου και τον τύπο δεδομένων boolean - είτε η εφαρμογή μας λειτουργεί είτε όχι.
Απάτησα λίγο με την τελευταία γραμμή, γιατί τοποθέτησα μια σταθερή τιμή boolean στην κορυφή του αρχείου, η οποία στο μέλλον θα με βοηθήσει να αναπτύξω ακόμη και μια «ανθυγιεινή» εφαρμογή. Θα ασχοληθούμε με αυτό αργότερα.
Ας ξεκινήσουμε λοιπόν. Αρχικά, ελέγχουμε για την παρουσία τυχόν εκτελούμενων pods χρησιμοποιώντας την εντολή ~ kubectl get pods και, με βάση την απουσία απάντησης από τη διεύθυνση URL του frontend, βεβαιωνόμαστε ότι δεν πραγματοποιούνται αναπτύξεις αυτήν τη στιγμή.
Στη συνέχεια στην οθόνη βλέπετε τη διεπαφή Deploymentctl που ανέφερα, στην οποία ορίζονται οι παράμετροι ανάπτυξης: χώρος ονομάτων, όνομα εφαρμογής, έκδοση ανάπτυξης, αριθμός αντιγράφων, διεύθυνση URL διεπαφής, όνομα κοντέινερ, εικόνα, όρια πόρων, αριθμός θύρας για έλεγχο υγείας, κλπ. Τα όρια πόρων είναι πολύ σημαντικά, καθώς σας επιτρέπουν να χρησιμοποιήσετε τη μέγιστη δυνατή ποσότητα υλικού. Εδώ μπορείτε επίσης να δείτε το αρχείο καταγραφής ανάπτυξης.
Εάν τώρα επαναλάβετε την εντολή ~ kubectl get pods, μπορείτε να δείτε ότι το σύστημα «παγώνει» για 20 δευτερόλεπτα, κατά τη διάρκεια των οποίων ο ha-proxy επαναδιαμορφώνεται. Μετά από αυτό, το pod ξεκινά και το αντίγραφό μας μπορεί να φανεί στο αρχείο καταγραφής ανάπτυξης.
Έκοψα την αναμονή των 20 δευτερολέπτων από το βίντεο και τώρα μπορείτε να δείτε στην οθόνη ότι η πρώτη έκδοση της εφαρμογής έχει αναπτυχθεί. Όλα αυτά έγιναν χρησιμοποιώντας μόνο το UI.
Τώρα ας δοκιμάσουμε τη δεύτερη έκδοση. Για να το κάνω αυτό, αλλάζω το μήνυμα της εφαρμογής από "Γεια σου, Kubernetes!" στο "Hello, Deployer!", το σύστημα δημιουργεί αυτήν την εικόνα και την τοποθετεί στο μητρώο Docker, μετά από το οποίο κάνουμε απλώς κλικ στο κουμπί "Deploy" ξανά στο παράθυρο Deploymentctl. Σε αυτήν την περίπτωση, το αρχείο καταγραφής ανάπτυξης εκκινείται αυτόματα με τον ίδιο τρόπο που συνέβη κατά την ανάπτυξη της πρώτης έκδοσης της εφαρμογής.
Η εντολή ~ kubectl get pods δείχνει ότι αυτή τη στιγμή εκτελούνται 2 εκδόσεις της εφαρμογής, αλλά το frontend δείχνει ότι εξακολουθούμε να εκτελούμε την έκδοση 1.
Το πρόγραμμα εξισορρόπησης φορτίου περιμένει να ολοκληρωθεί ο έλεγχος υγείας πριν ανακατευθύνει την κυκλοφορία στη νέα έκδοση. Μετά από 20 δευτερόλεπτα, μεταβαίνουμε στο curl και βλέπουμε ότι έχουμε πλέον αναπτυχθεί η έκδοση 2 της εφαρμογής και η πρώτη έχει διαγραφεί.
Αυτή ήταν η ανάπτυξη μιας «υγιεινής» εφαρμογής. Ας δούμε τι θα συμβεί αν για μια νέα έκδοση της εφαρμογής αλλάξω την παράμετρο Healthy από true σε false, δηλαδή προσπαθήσω να αναπτύξω μια ανθυγιεινή εφαρμογή που απέτυχε στον έλεγχο υγείας. Αυτό μπορεί να συμβεί εάν έγιναν κάποια σφάλματα διαμόρφωσης στην εφαρμογή στο στάδιο ανάπτυξης και στάλθηκε στην παραγωγή με αυτήν τη μορφή.
Όπως μπορείτε να δείτε, η ανάπτυξη περνά από όλα τα παραπάνω βήματα και το ~kubectl get pods δείχνει ότι και τα δύο pods εκτελούνται. Αλλά σε αντίθεση με την προηγούμενη ανάπτυξη, το αρχείο καταγραφής εμφανίζει την κατάσταση χρονικού ορίου. Δηλαδή, λόγω του ότι ο έλεγχος υγείας απέτυχε, η νέα έκδοση της εφαρμογής δεν μπορεί να αναπτυχθεί. Ως αποτέλεσμα, βλέπετε ότι το σύστημα έχει επανέλθει στη χρήση της παλιάς έκδοσης της εφαρμογής και η νέα έκδοση έχει απλώς απεγκατασταθεί.
Το καλό με αυτό είναι ότι ακόμα κι αν έχετε έναν τεράστιο αριθμό ταυτόχρονων αιτημάτων που εισέρχονται στην εφαρμογή, δεν θα παρατηρήσουν καν το χρόνο διακοπής λειτουργίας κατά την εφαρμογή της διαδικασίας ανάπτυξης. Εάν δοκιμάσετε αυτήν την εφαρμογή χρησιμοποιώντας το πλαίσιο Gatling, το οποίο της στέλνει όσο το δυνατόν περισσότερα αιτήματα, τότε κανένα από αυτά τα αιτήματα δεν θα απορριφθεί. Αυτό σημαίνει ότι οι χρήστες μας δεν θα παρατηρήσουν καν ενημερώσεις έκδοσης σε πραγματικό χρόνο. Εάν αποτύχει, η εργασία θα συνεχιστεί στην παλιά έκδοση. Εάν είναι επιτυχής, οι χρήστες θα μεταβούν στη νέα έκδοση.
Υπάρχει μόνο ένα πράγμα που μπορεί να αποτύχει - εάν ο έλεγχος υγείας επιτύχει, αλλά η εφαρμογή αποτυγχάνει μόλις εφαρμοστεί ο φόρτος εργασίας σε αυτήν, δηλαδή, η κατάρρευση θα συμβεί μόνο μετά την ολοκλήρωση της ανάπτυξης. Σε αυτήν την περίπτωση, θα πρέπει να επιστρέψετε με μη αυτόματο τρόπο στην παλιά έκδοση. Έτσι, εξετάσαμε πώς να χρησιμοποιήσουμε το Kubernetes με τα εργαλεία ανοιχτού κώδικα που έχουν σχεδιαστεί για αυτό. Η διαδικασία ανάπτυξης θα είναι πολύ πιο εύκολη εάν ενσωματώσετε αυτά τα εργαλεία στους αγωγούς Build/Deploy. Ταυτόχρονα, για να ξεκινήσετε την ανάπτυξη, μπορείτε να χρησιμοποιήσετε είτε τη διεπαφή χρήστη είτε να αυτοματοποιήσετε πλήρως αυτή τη διαδικασία χρησιμοποιώντας, για παράδειγμα, το commit to master.
Ο Build Server μας θα δημιουργήσει μια εικόνα Docker, θα την προωθήσει στο Docker Hub ή σε οποιοδήποτε άλλο μητρώο χρησιμοποιείτε. Το Docker Hub υποστηρίζει το webhook, ώστε να μπορούμε να ενεργοποιήσουμε την απομακρυσμένη ανάπτυξη μέσω του Deployer με τον τρόπο που φαίνεται παραπάνω. Με αυτόν τον τρόπο μπορείτε να αυτοματοποιήσετε πλήρως την ανάπτυξη της εφαρμογής σας σε πιθανή παραγωγή.
Ας προχωρήσουμε στο επόμενο θέμα - κλιμάκωση του συμπλέγματος Kubernetes. Σημειώστε ότι η εντολή kubectl είναι μια εντολή κλιμάκωσης. Με περισσότερη βοήθεια, μπορούμε εύκολα να αυξήσουμε τον αριθμό των αντιγράφων στο υπάρχον σύμπλεγμα μας. Ωστόσο, στην πράξη, συνήθως θέλουμε να αυξήσουμε τον αριθμό των κόμβων αντί των λοβών.
Ταυτόχρονα, κατά τις εργάσιμες ώρες μπορεί να χρειαστεί να αυξήσετε και τη νύχτα, για να μειώσετε το κόστος των υπηρεσιών της Amazon, ίσως χρειαστεί να μειώσετε τον αριθμό των εμφανίσεων εφαρμογών που εκτελούνται. Αυτό δεν σημαίνει ότι η κλιμάκωση μόνο του αριθμού των λοβών θα είναι αρκετή, γιατί ακόμα κι αν ένας από τους κόμβους είναι αδρανής, θα πρέπει να πληρώσετε την Amazon για αυτό. Δηλαδή, μαζί με την κλιμάκωση των λοβών, θα χρειαστεί να κλιμακώσετε τον αριθμό των μηχανημάτων που χρησιμοποιούνται.
Αυτό μπορεί να είναι δύσκολο γιατί είτε χρησιμοποιούμε Amazon είτε άλλη υπηρεσία cloud, η Kubernetes δεν γνωρίζει τίποτα για τον αριθμό των μηχανημάτων που χρησιμοποιούνται. Δεν διαθέτει ένα εργαλείο που σας επιτρέπει να κλιμακώσετε το σύστημα σε επίπεδο κόμβου.
Έτσι θα πρέπει να φροντίσουμε και τους κόμβους και τους λοβούς. Μπορούμε εύκολα να κλιμακώσουμε την εκκίνηση νέων κόμβων χρησιμοποιώντας τα μηχανήματα της ομάδας AWS API και Scaling για να διαμορφώσουμε τον αριθμό των εργαζομένων κόμβων Kubernetes. Μπορείτε επίσης να χρησιμοποιήσετε το cloud-init ή ένα παρόμοιο σενάριο για να καταχωρήσετε κόμβους στο σύμπλεγμα Kubernetes.
Το νέο μηχάνημα ξεκινά στην ομάδα Scaling, ξεκινάει ως κόμβος, καταχωρείται στο μητρώο του master και αρχίζει να λειτουργεί. Μετά από αυτό, μπορείτε να αυξήσετε τον αριθμό των αντιγράφων για χρήση στους κόμβους που προκύπτουν. Η κλιμάκωση απαιτεί περισσότερη προσπάθεια, καθώς πρέπει να βεβαιωθείτε ότι ένα τέτοιο βήμα δεν οδηγεί στην καταστροφή εφαρμογών που ήδη εκτελούνται μετά την απενεργοποίηση των «περιττών» μηχανημάτων. Για να αποτρέψετε ένα τέτοιο σενάριο, πρέπει να ορίσετε τους κόμβους στην κατάσταση "μη προγραμματισμένος". Αυτό σημαίνει ότι ο προεπιλεγμένος προγραμματιστής θα αγνοήσει αυτούς τους κόμβους κατά τον προγραμματισμό ομάδων DaemonSet. Ο προγραμματιστής δεν θα διαγράψει τίποτα από αυτούς τους διακομιστές, αλλά επίσης δεν θα εκκινήσει νέα κοντέινερ εκεί. Το επόμενο βήμα είναι να απομακρυνθεί ο κόμβος αποστράγγισης, δηλαδή να μεταφερθούν οι λοβοί λειτουργίας από αυτόν σε άλλο μηχάνημα ή σε άλλους κόμβους που έχουν επαρκή χωρητικότητα για αυτό. Αφού βεβαιωθείτε ότι δεν υπάρχουν πλέον κοντέινερ σε αυτούς τους κόμβους, μπορείτε να τα αφαιρέσετε από το Kubernetes. Μετά από αυτό, απλά θα πάψουν να υπάρχουν για τον Kubernetes. Στη συνέχεια, πρέπει να χρησιμοποιήσετε το API AWS για να απενεργοποιήσετε περιττούς κόμβους ή μηχανήματα.
Μπορείτε να χρησιμοποιήσετε το Amdatu Scalerd, ένα άλλο εργαλείο κλιμάκωσης ανοιχτού κώδικα παρόμοιο με το API AWS. Παρέχει ένα CLI για την προσθήκη ή την αφαίρεση κόμβων σε ένα σύμπλεγμα. Το ενδιαφέρον χαρακτηριστικό του είναι η δυνατότητα διαμόρφωσης του προγραμματιστή χρησιμοποιώντας το ακόλουθο αρχείο json.
Ο κωδικός που εμφανίζεται μειώνει τη χωρητικότητα του συμπλέγματος κατά το ήμισυ κατά τη διάρκεια της νυχτερινής περιόδου. Ρυθμίζει τόσο τον αριθμό των διαθέσιμων αντιγράφων όσο και την επιθυμητή χωρητικότητα του συμπλέγματος Amazon. Η χρήση αυτού του χρονοπρογραμματιστή θα μειώσει αυτόματα τον αριθμό των κόμβων τη νύχτα και θα τους αυξήσει το πρωί, εξοικονομώντας το κόστος χρήσης κόμβων από μια υπηρεσία cloud όπως η Amazon. Αυτή η δυνατότητα δεν είναι ενσωματωμένη στο Kubernetes, αλλά η χρήση του Scalerd θα σας επιτρέψει να κλιμακώσετε αυτήν την πλατφόρμα όπως θέλετε.
Θα ήθελα να επισημάνω ότι πολλοί άνθρωποι μου λένε, "Καλά όλα αυτά, αλλά τι γίνεται με τη βάση δεδομένων μου, η οποία είναι συνήθως στατική;" Πώς μπορείτε να εκτελέσετε κάτι τέτοιο σε ένα δυναμικό περιβάλλον όπως το Kubernetes; Κατά τη γνώμη μου, δεν πρέπει να το κάνετε αυτό, δεν πρέπει να προσπαθήσετε να εκτελέσετε μια αποθήκη δεδομένων στο Kubernetes. Αυτό είναι τεχνικά εφικτό, και υπάρχουν σεμινάρια στο Διαδίκτυο για αυτό το θέμα, αλλά θα περιπλέξει σοβαρά τη ζωή σας.
Ναι, υπάρχει η έννοια των επίμονων καταστημάτων στο Kubernetes και μπορείτε να δοκιμάσετε να εκτελέσετε καταστήματα δεδομένων όπως το Mongo ή η MySQL, αλλά αυτό είναι μια εργασία που απαιτεί πολύ κόπο. Αυτό οφείλεται στο γεγονός ότι οι αποθήκες δεδομένων δεν υποστηρίζουν πλήρως την αλληλεπίδραση με ένα δυναμικό περιβάλλον. Οι περισσότερες βάσεις δεδομένων απαιτούν σημαντικές ρυθμίσεις παραμέτρων, συμπεριλαμβανομένης της μη αυτόματης διαμόρφωσης του συμπλέγματος, δεν τους αρέσει η αυτόματη κλιμάκωση και άλλα παρόμοια πράγματα.
Επομένως, δεν πρέπει να περιπλέκετε τη ζωή σας προσπαθώντας να εκτελέσετε μια αποθήκη δεδομένων στο Kubernetes. Οργανώστε την εργασία τους με τον παραδοσιακό τρόπο χρησιμοποιώντας γνωστές υπηρεσίες και απλώς παρέχετε στους Kubernetes τη δυνατότητα να τις χρησιμοποιούν.
Για να ολοκληρώσω το θέμα, θα ήθελα να σας παρουσιάσω την πλατφόρμα Cloud RTI που βασίζεται στο Kubernetes, πάνω στην οποία εργάζεται η ομάδα μου. Παρέχει κεντρική καταγραφή, παρακολούθηση εφαρμογών και συμπλέγματος, και πολλές άλλες χρήσιμες λειτουργίες που θα σας φανούν χρήσιμες. Χρησιμοποιεί διάφορα εργαλεία ανοιχτού κώδικα όπως το Grafana για την εμφάνιση της παρακολούθησης.
Υπήρχε μια ερώτηση σχετικά με το γιατί να χρησιμοποιήσετε τον εξισορροπητή φορτίου ha-proxy με το Kubernetes. Καλή ερώτηση γιατί αυτή τη στιγμή υπάρχουν 2 επίπεδα εξισορρόπησης φορτίου. Οι υπηρεσίες Kubernetes εξακολουθούν να βρίσκονται σε εικονικές διευθύνσεις IP. Δεν μπορείτε να τα χρησιμοποιήσετε για θύρες σε εξωτερικά μηχανήματα κεντρικού υπολογιστή, επειδή εάν η Amazon υπερφορτώσει τον κεντρικό υπολογιστή του cloud, η διεύθυνση θα αλλάξει. Αυτός είναι ο λόγος για τον οποίο τοποθετούμε το ha-proxy μπροστά από τις υπηρεσίες - για να δημιουργήσουμε μια πιο στατική δομή ώστε η κυκλοφορία να επικοινωνεί απρόσκοπτα με το Kubernetes.
Μια άλλη καλή ερώτηση είναι πώς μπορείτε να φροντίσετε τις αλλαγές σχήματος βάσης δεδομένων όταν κάνετε ανάπτυξη μπλε/πράσινου; Το γεγονός είναι ότι ανεξάρτητα από τη χρήση του Kubernetes, η αλλαγή του σχήματος της βάσης δεδομένων είναι μια δύσκολη εργασία. Πρέπει να διασφαλίσετε ότι το παλιό και το νέο σχήμα είναι συμβατά, μετά από αυτό μπορείτε να ενημερώσετε τη βάση δεδομένων και στη συνέχεια να ενημερώσετε τις ίδιες τις εφαρμογές. Μπορείτε να κάνετε εναλλαγή της βάσης δεδομένων και στη συνέχεια να ενημερώσετε τις εφαρμογές. Γνωρίζω ανθρώπους που έχουν εκκινήσει ένα εντελώς νέο σύμπλεγμα βάσεων δεδομένων με ένα νέο σχήμα, αυτή είναι μια επιλογή εάν έχετε μια βάση δεδομένων χωρίς σχήμα όπως το Mongo, αλλά δεν είναι ούτως ή άλλως εύκολη δουλειά. Εάν δεν έχετε περαιτέρω ερωτήσεις, σας ευχαριστώ για την προσοχή σας!
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com