Kubernetes-ის მზარდი პოპულარობის შესახებ

ჰეი ჰაბრ!

ზაფხულის ბოლოს გვინდა შეგახსენოთ, რომ ვაგრძელებთ თემაზე მუშაობას კუბერნეტები და გადაწყვიტა გამოექვეყნებინა სტატია Stackoverflow-დან, რომელიც აჩვენებს ამ პროექტში არსებულ მდგომარეობას ივნისის დასაწყისში.

ისიამოვნეთ კითხვა!

ამ სტატიის დაწერის დროს კუბერნეტების ასაკი დაახლ. ექვსი წლისდა ბოლო ორი წლის განმავლობაში მისი პოპულარობა იმდენად გაიზარდა, რომ ის მუდმივად არის რეიტინგში ყველაზე საყვარელი პლატფორმები. კუბერნეტესი წელს მესამე ადგილზეა. შეგახსენებთ: Kubernetes არის პლატფორმა, რომელიც შექმნილია კონტეინერირებული სამუშაო დატვირთვის გასაშვებად და ორკესტრირებისთვის.

კონტეინერები დაიწყო როგორც სპეციალური დიზაინი ლინუქსის პროცესების იზოლირებისთვის; კონტეინერები შედის 2007 წლიდან ჯგუფები, ხოლო 2002 წლიდან – სახელთა სივრცეები. კონტეინერები კიდევ უფრო უკეთესი იყო 2008 წლისთვის, როდესაც ის ხელმისაწვდომი გახდა LXCდა Google-მა შეიმუშავა საკუთარი შიდა კორპორატიული მექანიზმი ე.წ ბორგე, სადაც „ყველა სამუშაო კეთდება კონტეინერებში“. აქედან ჩვენ სწრაფად მივიწევთ 2013 წლამდე, როდესაც შედგა Docker-ის პირველი გამოშვება და კონტეინერები საბოლოოდ გახდა პოპულარული მასობრივი გადაწყვეტა. იმ დროს კონტეინერის ორკესტრირების მთავარი ინსტრუმენტი იყო მესოსმიუხედავად იმისა, რომ ის არ იყო ძალიან პოპულარული. Kubernetes პირველად გამოვიდა 2015 წელს, რის შემდეგაც ეს ინსტრუმენტი გახდა დე ფაქტო სტანდარტი კონტეინერების ორკესტრირების სფეროში.

იმისათვის, რომ გავიგოთ, რატომ არის Kubernetes ასე პოპულარული, შევეცადოთ ვუპასუხოთ რამდენიმე კითხვას. ბოლოს როდის შეძლეს დეველოპერებმა შეთანხმდნენ, როგორ განათავსონ აპლიკაციები წარმოებაში? რამდენ დეველოპერს იცნობთ, რომლებიც იყენებენ ინსტრუმენტებს, რადგან ისინი მოწოდებულია ყუთში? რამდენი ღრუბლის ადმინისტრატორია დღეს, რომლებსაც არ ესმით როგორ მუშაობს აპლიკაციები? ამ კითხვებზე პასუხებს ამ სტატიაში განვიხილავთ.

ინფრასტრუქტურა, როგორც YAML

მსოფლიოში, რომელიც თოჯინებისა და შეფ-მზარეულიდან Kubernetes-მდე გადავიდა, ერთ-ერთი ყველაზე დიდი ცვლილება იყო გადასვლა „ინფრასტრუქტურიდან როგორც კოდიდან“ „ინფრასტრუქტურა, როგორც მონაცემები“ - კონკრეტულად, როგორიცაა YAML. Kubernetes-ის ყველა რესურსი, რომელიც მოიცავს პოდებს, კონფიგურაციებს, განლაგებულ ინსტანციებს, ტომებს და ა.შ., მარტივად შეიძლება აღწერილი იყოს 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 ოპერაციების ვერსიის კონტროლი. ეს მიდგომა საშუალებას გაძლევთ შეინახოთ ყველა Kubernetes YAML ფაილი 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 ვალიდატორი, პლუს გახსენით პოლიტიკის აგენტი, პოლიტიკის ვალიდატორი, რომელიც უზრუნველყოფს კონტექსტს უსაფრთხოების კონტექსტი თქვენი სამუშაო დატვირთვა არ იძლევა კონტეინერს ადმინისტრატორის პრივილეგიებით გაშვების საშუალებას. თუ ეს საჭიროა, მომხმარებლებს შეუძლიათ გამოიყენონ მარტივი პოლიტიკა რეგო, ამგვარად:

package main

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

• ღრუბლოვან პროვაიდერთან ინტეგრაციის ვარიანტები. დღევანდელი მაღალი ტექნოლოგიების ერთ-ერთი ყველაზე თვალსაჩინო ტენდენცია არის სამუშაო დატვირთვის გაშვება საჯარო ღრუბლოვან პროვაიდერებზე. კომპონენტის გამოყენება ღრუბლოვანი პროვაიდერი Kubernetes საშუალებას აძლევს ნებისმიერ კლასტერს ინტეგრირდეს ღრუბლოვან პროვაიდერთან, რომელზეც ის მუშაობს. მაგალითად, თუ მომხმარებელი აწარმოებს აპლიკაციას Kubernetes-ში AWS-ზე და სურს ამ აპლიკაციის გამჟღავნება სერვისის საშუალებით, ღრუბლოვანი პროვაიდერი ეხმარება ავტომატურად შექმნას სერვისი. LoadBalancerრომელიც ავტომატურად უზრუნველყოფს დატვირთვის ბალანსერს ამაზონის ელასტიური დატვირთვის ბალანსერიტრეფიკის გადამისამართება აპლიკაციის პოდებზე.

