🥇Επέκταση και συμπλήρωση του Kubernetes (αναθεώρηση και αναφορά βίντεο)

8 Απριλίου στο συνέδριο Saint HighLoad++ 2019, στο πλαίσιο της ενότητας «DevOps and Operations», δόθηκε η έκθεση «Expanding and complementing Kubernetes», στη δημιουργία της οποίας συμμετείχαν τρεις υπάλληλοι της εταιρείας Flant. Σε αυτό, μιλάμε για πολλές καταστάσεις στις οποίες θέλαμε να επεκτείνουμε και να συμπληρώσουμε τις δυνατότητες του Kubernetes, αλλά για τις οποίες δεν βρήκαμε μια έτοιμη και απλή λύση. Έχουμε τις απαραίτητες λύσεις με τη μορφή έργων ανοιχτού κώδικα και σε αυτές είναι αφιερωμένη και αυτή η ομιλία.

Κατά την παράδοση, είμαστε στην ευχάριστη θέση να παρουσιάσουμε βίντεο της έκθεσης (50 λεπτά, πολύ πιο κατατοπιστικό από το άρθρο) και η κύρια περίληψη σε μορφή κειμένου. Πηγαίνω!

Πυρήνας και προσθήκες στα K8

Η Kubernetes αλλάζει τον κλάδο και τις προσεγγίσεις στη διοίκηση που έχουν καθιερωθεί εδώ και καιρό:

Χάρη σε εκείνον αφαιρέσεις, δεν λειτουργούμε πλέον με έννοιες όπως η ρύθμιση παραμέτρων ή η εκτέλεση εντολής (Chef, Ansible...), αλλά χρησιμοποιούμε ομαδοποίηση κοντέινερ, υπηρεσιών κ.λπ.
Μπορούμε να ετοιμάσουμε εφαρμογές χωρίς να σκεφτόμαστε τις αποχρώσεις του συγκεκριμένο ιστότοπο, στο οποίο θα κυκλοφορήσει: γυμνό μέταλλο, σύννεφο ενός από τους παρόχους κ.λπ.
Με τα K8 δεν ήσουν ποτέ πιο προσιτός βέλτιστες πρακτικές σχετικά με την οργάνωση της υποδομής: τεχνικές κλιμάκωσης, αυτοίαση, ανοχή σφαλμάτων κ.λπ.

Ωστόσο, φυσικά, όλα δεν είναι τόσο ομαλά: Η Kubernetes έφερε επίσης τις δικές της νέες προκλήσεις.

Kubernetes όχι είναι ένας συνδυασμός που λύνει όλα τα προβλήματα όλων των χρηστών. Ο πυρήνας Το Kubernetes είναι υπεύθυνο μόνο για ένα σύνολο από τις ελάχιστες απαραίτητες λειτουργίες που υπάρχουν κάθε μία σύμπλεγμα:

Ο πυρήνας Kubernetes ορίζει ένα βασικό σύνολο πρωτόγονων για την ομαδοποίηση κοντέινερ, τη διαχείριση της κυκλοφορίας και ούτω καθεξής. Μιλήσαμε για αυτούς πιο αναλυτικά στο αναφορά πριν από 2 χρόνια.

Από την άλλη πλευρά, το K8s προσφέρει εξαιρετικές ευκαιρίες για επέκταση των διαθέσιμων λειτουργιών, οι οποίες βοηθούν στο κλείσιμο άλλων - ειδικός — ανάγκες των χρηστών. Οι προσθήκες στο Kubernetes είναι ευθύνη των διαχειριστών συμπλέγματος, οι οποίοι πρέπει να εγκαταστήσουν και να διαμορφώσουν όλα τα απαραίτητα για να φέρουν το σύμπλεγμα "στο σωστό σχήμα" [για την επίλυση των συγκεκριμένων προβλημάτων τους]. Τι είδους προσθήκες είναι αυτές; Ας δούμε μερικά παραδείγματα.

Παραδείγματα πρόσθετων

