Το πρόβλημα με τις κρατικές εφαρμογές στο Kubernetes
Η διαμόρφωση, η εκκίνηση και η περαιτέρω κλιμάκωση εφαρμογών και υπηρεσιών είναι εύκολη όταν πρόκειται για περιπτώσεις που ταξινομούνται ως ανιθαγενείς, π.χ. χωρίς αποθήκευση δεδομένων. Είναι βολικό να εκτελείτε τέτοιες υπηρεσίες στο Kubernetes, χρησιμοποιώντας τα τυπικά API του, επειδή όλα συμβαίνουν "εκτός συσκευασίας": σύμφωνα με τυπικές διαμορφώσεις, χωρίς να συνεπάγονται ιδιαιτερότητες ή μαγεία.
Με απλά λόγια, για να εκκινήσετε πέντε ακόμη αντίγραφα του backend σε PHP/Ruby/Python σε ένα σύμπλεγμα κοντέινερ, χρειάζεται μόνο να ρυθμίσετε έναν νέο διακομιστή 5 φορές και να αντιγράψετε τις πηγές. Δεδομένου ότι τόσο ο πηγαίος κώδικας όσο και το σενάριο έναρξης βρίσκονται στην εικόνα, η κλιμάκωση μιας εφαρμογής χωρίς κατάσταση γίνεται εντελώς στοιχειώδης. Όπως γνωρίζουν καλά οι λάτρεις των κοντέινερ και της αρχιτεκτονικής μικροϋπηρεσιών, η δυσκολία ξεκινά από αυτό κρατικές εφαρμογές, δηλ. με διατήρηση δεδομένων όπως βάσεις δεδομένων και κρυφές μνήμες (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra...). Αυτό ισχύει τόσο για λογισμικό που υλοποιεί ανεξάρτητα ένα σύμπλεγμα απαρτίας (για παράδειγμα, Percona XtraDB και Cassandra), όσο και για λογισμικό που απαιτεί ξεχωριστά βοηθητικά προγράμματα διαχείρισης (όπως Redis, MySQL, PostgreSQL...).
Προκύπτουν δυσκολίες επειδή ο πηγαίος κώδικας και η εκκίνηση της υπηρεσίας δεν είναι πλέον αρκετά - πρέπει να εκτελέσετε μερικά ακόμη βήματα. Τουλάχιστον, αντιγράψτε τα δεδομένα ή/και εγγραφείτε στο σύμπλεγμα. Πιο συγκεκριμένα, αυτές οι υπηρεσίες απαιτούν κατανόηση του τρόπου σωστής κλίμακας, ενημέρωσης και επαναδιαμόρφωσής τους χωρίς απώλεια δεδομένων ή προσωρινή μη διαθεσιμότητα. Η λήψη υπόψη αυτών των αναγκών ονομάζεται «λειτουργική γνώση».
Χειριστές CoreOS
Προκειμένου να «προγραμματιστεί» η επιχειρησιακή γνώση, στα τέλη του περασμένου έτους το έργο CoreOS «μια νέα κατηγορία λογισμικού» για την πλατφόρμα Kubernetes - Operators (από το αγγλικό «operation», δηλ. «operation»).
Χειριστές που χρησιμοποιούν και επεκτείνουν τις βασικές δυνατότητες του Kubernetes (συμπ. StatefulSets, δείτε τη διαφορά παρακάτω) επιτρέψτε στους ειδικούς του DevOps να προσθέσουν επιχειρησιακές γνώσεις στον κώδικα εφαρμογής.
Σκοπός χειριστή — παρέχετε στον χρήστη ένα API που σας επιτρέπει να διαχειρίζεστε πολλαπλές οντότητες εφαρμογών κατάστασης σε ένα σύμπλεγμα Kubernetes, χωρίς να σκέφτεστε τι υπάρχει κάτω από την κουκούλα (ποια δεδομένα και τι να κάνετε με αυτά, ποιες εντολές πρέπει να εκτελεστούν ακόμη για να διατηρηθεί το σύμπλεγμα ). Στην πραγματικότητα, ο χειριστής έχει σχεδιαστεί για να απλοποιεί όσο το δυνατόν περισσότερο την εργασία με την εφαρμογή εντός του συμπλέγματος, αυτοματοποιώντας την εκτέλεση λειτουργικών εργασιών που προηγουμένως έπρεπε να επιλυθούν χειροκίνητα.
Πώς λειτουργούν οι χειριστές
ReplicaSets Το Kubernetes σάς επιτρέπει να καθορίσετε τον επιθυμητό αριθμό ομάδων που εκτελούνται και οι ελεγκτές διασφαλίζουν ότι ο αριθμός τους διατηρείται (δημιουργώντας και διαγράφοντας pod). Ένας χειριστής λειτουργεί με παρόμοιο τρόπο, προσθέτοντας ένα σύνολο επιχειρησιακών γνώσεων σε έναν τυπικό πόρο και ελεγκτή Kubernetes που σας επιτρέπει να εκτελέσετε πρόσθετες ενέργειες για την υποστήριξη του απαιτούμενου αριθμού οντοτήτων εφαρμογής.
Σε τι διαφέρει αυτό από StatefulSets, σχεδιασμένο για εφαρμογές που απαιτούν από το σύμπλεγμα να τους παρέχει πόρους κατάστασης, όπως αποθήκευση δεδομένων ή στατικές IP; Για τέτοιες εφαρμογές, οι χειριστές μπορούν να χρησιμοποιήσουν StatefulSets (αντί για ReplicaSets) ως βάση, προσφορά πρόσθετος αυτοματισμός: εκτελέστε τις απαραίτητες ενέργειες σε περίπτωση σφαλμάτων, δημιουργήστε αντίγραφα ασφαλείας, ενημερώστε τη διαμόρφωση κ.λπ.
Ετσι, πώς λειτουργούν όλα αυτά; Ο χειριστής είναι ένας διαχειριστής δαίμονας που:
- εγγράφεται στο API εκδήλωσης στο Kubernetes.
- λαμβάνει από αυτό δεδομένα σχετικά με το σύστημα (σχετικά με αυτό ReplicaSets, Pods, Υπηρεσίες και ούτω καθεξής.);
- λαμβάνει δεδομένα για Πόροι τρίτων (βλ. παραδείγματα παρακάτω).
- αντιδρά στην εμφάνιση/αλλαγή Πόροι τρίτων (για παράδειγμα, για να αλλάξετε το μέγεθος, να αλλάξετε την έκδοση και ούτω καθεξής).
- αντιδρά στις αλλαγές στην κατάσταση του συστήματος (σχετικά με αυτό ReplicaSets, Pods, Υπηρεσίες και ούτω καθεξής.);
- το πιο σημαντικό:
- καλεί το Kubernetes API να δημιουργήσει όλα όσα χρειάζεται (και πάλι το δικό του ReplicaSets, Pods, Υπηρεσίες...),
- κάνει κάποια μαγικά (για απλοποίηση, μπορείτε να σκεφτείτε ότι ο χειριστής μπαίνει στα ίδια τα pods και καλεί εντολές, για παράδειγμα, για να συμμετάσχει σε ένα σύμπλεγμα ή για να αναβαθμίσει τη μορφή δεδομένων κατά την ενημέρωση μιας έκδοσης).
Στην πραγματικότητα, όπως φαίνεται από την εικόνα, μια ξεχωριστή εφαρμογή προστίθεται απλώς στο Kubernetes (μια κανονική Ανάπτυξη с Σετ ρεπλίκας), που ονομάζεται χειριστής. Ζει σε ένα συνηθισμένο λοβό (συνήθως μόνο ένα) και, κατά κανόνα, είναι υπεύθυνο μόνο για αυτό Ο χώρος ονομάτων. Αυτή η εφαρμογή χειριστή υλοποιεί το API της - αν και όχι άμεσα, αλλά μέσω Πόροι τρίτων στο Kubernetes.
Έτσι, αφού δημιουργήσαμε σε Ο χώρος ονομάτων Χειριστής, μπορούμε να προσθέσουμε σε αυτό Πόροι τρίτων.
Παράδειγμα για κ.λπ (δείτε παρακάτω για λεπτομέρειες):
apiVersion: etcd.coreos.com/v1beta1
kind: Cluster
metadata:
name: example-etcd-cluster
spec:
size: 3
version: 3.1.0
Παράδειγμα για το Elasticsearch:
apiVersion: enterprises.upmc.com/v1
kind: ElasticsearchCluster
metadata:
name: example-es-cluster
spec:
client-node-replicas: 3
master-node-replicas: 2
data-node-replicas: 3
zones:
- us-east-1c
- us-east-1d
- us-east-1e
data-volume-size: 10Gi
java-options: "-Xms1024m -Xmx1024m"
snapshot:
scheduler-enabled: true
bucket-name: elasticsnapshots99
cron-schedule: "@every 2m"
storage:
type: gp2
storage-class-provisioner: kubernetes.io/aws-ebs
Απαιτήσεις για χειριστές
Το CoreOS διατύπωσε τα κύρια μοτίβα που αποκτήθηκαν από τους μηχανικούς ενώ εργάζονταν σε Operators. Παρά το γεγονός ότι όλοι οι Χειριστές είναι ατομικοί (δημιουργημένοι για μια συγκεκριμένη εφαρμογή με τα δικά της χαρακτηριστικά και ανάγκες), η δημιουργία τους πρέπει να βασίζεται σε ένα είδος πλαισίου που επιβάλλει τις ακόλουθες απαιτήσεις:
- Η εγκατάσταση πρέπει να γίνει μέσω ενός ενιαίου Ανάπτυξη: kubectl δημιουργία -f SOME_OPERATOR_URL/deployment.yaml - και δεν απαιτούν πρόσθετες ενέργειες.
- Κατά την εγκατάσταση ενός χειριστή στο Kubernetes, πρέπει να δημιουργηθεί ένας νέος τύπος τρίτου μέρους (ThirdPartyResource). Για την εκκίνηση παρουσιών εφαρμογών (παρουσίες συμπλέγματος) και την περαιτέρω διαχείριση τους (ενημέρωση εκδόσεων, αλλαγή μεγέθους κ.λπ.), ο χρήστης θα χρησιμοποιήσει αυτόν τον τύπο.
- Όποτε είναι δυνατόν, θα πρέπει να χρησιμοποιείτε τα πρωτόγονα που είναι ενσωματωμένα στο Kubernetes, όπως π.χ Υπηρεσίες и ReplicaSetsγια να χρησιμοποιήσετε καλά δοκιμασμένο και κατανοητό κώδικα.
- Απαιτεί συμβατότητα προς τα πίσω των χειριστών και υποστήριξη για παλαιότερες εκδόσεις πόρων που δημιουργούνται από τον χρήστη.
- Εάν αφαιρεθεί ο χειριστής, η ίδια η εφαρμογή θα πρέπει να συνεχίσει να λειτουργεί χωρίς αλλαγές.
- Οι χρήστες θα πρέπει να μπορούν να ορίζουν την επιθυμητή έκδοση της εφαρμογής και να ενορχηστρώνουν τις ενημερώσεις της έκδοσης της εφαρμογής. Η έλλειψη ενημερώσεων λογισμικού είναι μια κοινή πηγή λειτουργικών προβλημάτων και προβλημάτων ασφάλειας, επομένως οι χειριστές πρέπει να βοηθούν τους χρήστες σε αυτό το θέμα.
- Οι χειριστές θα πρέπει να ελέγχονται με ένα εργαλείο όπως το Chaos Monkey, το οποίο εντοπίζει πιθανές αστοχίες σε ομάδες, διαμορφώσεις και το δίκτυο.
κλπ. Χειριστής
Παράδειγμα υλοποίησης χειριστή - Χειριστής etcd, την ημέρα της ανακοίνωσης αυτής της ιδέας. Η διαμόρφωση του συμπλέγματος etcd μπορεί να είναι πολύπλοκη λόγω της ανάγκης διατήρησης απαρτίας, της ανάγκης επαναδιαμόρφωσης της ιδιότητας μέλους στο σύμπλεγμα, δημιουργίας αντιγράφων ασφαλείας κ.λπ. Για παράδειγμα, η μη αυτόματη κλιμάκωση ενός συμπλέγματος etcd σημαίνει ότι πρέπει να δημιουργήσετε ένα όνομα DNS για ένα νέο μέλος συμπλέγματος, να ξεκινήσετε μια νέα οντότητα etcd και να ειδοποιήσετε το σύμπλεγμα για το νέο μέλος (Προσθήκη μέλους etcdctl). Στην περίπτωση του Χειριστή, ο χρήστης θα χρειαστεί μόνο να αλλάξει το μέγεθος του συμπλέγματος - όλα τα άλλα θα συμβούν αυτόματα.
Και επειδή το etcd δημιουργήθηκε επίσης στο CoreOS, ήταν πολύ λογικό να δούμε πρώτα τον Operator του να εμφανίζεται. Πώς λειτουργεί; Λογική χειριστή κ.λπ καθορίζεται από τρία συστατικά:
- Παρατηρώ. Ο χειριστής παρακολουθεί την κατάσταση του συμπλέγματος χρησιμοποιώντας το Kubernetes API.
- Ανάλυση. Βρίσκει διαφορές μεταξύ της τρέχουσας κατάστασης και της επιθυμητής κατάστασης (καθορίζεται από τη διαμόρφωση του χρήστη).
- Δράση. Επιλύει τις διαφορές που έχουν εντοπιστεί χρησιμοποιώντας τα API της υπηρεσίας etcd ή/και Kubernetes.
Για την εφαρμογή αυτής της λογικής, έχουν προετοιμαστεί συναρτήσεις στον Χειριστή Δημιουργία/Καταστροφή (δημιουργία και διαγραφή μελών συμπλέγματος etcd) και Αλλαγή μεγέθους (αλλαγή στον αριθμό των μελών του cluster). Η ορθότητα της λειτουργίας του ελέγχθηκε χρησιμοποιώντας ένα βοηθητικό πρόγραμμα που δημιουργήθηκε με την ομοιότητα του Chaos Monkey από το Netflix, δηλ. σκοτώνοντας λοβούς etcd τυχαία.
Για την πλήρη λειτουργία του etcd, ο χειριστής παρέχει πρόσθετες δυνατότητες: εφεδρικός (αυτόματη και αόρατη για τους χρήστες δημιουργία αντιγράφων αντιγράφων ασφαλείας - στη διαμόρφωση αρκεί να καθορίσετε πόσο συχνά θα τα δημιουργήσετε και πόσα θα αποθηκεύσετε - και στη συνέχεια επαναφορά δεδομένων από αυτά) και αναβάθμιση (ενημέρωση εγκαταστάσεων etcd χωρίς χρόνο διακοπής λειτουργίας).
Πώς μοιάζει η εργασία με έναν χειριστή;
$ kubectl create -f https://coreos.com/operators/etcd/latest/deployment.yaml
$ kubectl create -f https://coreos.com/operators/etcd/latest/example-etcd-cluster.yaml
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
etcd-cluster-0000 1/1 Running 0 23s
etcd-cluster-0001 1/1 Running 0 16s
etcd-cluster-0002 1/1 Running 0 8s
etcd-cluster-backup-tool-rhygq 1/1 Running 0 18s
Η τρέχουσα κατάσταση του etcd Operator είναι μια έκδοση beta, που απαιτεί Kubernetes 1.5.3+ και etcd 3.0+ για να εκτελεστεί. Ο πηγαίος κώδικας και η τεκμηρίωση (συμπεριλαμβανομένων των οδηγιών χρήσης) είναι διαθέσιμα στη διεύθυνση .
Ένα άλλο παράδειγμα υλοποίησης από το CoreOS έχει δημιουργηθεί - , αλλά εξακολουθεί να είναι σε έκδοση άλφα (δεν έχουν εφαρμοστεί όλες οι προγραμματισμένες δυνατότητες).
Κατάσταση και προοπτικές
Έχουν περάσει 5 μήνες από την ανακοίνωση των Kubernetes Operators. Υπάρχουν ακόμη μόνο δύο διαθέσιμες υλοποιήσεις στο επίσημο αποθετήριο CoreOS (για etcd και Prometheus). Και οι δύο δεν έχουν φτάσει ακόμη στις σταθερές εκδόσεις τους, αλλά οι δεσμεύσεις παρατηρούνται σε καθημερινή βάση.
Οι προγραμματιστές οραματίζονται «ένα μέλλον στο οποίο οι χρήστες εγκαθιστούν Postgres Operators, Cassandra Operators ή Redis Operators στα συμπλέγματα Kubernetes και συνεργάζονται με τις επεκτάσιμες οντότητες αυτών των εφαρμογών τόσο εύκολα όσο είναι σήμερα η ανάπτυξη αντιγράφων εφαρμογών ιστού χωρίς κατάσταση». Πρώτα Χειριστές από τρίτους προγραμματιστές πραγματικά άρχισε να εμφανίζεται:
- από την UPMC Enterprises?
- από Crunchy Data (ανακοινώθηκε στα τέλη Μαρτίου 2017).
- από τους δημιουργούς ενός κατανεμημένου συστήματος αποθήκευσης δεδομένων που βασίζεται στο Ceph (ο Rook βρίσκεται σε κατάσταση άλφα).
- από το SAP CCloud.
Στο μεγαλύτερο ευρωπαϊκό συνέδριο ελεύθερου λογισμικού FOSDEM, που πραγματοποιήθηκε τον Φεβρουάριο του 2017 στις Βρυξέλλες, ο Josh Wood από την CoreOS ανακοίνωσε τους Operators in (ένα βίντεο είναι διαθέσιμο στον σύνδεσμο!), το οποίο αναμένεται να συμβάλει στην αύξηση της δημοτικότητας αυτής της έννοιας στην ευρύτερη κοινότητα Ανοιχτού Κώδικα.
PS Ευχαριστούμε για το ενδιαφέρον σας για το άρθρο! Εγγραφείτε στο κέντρο μας, για να μην χάνετε νέα υλικά και συνταγές για DevOps και διαχείριση συστήματος GNU/Linux - θα τα δημοσιεύουμε τακτικά!
Πηγή: www.habr.com