გაფართოებადობა

Kubernetes ძალიან გაფართოებულია და დეველოპერებს უყვართ იგი. არსებობს ხელმისაწვდომი რესურსების ნაკრები, როგორიცაა პოდები, განლაგება, 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-ში არის ის, რომ დეველოპერს შეუძლია დაწეროს საკუთარი განცხადებები. ოპერატორი არის სპეციალური პროცესი კუბერნეტის კლასტერში, რომელიც მუშაობს "საკონტროლო წრე" ოპერატორის დახმარებით მომხმარებელს შეუძლია ავტომატიზირება მოახდინოს 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

თუ დეველოპერს კიდევ მეტი კონტროლი სურს, Go ფაილებში boilerplate კოდი შეიძლება შეიცვალოს. მაგალითად, კონტროლერის სპეციფიკის შესაცვლელად, შეგიძლიათ შეიტანოთ ცვლილებები ფაილში controller.go.

კიდევ ერთი პროექტი ყველგან, საშუალებას გაძლევთ შექმნათ განცხადებები მხოლოდ დეკლარაციული YAML ფაილების გამოყენებით. მაგალითად, Apache 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-ზე.

ახალი შესაძლებლობები საშუალებას გაძლევთ უფრო მოქნილად მოაწყოთ ოპერაციები სხვადასხვა დატვირთვაზე. გარდა ამისა, პროგრამისტები სარგებლობენ უფრო დიდი კონტროლით აპლიკაციების უშუალოდ წარმოებაში განლაგებისას.

Community

Kubernetes-ის პოპულარობის კიდევ ერთი მთავარი ასპექტია მისი საზოგადოების სიძლიერე. 2015 წელს, 1.0 ვერსიის მიღწევის შემდეგ, Kubernetes დაფინანსებული იყო Cloud Native Computing Foundation.

ასევე არის სხვადასხვა თემები GIS (სპეციალური ინტერესთა ჯგუფები) ორიენტირებულია Kubernetes-ის სხვადასხვა სფეროზე მუშაობაზე, როგორც პროექტი ვითარდება. ეს ჯგუფები მუდმივად ამატებენ ახალ ფუნქციებს, რაც Kubernetes-თან მუშაობას უფრო მოსახერხებელს და მოსახერხებელს ხდის.

Cloud Native Foundation ასევე მასპინძლობს CloudNativeCon/KubeCon-ს, რომელიც წერის მომენტისთვის არის მსოფლიოში ყველაზე დიდი ღია კოდის კონფერენცია. როგორც წესი, წელიწადში სამჯერ ტარდება, ის აერთიანებს ათასობით პროფესიონალს, რომელთაც სურთ Kubernetes-ის და მისი ეკოსისტემის გაუმჯობესება, ასევე ახალი ფუნქციების სწავლა, რომლებიც ყოველ სამ თვეში ჩნდება.

უფრო მეტიც, Cloud Native Foundation-ს აქვს ტექნიკური ზედამხედველობის კომიტეტი, რომელიც SIG-ებთან ერთად განიხილავს ახალს და არსებულს პროექტები ღრუბლის ეკოსისტემაზე ორიენტირებული სახსრები. ამ პროექტების უმეტესობა ხელს უწყობს Kubernetes-ის ძლიერი მხარეების გაუმჯობესებას.

და ბოლოს, მე მჯერა, რომ Kubernetes არ იქნებოდა ისეთი წარმატებული, როგორც ეს არის მთელი საზოგადოების შეგნებული ძალისხმევის გარეშე, სადაც ხალხი ერთად იყრის თავს, მაგრამ ამავდროულად მიესალმება ახალწვეულებს.

მომავალი

ერთ-ერთი მთავარი გამოწვევა, რომელთანაც დეველოპერებს მომავალში მოუწევთ გამკლავება, არის თვით კოდის დეტალებზე ფოკუსირების შესაძლებლობა და არა ინფრასტრუქტურაზე, რომელშიც ის მუშაობს. ის აკმაყოფილებს ამ ტენდენციებს სერვერის გარეშე არქიტექტურული პარადიგმა, რომელიც დღეს ერთ-ერთი წამყვანია. გაფართოებული ჩარჩოები უკვე არსებობს, მაგ. ნატიფი и OpenFaas, რომელიც იყენებს Kubernetes-ს დეველოპერისგან ინფრასტრუქტურის აბსტრაქციისთვის.

ამ სტატიაში ჩვენ მხოლოდ კუბერნეტესის ამჟამინდელი მდგომარეობის ზედაპირი გავფხეკით - ფაქტობრივად, ეს მხოლოდ აისბერგის მწვერვალია. Kubernetes მომხმარებლებს აქვთ სხვა მრავალი რესურსი, შესაძლებლობები და კონფიგურაცია.

წყარო: www.habr.com