Έχοντας εγκαταστήσει το Kubernetes, μπορεί να εκπλαγούμε που η δικτύωση που είναι τόσο απαραίτητη για την αλληλεπίδραση των pods τόσο εντός ενός κόμβου όσο και μεταξύ των κόμβων δεν λειτουργεί από μόνη της. Ο πυρήνας Kubernetes δεν εγγυάται τις απαραίτητες συνδέσεις, αλλά καθορίζει το δίκτυο διεπαφή (CNI) για πρόσθετα τρίτων. Πρέπει να εγκαταστήσουμε ένα από αυτά τα πρόσθετα, το οποίο θα είναι υπεύθυνο για τη διαμόρφωση του δικτύου.

Ένα κοντινό παράδειγμα είναι οι λύσεις αποθήκευσης δεδομένων (τοπικός δίσκος, συσκευή μπλοκ δικτύου, Ceph...). Αρχικά ήταν στον πυρήνα, αλλά με την έλευση CSI η κατάσταση αλλάζει σε κάτι παρόμοιο με αυτό που έχει ήδη περιγραφεί: η διεπαφή βρίσκεται στο Kubernetes και η υλοποίησή της είναι σε λειτουργικές μονάδες τρίτων.

Άλλα παραδείγματα περιλαμβάνουν:

Είσοδος-ελεγκτές (δείτε την κριτική τους στο πρόσφατο άρθρο μας).
διευθυντής πιστοποιητικών:
Χειριστές είναι μια ολόκληρη κατηγορία πρόσθετων (η οποία περιλαμβάνει τον αναφερόμενο διαχειριστή πιστοποιητικών), ορίζουν πρωτόγονους και ελεγκτές. Η λογική της δουλειάς τους περιορίζεται μόνο από τη φαντασία μας και μας επιτρέπει να μετατρέψουμε έτοιμα στοιχεία υποδομής (για παράδειγμα, ένα DBMS) σε πρωτόγονα, με τα οποία είναι πολύ πιο εύκολο να δουλέψουμε (παρά με ένα σύνολο κοντέινερ και τις ρυθμίσεις τους). Ένας τεράστιος αριθμός χειριστών έχει γραφτεί - ακόμα κι αν πολλοί από αυτούς δεν είναι ακόμη έτοιμοι για παραγωγή, είναι μόνο θέμα χρόνου:
Μετρήσεις - άλλη μια απεικόνιση του τρόπου με τον οποίο η Kubernetes διαχώρισε τη διεπαφή (Metrics API) από την υλοποίηση (πρόσθετα τρίτων όπως ο προσαρμογέας Prometheus, ο πράκτορας συμπλέγματος Datadog...).
Για παρακολούθηση και στατιστικές, όπου στην πράξη όχι μόνο χρειάζονται Προμηθέας και Γραφάνα, αλλά και kube-state-metrics, node-exporter κ.λπ.

Και αυτή δεν είναι μια πλήρης λίστα με προσθήκες... Για παράδειγμα, στην εταιρεία Flant που εγκαθιστούμε αυτήν τη στιγμή 29 πρόσθετα (όλα τα οποία δημιουργούν συνολικά 249 αντικείμενα Kubernetes). Με απλά λόγια, δεν μπορούμε να δούμε τη ζωή ενός συμπλέγματος χωρίς προσθήκες.

Αυτοματοποίηση

Οι χειριστές έχουν σχεδιαστεί για να αυτοματοποιούν τις συνήθεις λειτουργίες που αντιμετωπίζουμε καθημερινά. Ακολουθούν πραγματικά παραδείγματα για τα οποία η σύνταξη ενός χειριστή θα ήταν μια εξαιρετική λύση:

