Σχετικά με την αυξανόμενη δημοτικότητα του Kubernetes

Γεια σου Χαμπρ!

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

Απολαύστε την ανάγνωση!

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

Τα κοντέινερ ξεκίνησαν ως ειδικός σχεδιασμός για την απομόνωση διαδικασιών στο Linux. τα εμπορευματοκιβώτια περιλαμβάνονται από το 2007 ομάδες, και από το 2002 – χώροι ονομάτων. Τα δοχεία σχεδιάστηκαν ακόμη καλύτερα από το 2008, όταν έγιναν διαθέσιμα LXC, και η Google ανέπτυξε τον δικό της εσωτερικό εταιρικό μηχανισμό που ονομάζεται Borg, όπου «όλη η εργασία γίνεται σε κοντέινερ». Από εδώ προχωράμε γρήγορα για το 2013, όταν πραγματοποιήθηκε η πρώτη κυκλοφορία του Docker και τα κοντέινερ έγιναν τελικά μια δημοφιλής μαζική λύση. Εκείνη την εποχή, το βασικό εργαλείο για την ενορχήστρωση κοντέινερ ήταν Μέσος, αν και δεν ήταν ιδιαίτερα δημοφιλής. Το Kubernetes κυκλοφόρησε για πρώτη φορά το 2015, μετά το οποίο αυτό το εργαλείο έγινε το de facto πρότυπο στον τομέα της ενορχήστρωσης κοντέινερ.

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

Υποδομή ως YAML

Στον κόσμο που πήγε από το Puppet και τον Chef στο Kubernetes, μία από τις μεγαλύτερες αλλαγές ήταν η μετάβαση από την «υποδομή ως κώδικας» στην «υποδομή ως δεδομένα»—συγκεκριμένα, όπως το YAML. Όλοι οι πόροι στο Kubernetes, που περιλαμβάνουν pods, διαμορφώσεις, αναπτυγμένες παρουσίες, τόμους κ.λπ., μπορούν εύκολα να περιγραφούν σε ένα αρχείο YAML. Για παράδειγμα:

apiVersion: v1
kind: Pod
metadata:
  name: site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80

Αυτή η προβολή διευκολύνει τους επαγγελματίες DevOps ή SRE να εκφράσουν πλήρως τον φόρτο εργασίας τους χωρίς να χρειάζεται να γράφουν κώδικα σε γλώσσες όπως η Python ή η Javascript.

Άλλα πλεονεκτήματα της οργάνωσης της υποδομής ως δεδομένων περιλαμβάνουν:

• Έλεγχος έκδοσης GitOps ή Git Operations. Αυτή η προσέγγιση σάς επιτρέπει να διατηρείτε όλα τα αρχεία YAML του Kubernetes σε αποθετήρια git, ώστε να μπορείτε να παρακολουθείτε ακριβώς πότε έγινε μια αλλαγή, ποιος την έκανε και τι ακριβώς άλλαξε. Αυτό αυξάνει τη διαφάνεια των λειτουργιών σε ολόκληρο τον οργανισμό και βελτιώνει τη λειτουργική αποτελεσματικότητα εξαλείφοντας την ασάφεια, ιδιαίτερα εκεί όπου οι εργαζόμενοι πρέπει να αναζητήσουν τους πόρους που χρειάζονται. Ταυτόχρονα, γίνεται ευκολότερη η αυτόματη πραγματοποίηση αλλαγών στους πόρους του Kubernetes με απλή συγχώνευση ενός αιτήματος έλξης.
• Επεκτασιμότητα. Όταν οι πόροι ορίζονται ως YAML, γίνεται εξαιρετικά εύκολο για τους χειριστές συμπλέγματος να αλλάξουν έναν ή δύο αριθμούς σε έναν πόρο Kubernetes, αλλάζοντας έτσι τον τρόπο κλιμάκωσής του. Το Kubernetes παρέχει έναν μηχανισμό για οριζόντια αυτόματη κλιμάκωση ομάδων, ο οποίος μπορεί να χρησιμοποιηθεί για να προσδιορίσει εύκολα ποιος είναι ο ελάχιστος και ο μέγιστος αριθμός ομάδων που απαιτούνται σε μια συγκεκριμένη διαμόρφωση ανάπτυξης για τη διαχείριση χαμηλών και υψηλών επιπέδων επισκεψιμότητας. Για παράδειγμα, εάν έχετε αναπτύξει μια διαμόρφωση που απαιτεί πρόσθετη χωρητικότητα λόγω μιας ξαφνικής αύξησης της κυκλοφορίας, τότε το maxReplicas μπορεί να αλλάξει από 10 σε 20:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp-deployment
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

