Το Docker Swarm, το Kubernetes και το Mesos είναι τα πιο δημοφιλή πλαίσια ενορχήστρωσης κοντέινερ. Στην ομιλία του, ο Arun Gupta συγκρίνει τις ακόλουθες πτυχές των Docker, Swarm και Kubernetes:
- Τοπική ανάπτυξη.
- Λειτουργίες ανάπτυξης.
- Εφαρμογές πολλαπλών δοχείων.
- Ανακάλυψη υπηρεσίας.
- Κλιμάκωση της υπηρεσίας.
- Εργασίες που εκτελούνται μία φορά.
- Ενσωμάτωση με τον Maven.
- Ενημέρωση "Rolling".
- Δημιουργία συμπλέγματος βάσεων δεδομένων Couchbase.
Ως αποτέλεσμα, θα αποκτήσετε μια σαφή κατανόηση του τι έχει να προσφέρει κάθε εργαλείο ενορχήστρωσης και θα μάθετε πώς να χρησιμοποιείτε αυτές τις πλατφόρμες αποτελεσματικά.
Ο Arun Gupta είναι ο επικεφαλής τεχνολόγος για προϊόντα ανοιχτού κώδικα στην Amazon Web Services, ο οποίος αναπτύσσει τις κοινότητες προγραμματιστών Sun, Oracle, Red Hat και Couchbase για περισσότερα από 10 χρόνια. Διαθέτει εκτενή εμπειρία εργασίας σε κορυφαίες διαλειτουργικές ομάδες που αναπτύσσουν και εφαρμόζουν στρατηγική για εκστρατείες και προγράμματα μάρκετινγκ. Οδήγησε ομάδες μηχανικών της Sun, είναι ένας από τους ιδρυτές της ομάδας Java EE και δημιουργός του αμερικανικού παραρτήματος της Devoxx4Kids. Ο Arun Gupta είναι ο συγγραφέας περισσότερων από 2 χιλιάδων αναρτήσεων σε ιστολόγια πληροφορικής και έχει δώσει ομιλίες σε περισσότερες από 40 χώρες.
Η γραμμή 55 περιέχει ένα COUCHBASE_URI που δείχνει σε αυτήν την υπηρεσία βάσης δεδομένων, η οποία δημιουργήθηκε επίσης χρησιμοποιώντας το αρχείο διαμόρφωσης Kubernetes. Αν κοιτάξετε τη γραμμή 2, μπορείτε να δείτε το είδος: Η υπηρεσία είναι η υπηρεσία που δημιουργώ με την ονομασία couchbase-service και το ίδιο όνομα παρατίθεται στη γραμμή 4. Ακολουθούν ορισμένες θύρες.
Οι γραμμές κλειδιά είναι 6 και 7. Κατά την υπηρεσία λέω, "Γεια, αυτές είναι οι ετικέτες που ψάχνω!" και αυτές οι ετικέτες δεν είναι τίποτα άλλο από ονόματα ζευγών μεταβλητών και η γραμμή 7 δείχνει στο couchbase-rs-pod μου εφαρμογή. Ακολουθούν οι θύρες που παρέχουν πρόσβαση σε αυτές τις ίδιες ετικέτες.
Στη γραμμή 19 δημιουργώ ένα νέο τύπο ReplicaSet, η γραμμή 31 περιέχει το όνομα της εικόνας και οι γραμμές 24-27 δείχνουν τα μεταδεδομένα που σχετίζονται με την ομάδα μου. Αυτό ακριβώς αναζητά η υπηρεσία και σε τι πρέπει να γίνει η σύνδεση. Στο τέλος του αρχείου υπάρχει κάποιο είδος σύνδεσης μεταξύ των γραμμών 55-56 και 4, λέγοντας: "χρησιμοποιήστε αυτήν την υπηρεσία!"
Ξεκινάω λοιπόν την υπηρεσία μου όταν υπάρχει σετ ρεπλίκα και αφού κάθε σετ ρεπλίκα έχει τη δική του θύρα με την αντίστοιχη ετικέτα, περιλαμβάνεται στην υπηρεσία. Από την πλευρά ενός προγραμματιστή, καλείτε απλώς την υπηρεσία, η οποία στη συνέχεια χρησιμοποιεί το σύνολο των αντιγράφων που χρειάζεστε.
Ως αποτέλεσμα, έχω μια ομάδα WildFly που επικοινωνεί με το backend της βάσης δεδομένων μέσω της υπηρεσίας Couchbase. Μπορώ να χρησιμοποιήσω το frontend με πολλά pods WildFly, το οποίο επίσης επικοινωνεί με το backend του couchbase μέσω της υπηρεσίας couchbase.
Αργότερα θα δούμε πώς μια υπηρεσία που βρίσκεται εκτός του συμπλέγματος επικοινωνεί μέσω της διεύθυνσης IP της με στοιχεία που βρίσκονται μέσα στο σύμπλεγμα και έχουν μια εσωτερική διεύθυνση IP.
Έτσι, τα κοντέινερ χωρίς ιθαγένεια είναι υπέροχα, αλλά πόσο καλό είναι να χρησιμοποιείτε κοντέινερ με κατάσταση κατάστασης; Ας δούμε τις ρυθμίσεις συστήματος για κρατικά ή μόνιμα κοντέινερ. Στο Docker, υπάρχουν 4 διαφορετικές προσεγγίσεις για τη διάταξη αποθήκευσης δεδομένων που πρέπει να δώσετε προσοχή. Το πρώτο είναι το Implicit Per-Container, που σημαίνει ότι όταν χρησιμοποιούνται κοντέινερ με couchbase, MySQL ή MyDB, ξεκινούν όλα με το προεπιλεγμένο Sandbox. Δηλαδή, ό,τι είναι αποθηκευμένο στη βάση δεδομένων αποθηκεύεται στο ίδιο το κοντέινερ. Εάν το κοντέινερ εξαφανιστεί, τα δεδομένα εξαφανίζονται μαζί του.
Το δεύτερο είναι το Explicit Per-Container, όταν δημιουργείτε έναν συγκεκριμένο χώρο αποθήκευσης με την εντολή δημιουργίας τόμου docker και αποθηκεύετε δεδομένα σε αυτό. Η τρίτη προσέγγιση ανά κεντρικό υπολογιστή σχετίζεται με τη χαρτογράφηση αποθήκευσης, όταν όλα όσα είναι αποθηκευμένα στο κοντέινερ αντιγράφονται ταυτόχρονα στον κεντρικό υπολογιστή. Εάν το κοντέινερ αποτύχει, τα δεδομένα θα παραμείνουν στον κεντρικό υπολογιστή. Το τελευταίο είναι η χρήση πολλών κεντρικών υπολογιστών Multi-Host, κάτι που ενδείκνυται στο στάδιο παραγωγής διαφόρων λύσεων. Ας υποθέσουμε ότι τα κοντέινερ με τις εφαρμογές σας εκτελούνται στον κεντρικό υπολογιστή, αλλά θέλετε να αποθηκεύσετε τα δεδομένα σας κάπου στο Διαδίκτυο και για αυτό χρησιμοποιείτε αυτόματη αντιστοίχιση για κατανεμημένα συστήματα.
Κάθε μία από αυτές τις μεθόδους χρησιμοποιεί μια συγκεκριμένη θέση αποθήκευσης. Το Implicit and Explicit Per-Container αποθηκεύει δεδομένα στον κεντρικό υπολογιστή στο /var/lib/docker/volumes. Όταν χρησιμοποιείτε τη μέθοδο ανά κεντρικό υπολογιστή, η αποθήκευση τοποθετείται μέσα στο κοντέινερ και το ίδιο το κοντέινερ τοποθετείται στον κεντρικό υπολογιστή. Για πολλούς κεντρικούς υπολογιστές, μπορούν να χρησιμοποιηθούν λύσεις όπως Ceph, ClusterFS, NFS κ.λπ.
Εάν ένα μόνιμο κοντέινερ αποτύχει, ο κατάλογος αποθήκευσης καθίσταται απρόσιτος στις δύο πρώτες περιπτώσεις, αλλά στις δύο τελευταίες περιπτώσεις η πρόσβαση διατηρείται. Ωστόσο, στην πρώτη περίπτωση, μπορείτε να έχετε πρόσβαση στο αποθετήριο μέσω ενός κεντρικού υπολογιστή Docker που εκτελείται σε μια εικονική μηχανή. Στη δεύτερη περίπτωση, δεν θα χαθούν ούτε τα δεδομένα, γιατί έχετε δημιουργήσει μια Explicit αποθήκευση.
Εάν ο κεντρικός υπολογιστής αποτύχει, ο κατάλογος αποθήκευσης δεν είναι διαθέσιμος στις τρεις πρώτες περιπτώσεις, στην τελευταία περίπτωση, η σύνδεση με τον χώρο αποθήκευσης δεν διακόπτεται. Τέλος, η κοινόχρηστη λειτουργία αποκλείεται εντελώς για αποθήκευση στην πρώτη περίπτωση και είναι δυνατή στις υπόλοιπες. Στη δεύτερη περίπτωση, μπορείτε να μοιραστείτε χώρο αποθήκευσης ανάλογα με το αν η βάση δεδομένων σας υποστηρίζει κατανεμημένη αποθήκευση ή όχι. Στην περίπτωση του Per-Host, η διανομή δεδομένων είναι δυνατή μόνο σε έναν δεδομένο κεντρικό υπολογιστή και για έναν multihost παρέχεται από την επέκταση συμπλέγματος.
Αυτό θα πρέπει να λαμβάνεται υπόψη κατά τη δημιουργία κρατικών κοντέινερ. Ένα άλλο χρήσιμο εργαλείο Docker είναι το πρόσθετο Volume, το οποίο λειτουργεί βάσει της αρχής «οι μπαταρίες υπάρχουν, αλλά πρέπει να αντικατασταθούν». Όταν ξεκινάτε ένα κοντέινερ Docker, λέει, "Γεια, μόλις ξεκινήσετε ένα κοντέινερ με βάση δεδομένων, μπορείτε να αποθηκεύσετε τα δεδομένα σας σε αυτό το κοντέινερ!" Αυτή είναι η προεπιλεγμένη δυνατότητα, αλλά μπορείτε να την αλλάξετε. Αυτή η προσθήκη σάς επιτρέπει να χρησιμοποιείτε μια μονάδα δίσκου δικτύου ή κάτι παρόμοιο αντί για μια βάση δεδομένων κοντέινερ. Περιλαμβάνει ένα προεπιλεγμένο πρόγραμμα οδήγησης για αποθήκευση που βασίζεται σε κεντρικό υπολογιστή και επιτρέπει την ενοποίηση κοντέινερ με εξωτερικά συστήματα αποθήκευσης όπως οι δίσκοι Amazon EBS, Azure Storage και GCE Persistent.
Η επόμενη διαφάνεια δείχνει την αρχιτεκτονική της προσθήκης Docker Volume.
Το μπλε χρώμα αντιπροσωπεύει το πρόγραμμα-πελάτη Docker που σχετίζεται με τον μπλε κεντρικό υπολογιστή Docker, ο οποίος έχει μια μηχανή τοπικής αποθήκευσης που σας παρέχει κοντέινερ για την αποθήκευση δεδομένων. Το πράσινο υποδεικνύει το Plugin Client και το Plugin Daemon, τα οποία είναι επίσης συνδεδεμένα με τον κεντρικό υπολογιστή. Παρέχουν τη δυνατότητα αποθήκευσης δεδομένων σε αποθήκευση δικτύου του τύπου Storage Backend που χρειάζεστε.
Η προσθήκη Docker Volume μπορεί να χρησιμοποιηθεί με αποθήκευση Portworx. Η μονάδα PX-Dev είναι στην πραγματικότητα ένα κοντέινερ που εκτελείτε και συνδέεται με τον κεντρικό υπολογιστή Docker και σας επιτρέπει να αποθηκεύετε εύκολα δεδομένα στο Amazon EBS.
Ο υπολογιστής-πελάτης Portworx σάς επιτρέπει να παρακολουθείτε την κατάσταση διαφόρων κοντέινερ αποθήκευσης που είναι συνδεδεμένα με τον κεντρικό υπολογιστή σας. Εάν επισκεφτείτε το ιστολόγιό μου, μπορείτε να διαβάσετε πώς να αξιοποιήσετε στο έπακρο το Portworx με το Docker.
Η έννοια της αποθήκευσης στο Kubernetes είναι παρόμοια με το Docker και αντιπροσωπεύεται από καταλόγους που είναι προσβάσιμοι στο κοντέινερ σας σε ένα pod. Είναι ανεξάρτητα από τη διάρκεια ζωής οποιουδήποτε δοχείου. Οι πιο συνηθισμένοι διαθέσιμοι τύποι αποθήκευσης είναι οι hostPath, nfs, awsElasticBlockStore και gsePersistentDisk. Ας ρίξουμε μια ματιά στο πώς λειτουργούν αυτά τα καταστήματα στο Kubernetes. Συνήθως, η διαδικασία σύνδεσής τους αποτελείται από 3 βήματα.
Το πρώτο είναι ότι κάποιος από την πλευρά του δικτύου, συνήθως ένας διαχειριστής, σας παρέχει μόνιμο χώρο αποθήκευσης. Υπάρχει ένα αντίστοιχο αρχείο διαμόρφωσης PersistentVolume για αυτό. Στη συνέχεια, ο προγραμματιστής της εφαρμογής γράφει ένα αρχείο διαμόρφωσης που ονομάζεται PersistentVolumeClaim, ή ένα αίτημα αποθήκευσης PVC, το οποίο λέει: «Έχω 50 GB κατανεμημένου χώρου αποθήκευσης, αλλά για να χρησιμοποιήσουν και άλλα άτομα τη χωρητικότητά του, λέω σε αυτό το PVC ότι αυτήν τη στιγμή χρειάζονται μόνο 10 GB». Τέλος, το τρίτο βήμα είναι ότι το αίτημά σας προσαρτάται ως αποθηκευτικός χώρος και η εφαρμογή που έχει το pod, ή σετ ρεπλίκα, ή κάτι παρόμοιο, αρχίζει να το χρησιμοποιεί. Είναι σημαντικό να θυμάστε ότι αυτή η διαδικασία αποτελείται από τα 3 βήματα που αναφέρονται και είναι επεκτάσιμη.
Η επόμενη διαφάνεια δείχνει το Kubernetes Persistence Container της αρχιτεκτονικής AWS.
Μέσα στο καφέ ορθογώνιο που αντιπροσωπεύει το σύμπλεγμα Kubernetes, υπάρχει ένας κύριος κόμβος και δύο κόμβοι εργαζόμενοι, που υποδεικνύονται με κίτρινο χρώμα. Ένας από τους κόμβους εργαζομένων περιέχει ένα πορτοκαλί λοβό, χώρο αποθήκευσης, έναν ελεγκτή ρεπλίκα και ένα πράσινο δοχείο Docker Couchbase. Μέσα στο σύμπλεγμα, πάνω από τους κόμβους, ένα μωβ ορθογώνιο υποδεικνύει την Υπηρεσία προσβάσιμη από το εξωτερικό. Αυτή η αρχιτεκτονική συνιστάται για την αποθήκευση δεδομένων στην ίδια τη συσκευή. Εάν είναι απαραίτητο, μπορώ να αποθηκεύσω τα δεδομένα μου σε EBS εκτός του συμπλέγματος, όπως φαίνεται στην επόμενη διαφάνεια. Αυτό είναι ένα τυπικό μοντέλο για την κλιμάκωση, αλλά υπάρχει μια οικονομική πτυχή που πρέπει να λάβετε υπόψη κατά τη χρήση του - η αποθήκευση δεδομένων σε κάποιο σημείο του δικτύου μπορεί να είναι πιο ακριβή από ό,τι σε έναν κεντρικό υπολογιστή. Όταν επιλέγετε λύσεις μεταφοράς εμπορευματοκιβωτίων, αυτό είναι ένα από τα σημαντικά επιχειρήματα.
Όπως και με το Docker, μπορείτε να χρησιμοποιήσετε μόνιμα κοντέινερ Kubernetes με το Portworx.
Αυτό είναι που στην τρέχουσα ορολογία του Kubernetes 1.6 ονομάζεται "StatefulSet" - ένας τρόπος εργασίας με εφαρμογές Stateful που επεξεργάζονται συμβάντα σχετικά με τη διακοπή του Pod και την εκτέλεση Graceful Shutdown. Στην περίπτωσή μας, τέτοιες εφαρμογές είναι βάσεις δεδομένων. Στο ιστολόγιό μου μπορείτε να διαβάσετε πώς να δημιουργήσετε ένα StatefulSet στο Kubernetes χρησιμοποιώντας το Portworx.
Ας μιλήσουμε για την πτυχή της ανάπτυξης. Όπως είπα, το Docker έχει 2 εκδόσεις - CE και EE, στην πρώτη περίπτωση μιλάμε για μια σταθερή έκδοση της Community Edition, η οποία ενημερώνεται μία φορά κάθε 3 μήνες, σε αντίθεση με τη μηνιαία ενημερωμένη έκδοση της EE. Μπορείτε να κάνετε λήψη του Docker για Mac, Linux ή Windows. Μόλις εγκατασταθεί, το Docker θα ενημερώνεται αυτόματα και είναι πολύ εύκολο να ξεκινήσετε.
Για το Kubernetes, προτιμώ την έκδοση Minikube - είναι ένας καλός τρόπος για να ξεκινήσετε με την πλατφόρμα δημιουργώντας ένα σύμπλεγμα σε έναν μόνο κόμβο. Για να δημιουργήσετε συμπλέγματα πολλών κόμβων, η επιλογή των εκδόσεων είναι ευρύτερη: αυτές είναι kops, kube-aws (CoreOS+AWS), kube-up (παλαιωμένο). Αν θέλετε να χρησιμοποιήσετε το Kubernetes που βασίζεται σε AWS, σας προτείνω να εγγραφείτε στο AWS SIG, το οποίο συνεδριάζει στο διαδίκτυο κάθε Παρασκευή και δημοσιεύει μια ποικιλία από ενδιαφέροντα υλικά σχετικά με την εργασία με το AWS Kubernetes.
Ας δούμε πώς εκτελείται η Κυλιόμενη ενημέρωση σε αυτές τις πλατφόρμες. Εάν υπάρχει ένα σύμπλεγμα πολλών κόμβων, τότε χρησιμοποιεί μια συγκεκριμένη έκδοση της εικόνας, για παράδειγμα, WildFly:1. Μια κυλιόμενη ενημέρωση σημαίνει ότι η έκδοση εικόνας αντικαθίσταται διαδοχικά με μια νέα σε κάθε κόμβο, η μία μετά την άλλη.
Για να το κάνω αυτό, χρησιμοποιώ την εντολή ενημέρωσης υπηρεσίας docker (όνομα υπηρεσίας), στην οποία καθορίζω τη νέα έκδοση της εικόνας WildFly:2 και τη μέθοδο ενημέρωσης update-parallelism 2. Ο αριθμός 2 σημαίνει ότι το σύστημα θα ενημερώσει 2 εικόνες εφαρμογής ταυτόχρονα, στη συνέχεια, μια καθυστέρηση ενημέρωσης 10 δευτερολέπτων 10s, μετά την οποία οι επόμενες 2 εικόνες θα ενημερωθούν σε 2 ακόμη κόμβους κ.λπ. Αυτός ο απλός μηχανισμός κυλιόμενης ενημέρωσης παρέχεται σε εσάς ως μέρος του Docker.
Στο Kubernetes, μια κυλιόμενη ενημέρωση λειτουργεί έτσι. Ο ελεγκτής αναπαραγωγής rc δημιουργεί ένα σύνολο από αντίγραφα της ίδιας έκδοσης και κάθε ομάδα σε αυτό το webapp-rc παρέχεται με μια ετικέτα που βρίσκεται στο etcd. Όταν χρειάζομαι ένα pod, χρησιμοποιώ την Υπηρεσία Εφαρμογών για πρόσβαση στο αποθετήριο etcd, το οποίο μου παρέχει το pod χρησιμοποιώντας την καθορισμένη ετικέτα.
Σε αυτήν την περίπτωση, έχουμε 3 ομάδες στον ελεγκτή Replication που εκτελούν την εφαρμογή WildFly έκδοση 1. Κατά την ενημέρωση στο παρασκήνιο, δημιουργείται ένας άλλος ελεγκτής αναπαραγωγής με το ίδιο όνομα και ευρετήριο στο τέλος - - xxxxx, όπου x είναι τυχαίοι αριθμοί και με τις ίδιες ετικέτες. Τώρα το Application Service έχει τρία pods με την παλιά έκδοση της εφαρμογής και τρία pods με τη νέα έκδοση στον νέο ελεγκτή Replication. Μετά από αυτό, τα παλιά pods διαγράφονται, ο ελεγκτής αναπαραγωγής με τα νέα pod μετονομάζεται και τίθεται σε λειτουργία.
Ας περάσουμε στην παρακολούθηση. Το Docker έχει πολλές ενσωματωμένες εντολές παρακολούθησης. Για παράδειγμα, η διεπαφή γραμμής εντολών στατιστικών κοντέινερ docker σάς επιτρέπει να εμφανίζετε πληροφορίες σχετικά με την κατάσταση των κοντέινερ στην κονσόλα κάθε δευτερόλεπτο - χρήση επεξεργαστή, χρήση δίσκου, φόρτωση δικτύου. Το εργαλείο Docker Remote API παρέχει δεδομένα σχετικά με τον τρόπο επικοινωνίας του πελάτη με τον διακομιστή. Χρησιμοποιεί απλές εντολές, αλλά βασίζεται στο Docker REST API. Σε αυτήν την περίπτωση, οι λέξεις REST, Flash, Remote σημαίνουν το ίδιο πράγμα. Όταν επικοινωνείτε με τον κεντρικό υπολογιστή, είναι ένα REST API. Το Docker Remote API σάς επιτρέπει να λαμβάνετε περισσότερες πληροφορίες σχετικά με τη λειτουργία κοντέινερ. Το ιστολόγιό μου περιγράφει τις λεπτομέρειες χρήσης αυτής της παρακολούθησης με τον Windows Server.
Η παρακολούθηση συμβάντων συστήματος βάσης σύνδεσης κατά την εκτέλεση ενός συμπλέγματος πολλών κεντρικών υπολογιστών καθιστά δυνατή τη λήψη δεδομένων σχετικά με ένα σφάλμα κεντρικού υπολογιστή ή ένα σφάλμα κοντέινερ σε έναν συγκεκριμένο κεντρικό υπολογιστή, υπηρεσίες κλιμάκωσης και παρόμοια. Ξεκινώντας με το Docker 1.20, περιλαμβάνει το Prometheus, το οποίο ενσωματώνει τελικά σημεία σε υπάρχουσες εφαρμογές. Αυτό σας επιτρέπει να λαμβάνετε μετρήσεις μέσω HTTP και να τις εμφανίζετε σε πίνακες εργαλείων.
Ένα άλλο χαρακτηριστικό παρακολούθησης είναι το cAdvisor (συντομογραφία για σύμβουλος κοντέινερ). Αναλύει και παρέχει δεδομένα χρήσης πόρων και απόδοσης από κοντέινερ που τρέχουν, παρέχοντας μετρήσεις Prometheus αμέσως. Το ιδιαίτερο με αυτό το εργαλείο είναι ότι παρέχει δεδομένα μόνο για τα τελευταία 60 δευτερόλεπτα. Επομένως, πρέπει να είστε σε θέση να συλλέγετε αυτά τα δεδομένα και να τα τοποθετείτε σε μια βάση δεδομένων, ώστε να μπορείτε να παρακολουθείτε μια μακροπρόθεσμη διαδικασία. Μπορεί επίσης να χρησιμοποιηθεί για την εμφάνιση μετρήσεων του πίνακα εργαλείων γραφικά χρησιμοποιώντας Grafana ή Kibana. Το ιστολόγιό μου έχει μια λεπτομερή περιγραφή του τρόπου χρήσης του cAdvisor για την παρακολούθηση κοντέινερ χρησιμοποιώντας τον πίνακα εργαλείων Kibana.
Η επόμενη διαφάνεια δείχνει πώς φαίνεται το τελικό σημείο εξόδου του Prometheus και τις μετρήσεις που είναι διαθέσιμες για εμφάνιση.
Κάτω αριστερά βλέπετε μετρήσεις για αιτήματα HTTP, απαντήσεις κ.λπ., δεξιά η γραφική τους εμφάνιση.
Το Kubernetes περιλαμβάνει επίσης ενσωματωμένα εργαλεία παρακολούθησης. Αυτή η διαφάνεια δείχνει ένα τυπικό σύμπλεγμα που περιέχει έναν κύριο και τρεις κόμβους εργασίας.
Κάθε ένας από τους κόμβους εργασίας περιέχει έναν cAdvisor που εκκινείται αυτόματα. Επιπλέον, υπάρχει το Heapster, ένα σύστημα παρακολούθησης απόδοσης και συλλογής μετρήσεων συμβατό με την έκδοση Kubernetes 1.0.6 και νεότερη. Το Heapster σάς επιτρέπει να συλλέγετε όχι μόνο μετρήσεις απόδοσης φόρτου εργασίας, λοβών και κοντέινερ, αλλά και συμβάντων και άλλων σημάτων που παράγονται από ολόκληρο το σύμπλεγμα. Για τη συλλογή δεδομένων, συνομιλεί με το Kubelet κάθε pod, αποθηκεύει αυτόματα τις πληροφορίες στη βάση δεδομένων InfluxDB και τις εξάγει ως μετρήσεις στον πίνακα ελέγχου Grafana. Ωστόσο, λάβετε υπόψη ότι εάν χρησιμοποιείτε το miniKube, αυτή η δυνατότητα δεν είναι διαθέσιμη από προεπιλογή, επομένως θα πρέπει να χρησιμοποιήσετε πρόσθετα για παρακολούθηση. Όλα λοιπόν εξαρτώνται από το πού εκτελείτε τα κοντέινερ και ποια εργαλεία παρακολούθησης μπορείτε να χρησιμοποιήσετε από προεπιλογή και ποια πρέπει να εγκαταστήσετε ως ξεχωριστά πρόσθετα.
Η επόμενη διαφάνεια δείχνει πίνακες εργαλείων Grafana που δείχνουν την κατάσταση λειτουργίας των κοντέινερ μου. Υπάρχουν αρκετά ενδιαφέροντα δεδομένα εδώ. Φυσικά, υπάρχουν πολλά εμπορικά εργαλεία παρακολούθησης διαδικασιών Docker και Kubernetes, όπως τα SysDig, DataDog, NewRelic. Ορισμένα από αυτά έχουν δωρεάν δοκιμαστική περίοδο 30 ετών, ώστε να μπορείτε να δοκιμάσετε να βρείτε αυτό που σας ταιριάζει καλύτερα. Προσωπικά, προτιμώ να χρησιμοποιώ τα SysDig και NewRelic, τα οποία ενσωματώνονται καλά με το Kubernetes. Υπάρχουν εργαλεία που ενσωματώνονται εξίσου καλά και στις πλατφόρμες Docker και Kubernetes.
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με 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