ProHoster > Blog > Administrimi > Knative — platformĂ« si shĂ«rbim e bazuar nĂ« k8s me mbĂ«shtetje pĂ«r serverless

Knative — platformĂ« si shĂ«rbim e bazuar nĂ« k8s me mbĂ«shtetje pĂ«r serverless

Knative — platformĂ« si shĂ«rbim e bazuar nĂ« k8s me mbĂ«shtetje pĂ«r serverless

Platforma dominuese për shpërndarjen e kontejnerëve padyshim është Kubernetes. Ajo ofron mundësinë për të menaxhuar praktikisht gjithçka, duke përdorur API-të e saj dhe kontrollorët e përdoruesit që zgjasin API-në e saj përmes burimeve të personalizuara.

Megjithatë, përdoruesi ende duhet të marrë vendime të detajuara rreth se si të shpërndajë, konfigurojë, menaxhojë dhe shkallëzoni aplikacionet. Pyetjet për shkallëzimin e aplikacionit, sigurimin dhe kalimin e trafikut mbeten në diskrecionin e përdoruesit. Kjo është ajo që e dallon Kubernetes nga platforma të zakonshme "shërbim si platformë" (PaaS), si Cloud Foundry dhe Heroku.

Platformat ofrojnë një ndërfaqe të thjeshtuar përdoruesi, të orientuar ndaj zhvilluesve të aplikacioneve, të cilët shpesh merren me konfigurimin e aplikacioneve individuale. Rrugëtimi, shpërndarja dhe metrikat menaxhohen në mënyrë të transparentë për përdoruesin nga sistemi bazë PaaS.

Procesi i punĂ«s “kode burimi – dorĂ«zim” pĂ«rpunon PaaS duke krijuar njĂ« imazh tĂ« personalizuar tĂ« kontejnerit, duke e shpĂ«rndarĂ«, duke konfiguruar njĂ« rrugĂ« tĂ« re dhe njĂ« subdomen DNS pĂ«r trafikun e ardhshĂ«m. TĂ« gjitha kĂ«to aktivizohen me njĂ« komandĂ«. git push.

Në Kubernetes (në mënyrë të qartë) ofrohen vetëm blloqet kryesore për këto platforma, duke i dhënë komunitetit mundësinë për të bërë këtë punë vetë. Si tha Kelsey Hightower:

Kubernetes është një platformë për ndërtimin e platformave. Pozita më e mirë për të filluar, por jo për të përfunduar.

Si rezultat, ne shohim një shumëllojshmëri ndërtimesh Kubernetes dhe gjithashtu ofruesish të hostimit që përpiqen të krijojnë PaaS për Kubernetes, si për shembull OpenShift dhe Rancher. Në sfondin e tregut në rritje të Kube-PaaS, në ring del Knative, i krijuar në korrik 2018 nga kompanitë Google dhe Pivotal.

Knative doli si rezultat i bashkëpunimit midis Google dhe Pivotal, me ndihmë të vogël nga kompani të tjera si IBM, RedHat dhe Solo.im. Ai ofron të ngjashme me PaaS për Kubernetes me mbështetje të klasit të parë për aplikacionet e bazuara në kompjuterizim pa server. Në dallim nga ndërtimet Kubernetes, Knative instalohet si një shtesë në çdo grup Kubernetes të përshtatshëm dhe konfigurohet përmes burimeve të personalizuara.

ÇfarĂ« Ă«shtĂ« Knative?

Knative përshkruhet si "një platformë e bazuar në Kubernetes për përmirësimin dhe menaxhimin e ngarkesave të punës me ndihmën e computing-ut modern pa serverë". Duke shpallur veten si një platformë të tillë, Knative automatikisht shkallëzon konteinerët në përpjesëtim me kërkesat HTTP të njëkohshme. Shërbimet e papërdorura përfundimisht shkallëzohen deri në zero, duke ofruar shkallëzim sipas kërkesës në stilin e computing-ut pa serverë.

Knative përbëhet nga një grup kontrolluesish që instalohen në çdo grup Kubernetes dhe ofrojnë këto mundësi:

  • ndĂ«rtimin e aplikacioneve tĂ« konteinerizuara nga kodi burimor (sigurohet nga komponenti Build),
  • ofrimin e aksesit tĂ« trafikut tĂ« ardhshĂ«m nĂ« aplikacione (sigurohet nga komponenti Serving),
  • shpĂ«rndarja dhe shkallĂ«zimi automatik i aplikacioneve sipas kĂ«rkesĂ«s (po ashtu sigurohet nga komponenti Serving),
  • pĂ«rcaktimi i burimeve tĂ« ngjarjeve qĂ« pĂ«rfundojnĂ« nĂ« aktivizimin e aplikacioneve (sigurohet nga komponenti Eventing).

Një komponent kyç është Serving, i cili ofron shpërndarje, përmasim automatik dhe menaxhim të kalimit të trafikut për aplikacione të menaxhuara. Pas instalimit, Knative ende ruan qasjen e plotë në API-në e Kubernetes, duke lejuar përdoruesit të menaxhojnë aplikacionet. të zakonshëm në mënyrë, dhe gjithashtu shërben për të debuguar shërbimet Knative, duke punuar me njëjtat primitive API që këto shërbime përdorin (module, shërbime, etj.).

Me anë të Serving, gjithashtu automatizohet rregullimi blue-green i trafikut, duke siguruar ndarjen e trafikut midis versioneve të reja dhe të vjetra të aplikacionit kur përdoruesi shpërndan një version të azhurnuar të aplikacionit.

