Πηγαίνω? Βίαιο χτύπημα! Γνωρίστε τον χειριστή του κελύφους (επισκόπηση και αναφορά βίντεο από το KubeCon EU'2020)

Φέτος, το κύριο ευρωπαϊκό συνέδριο Kubernetes - KubeCon + CloudNativeCon Europe 2020 - ήταν εικονικό. Ωστόσο, μια τέτοια αλλαγή στη μορφή δεν μας εμπόδισε να παραδώσουμε την από καιρό προγραμματισμένη έκθεσή μας «Πήγαινε; Βίαιο χτύπημα! Meet the Shell-operator» αφιερωμένο στο έργο μας Ανοιχτού Κώδικα κέλυφος-χειριστής.

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

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

Στη Flant βελτιστοποιούμε και αυτοματοποιούμε συνεχώς τα πάντα. Σήμερα θα μιλήσουμε για μια άλλη συναρπαστική ιδέα. Συναντώ: δέσμες ενεργειών με φυσικό κέλυφος στο cloud!

Ωστόσο, ας ξεκινήσουμε με το πλαίσιο στο οποίο συμβαίνουν όλα αυτά: Kubernetes.

Kubernetes API και ελεγκτές

Το API στο Kubernetes μπορεί να αναπαρασταθεί ως ένα είδος διακομιστή αρχείων με καταλόγους για κάθε τύπο αντικειμένου. Τα αντικείμενα (πόροι) σε αυτόν τον διακομιστή αντιπροσωπεύονται από αρχεία YAML. Επιπλέον, ο διακομιστής διαθέτει ένα βασικό API που σας επιτρέπει να κάνετε τρία πράγματα:

• να λάβετε πόρος με το είδος και το όνομά του·
• αλλαγή πόρος (σε αυτήν την περίπτωση, ο διακομιστής αποθηκεύει μόνο "σωστά" αντικείμενα - όλα τα εσφαλμένα διαμορφωμένα ή που προορίζονται για άλλους καταλόγους απορρίπτονται).
• ακολουθήστε για τον πόρο (σε αυτήν την περίπτωση, ο χρήστης λαμβάνει αμέσως την τρέχουσα/ενημερωμένη έκδοσή του).

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

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

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

Ας ρίξουμε μια πιο προσεκτική ματιά στη διαδικασία δημιουργίας ενός Deployment στο Kubernetes:

• Ελεγκτής ανάπτυξης (περιλαμβάνεται στο kube-controller-manager) λαμβάνει πληροφορίες σχετικά με την ανάπτυξη και δημιουργεί ένα ReplicaSet.
• Το ReplicaSet δημιουργεί δύο αντίγραφα (δύο ομάδες) με βάση αυτές τις πληροφορίες, αλλά αυτές οι ομάδες δεν έχουν προγραμματιστεί ακόμα.
• Ο προγραμματιστής προγραμματίζει τα pods και προσθέτει πληροφορίες κόμβων στα YAML τους.
• Το Kubelets κάνει αλλαγές σε έναν εξωτερικό πόρο (ας πούμε Docker).

Στη συνέχεια, όλη αυτή η ακολουθία επαναλαμβάνεται με αντίστροφη σειρά: το kubelet ελέγχει τα δοχεία, υπολογίζει την κατάσταση του pod και το στέλνει πίσω. Ο ελεγκτής ReplicaSet λαμβάνει την κατάσταση και ενημερώνει την κατάσταση του συνόλου αντιγράφων. Το ίδιο συμβαίνει και με το Deployment Controller και ο χρήστης αποκτά τελικά την ενημερωμένη (τρέχουσα) κατάσταση.

Shell-operator

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

Απλό παράδειγμα: αντιγραφή μυστικών

Ας δούμε ένα απλό παράδειγμα.

Ας πούμε ότι έχουμε ένα σύμπλεγμα Kubernetes. Έχει χώρο ονομάτων default με κάποιο μυστικό mysecret. Επιπλέον, υπάρχουν και άλλοι χώροι ονομάτων στο σύμπλεγμα. Ορισμένα από αυτά έχουν μια συγκεκριμένη ετικέτα κολλημένη πάνω τους. Στόχος μας είναι να αντιγράψουμε το Secret σε χώρους ονομάτων με ετικέτα.

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

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

Πώς λειτουργεί ο χειριστής του κελύφους

Όπως και άλλοι φόρτοι εργασίας στο Kubernetes, ο χειριστής του κελύφους εκτελείται στο δικό του pod. Σε αυτό το pod στον κατάλογο /hooks αποθηκεύονται εκτελέσιμα αρχεία. Αυτά μπορεί να είναι σενάρια σε Bash, Python, Ruby κ.λπ. Αυτά τα εκτελέσιμα αρχεία ονομάζουμε άγκιστρα (άγκιστρα).

Ο χειριστής της Shell εγγράφεται σε συμβάντα Kubernetes και εκτελεί αυτά τα hook ως απόκριση σε εκείνα τα συμβάντα που χρειαζόμαστε.

Πώς γνωρίζει ο χειριστής του κελύφους ποιο άγκιστρο να τρέξει και πότε; Το θέμα είναι ότι κάθε γάντζος έχει δύο στάδια. Κατά την εκκίνηση, ο χειριστής του κελύφους εκτελεί όλα τα hook με όρισμα --config Αυτό είναι το στάδιο διαμόρφωσης. Και μετά από αυτό, τα άγκιστρα εκτοξεύονται με τον κανονικό τρόπο - ως απάντηση στα γεγονότα στα οποία συνδέονται. Στην τελευταία περίπτωση, το άγκιστρο λαμβάνει το δεσμευτικό πλαίσιο (δεσμευτικό πλαίσιο) - δεδομένα σε μορφή JSON, για τα οποία θα μιλήσουμε λεπτομερέστερα παρακάτω.

Δημιουργία χειριστή στο Bash

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

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

#!/bin/bash

source /shell_lib.sh

function __config__() {
  cat << EOF
    configVersion: v1
    # BINDING CONFIGURATION
EOF
}

function __main__() {
  # THE LOGIC
}

hook::run "$@"

Το επόμενο βήμα είναι να αποφασίσουμε ποια αντικείμενα χρειαζόμαστε. Στην περίπτωσή μας, πρέπει να παρακολουθούμε:

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

Εγγραφείτε στη μυστική πηγή

Η διαμόρφωση δέσμευσης για αυτό είναι αρκετά απλή. Δηλώνουμε ότι μας ενδιαφέρει το Secret με το όνομα mysecret στον χώρο ονομάτων default:

function __config__() {
  cat << EOF
    configVersion: v1
    kubernetes:
    - name: src_secret
      apiVersion: v1
      kind: Secret
      nameSelector:
        matchNames:
        - mysecret
      namespace:
        nameSelector:
          matchNames: ["default"]
      group: main
EOF

Ως αποτέλεσμα, το άγκιστρο θα ενεργοποιηθεί όταν αλλάξει το μυστικό πηγής (src_secret) και λάβετε το ακόλουθο δεσμευτικό πλαίσιο:

Όπως μπορείτε να δείτε, περιέχει το όνομα και ολόκληρο το αντικείμενο.

Παρακολούθηση χώρων ονομάτων

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

- name: namespaces
  group: main
  apiVersion: v1
  kind: Namespace
  jqFilter: |
    {
      namespace: .metadata.name,
      hasLabel: (
       .metadata.labels // {} |  
         contains({"secret": "yes"})
      )
    }
  group: main
  keepFullObjectsInMemory: false

Όπως μπορείτε να δείτε, ένα νέο πεδίο έχει εμφανιστεί στη διαμόρφωση με το όνομα jqFilter. Όπως υποδηλώνει το όνομά του, jqFilter φιλτράρει όλες τις περιττές πληροφορίες και δημιουργεί ένα νέο αντικείμενο JSON με τα πεδία που μας ενδιαφέρουν. Ένα άγκιστρο με παρόμοια διαμόρφωση θα λάβει το ακόλουθο δεσμευτικό πλαίσιο:

Περιέχει έναν πίνακα filterResults για κάθε χώρο ονομάτων στο σύμπλεγμα. Μεταβλητή Boolean hasLabel υποδεικνύει εάν μια ετικέτα είναι συνδεδεμένη σε έναν δεδομένο χώρο ονομάτων. Εκλέκτορας keepFullObjectsInMemory: false υποδηλώνει ότι δεν υπάρχει ανάγκη διατήρησης πλήρων αντικειμένων στη μνήμη.

Παρακολούθηση μυστικών στόχων

Έχουμε εγγραφεί σε όλα τα μυστικά που έχουν καθορισμένο σχολιασμό managed-secret: "yes" (αυτοί είναι ο στόχος μας dst_secrets):

- name: dst_secrets
  apiVersion: v1
  kind: Secret
  labelSelector:
    matchLabels:
      managed-secret: "yes"
  jqFilter: |
    {
      "namespace":
        .metadata.namespace,
      "resourceVersion":
        .metadata.annotations.resourceVersion
    }
  group: main
  keepFullObjectsInMemory: false

Σε αυτή την περίπτωση jqFilter φιλτράρει όλες τις πληροφορίες εκτός από τον χώρο ονομάτων και την παράμετρο resourceVersion. Η τελευταία παράμετρος μεταβιβάστηκε στον σχολιασμό κατά τη δημιουργία του μυστικού: σας επιτρέπει να συγκρίνετε εκδόσεις μυστικών και να τα διατηρείτε ενημερωμένα.

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

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

• αν hasLabel θέματα true για τον τρέχοντα χώρο ονομάτων:
  • συγκρίνει το παγκόσμιο μυστικό με το τοπικό:
    • αν είναι τα ίδια, δεν κάνει τίποτα?
    • αν διαφέρουν - εκτελεί kubectl replace ή create;
• αν hasLabel θέματα false για τον τρέχοντα χώρο ονομάτων:
  • βεβαιωθείτε ότι το Secret δεν βρίσκεται στον δεδομένο χώρο ονομάτων:
    • εάν υπάρχει το τοπικό Secret, διαγράψτε το χρησιμοποιώντας kubectl delete;
    • αν δεν εντοπιστεί το τοπικό Secret, δεν κάνει τίποτα.

Εφαρμογή του αλγορίθμου στο Bash μπορείτε να κατεβάσετε στο δικό μας αποθετήρια με παραδείγματα.

Έτσι καταφέραμε να δημιουργήσουμε έναν απλό ελεγκτή Kubernetes χρησιμοποιώντας 35 γραμμές διαμόρφωσης YAML και περίπου τον ίδιο αριθμό κώδικα Bash! Η δουλειά του χειριστή του κελύφους είναι να τα συνδέσει μεταξύ τους.

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

Παράδειγμα 1: Πραγματοποίηση αλλαγών στο ConfigMap

Ας δούμε ένα Deployment που αποτελείται από τρία pods. Τα Pods χρησιμοποιούν το ConfigMap για να αποθηκεύσουν ορισμένες ρυθμίσεις. Όταν κυκλοφόρησαν τα pods, το ConfigMap ήταν σε μια συγκεκριμένη κατάσταση (ας το ονομάσουμε v.1). Αντίστοιχα, όλα τα pods χρησιμοποιούν αυτή τη συγκεκριμένη έκδοση του ConfigMap.

Τώρα ας υποθέσουμε ότι το ConfigMap έχει αλλάξει (v.2). Ωστόσο, οι ομάδες θα χρησιμοποιούν την προηγούμενη έκδοση του ConfigMap (v.1):

Πώς μπορώ να τους κάνω να μεταβούν στο νέο ConfigMap (v.2); Η απάντηση είναι απλή: χρησιμοποιήστε ένα πρότυπο. Ας προσθέσουμε έναν σχολιασμό αθροίσματος ελέγχου στην ενότητα template Διαμορφώσεις ανάπτυξης:

Ως αποτέλεσμα, αυτό το άθροισμα ελέγχου θα καταχωρηθεί σε όλα τα pods και θα είναι το ίδιο με αυτό του Deployment. Τώρα χρειάζεται απλώς να ενημερώσετε τον σχολιασμό όταν αλλάξει το ConfigMap. Και ο χειριστής του κελύφους είναι χρήσιμος σε αυτή την περίπτωση. Το μόνο που χρειάζεται να κάνετε είναι να προγραμματίσετε ένα άγκιστρο που θα εγγραφεί στο ConfigMap και θα ενημερώσει το άθροισμα ελέγχου.

Εάν ο χρήστης κάνει αλλαγές στο ConfigMap, ο χειριστής του κελύφους θα τις παρατηρήσει και θα υπολογίσει εκ νέου το άθροισμα ελέγχου. Μετά από αυτό θα μπει στο παιχνίδι η μαγεία του Kubernetes: ο ενορχηστρωτής θα σκοτώσει το λοβό, θα δημιουργήσει ένα νέο, θα περιμένει να γίνει Ready, και προχωρά στο επόμενο. Ως αποτέλεσμα, το Deployment θα συγχρονιστεί και θα μεταβεί στη νέα έκδοση του ConfigMap.

Παράδειγμα 2: Εργασία με προσαρμοσμένους ορισμούς πόρων

Όπως γνωρίζετε, το Kubernetes σάς επιτρέπει να δημιουργείτε προσαρμοσμένους τύπους αντικειμένων. Για παράδειγμα, μπορείτε να δημιουργήσετε είδος MysqlDatabase. Ας υποθέσουμε ότι αυτός ο τύπος έχει δύο παραμέτρους μεταδεδομένων: name и namespace.

apiVersion: example.com/v1alpha1
kind: MysqlDatabase
metadata:
  name: foo
  namespace: bar

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

Παράδειγμα 3: Παρακολούθηση δικτύου συμπλέγματος

Όπως γνωρίζετε, η χρήση του ping είναι ο απλούστερος τρόπος παρακολούθησης ενός δικτύου. Σε αυτό το παράδειγμα θα δείξουμε πώς να εφαρμόσουμε μια τέτοια παρακολούθηση χρησιμοποιώντας το shell-operator.

Πρώτα απ 'όλα, θα χρειαστεί να εγγραφείτε σε κόμβους. Ο χειριστής φλοιού χρειάζεται το όνομα και τη διεύθυνση IP κάθε κόμβου. Με τη βοήθειά τους, θα κάνει ping σε αυτούς τους κόμβους.

configVersion: v1
kubernetes:
- name: nodes
  apiVersion: v1
  kind: Node
  jqFilter: |
    {
      name: .metadata.name,
      ip: (
       .status.addresses[] |  
        select(.type == "InternalIP") |
        .address
      )
    }
  group: main
  keepFullObjectsInMemory: false
  executeHookOnEvent: []
schedule:
- name: every_minute
  group: main
  crontab: "* * * * *"

Παράμετρος executeHookOnEvent: [] αποτρέπει την εκτέλεση του γάντζου ως απόκριση σε οποιοδήποτε συμβάν (δηλαδή ως απόκριση στην αλλαγή, προσθήκη, διαγραφή κόμβων). Ωστόσο, αυτός θα τρέξει (και ενημερώστε τη λίστα των κόμβων) Προγραμματισμένος - κάθε λεπτό, όπως ορίζεται από το γήπεδο schedule.

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

function __main__() {
  for i in $(seq 0 "$(context::jq -r '(.snapshots.nodes | length) - 1')"); do
    node_name="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.name')"
    node_ip="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.ip')"
    packets_lost=0
    if ! ping -c 1 "$node_ip" -t 1 ; then
      packets_lost=1
    fi
    cat >> "$METRICS_PATH" <<END
      {
        "name": "node_packets_lost",
        "add": $packets_lost,
        "labels": {
          "node": "$node_name"
        }
      }
END
  done
}

Επαναλαμβάνουμε τη λίστα των κόμβων, παίρνουμε τα ονόματα και τις διευθύνσεις IP τους, τους κάνουμε ping και στέλνουμε τα αποτελέσματα στον Προμηθέα. Ο χειριστής της Shell μπορεί να εξάγει μετρήσεις στον Prometheus, αποθηκεύοντάς τα σε ένα αρχείο που βρίσκεται σύμφωνα με τη διαδρομή που καθορίζεται στη μεταβλητή περιβάλλοντος $METRICS_PATH.

Εδώ μπορείτε να δημιουργήσετε έναν χειριστή για απλή παρακολούθηση δικτύου σε ένα σύμπλεγμα.

Μηχανισμός ουράς

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

• Τι συμβαίνει αν, ταυτόχρονα, συμβεί κάτι στο σύμπλεγμα; ένα ακόμα Εκδήλωση?
• Ο χειριστής του κελύφους θα εκτελέσει άλλη παρουσία του γάντζου;
• Τι θα συμβεί αν, ας πούμε, συμβούν πέντε γεγονότα στο σύμπλεγμα ταυτόχρονα;
• Ο χειριστής του κελύφους θα τα επεξεργάζεται παράλληλα;
• Τι γίνεται με τους πόρους που καταναλώνονται, όπως η μνήμη και η CPU;

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

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

Επίσης αυτά τα γεγονότα μπορούν να συνδυαστούν σε ένα μεγάλο. Η παράμετρος είναι υπεύθυνη για αυτό group στη διαμόρφωση βιβλιοδεσίας.

Μπορείτε να δημιουργήσετε οποιονδήποτε αριθμό ουρών/αγκίστρων και τους διάφορους συνδυασμούς τους. Για παράδειγμα, μια ουρά μπορεί να λειτουργήσει με δύο άγκιστρα ή το αντίστροφο.

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

Συμπέρασμα

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

Λεπτομερείς πληροφορίες για τον χειριστή του κελύφους, καθώς και ένα γρήγορο σεμινάριο για τον τρόπο χρήσης του, είναι διαθέσιμες στο αντίστοιχο αποθετήρια στο GitHub. Μη διστάσετε να επικοινωνήσετε μαζί μας με ερωτήσεις: μπορείτε να τις συζητήσετε σε ειδικό Ομάδα Telegram (στα ρωσικά) ή σε αυτό το φόρουμ (Στα Αγγλικά).

Και αν σας άρεσε, χαιρόμαστε πάντα να βλέπουμε νέα τεύχη/PR/αστέρια στο GitHub, όπου, παρεμπιπτόντως, μπορείτε να βρείτε άλλα ενδιαφέροντα έργα. Ανάμεσά τους αξίζει να τονίσουμε addon-operator, που είναι ο μεγάλος αδερφός του χειριστή του κοχυλιού. Αυτό το βοηθητικό πρόγραμμα χρησιμοποιεί διαγράμματα Helm για την εγκατάσταση πρόσθετων, μπορεί να παρέχει ενημερώσεις και να παρακολουθεί διάφορες παραμέτρους/τιμές γραφημάτων, ελέγχει τη διαδικασία εγκατάστασης των γραφημάτων και μπορεί επίσης να τα τροποποιήσει ως απόκριση σε συμβάντα στο σύμπλεγμα.

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

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

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

PS

Διαβάστε επίσης στο blog μας:

• «Εύκολη δημιουργία χειριστών Kubernetes με shell-operator: πρόοδος του έργου κατά τη διάρκεια του έτους"?
• «Παρουσίαση του shell-operator: η δημιουργία τελεστών για το Kubernetes μόλις έγινε ευκολότερη"?
• «Είναι εύκολο και βολικό να προετοιμάσετε ένα σύμπλεγμα Kubernetes; Ανακοινώνουμε τον χειριστή πρόσθετων"?
• «Επέκταση και συμπλήρωση του Kubernetes» (επισκόπηση και αναφορά βίντεο).

Πηγή: www.habr.com