Το Kubernetes είναι ένα εξαιρετικό εργαλείο για την εκτέλεση κοντέινερ Docker σε ένα περιβάλλον παραγωγής σε σύμπλεγμα. Ωστόσο, υπάρχουν ορισμένες εργασίες που το Kubernetes δεν μπορεί να χειριστεί. Όταν αναπτύσσουμε συχνά σε παραγωγή, χρειαζόμαστε μια πλήρως αυτοματοποιημένη ανάπτυξη σε μπλε/πράσινο χρώμα για να αποφύγουμε τον χρόνο διακοπής λειτουργίας της διαδικασίας, η οποία απαιτεί επίσης τη διαχείριση εξωτερικών αιτημάτων HTTP και την εκτέλεση εκφόρτωσης SSL. Αυτό απαιτεί ενσωμάτωση με έναν εξισορροπητή φορτίου όπως το ha-proxy. Μια άλλη εργασία είναι η ημιαυτόματη κλιμάκωση του ίδιου του συμπλέγματος Kubernetes όταν εκτελείται σε περιβάλλον cloud, όπως η μερική κλιμάκωση του συμπλέγματος τη νύχτα.
Ενώ το Kubernetes δεν διαθέτει αυτές τις δυνατότητες άμεσα, παρέχει ένα API που μπορεί να χρησιμοποιηθεί για την επίλυση αυτών των προβλημάτων. Εργαλεία για αυτοματοποιημένη ανάπτυξη και κλιμάκωση Blue/Green ενός cluster Kubernetes αναπτύχθηκαν στο πλαίσιο του έργου ανοιχτού κώδικα Cloud RTI.
Αυτό το άρθρο, ένα αντίγραφο ενός βίντεο, δείχνει πώς να ρυθμίσετε το Kubernetes μαζί με άλλα στοιχεία ανοιχτού κώδικα για να δημιουργήσετε ένα περιβάλλον έτοιμο για παραγωγή που καταναλώνει κώδικα από μια git commit χωρίς κανένα χρόνο διακοπής λειτουργίας στην παραγωγή.
Έτσι, μόλις αποκτήσετε πρόσβαση στις εφαρμογές σας από τον έξω κόσμο, μπορείτε να ξεκινήσετε να ρυθμίζετε πλήρως τον αυτοματισμό, δηλαδή να τον φέρετε στο στάδιο όπου μπορείτε να κάνετε μια git commit και να βεβαιωθείτε ότι αυτή η git commit θα καταλήξει στην παραγωγή. Φυσικά, κατά την εφαρμογή αυτών των βημάτων, κατά την εκτέλεση μιας ανάπτυξης, δεν θέλουμε να αντιμετωπίσουμε χρόνο διακοπής λειτουργίας. Έτσι, κάθε αυτοματοποίηση στο 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 δημιουργεί pod και υπηρεσίες για περαιτέρω ανάπτυξη, δηλαδή δημιουργεί ένα εντελώς νέο σύμπλεγμα για τις εφαρμογές μας. Μόλις ο RC βεβαιωθεί ότι τα αντίγραφα έχουν ξεκινήσει, θα εκτελέσει έναν έλεγχο εύρυθμης λειτουργίας τους. Για να το κάνει αυτό, ο Deployer χρησιμοποιεί την εντολή GET /health. Εκτελεί τα κατάλληλα στοιχεία ελέγχου και ελέγχει όλα τα στοιχεία που διασφαλίζουν ότι το σύμπλεγμα λειτουργεί.
Μόλις όλα τα pod αναφέρουν την εύρυθμη λειτουργία τους, το 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-proxy με άμεση υποστήριξη και να χρησιμοποιήσετε εύκολα το δικό σας αρχείο διαμόρφωσης εξισορρόπησης φορτίου. Το Amdatu Deployer είναι γραμμένο σε Go, όπως και το ίδιο το Kubernetes, και διαθέτει άδεια χρήσης Apache.
Πριν ξεκινήσω να χρησιμοποιώ αυτήν την έκδοση του προγραμματιστή, χρησιμοποίησα την ακόλουθη περιγραφή ανάπτυξης, η οποία καθορίζει τις παραμέτρους που χρειάζομαι.
Μία σημαντική παράμετρος σε αυτόν τον κώδικα είναι η ενεργοποίηση της σημαίας "useHealthCheck". Πρέπει να καθορίσουμε ότι θα πρέπει να εκτελείται έλεγχος εύρυθμης λειτουργίας κατά την ανάπτυξη. Αυτό μπορεί να απενεργοποιηθεί κατά την ανάπτυξη κοντέινερ τρίτων που δεν χρειάζεται να ελεγχθούν. Αυτός ο περιγραφέας καθορίζει επίσης τον αριθμό των αντιγράφων και τη διεύθυνση URL frontend που χρειάζεται το ha-proxy. Τέλος, καθορίζουμε τη σημαία podspec, η οποία επικοινωνεί με το Kubernetes για να λάβει πληροφορίες σχετικά με τη διαμόρφωση θύρας, την εικόνα κ.λπ. Αυτός είναι ένας αρκετά απλός περιγραφέας σε μορφή JSON.
Ένα άλλο εργαλείο που αποτελεί μέρος του έργου ανοιχτού κώδικα Amdatu είναι το Deploymentctl. Διαθέτει ένα περιβάλλον χρήστη για τη διαμόρφωση αναπτύξεων, αποθηκεύει το ιστορικό αναπτύξεων και περιέχει webhooks για επανακλήσεις από τρίτους χρήστες και προγραμματιστές. Δεν επιτρέπεται να χρησιμοποιήσετε το περιβάλλον χρήστη, καθώς το ίδιο το 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 frontend, όνομα κοντέινερ, εικόνα, όρια πόρων, αριθμό θύρας για έλεγχο εύρυθμης λειτουργίας κ.λπ. Τα όρια πόρων είναι πολύ σημαντικά, καθώς σας επιτρέπουν να χρησιμοποιήσετε τη μέγιστη δυνατή ποσότητα υλικού. Εδώ μπορείτε επίσης να δείτε το αρχείο καταγραφής ανάπτυξης.
Αν τώρα επαναλάβετε την εντολή ~ kubectl get pods, μπορείτε να δείτε ότι το σύστημα "παγώνει" για 20 δευτερόλεπτα, κατά τη διάρκεια των οποίων το ha-proxy αναδιαμορφώνεται. Μετά από αυτό, το pod ξεκινά και το αντίγραφο μας μπορεί να εμφανιστεί στο αρχείο καταγραφής ανάπτυξης.
Αφαίρεσα την αναμονή των 20 δευτερολέπτων από το βίντεο και τώρα μπορείτε να δείτε στην οθόνη ότι έχει αναπτυχθεί η πρώτη έκδοση της εφαρμογής. Όλα αυτά έγιναν χρησιμοποιώντας μόνο το περιβάλλον χρήστη.
Ας δοκιμάσουμε τώρα τη δεύτερη έκδοση. Για να το κάνω αυτό, αλλάζω το μήνυμα της εφαρμογής από "Γεια σου, Kubernetes!" σε "Γεια σου, Deployer!", το σύστημα δημιουργεί αυτήν την εικόνα και την τοποθετεί στο μητρώο του Docker, μετά από το οποίο απλώς κάνουμε ξανά κλικ στο κουμπί "Ανάπτυξη" στο παράθυρο Deploymentctl. Αυτό ξεκινά αυτόματα το αρχείο καταγραφής ανάπτυξης, όπως ακριβώς έκανε και κατά την ανάπτυξη της πρώτης έκδοσης της εφαρμογής.
Η εντολή ~ kubectl get pods δείχνει ότι αυτήν τη στιγμή εκτελούνται 2 εκδόσεις της εφαρμογής, αλλά το frontend δείχνει ότι εξακολουθούμε να εκτελούμε την έκδοση 1.
Ο εξισορροπητής φόρτου περιμένει να ολοκληρωθεί ο έλεγχος εύρυθμης λειτουργίας και, στη συνέχεια, ανακατευθύνει την κυκλοφορία στη νέα έκδοση. Μετά από 20 δευτερόλεπτα, μεταβαίνουμε στο curl και βλέπουμε ότι έχουμε πλέον αναπτύξει την έκδοση 2 της εφαρμογής και η πρώτη έχει αφαιρεθεί.
Αυτή ήταν μια ανάπτυξη μιας υγιούς εφαρμογής. Ας δούμε τι θα συμβεί αν αλλάξω την παράμετρο Healthy από true σε false για μια νέα έκδοση της εφαρμογής, δηλαδή αν προσπαθήσω να αναπτύξω μια μη υγιείς εφαρμογή που δεν πέρασε τον έλεγχο εύρυθμης λειτουργίας. Αυτό μπορεί να συμβεί εάν η εφαρμογή παρουσίασε κάποια σφάλματα διαμόρφωσης κατά την ανάπτυξη και στάλθηκε στην παραγωγή με αυτήν τη μορφή.
Όπως μπορείτε να δείτε, η ανάπτυξη ακολουθεί όλα τα παραπάνω βήματα και η εντολή ~ kubectl get pods δείχνει ότι και τα δύο pod εκτελούνται. Αλλά σε αντίθεση με την προηγούμενη ανάπτυξη, το αρχείο καταγραφής εμφανίζει μια κατάσταση χρονικού ορίου. Δηλαδή, επειδή ο έλεγχος εύρυθμης λειτουργίας απέτυχε, η νέα έκδοση της εφαρμογής δεν μπορεί να αναπτυχθεί. Ως αποτέλεσμα, βλέπετε ότι το σύστημα έχει επιστρέψει στη χρήση της παλιάς έκδοσης της εφαρμογής και η νέα έκδοση έχει απλώς καταργηθεί.
Το καλό με αυτό είναι ότι ακόμα κι αν έχετε έναν τεράστιο αριθμό ταυτόχρονων αιτημάτων που εισέρχονται στην εφαρμογή, αυτά δεν θα παρατηρήσουν καν τον χρόνο διακοπής λειτουργίας κατά τη διάρκεια της διαδικασίας ανάπτυξης. Εάν δοκιμάσετε αυτήν την εφαρμογή με το πλαίσιο Gatling, το οποίο της στέλνει όσο το δυνατόν περισσότερα αιτήματα, κανένα από αυτά τα αιτήματα δεν θα απορριφθεί. Αυτό σημαίνει ότι οι χρήστες μας δεν θα παρατηρήσουν καν την αναβάθμιση της έκδοσης σε πραγματικό χρόνο. Εάν αποτύχει, θα συνεχίσουν να εργάζονται στην παλιά έκδοση, εάν είναι επιτυχής, θα αναβαθμίσουν στη νέα έκδοση.
Υπάρχει μόνο ένα πράγμα που μπορεί να αποτύχει - αν ο έλεγχος εύρυθμης λειτουργίας είναι επιτυχής, αλλά η εφαρμογή καταρρέει μόλις εφαρμοστεί το φόρτο εργασίας σε αυτήν, δηλαδή η κατάρρευση θα συμβεί μόνο μετά την ολοκλήρωση της ανάπτυξης. Σε αυτήν την περίπτωση, θα πρέπει να επιστρέψετε χειροκίνητα στην παλιά έκδοση. Έτσι, εξετάσαμε πώς να χρησιμοποιήσετε το Kubernetes με εργαλεία ανοιχτού κώδικα που έχουν σχεδιαστεί για αυτό. Η διαδικασία ανάπτυξης θα είναι πολύ πιο απλή αν ενσωματώσετε αυτά τα εργαλεία στους αγωγούς Build/Deploy. Ταυτόχρονα, μπορείτε να χρησιμοποιήσετε τόσο το UI για να ξεκινήσετε την ανάπτυξη όσο και να αυτοματοποιήσετε πλήρως αυτήν τη διαδικασία, χρησιμοποιώντας, για παράδειγμα, το commit to master.
Ο Build Server μας θα δημιουργήσει μια εικόνα Docker, θα την προωθήσει στο Docker Hub ή σε οποιοδήποτε άλλο μητρώο χρησιμοποιείτε. Το Docker Hub υποστηρίζει webhooks, επομένως μπορούμε να ενεργοποιήσουμε μια απομακρυσμένη ανάπτυξη μέσω του Deployer όπως φαίνεται παραπάνω. Με αυτόν τον τρόπο, μπορείτε να αυτοματοποιήσετε πλήρως την ανάπτυξη της εφαρμογής σας σε πιθανή παραγωγή.
Ας προχωρήσουμε στο επόμενο θέμα - την κλιμάκωση ενός συμπλέγματος Kubernetes. Σημειώστε ότι η εντολή kubectl είναι μια εντολή κλιμάκωσης. Μπορεί επίσης να χρησιμοποιηθεί για να αυξήσει εύκολα τον αριθμό των αντιγράφων στο υπάρχον σύμπλεγμά μας. Ωστόσο, στην πράξη, συνήθως θέλουμε να αυξήσουμε τον αριθμό των κόμβων, όχι των ομάδων (pods).
Ταυτόχρονα, κατά τις εργάσιμες ώρες, ίσως χρειαστεί να αυξήσετε, και τη νύχτα, για να μειώσετε το κόστος των υπηρεσιών της Amazon, να μειώσετε τον αριθμό των εκτελούμενων παρουσιών εφαρμογών. Αυτό δεν σημαίνει ότι θα αρκεί να κλιμακώσετε μόνο τον αριθμό των pods, επειδή ακόμη και αν ένας από τους κόμβους δεν είναι απασχολημένος με τίποτα, θα πρέπει να πληρώσετε την Amazon για αυτό. Δηλαδή, μαζί με την κλιμάκωση των pods, θα χρειαστεί επίσης να κλιμακώσετε τον αριθμό των μηχανημάτων που χρησιμοποιούνται.
Αυτό μπορεί να είναι δύσκολο, επειδή είτε χρησιμοποιούμε το Amazon είτε κάποια άλλη υπηρεσία cloud, το Kubernetes δεν γνωρίζει τίποτα για τον αριθμό των μηχανημάτων που χρησιμοποιούνται. Δεν διαθέτει εργαλείο για την κλιμάκωση του συστήματος σε επίπεδο κόμβου.
Επομένως, πρέπει να φροντίσουμε τόσο τους κόμβους όσο και τα pods. Μπορούμε εύκολα να κλιμακώσουμε την εκκίνηση νέων κόμβων χρησιμοποιώντας το AWS API και τις μηχανές ομάδας κλιμάκωσης για να διαμορφώσουμε τον αριθμό των κόμβων εργασίας Kubernetes. Μπορούμε επίσης να χρησιμοποιήσουμε το cloud-init ή ένα παρόμοιο σενάριο για να καταχωρήσουμε κόμβους στο σύμπλεγμα Kubernetes.
Το νέο μηχάνημα ξεκινά στην ομάδα Κλιμάκωση, ξεκινά ως κόμβος, εγγράφεται στο κύριο μητρώο και αρχίζει να λειτουργεί. Μετά από αυτό, μπορείτε να αυξήσετε τον αριθμό των αντιγράφων για χρήση στους κόμβους που προκύπτουν. Η μείωση της κλίμακας απαιτεί περισσότερη προσπάθεια, καθώς πρέπει να βεβαιωθείτε ότι ένα τέτοιο βήμα δεν θα οδηγήσει στην καταστροφή εφαρμογών που εκτελούνται ήδη μετά την απενεργοποίηση των "περιττών" μηχανημάτων. Για να αποτρέψετε αυτό το σενάριο, πρέπει να ορίσετε τους κόμβους στην κατάσταση "μη προγραμματισμένου". Αυτό σημαίνει ότι ο χρονοπρογραμματιστής θα αγνοήσει αυτούς τους κόμβους από προεπιλογή κατά τον προγραμματισμό των pod DaemonSet. Ο χρονοπρογραμματιστής δεν θα αφαιρέσει τίποτα από αυτούς τους διακομιστές, αλλά δεν θα εκκινήσει νέα κοντέινερ εκεί. Το επόμενο βήμα είναι να εκδιώξετε τον κόμβο αποστράγγισης, δηλαδή να μετακινήσετε τα pod που εκτελούνται από αυτόν σε άλλο μηχάνημα ή σε άλλους κόμβους που έχουν επαρκή χωρητικότητα για αυτό. Αφού βεβαιωθείτε ότι δεν υπάρχουν άλλα κοντέινερ σε αυτούς τους κόμβους, μπορείτε να τα διαγράψετε από το Kubernetes. Μετά από αυτό, απλώς θα πάψουν να υπάρχουν για το Kubernetes. Στη συνέχεια, πρέπει να χρησιμοποιήσετε το API AWS για να απενεργοποιήσετε τους περιττούς κόμβους ή μηχανήματα.
Μπορείτε να χρησιμοποιήσετε το Amdatu Scalerd, ένα άλλο εργαλείο κλιμάκωσης ανοιχτού κώδικα παρόμοιο με το AWS API. Παρέχει ένα CLI για την προσθήκη ή την αφαίρεση κόμβων σε ένα σύμπλεγμα. Το ενδιαφέρον χαρακτηριστικό του είναι η δυνατότητα διαμόρφωσης του χρονοπρογραμματιστή χρησιμοποιώντας το ακόλουθο αρχείο json.
Ο κώδικας που εμφανίζεται μειώνει τη χωρητικότητα του συμπλέγματος κατά το ήμισυ κατά τη διάρκεια της νύχτας. Έχει ρυθμιστεί τόσο με τον αριθμό των υπαρχόντων αντιγράφων όσο και με την επιθυμητή χωρητικότητα του συμπλέγματος Amazon. Η χρήση αυτού του χρονοπρογραμματιστή θα μειώσει αυτόματα τον αριθμό των κόμβων τη νύχτα και θα τους αυξήσει το πρωί, εξοικονομώντας το κόστος χρήσης κόμβων σε μια υπηρεσία cloud όπως το Amazon. Αυτή η λειτουργία δεν είναι ενσωματωμένη στο Kubernetes, αλλά η χρήση του Scalerd θα σας επιτρέψει να κλιμακώσετε την πλατφόρμα όσο θέλετε.
Θέλω να επισημάνω ότι πολλοί άνθρωποι μου λένε: «Ωραία όλα αυτά, αλλά τι γίνεται με τη βάση δεδομένων μου, η οποία είναι συνήθως στατική;» Πώς εκτελείτε κάτι τέτοιο σε ένα δυναμικό περιβάλλον όπως το Kubernetes; Κατά τη γνώμη μου, δεν πρέπει να το κάνετε αυτό, δεν πρέπει να προσπαθήσετε να εκτελέσετε μια αποθήκη δεδομένων στο Kubernetes. Είναι τεχνικά εφικτό και υπάρχουν σχετικά tutorials στο διαδίκτυο, αλλά θα σας κάνει τη ζωή πολύ δύσκολη.
Ναι, το 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