Υπάρχει ένα ιδιωτικό μητρώο (δηλαδή απαιτείται σύνδεση) με εικόνες για την εφαρμογή. Υποτίθεται ότι σε κάθε pod έχει εκχωρηθεί ένα ειδικό μυστικό που επιτρέπει τον έλεγχο ταυτότητας στο μητρώο. Καθήκον μας είναι να διασφαλίσουμε ότι αυτό το μυστικό βρίσκεται στον χώρο ονομάτων, έτσι ώστε τα pods να μπορούν να κάνουν λήψη εικόνων. Μπορεί να υπάρχουν πολλές εφαρμογές (καθεμία από τις οποίες χρειάζεται ένα μυστικό) και είναι χρήσιμο να ενημερώνετε τακτικά τα ίδια τα μυστικά, έτσι ώστε να εξαλείφεται η επιλογή να εκθέσετε τα μυστικά με το χέρι. Εδώ έρχεται να σώσει ο χειριστής: δημιουργούμε έναν ελεγκτή που θα περιμένει να εμφανιστεί ο χώρος ονομάτων και, βάσει αυτού του συμβάντος, θα προσθέσει ένα μυστικό στον χώρο ονομάτων.
Απαγορεύεται από προεπιλογή η πρόσβαση από τα pod στο Διαδίκτυο. Αλλά μερικές φορές μπορεί να απαιτείται: είναι λογικό ο μηχανισμός άδειας πρόσβασης να λειτουργεί απλά, χωρίς να απαιτεί συγκεκριμένες δεξιότητες, για παράδειγμα, με την παρουσία μιας συγκεκριμένης ετικέτας στον χώρο ονομάτων. Πώς μπορεί ο χειριστής να μας βοηθήσει εδώ; Δημιουργείται ένας ελεγκτής που περιμένει να εμφανιστεί η ετικέτα στο χώρο ονομάτων και προσθέτει την κατάλληλη πολιτική για πρόσβαση στο Διαδίκτυο.
Μια παρόμοια κατάσταση: ας υποθέσουμε ότι έπρεπε να προσθέσουμε ένα συγκεκριμένο κηλίδα, αν έχει παρόμοια ετικέτα (με κάποιο είδος προθέματος). Οι ενέργειες με τον χειριστή είναι προφανείς...

Σε οποιοδήποτε σύμπλεγμα, οι εργασίες ρουτίνας πρέπει να επιλυθούν και σωστά αυτό μπορεί να γίνει χρησιμοποιώντας τελεστές.

Συνοψίζοντας όλες τις ιστορίες που περιγράφηκαν, καταλήξαμε στο συμπέρασμα ότι για άνετη εργασία στο Kubernetes χρειάζεστε: ΕΝΑ) εγκαταστήστε πρόσθετα, β) αναπτύξουν χειριστές (για την επίλυση καθημερινών εργασιών διαχειριστή).

Πώς να γράψετε μια δήλωση για το Kubernetes;

Σε γενικές γραμμές, το σχέδιο είναι απλό:

... αλλά μετά αποδεικνύεται ότι:

Το Kubernetes API είναι ένα μάλλον μη τετριμμένο πράγμα που απαιτεί πολύ χρόνο για να κυριαρχήσει.
Ο προγραμματισμός δεν είναι επίσης για όλους (η γλώσσα Go επιλέχθηκε ως προτιμώμενη γλώσσα επειδή υπάρχει ένα ειδικό πλαίσιο για αυτήν - SDK χειριστή);
Η κατάσταση είναι παρόμοια με το ίδιο το πλαίσιο.

Η κατώτατη γραμμή: για να γράψετε έναν ελεγκτή (χειριστής) πρέπει να ξοδεύουν σημαντικούς πόρους να μελετήσει υλικό. Αυτό θα ήταν δικαιολογημένο για «μεγάλους» χειριστές - ας πούμε, για το MySQL DBMS. Αλλά αν θυμηθούμε τα παραδείγματα που περιγράφηκαν παραπάνω (ξεδίπλωμα μυστικών, πρόσβαση σε ομάδες στο Διαδίκτυο...), τα οποία θέλουμε επίσης να κάνουμε σωστά, τότε θα καταλάβουμε ότι η προσπάθεια που καταβλήθηκε θα υπερβεί το αποτέλεσμα που χρειαζόμαστε τώρα:

Γενικά, προκύπτει ένα δίλημμα: ξοδέψτε πολλούς πόρους και βρείτε το κατάλληλο εργαλείο για τη σύνταξη δηλώσεων ή κάντε το με τον παλιομοδίτικο τρόπο (αλλά γρήγορα). Για να το λύσουμε - για να βρούμε έναν συμβιβασμό μεταξύ αυτών των άκρων - δημιουργήσαμε το δικό μας έργο: κέλυφος-χειριστής (βλέπε επίσης το δικό του πρόσφατη ανακοίνωση στο κέντρο).