Knative vetë varet nga instalimi i një kontrolluesi ingress të përputhshëm. Në momentin e shkruar, mbështeten Gloo API Gateway dhe Istio Service Mesh. Ai do të konfigurojë një ingress të disponueshëm për të rregulluar trafikun drejt aplikacioneve të menaxhuara përmes Knative.

Istio Service Mesh mund të bëhet një varësi e madhe për përdoruesit e Knative që duan ta provojnë pa instaluar panelin e kontrollit të Istio, pasi Knative varet vetëm nga gateway.

Për këtë arsye, shumica e përdoruesve preferojnë Gloo si një kalim për Knative, duke ofruar një grup të ngjashëm mundësish me Istio (kur flasim për përdorimin e vetëm Knative), si dhe duke përdorur ndjeshëm më pak burime dhe duke pasur kostot më të ulëta operuese.

Le të kontrollojmë Knative në veprim në një skenë. Unë do të përdor një kluster të sapoinstaluar, të nisur në GKE:

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

Të fillojmë instalimin e Knative dhe Gloo. Kjo mund të bëhet në çdo rend:

# стаĐČĐžĐŒ 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
# ...

Po kontrollojmë që të gjithë Pods janë në statusin "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 është gati për ruterim, le të krijojmë një shërbim Knative që shkallëzohet automatikisht (ta quajmë kservice) dhe ta drejtojmë trafikun atij.

ShĂ«rbimet Knative ofrojnĂ« njĂ« rrugĂ« mĂ« tĂ« lehtĂ« pĂ«r tĂ« shpĂ«rndarĂ« aplikacione nĂ« Kubernetes — krahasuar me modelin e zakonshĂ«m Deployment+Service+Ingress. Do tĂ« punojmĂ« me njĂ« shembull tĂ« tillĂ«:

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

E kopjova këtë në një skedar, pastaj e aplikova në klastrin tim Kubernetes në këtë mënyrë:

kubectl apply -f ksvc.yaml -n default

Mund tĂ« shohim burimet e krijuara nga Knative nĂ« klasĂ«r pas shpĂ«rndarjes sĂ« ‘helloworld-go’ kservice:

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

Pod me imazhin tonĂ« ‘helloworld-go’ niset gjatĂ« shpĂ«rndarjes sĂ« kservice. NĂ«se nuk ka trafik — numri i pod'Ă«ve do tĂ« reduktohet nĂ« zero. PĂ«rkundrazi, nĂ«se numri i kĂ«rkesave njĂ«kohĂ«she tejkalon njĂ« vlerĂ« prag tĂ« caktueshme — numri i pod'Ă«ve do tĂ« rritet.

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

Knative konfiguron ingress-in e tij me përdorimin e një resursi të veçantë 'ingress' në API-në e brendshme Knative. Gloo e merr këtë API si konfigurimin e tij për të ofruar karakteristika tipike të PaaS, duke përfshirë modelin e implementimit blue-green, aplikimin automatik të TLS, kohëzgjatjet dhe tipare të tjera të avancuara të trajtimit të trafikut.

Pas një kohe, ne vëmë re se pod-et tona janë zhdukur (për shkak se nuk kishte trafik të ardhshëm):

kubectl get pod -n default

Nuk ka burime të gjetura.
kubectl get deployment -n default
EMRI                             DESHIROHEN   AKTUARE   TË PERSHTATSHME   TË DISPONUESHME   MOSHA
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

Në fund, do të përpiqemi të arrijmë deri tek ata. Të marrim URL-në për Knative Proxy është e lehtë dhe pa probleme me ndihmën e glooctl:

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

Pa instaluar glooctl mund ta shikoni adresën dhe portin në kube service:

kubectl get svc -n gloo-system knative-external-proxy
EMRI                     LLOJI           CLUSTER-IP     EXTERNAL-IP      PORT(E)                      MOSHA
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

Do të dërgojmë disa të dhëna duke përdorur cURL:

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Përshëndetje përdorues i Knative!

Knative ofron pothuajse-PaaS për zhvilluesit mbi Kubernetes 'nga kutia', duke përdorur një portë API të plotë, me performancë të lartë Gloo. Ky shënim prek vetëm pak si një numër të gjerë mundësish që Knative ofron për personalizim, si dhe funksione shtesë. Po ashtu me Gloo!

Megjithëse Knative është akoma një projekt i ri, ekipi i tij lëshon versione të reja çdo gjashtë javë, duke filluar implementimin e karakteristikave të avancuara, si automatizimi i vendosjes së TLS, automatizimi i shkallëzimit të panelit të kontrollit. Ka një probabilitet të lartë që, si rezultat i bashkëpunimit të shumë kompanive cloud, si dhe si një bazë për ofertën e re Cloud Run nga Google, Knative mund të bëhet opsioni kryesor për ofrimin e llogarive pa server dhe PaaS në Kubernetes. Qëndroni të informuar!

Nga redaksia e SouthBridge
Na intereson mendimi i lexuesve, prandaj ju kërkojmë të merrni pjesë në një anketë të vogël, në lidhje me artikujt e ardhshëm mbi Knative, Kubernetes, dhe llogaritë pa server:

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutemi.

A duhet të vazhdojmë të shkruajmë artikuj dhe guida mbi Knative dhe llogaritë pa server?

  • Po, ju lutem.

  • Faleminderit, nuk Ă«shtĂ« nevojĂ«.

28 përdorues kanë votuar. 4 përdorues janë abstenues.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster