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-ն ինքնին կախված է համատեղելի մուտքի վերահսկիչի տեղադրումից: Գրելու պահին այս հոդվածը աջակցվում է
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
# ...
Մենք ստուգում ենք, որ բոլոր Pods-ը գտնվում են «Գործող» կարգավիճակում.
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» առաքումից հետո: 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-ը տեղակայվում է: Եթե երթևեկություն չլինի, պատիճների քանակը կզրոյի: Եվ հակառակը, եթե միաժամանակյա հարցումների քանակը գերազանցի որոշակի կարգավորվող շեմը, ապա կաճեցվի պատիճների թիվը:
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go True
Knative-ը կարգավորում է իր ներթափանցումը, օգտագործելով հատուկ «ingress» ռեսուրսը ներքին 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
Վերջապես մենք կփորձենք հասնել նրանց։ Դուք կարող եք հեշտությամբ և հեշտությամբ ստանալ 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-ի ավտոմատ տեղակայումը, կառավարման վահանակի ավտոմատ մասշտաբը: Մեծ հավանականություն կա, որ բազմաթիվ ամպային ընկերությունների միջև համագործակցության արդյունքում և որպես Google-ի նոր Cloud Run առաջարկի հիմք, Knative-ը կարող է դառնալ առանց սերվերի հաշվարկման և PaaS-ի հիմնական տարբերակը Kubernetes-ում: Հետևե՛ք նորություններին։
SouthBridge-ի խմբագիրներից
Ընթերցողների կարծիքները կարևոր են մեզ համար, ուստի խնդրում ենք ձեզ մասնակցել կարճ հարցմանը, որը կապված է Knative-ի, Kubernetes-ի, առանց սերվերի հաշվարկման մասին ապագա հոդվածների հետ.
Հարցմանը կարող են մասնակցել միայն գրանցված օգտվողները։
Արդյո՞ք պետք է շարունակեմ հոդվածներ և ուղեցույցներ գրել Knative-ի և առանց սերվերի հաշվարկների մասին:
-
Այո խնդրում եմ.
-
Ոչ, շնորհակալություն.
Քվեարկել է 28 օգտատեր։ 4 օգտատեր ձեռնպահ է մնացել։
Source: www.habr.com