Knative - k8s-ზე დაფუძნებული პლატფორმა როგორც სერვისი სერვერის გარეშე

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

თუმცა, მომხმარებელმა ჯერ კიდევ უნდა მიიღოს დეტალური გადაწყვეტილებები იმის შესახებ, თუ როგორ განათავსოს, დააკონფიგურიროს, მართოს და გააფართოოს აპლიკაციები. აპლიკაციის მასშტაბირების, დაცვისა და მოძრაობის ნაკადის საკითხები რჩება მომხმარებლის შეხედულებისამებრ. ეს განასხვავებს Kubernetes-ს ჩვეულებრივი პლატფორმებისგან, როგორც სერვისისგან (PaaS), როგორიცაა Cloud Foundry და Heroku.

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

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

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

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

შედეგად, ჩვენ ვხედავთ Kubernetes-ის უამრავ ნაგებობას, ასევე მასპინძელ კომპანიებს, რომლებიც ცდილობენ შექმნან PaaS Kubernetes-ისთვის, როგორიცაა OpenShift და Rancher. მზარდი Kube-PaaS ბაზრის ფონზე, Knative, რომელიც დაარსდა 2018 წლის ივლისში Google-ისა და Pivotal-ის მიერ, შემოდის რინგზე.

Knative იყო Google-ისა და Pivotal-ის თანამშრომლობა, სხვა კომპანიების მცირე დახმარებით, როგორიცაა IBM, RedHat და Solo.im. ის მსგავს PaaS-ს სთავაზობს Kubernetes-ს უმაღლეს დონეზე მხარდაჭერით სერვერის გარეშე გამოთვლებზე დაფუძნებული აპლიკაციებისთვის. Kubernetes build-ებისგან განსხვავებით, Knative დაინსტალირებულია როგორც დანამატი ნებისმიერ თავსებადი Kubernetes კლასტერზე და კონფიგურირებულია მომხმარებლის რესურსებით.

რა არის Knative?

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

Knative შედგება კონტროლერების ნაკრებისგან, რომლებიც დამონტაჟებულია Kubernetes-ის ნებისმიერ კლასტერში და უზრუნველყოფს შემდეგ შესაძლებლობებს:

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

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

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

თავად Knative დამოკიდებულია თავსებადი შესასვლელი კონტროლერის დაყენებაზე. წერის დროს ეს სტატია მხარდაჭერილია Gloo API Gateway и ისტიო სერვისის ბადე. ის დააკონფიგურირებს ხელმისაწვდომ შეღწევას, რათა გადაიყვანოს ტრაფიკი Knative-ის მიერ მართულ აპლიკაციებში.

Istio Service Mesh შეიძლება იყოს დიდი დამოკიდებულება Knative მომხმარებლებისთვის, რომლებსაც სურთ სცადონ ის Istio მართვის პანელის დაყენების გარეშე, რადგან Knative დამოკიდებულია მხოლოდ კარიბჭეზე.

ამ მიზეზით, მომხმარებელთა უმეტესობა უპირატესობას ანიჭებს Gloo-ს, როგორც Knative-ის კარიბჭეს, რომელიც უზრუნველყოფს Istio-ს მსგავსი შესაძლებლობების კომპლექტს (მხოლოდ Knative-ის გამოყენების მიზნით), ამასთან, ასევე იყენებს მნიშვნელოვნად ნაკლებ რესურსებს და აქვს დაბალი ოპერაციული ხარჯები.

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

kubectl get namespace
NAME          STATUS   AGE
default       Active   21h
kube-public   Active   21h
kube-system   Active   21h

დავიწყოთ Knative-ისა და Gloo-ს ინსტალაცია. ეს შეიძლება გაკეთდეს ნებისმიერი თანმიმდევრობით:

# ставим Knative-Serving
kubectl apply -f 
 https://github.com/knative/serving/releases/download/v0.8.0/serving-core.yaml
namespace/knative-serving created
# ...
# ставим Gloo
kubectl apply -f 
  https://github.com/solo-io/gloo/releases/download/v0.18.22/gloo-knative.yaml
namespace/gloo-system created
# ...

ჩვენ ვამოწმებთ, რომ ყველა პოდი არის „გაშვებული“ სტატუსში:

kubectl get pod -n knative-serving
NAME                              READY   STATUS    RESTARTS   AGE
activator-5dd55958cc-fkp7r        1/1     Running   0          7m32s
autoscaler-fd66459b7-7d5s2        1/1     Running   0          7m31s
autoscaler-hpa-85b5667df4-mdjch   1/1     Running   0          7m32s
controller-85c8bb7ffd-nj9cs       1/1     Running   0          7m29s
webhook-5bd79b5c8b-7czrm          1/1     Running   0          7m29s
kubectl get pod -n gloo-system
NAME                                      READY   STATUS    RESTARTS   AGE
discovery-69548c8475-fvh7q                1/1     Running   0          44s
gloo-5b6954d7c7-7rfk9                     1/1     Running   0          45s
ingress-6c46cdf6f6-jwj7m                  1/1     Running   0          44s
knative-external-proxy-7dd7665869-x9xkg   1/1     Running   0          44s
knative-internal-proxy-7775476875-9xvdg   1/1     Running   0          44s