• Ασφάλεια και διαχείριση. Το YAML είναι εξαιρετικό για την αξιολόγηση του τρόπου με τον οποίο αναπτύσσονται τα πράγματα στο Kubernetes. Για παράδειγμα, μια σημαντική ανησυχία για την ασφάλεια αφορά το εάν οι φόρτοι εργασίας σας εκτελούνται ως χρήστης που δεν είναι διαχειριστής. Σε αυτή την περίπτωση, μπορεί να χρειαστούμε εργαλεία όπως π.χ διαγωνισμός, εργαλείο επικύρωσης YAML/JSON, συν Open Policy Agent, ένα εργαλείο επικύρωσης πολιτικής για να διασφαλιστεί ότι το πλαίσιο SecurityContext Ο φόρτος εργασίας σας δεν επιτρέπει στο κοντέινερ να εκτελείται με δικαιώματα διαχειριστή. Εάν αυτό απαιτείται, οι χρήστες μπορούν να εφαρμόσουν μια απλή πολιτική rego, σαν αυτό:

package main

deny[msg] {
  input.kind = "Deployment"
  not input.spec.template.spec.securityContext.runAsNonRoot = true
  msg = "Containers must not run as root"
}

• Επιλογές για ενοποίηση με πάροχο cloud. Μία από τις πιο αξιοσημείωτες τάσεις στη σημερινή υψηλή τεχνολογία είναι η εκτέλεση φόρτου εργασίας σε δημόσιους παρόχους cloud. Χρησιμοποιώντας το στοιχείο παροχής cloud Το Kubernetes επιτρέπει σε οποιοδήποτε σύμπλεγμα να ενσωματωθεί με τον πάροχο cloud στον οποίο εκτελείται. Για παράδειγμα, εάν ένας χρήστης εκτελεί μια εφαρμογή στο Kubernetes σε AWS και θέλει να εκθέσει αυτήν την εφαρμογή μέσω μιας υπηρεσίας, ο πάροχος cloud βοηθάει αυτόματα στη δημιουργία της υπηρεσίας LoadBalancerπου θα παρέχει αυτόματα τον εξισορροπητή φορτίου Amazon Elastic Load Balancerγια να ανακατευθύνει την κυκλοφορία σε ομάδες εφαρμογών.

Επεκτασιμότητα

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

Για παράδειγμα, αν θέλουμε να ορίσουμε έναν πόρο CronTab, τότε μπορείτε να κάνετε κάτι σαν αυτό:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: crontabs.my.org
spec:
  group: my.org
  versions:
    - name: v1
      served: true
      storage: true
      Schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                  pattern: '^(d+|*)(/d+)?(s+(d+|*)(/d+)?){4}$'
                replicas:
                  type: integer
                  minimum: 1
                  maximum: 10
  scope: Namespaced
  names:
    plural: crontabs
    singular: crontab
    kind: CronTab
    shortNames:
    - ct

Αργότερα μπορούμε να δημιουργήσουμε έναν πόρο CronTab κάπως έτσι:

apiVersion: "my.org/v1"
kind: CronTab
metadata:
  name: my-cron-object
spec:
  cronSpec: "* * * * */5"
  image: my-cron-image
  replicas: 5

Μια άλλη επιλογή για επεκτασιμότητα στο Kubernetes είναι ότι ο προγραμματιστής μπορεί να γράψει τις δικές του δηλώσεις. Χειριστής είναι μια ειδική διαδικασία στο σύμπλεγμα Kubernetes που λειτουργεί σύμφωνα με το "κύκλωμα ελέγχου" Με τη βοήθεια ενός χειριστή, ο χρήστης μπορεί να αυτοματοποιήσει τη διαχείριση των CRD (προσαρμοσμένοι ορισμοί πόρων) ανταλλάσσοντας πληροφορίες με το Kubernetes API.

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

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