Shell-operator

Πώς λειτουργεί; Το σύμπλεγμα έχει ένα pod που περιέχει ένα δυαδικό Go με έναν τελεστή κελύφους. Δίπλα είναι ένα σύνολο από αγκίστρια (περισσότερες λεπτομέρειες για αυτούς - δείτε παρακάτω). Ο ίδιος ο χειριστής του κελύφους προσυπογράφει ορισμένα εξελίξεις στο Kubernetes API, με την εμφάνιση του οποίου εκκινεί τα αντίστοιχα hook.

Πώς γνωρίζει ο χειριστής του κελύφους ποια hook να καλέσει σε ποια γεγονότα; Αυτές οι πληροφορίες μεταδίδονται στον χειριστή του κελύφους από τα ίδια τα άγκιστρα και το κάνουν πολύ απλά.

Ένα άγκιστρο είναι ένα σενάριο Bash ή οποιοδήποτε άλλο εκτελέσιμο αρχείο που δέχεται ένα μόνο όρισμα --config και απαντά με JSON. Το τελευταίο καθορίζει ποια αντικείμενα το ενδιαφέρουν και ποια γεγονότα (για αυτά τα αντικείμενα) πρέπει να απαντηθούν:

Θα παρουσιάσω την υλοποίηση στον χειριστή του κελύφους ενός από τα παραδείγματά μας - αποσύνθεση μυστικών για πρόσβαση σε ιδιωτικό μητρώο με εικόνες εφαρμογής. Αποτελείται από δύο στάδια.

Εξάσκηση: 1. Γράψε ένα γάντζο

Πρώτα απ 'όλα, στο γάντζο που θα επεξεργαστούμε --config, υποδεικνύοντας ότι μας ενδιαφέρουν οι χώροι ονομάτων, και συγκεκριμένα, η στιγμή της δημιουργίας τους:

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

Πώς θα ήταν η λογική; Επίσης πολύ απλό:

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

Το πρώτο βήμα είναι να μάθετε ποιος χώρος ονομάτων δημιουργήθηκε και το δεύτερο είναι να τον δημιουργήσετε χρησιμοποιώντας kubectl μυστικό για αυτόν τον χώρο ονομάτων.

Εξάσκηση: 2. Συναρμολόγηση της εικόνας

Το μόνο που μένει είναι να περάσετε το δημιουργημένο άγκιστρο στον χειριστή του κελύφους - πώς να το κάνετε αυτό; Ο ίδιος ο τελεστής φλοιού έρχεται ως εικόνα Docker, επομένως η αποστολή μας είναι να προσθέσουμε το άγκιστρο σε έναν ειδικό κατάλογο σε αυτήν την εικόνα:

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

Το μόνο που μένει είναι να το συναρμολογήσετε και να το σπρώξετε:

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

Η τελευταία πινελιά είναι η ανάπτυξη της εικόνας στο σύμπλεγμα. Για να γίνει αυτό, ας γράψουμε Ανάπτυξη:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

Υπάρχουν δύο σημεία που πρέπει να προσέξετε:

ένδειξη της νέας εικόνας.
Αυτό είναι ένα στοιχείο συστήματος που (τουλάχιστον) χρειάζεται δικαιώματα για να εγγραφεί σε συμβάντα στο Kubernetes και να εκχωρήσει μυστικά σε χώρους ονομάτων, επομένως δημιουργούμε έναν Λογαριασμό Υπηρεσίας (και ένα σύνολο κανόνων) για το άγκιστρο.

Αποτέλεσμα - λύσαμε το πρόβλημά μας συγγενείς για Kubernetes με τρόπο που δημιουργεί έναν τελεστή για την αποσύνθεση μυστικών.

Άλλα χαρακτηριστικά χειριστή του κελύφους