Gloo მზად არის მარშრუტიზაციისთვის, მოდით შევქმნათ Knative სერვისის ავტომატური მასშტაბირება (მოდით დავარქვათ მას kservice) და მივმართოთ ტრაფიკს მასზე.

Knative სერვისები იძლევა უფრო მარტივ გზას Kubernetes-ში აპლიკაციების მიწოდებისთვის, ვიდრე ჩვეულებრივი Deployment+Service+Ingress მოდელი. ჩვენ ვიმუშავებთ ამ მაგალითზე:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
 name: helloworld-go
 namespace: default
spec:
 template:
   spec:
     containers:
       - image: gcr.io/knative-samples/helloworld-go
         env:
           - name: TARGET
             Value: Knative user

მე დავაკოპირე ეს ფაილში, შემდეგ მივმართე ჩემს Kubernetes კლასტერს ამ გზით:

kubectl apply -f ksvc.yaml -n default

ჩვენ შეგვიძლია ვნახოთ Knative-ის მიერ შექმნილი რესურსები კლასტერში ჩვენი 'helloworld-go'-ის მიწოდების შემდეგ ქსსერვისი:

kubectl get pod -n default
NAME                                              READY   STATUS    RESTARTS   AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8   2/2     Running   0          68s

პოდი ჩვენი 'helloworld-go' იმიჯით იხსნება, როდესაც kservice განლაგებულია. თუ ტრაფიკი არ არის, პოდების რაოდენობა ნულამდე შემცირდება. და პირიქით, თუ ერთდროული მოთხოვნების რაოდენობა გადააჭარბებს გარკვეულ კონფიგურირებად ზღურბლს, გაიზრდება პოდების რაოდენობა.

kubectl get ingresses.networking.internal.knative.dev -n default
NAME            READY   REASON
helloworld-go   True

Knative აკონფიგურირებს მის შეღწევას შიდა Knative API-ში სპეციალური „შესვლის“ რესურსის გამოყენებით. Gloo იყენებს ამ API-ს, როგორც მის კონფიგურაციას PaaS-ის მსგავსი ფუნქციების უზრუნველსაყოფად, მათ შორის ლურჯი-მწვანე განლაგების მოდელის, ავტომატური TLS აღსრულების, დროის ამოწურვისა და სხვა გაფართოებული მარშრუტიზაციის ფუნქციების ჩათვლით.

გარკვეული პერიოდის შემდეგ, ჩვენ ვხედავთ, რომ ჩვენი რგოლები გაქრა (რადგან არ იყო შემომავალი ტრაფიკი):

kubectl get pod -n default

No resources found.
kubectl get deployment -n default
NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

საბოლოოდ ჩვენ ვეცდებით მათ მივაღწიოთ. თქვენ შეგიძლიათ მარტივად და მარტივად მიიღოთ URL Knative Proxy-ის გამოყენებით glooctl:

glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80

დაყენების გარეშე glooctl მისამართი და პორტი შეგიძლიათ ნახოთ kube სერვისში:

kubectl get svc -n gloo-system knative-external-proxy
NAME                     TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      AGE
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

მოდით გავუშვათ გარკვეული მონაცემები cURL-ის გამოყენებით:

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!

Knative უზრუნველყოფს თითქმის PaaS-ს დეველოპერებისთვის ყუთის მიღმა Kubernetes-ის თავზე Gloo-ს მაღალი ხარისხის API კარიბჭის გამოყენებით. ამ პოსტმა მხოლოდ გაკაწრა Knative-ის პერსონალიზაციის ვრცელი ვარიანტები და დამატებითი ფუნქციები. იგივე Gloo!

იმისდა მიუხედავად, რომ Knative ჯერ კიდევ ახალგაზრდა პროექტია, მისი გუნდი ავრცელებს ახალ ვერსიებს ყოველ ექვს კვირაში ერთხელ და დაიწყო მოწინავე ფუნქციების დანერგვა, როგორიცაა ავტომატური TLS განლაგება, მართვის პანელის ავტომატური მასშტაბირება. არსებობს კარგი შანსი, რომ მრავალ ღრუბლოვან კომპანიას შორის თანამშრომლობის შედეგად და როგორც Google-ის ახალი Cloud Run შეთავაზების საფუძველი, Knative შეიძლება გახდეს უსერვერო გამოთვლისა და PaaS-ის ძირითადი ვარიანტი Kubernetes-ზე. მიჰყევით სიახლეებს!

SouthBridge-ის რედაქტორებიდან
მკითხველთა მოსაზრებები ჩვენთვის მნიშვნელოვანია, ამიტომ გთხოვთ, მიიღოთ მონაწილეობა მოკლე გამოკითხვაში, რომელიც დაკავშირებულია მომავალ სტატიებთან Knative-ის, Kubernetes-ის, სერვერის გარეშე გამოთვლის შესახებ:

გამოკითხვაში მონაწილეობა შეუძლიათ მხოლოდ დარეგისტრირებულ მომხმარებლებს. Შებრძანდითგთხოვთ

უნდა გავაგრძელო სტატიების და სახელმძღვანელოების წერა Knative და სერვერის გარეშე გამოთვლის შესახებ?

• Დიახ, თუ შეიძლება.

• Არა გმადლობთ.

მისცა ხმა 28 მომხმარებელმა. 4 მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com