🥇Knative — k8s հիման վրա ծառայություն որպես պլատֆորմ serverless աջակցությամբ

Կոնտեյներների իրացման համար գերիշխող հարթակը անկասկած Kubernetes-ն է: Այն հնարավորություն է տալիս կառավարելու כמעט ամեն բան, օգտագործելով իր API-ները և օգտագործողի վերահսկիչները, որոնք ընդլայնում են դրա API-ն օգտագործող ռեսուրսների միջոցով:

Այդուհանդերձ, օգտագործողը դեռ պետք է մանրամասնորեն որոշումներ ընդունի, թե ինչպես կոնկրետ իրացնել, կարգաբերել, կառավարել և մասշտաբավորել հավելվածները: Մարդու վրա է թողնված հավելվածի մասշտաբավորման, անվտանգության և տրաֆիկի անցման հարցերը: Այսպիսով, Kubernetes-ը տարբերակում է սովորական «հարթակ որպես ծառայություն» (PaaS) օրինակ՝ Cloud Foundry և Heroku:

Հարթակները ունեն պարզեցված օգտագործողի ուշադրություն, կենտրոնացած են հավելվածների մշակողների վրա, որոնք ավելի հաճախ զբաղվում են առանձին հավելվածների կարգավորմամբ: Անսահմանը, իրացումը և մետրանքները թափանցիկորեն կառավարվում են PaaS-ի հիմանական համակարգով:

Երաշխիքային գործիրէց’ny կրոնը ընդունում է PaaS-ը, ստեղծելով օգտագործողի կոնտեյների պատկեր, նրա գործադրումը, նոր երթուղու և DNS ենթատեքստի կարգավորումը՝ ներգարացվող տրաֆիկի համար: Այս ամենը իրականացնում է հրամանով: git push.

Kubernetes-ում (ժպիտով) տրամադրված են միայն հիմնական բլոկները նման հարթակների համար,Providing the community with the ability to do this work themselves. As Kelsey Hightower-ը ասաց:

Kubernetes-ը հարթակ է՝ հարթակներ ստեղծելու համար: Լավագույն մեկնարկային դիրք, բայց ոչ ավարտ:

Այն պատճառով մենք տեսնում ենք Kubernetes-ի մի շարք հավաքների, ինչպես նաև հյուրընկալողների, որոնք փորձում են ստեղծել PaaS Kubernetes-ի համար, օրինակ՝ OpenShift և Rancher: Վաճառքի աճող շուկայում Kube-PaaS-ին չորեքշաբթի է ելնում Knative-ը, ստեղծված է 2018 թվականի հուլիսին Google-ի և Pivotal-ի կողմից:

Knative-ը ստեղծվել է Google-ի և Pivotal-ի համատեղ աշխատանքի արդյունքում, փոքր աղբյուրով այլ ընկերությունների, օրինակ՝ IBM, RedHat և Solo.im: Այն առաջարկում է նմանատիպ PaaS բաներ Kubernetes-ի համար՝ առաջատար աջակցությամբ առանցսերվերային հաշվողական հավելվածների համար: Kubernet-ի հավաքների հակառակությամբ, Knative-ը տեղադրվում է որպես հավելում ցանկացած համատեղելի Kubernetes կլաստերներում և կարգավորվում է օգտագործողի ռեսուրսների միջոցով:

Ի՞նչ է Knative-ը:

Knative-ն նկարագրվում է որպես «Kubernetes-ի վրա հիմնված հարթակ, աշխատասպասարկման բեռների ներգործության և կառավարելու համար ժամանակակից առանցսերվերային հաշվողական ծառայությունների միջոցով»: Knative-ն՝ նմանությամբ այդ հարթակ, ակտիվորեն ավտոմատապես մասշտաբավորում է կոնտեյները՝ համաչափ HTTP-ների մեկանգամյա հարցումներին: Անհանգիստ ծառայությունները վերջում մասշտաբավորվում են զրոյին, ապահովելով պահանջով մասշտաբավորում առանցսերվերային հաշվելու ոճով:

Knative-ը բաղկացած է մի շարք վերահսկիչներից, որոնք տեղադրվում են ցանկացած Kubernetes կլաստերում և ապահովում են հետևյալ հնարավորությունները:

կոնտեյներով հաստոուն անել ապարատներից (մատակարարվում է բաղադրիչով Build),
մուտքային տրաֆիկի մուտք գործելու հնարավորություն տալը (ապահովում է բաղադրիչը Servicing),
հաճախակի կայունություն ապահովել և ավտոմատ կերպով բացվել ըստ պահանջի (այդպես էլ ապահովում է բաղադրիչը, Servicing),
իրավիճակային գործոնները, որոնք հանգեցնում են ծրագրերի գործարկմանը (ապահովում է բաղադրիչը Eventing).