Για να περιορίσετε τα αντικείμενα του τύπου που έχετε επιλέξει με τα οποία θα λειτουργεί το άγκιστρο, μπορούν να φιλτραριστούν, επιλέγοντας σύμφωνα με ορισμένες ετικέτες (ή χρησιμοποιώντας matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

Υπό την προϋπόθεση μηχανισμός αποδιπλασιασμού, το οποίο - χρησιμοποιώντας ένα φίλτρο jq - σας επιτρέπει να μετατρέψετε μεγάλα αντικείμενα JSON σε μικρά, όπου παραμένουν μόνο εκείνες οι παράμετροι που θέλουμε να παρακολουθήσουμε για αλλαγές.

Όταν καλείται ένα άγκιστρο, ο χειριστής του κελύφους το περνάει δεδομένα αντικειμένου, το οποίο μπορεί να χρησιμοποιηθεί για οποιαδήποτε ανάγκη.

Τα συμβάντα που ενεργοποιούν τα hook δεν περιορίζονται στα συμβάντα Kubernetes: ο χειριστής του κελύφους παρέχει υποστήριξη για καλώντας αγκίστρια με την ώρα (παρόμοιο με το crontab σε έναν παραδοσιακό προγραμματιστή), καθώς και μια ειδική εκδήλωση κατά την εκκίνηση. Όλα αυτά τα συμβάντα μπορούν να συνδυαστούν και να αντιστοιχιστούν στο ίδιο άγκιστρο.

Και δύο ακόμη χαρακτηριστικά του χειριστή του κελύφους:

Δουλεύει ασύγχρονα. Εφόσον ελήφθη ένα συμβάν Kubernetes (όπως ένα αντικείμενο που δημιουργείται), άλλα συμβάντα (όπως η διαγραφή του ίδιου αντικειμένου) θα μπορούσαν να έχουν συμβεί στο σύμπλεγμα και τα άγκιστρα πρέπει να το λάβουν υπόψη. Εάν το άγκιστρο εκτελέστηκε με σφάλμα, τότε από προεπιλογή θα είναι ανάκληση μέχρι την επιτυχή ολοκλήρωση (αυτή η συμπεριφορά μπορεί να αλλάξει).
Εξάγει μετρήσεις για το Prometheus, με το οποίο μπορείτε να καταλάβετε εάν ο χειριστής του κελύφους λειτουργεί, μάθετε τον αριθμό των σφαλμάτων για κάθε άγκιστρο και το τρέχον μέγεθος ουράς.

Για να συνοψίσουμε αυτό το μέρος της έκθεσης:

Εγκατάσταση πρόσθετων

Για άνετη εργασία με το Kubernetes, αναφέρθηκε και η ανάγκη εγκατάστασης πρόσθετων. Θα σας πω για αυτό χρησιμοποιώντας το παράδειγμα της πορείας της εταιρείας μας για το πώς το κάνουμε τώρα.

Ξεκινήσαμε να δουλεύουμε με την Kubernetes με πολλά clusters, η μόνη προσθήκη στα οποία ήταν το Ingress. Χρειαζόταν να εγκατασταθεί διαφορετικά σε κάθε σύμπλεγμα και κάναμε πολλές διαμορφώσεις YAML για διαφορετικά περιβάλλοντα: γυμνό μέταλλο, AWS...

Καθώς υπήρχαν περισσότερα συμπλέγματα, υπήρχαν περισσότερες διαμορφώσεις. Επιπλέον, βελτιώσαμε αυτές τις διαμορφώσεις οι ίδιες, με αποτέλεσμα να γίνουν αρκετά ετερογενείς:

Για να τα βάλουμε όλα σε τάξη, ξεκινήσαμε με ένα σενάριο (install-ingress.sh), το οποίο έλαβε ως επιχείρημα τον τύπο του συμπλέγματος στο οποίο θα αναπτύξουμε, δημιούργησε την απαραίτητη διαμόρφωση YAML και την έβγαλε στο Kubernetes.

Εν ολίγοις, η περαιτέρω πορεία μας και οι συλλογισμοί που συνδέονται με αυτήν ήταν οι εξής:

Για να εργαστείτε με διαμορφώσεις YAML, απαιτείται κινητήρας προτύπου (στα πρώτα στάδια αυτό είναι απλό sed).
με την αύξηση του αριθμού των συμπλεγμάτων, ήρθε η ανάγκη για αυτόματη ενημέρωση (η πρώτη λύση ήταν να βάλετε το σενάριο στο Git, να το ενημερώσετε χρησιμοποιώντας το cron και να το εκτελέσετε).
ένα παρόμοιο σενάριο χρειαζόταν για τον Προμηθέα (install-prometheus.sh), ωστόσο, είναι αξιοσημείωτο για το γεγονός ότι απαιτεί πολύ περισσότερα δεδομένα εισόδου, καθώς και την αποθήκευσή τους (με την καλή έννοια - συγκεντρωτικά και σε ένα σύμπλεγμα) και ορισμένα δεδομένα (κωδικοί πρόσβασης) θα μπορούσαν να δημιουργηθούν αυτόματα:
ο κίνδυνος να κυκλοφορήσει κάτι λάθος σε έναν αυξανόμενο αριθμό συμπλεγμάτων αυξανόταν συνεχώς, έτσι συνειδητοποιήσαμε ότι οι εγκαταστάτες (δηλαδή δύο σενάρια: για Ingress και Prometheus) Χρειαζόταν σταδιοποίηση (αρκετοί κλάδοι στο Git, αρκετά crons για να ενημερωθούν στα αντίστοιχα: σταθερά ή δοκιμαστικά συμπλέγματα).
с kubectl apply Έχει γίνει δύσκολο να δουλέψεις γιατί δεν είναι δηλωτικό και μπορεί μόνο να δημιουργήσει αντικείμενα, αλλά όχι να λάβει αποφάσεις για την κατάστασή τους/να τα διαγράψει.
Μας έλειπαν κάποιες λειτουργίες που δεν είχαμε εφαρμόσει καθόλου εκείνη τη στιγμή:
- πλήρη έλεγχο του αποτελέσματος των ενημερώσεων συμπλέγματος,
- αυτόματος προσδιορισμός ορισμένων παραμέτρων (εισαγωγή για σενάρια εγκατάστασης) με βάση δεδομένα που μπορούν να ληφθούν από το σύμπλεγμα (ανακάλυψη),
- τη λογική του ανάπτυξη με τη μορφή συνεχούς ανακάλυψης.

Υλοποιήσαμε όλη αυτή τη συσσωρευμένη εμπειρία στο πλαίσιο του άλλου έργου μας - addon-operator.

Addon-operator

Βασίζεται στον ήδη αναφερόμενο χειριστή του κελύφους. Όλο το σύστημα μοιάζει με αυτό:

Τα ακόλουθα προστίθενται στα άγκιστρα χειριστή του κελύφους:

αποθήκευση αξιών,
Διάγραμμα τιμόνι,
συστατικό που παρακολουθεί την αποθήκευση τιμών και - σε περίπτωση οποιωνδήποτε αλλαγών - ζητά από τον Helm να επαναφέρει το διάγραμμα.

Έτσι, μπορούμε να αντιδράσουμε σε ένα συμβάν στο Kubernetes, να ξεκινήσουμε ένα άγκιστρο και από αυτό το άγκιστρο να κάνουμε αλλαγές στον αποθηκευτικό χώρο, μετά από τις οποίες θα γίνει εκ νέου λήψη του γραφήματος. Στο διάγραμμα που προκύπτει, χωρίζουμε το σύνολο των αγκίστρων και το γράφημα σε ένα στοιχείο, το οποίο ονομάζουμε μονάδα μέτρησης:

Μπορεί να υπάρχουν πολλές ενότητες και σε αυτές προσθέτουμε καθολικά άγκιστρα, ένα παγκόσμιο κατάστημα τιμών και ένα στοιχείο που παρακολουθεί αυτό το παγκόσμιο κατάστημα.

Τώρα, όταν συμβαίνει κάτι στο Kubernetes, μπορούμε να αντιδράσουμε σε αυτό χρησιμοποιώντας ένα παγκόσμιο άγκιστρο και να αλλάξουμε κάτι στο παγκόσμιο κατάστημα. Αυτή η αλλαγή θα γίνει αντιληπτή και θα προκαλέσει την κυκλοφορία όλων των λειτουργικών μονάδων στο σύμπλεγμα:

Αυτό το σχήμα ικανοποιεί όλες τις απαιτήσεις για την εγκατάσταση πρόσθετων που αναφέρθηκαν παραπάνω:

Η Helm είναι υπεύθυνη για το template και τη δηλωτικότητα.
Το ζήτημα της αυτόματης ενημέρωσης επιλύθηκε χρησιμοποιώντας ένα καθολικό άγκιστρο, το οποίο πηγαίνει στο μητρώο σύμφωνα με ένα χρονοδιάγραμμα και, εάν δει μια νέα εικόνα συστήματος εκεί, το κυκλοφορεί (δηλαδή "ο ίδιος").
Η αποθήκευση ρυθμίσεων στο σύμπλεγμα υλοποιείται χρησιμοποιώντας ConfigMap, το οποίο περιέχει τα κύρια δεδομένα για τους αποθηκευτικούς χώρους (κατά την εκκίνηση φορτώνονται στους αποθηκευτικούς χώρους).
Προβλήματα με τη δημιουργία κωδικού πρόσβασης, την ανακάλυψη και τη συνεχή ανακάλυψη επιλύθηκαν χρησιμοποιώντας άγκιστρα.
Η σταδιοποίηση επιτυγχάνεται χάρη στις ετικέτες, τις οποίες το Docker υποστηρίζει εκτός συσκευασίας.
Το αποτέλεσμα παρακολουθείται χρησιμοποιώντας μετρήσεις με τις οποίες μπορούμε να κατανοήσουμε την κατάσταση.

Ολόκληρο αυτό το σύστημα υλοποιείται με τη μορφή ενός ενιαίου δυαδικού αρχείου στο Go, το οποίο ονομάζεται addon-operator. Αυτό κάνει το διάγραμμα να φαίνεται πιο απλό:

Το κύριο συστατικό σε αυτό το διάγραμμα είναι ένα σύνολο ενοτήτων (επισημαίνεται με γκρι παρακάτω). Τώρα μπορούμε να γράψουμε μια ενότητα για το απαιτούμενο πρόσθετο με λίγη προσπάθεια και να είμαστε σίγουροι ότι θα εγκατασταθεί σε κάθε σύμπλεγμα, θα ενημερωθεί και θα ανταποκρίνεται στα συμβάντα που χρειάζεται στο σύμπλεγμα.

"Flant" χρήσεις addon-operator σε 70+ συμπλέγματα Kubernetes. Τρέχουσα κατάσταση - άλφα έκδοση. Τώρα ετοιμάζουμε τεκμηρίωση για την κυκλοφορία της beta, αλλά προς το παρόν στο αποθετήριο διαθέσιμα παραδείγματα, βάσει του οποίου μπορείτε να δημιουργήσετε το δικό σας πρόσθετο.

Πού μπορώ να βρω τα modules για addon-operator; Η έκδοση της βιβλιοθήκης μας είναι το επόμενο στάδιο για εμάς· σκοπεύουμε να το κάνουμε το καλοκαίρι.

Βίντεο και διαφάνειες

Βίντεο από την παράσταση (~50 λεπτά):

Παρουσίαση της έκθεσης:

PS

Άλλες αναφορές στο ιστολόγιό μας:

«Βάσεις δεδομένων και Kubernetes"? (Dmitry Stolyarov, 8 Νοεμβρίου 2018 στο HighLoad++);
«Παρακολούθηση και Kubernetes"? (Dmitry Stolyarov; 28 Μαΐου 2018 στο RootConf);
«Βέλτιστες πρακτικές CI/CD με Kubernetes και GitLab"? (Dmitry Stolyarov, 7 Νοεμβρίου 2017 στο HighLoad++);
«Η εμπειρία μας με την Kubernetes σε μικρά έργα"? (Dmitry Stolyarov, 6 Ιουνίου 2017 στο RootConf).

Μπορεί επίσης να σας ενδιαφέρουν οι ακόλουθες δημοσιεύσεις:

«Παρουσίαση του shell-operator: η δημιουργία τελεστών για το Kubernetes μόλις έγινε ευκολότερη».

Πηγή: www.habr.com

Επέκταση και συμπλήρωση του Kubernetes (αναθεώρηση και αναφορά βίντεο)