Αυτό δημιουργεί όλο τον κώδικα λέβητα για τον χειριστή σας, συμπεριλαμβανομένων των αρχείων YAML και του κώδικα Golang:

.
|____cmd
| |____manager
| | |____main.go
|____go.mod
|____deploy
| |____role.yaml
| |____role_binding.yaml
| |____service_account.yaml
| |____operator.yaml
|____tools.go
|____go.sum
|____.gitignore
|____version
| |____version.go
|____build
| |____bin
| | |____user_setup
| | |____entrypoint
| |____Dockerfile
|____pkg
| |____apis
| | |____apis.go
| |____controller
| | |____controller.go

Στη συνέχεια, μπορείτε να προσθέσετε τα απαιτούμενα API και ελεγκτή, ως εξής:

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

Στη συνέχεια, τέλος, συναρμολογήστε τον χειριστή και στείλτε τον στο μητρώο του κοντέινερ σας:

$ operator-sdk build your.container.registry/youruser/myapp-operator

Εάν ο προγραμματιστής θέλει ακόμη περισσότερο έλεγχο, ο κωδικός του boilerplate στα αρχεία Go μπορεί να αλλάξει. Για παράδειγμα, για να τροποποιήσετε τις ιδιαιτερότητες του ελεγκτή, μπορείτε να κάνετε αλλαγές στο αρχείο controller.go.

Άλλο ένα έργο ΠΑΝΤΟΥ, σας επιτρέπει να δημιουργείτε δηλώσεις χρησιμοποιώντας μόνο δηλωτικά αρχεία YAML. Για παράδειγμα, ένας τελεστής για τον Apache Kafka θα οριστεί κατά προσέγγιση έτσι. Με αυτό, μπορείτε να εγκαταστήσετε ένα σύμπλεγμα Kafka στην κορυφή του Kubernetes με μερικές μόνο εντολές:

$ kubectl kudo install zookeeper
$ kubectl kudo install kafka

Και μετά ρυθμίστε το με μια άλλη εντολή:

$ kubectl kudo install kafka --instance=my-kafka-name 
            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 
            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m 
            -p BROKER_COUNT=5 -p BROKER_MEM=4096m 
            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 
            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

Καινοτομία

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

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

Κοινότητα

Μια άλλη σημαντική πτυχή της δημοτικότητας της Kubernetes είναι η δύναμη της κοινότητάς της. Το 2015, όταν έφτασε στην έκδοση 1.0, η Kubernetes χρηματοδοτήθηκε από Ίδρυμα Cloud Native Computing.

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

Το Ίδρυμα Cloud Native φιλοξενεί επίσης το CloudNativeCon/KubeCon, το οποίο, τη στιγμή που γράφονται αυτές οι γραμμές, είναι το μεγαλύτερο συνέδριο ανοιχτού κώδικα στον κόσμο. Συνήθως διεξάγεται τρεις φορές το χρόνο, συγκεντρώνει χιλιάδες επαγγελματίες που θέλουν να βελτιώσουν το Kubernetes και το οικοσύστημά του, καθώς και να μάθουν νέα χαρακτηριστικά που εμφανίζονται κάθε τρεις μήνες.

Επιπλέον, το Cloud Native Foundation έχει Επιτροπή Τεχνικής Εποπτείας, το οποίο, μαζί με τα SIG, εξετάζει νέα και υπάρχοντα Έργα κεφάλαια που επικεντρώνονται στο οικοσύστημα cloud. Τα περισσότερα από αυτά τα έργα βοηθούν στη βελτίωση των δυνατοτήτων του Kubernetes.

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

Το μέλλον

Μία από τις κύριες προκλήσεις που θα πρέπει να αντιμετωπίσουν οι προγραμματιστές στο μέλλον είναι η δυνατότητα εστίασης στις λεπτομέρειες του ίδιου του κώδικα και όχι στην υποδομή στην οποία εκτελείται. Ανταποκρίνεται σε αυτές τις τάσεις αρχιτεκτονικό παράδειγμα χωρίς διακομιστή, που είναι ένα από τα κορυφαία σήμερα. Υπάρχουν ήδη προηγμένα πλαίσια, π.χ. Γνωστικό и OpenFaas, τα οποία χρησιμοποιούν το Kubernetes για να αφαιρέσουν την υποδομή από τον προγραμματιστή.

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

Πηγή: www.habr.com