Հիմնական բաղադրիչը Servicing-ն է, որը ապահովում է մատակարարում, ավտոմատ մասշտաբացում և տրաֆիկի վերահսկում իմպրովիզացված ծրագրերի համար: Knative-ի տեղադրումից հետո օգտագործողները շարունակում են ամբողջական մուտքը Kubernetes API-ին, որը թույլ է տալիս կառավարել ծրագրերը: ընդամենը շարքից, ինչպես նաև ծառայում է Knative ծառայությունների հեռուստատեսային վճիռներին, աշխատելով այդ ծառայությունների օգտագործած API-ի նույն պլաստիկների հետ (մոդուլներ, ծառայություններ և այլն):

Servicing-ով ավտոմատացում է իրականացվում blue-green տրաֆիկի routed-ին, ապահովելով հին ու նոր տարբերակների միջև տրաֆիկի բաժանում՝ երբ օգտվողը տրամադրում է ծրագրի նորացված տարբերակը:

Knative-ն կախվածություն ունի համապատասխան ingress վերահսկիչի տեղադրումից: Այս փաստաթղթի մշակման պահին աջակցության տակ են Gloo API Gateway և Istio Service Mesh. Այն կարգավորում է հասանելի ingress տրաֆիկի routed-ման համար Knative-ի միջոցով կառավարվող ծրագրերին:

Istio Service Mesh-ը կարող է հանդիսանալ ավելի մեծ կախվածություն Knative օգտագործողների համար, որոնք ցանկանում են փորձարկել այն առանց Istio կառավարման տախտակն իրագործելու, քանի որ Knative-ն կախված է միայն շիլից:

Սա պատճառով, մեծ մասը օգտագործողների Gloo-ն նախընտրում են որպես Knative-ի շիլ, որը առաջարկում է Իստիոի հետ համեմատելի հնարավորությունների նույն հավաքածուն (իշխանության միակ նպատակ - 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
# ...

Տեսնենք, թե բոլոր Pods-ը «Running» վիճակում են.

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-ն պատրաստ է routed-մանը, եկեք ստեղծենք Knative-ի ավտոմատ կերպով մասշտաբվող ծառայություն (որն անվանում ենք kservice) և Richtung տրաֆիկ:

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' փոխանցումից հետո: kservice:

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

Մեր 'helloworld-go' պատկերով Pod-ը մեկնարկվում է kservice-ի բացման ժամանակ։ Եթե տրանֆիկ չլինի, pod-ների թիվը կրճատվի զրոյի։ Իսկ հակառակը, եթե միաժամանակյա հարցումների թիվը գերազանցի որոշակի կարգավորելի եզր, pod-ների թիվը կաճի։

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

Knative-ը կարգավորում է իր ingress-ը հատուկ 'ingress' ռեսուրսի միջոցով Knative-ի ներքին API-ում։ Gloo-ն վերցնում է այս API-ն որպես իր կարգավորումը՝ տրամադրելով PaaS-ին բնորոշ հատկությունները, այդ թվում՝ blue-green բացման մոդելը, ավտոմատ TLS կիրառումը, ժամանցները եւ այլ բարելավված ուղղղման հնարավորություններ։

Թեև որոշ ժամանակ անց մենք տեսնում ենք, որ մեր pod-երը անհետացել են (քանի որ բարեխոսող տրանֆիկ չի եղել):

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

Վերջապես, փորձենք հասնել նրանց։ Knative Proxy-ի URL ստանալու գործընթացը հեշտ և հանգիստ կարելի է անել՝ օգտագործելով 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-ի բացում, ավտոմատ չլուսավորող հսկողություն: Գոյություն ունի մեծ հավանականություն, որ բազմաթիվ Cloud ընկերություններին համագործակցելու արդյունքում, ինչպես նաև Google-ի Cloud Run նոր առաջարկի հիմք հանդիսանալով, Knative-ը կարող է դառնալ հիմնական տարբերակը ամպային հաշվողական համակարգերի և PaaS-ի կազմակերպման համար Kubernetes-ում: Օգտվեք վերջին նորություններին!

SouthBridge խմբագրությունից
Մեզ համար կարևոր է ընթերցողների կարծիքը, ուստի խնդրում ենք մասնակցել փոքր հարցմանը, որը կապված է Knative-ի, Kubernetes-ի, ամպային հաշվումների ապագա հոդվածների հետ:

Պատասխանելու համար պետք է գրանցված օգտվող լինել։ Մուտք, խնդրում եմ։