🥇Knative — platforma si shërbim e bazuar në k8s me mbështetje për serverless

Platforma dominuese për vendosjen e konteinerëve, pa dyshim, është Kubernetes. Ajo ofron mundësinë për të menaxhuar gjithçka, duke përdorur API-të e saj dhe kontrolluesit përdorues që zgjasin API-të e saj përmes burimeve të përdoruesit.

Megjithatë, përdoruesi duhet ende të marrë vende të detajuara se si të vendosë, konfiguroni, menaxhoni dhe shkallëzoni aplikacionet. Çështjet e shkallëzimit të aplikacioneve, sigurisë dhe kalimit të trafikimit mbeten në discretion të përdoruesit. Kjo e veçon Kubernetes nga "platforma si shërbim" (PaaS) të zakonshme, si Cloud Foundry dhe Heroku.

Platforma ofrojnë një ndërfaqe përdoruesi të thjeshtëzuar, të orientuar drejt zhvilluesve të aplikacioneve, të cilët shpesh merren me konfigurimin e aplikacioneve të veçanta. Rrugëzimi, vendosja dhe metrikat menaxhohen në mënyrë transparente për përdoruesin nga sistemi bazë PaaS.

Punëtori "burim kodi – dorëzim" përpunon PaaS duke krijuar një imazh të personalizuar të konteinerit, duke e vendosur atë, duke konfiguruar një rrugë të re dhe një nën-domain DNS për trafikun e ardhshëm. Të gjitha këto nisin me komandën git push.

Në Kubernetes (me qëllim) ofrohen vetëm blloqet bazike për këto platforma, duke i dhënë komunitetit mundësinë për ta 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ë nisur, por jo për të përfunduar.

Si rezultat, ne shohim një grumbull ndërtimesh Kubernetes, si dhe hostesh që përpiqen të krijojnë PaaS për Kubernetes, siç janë OpenShift dhe Rancher. Në kontekstin e tregut në rritje Kube-PaaS, në skenë del Knative, i krijuar në korrik 2018 nga kompanitë Google dhe Pivotal.

Knative u krijua si rezultat i punës së përbashkët të Google dhe Pivotal, me mbështetje të vogël nga kompani të tjera, si IBM, RedHat dhe Solo.im. Ai ofron gjëra të ngjashme PaaS për Kubernetes me mbështetje të klasit të parë për aplikacione të bazuara në llogaritje pa server. Ndryshe nga ndërtimet e Kubernetes, Knative instalohet si një shtesë në çdo grup Kubernetes të përputhshëm, duke u konfiguruar përmes burimeve të përdoruesit.

Çfarë është Knative?

Knative përshkruhet si «Platformë e bazuar në Kubernetes për dërgimin dhe menaxhimin e ngarkesave të punës duke përdorur llogaritë moderne pa server». Knative, duke e shpallur veten si një platformë të tillë, automatikisht shkallëzon konteinerët në përpjesëtim me kërkesat e përbashkëta HTTP. Shërbimet që nuk përdoren në fund shkallëzohen deri në zero, duke ofruar shkallëzim sipas kërkesës në stilin e llogaritjes pa server.

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

ndërtimi i aplikacioneve të kontejnerizuara nga kodi burimor (ofrohet nga komponenti Build),
sigurimi i aksesit të trafikut të ardhshëm në aplikacione (ofrohet nga komponenti Serving),
dërgimi dhe automatizimi i shkallëzimit të aplikacioneve sipas nevojës (po ashtu ofrohet nga komponenti Serving),
definimi i burimeve të ngjarjeve që çojnë në aktivizimin e aplikacioneve (ofrohet nga komponenti Eventing).

Komponenti kryesor është Serving, i cili ofron dërgimin, shkallëzimin automatike dhe menaxhimin e kalimit të trafikut për aplikacionet e menaxhuara. Pas instalimit të Knative, mbetet akoma qasja e plotë në API-në e Kubernetes, që u lejon përdoruesve të menaxhojnë aplikacionet në mënyrën më të zakonshme, si dhe shërben për ndihmën e shërbimeve Knative, duke punuar me të njëjtat primitive API që këto shërbime përdorin (modulet, shërbimet, etj.).

Me ndihmën e Serving gjithashtu automatizohet kalimi i trafikut blue-green, duke siguruar ndarjen e trafikshëm midis versioneve të reja dhe atyre të vjetra të aplikacionit kur përdoruesi dërgon një version të përditësuar të aplikacionit.

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

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

Për këtë arsye, shumica e përdoruesve preferojnë Gloo si portë për Knative, duke ofruar një grup të ngjashëm mundësish me Istio (kur flasim për qëllimin e përdorimit vetëm të Knative), si dhe duke përdorur ndjeshëm më pak resurse dhe duke krijuar kostot më të ulëta të funksionimit.

Le të shohim Knative në veprim në një skenë. Do të përdor një klaster të sapoinstaluar, të nisur në GKE:

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

Të fillojmë me 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
# ...

Kontrollojmë që të gjitha 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ë gatshëm për ruterimin, le të krijojmë një shërbim Knative që mund të përshtatet automatikisht (të cilin do ta quajmë kservice) dhe të drejtojmë trafikun tek ai.

Shërbimet Knative ofrojnë një mënyrë më të lehtë për të shpërndarë aplikacione në Kubernetes — në krahasim 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: Përdorues Knative

E kam kopjuar këtë në një file, pastaj e aplikova atë në klasterin tim Kubernetes në këtë mënyrë:

kubectl apply -f ksvc.yaml -n default

Mund të shohim burimet e krijuara nga Knative në klaster 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-i me imazh ‘helloworld-go’ niset kur shpërndahet kservice. Nëse nuk ka trafiku — numri i pod-eve do të reduktohet në zero. Dhe anasjelltas, nëse numri i kërkesave të njëkohshme tejkalon një vlera e caktuar, numri i pod-eve do të rritet.

kubectl get ingresses.networking.internal.knative.dev -n default
NAME            READY   REASON
helloworld-go   E vërtetë

Knative konfiguron ingress-in e tij duke përdorur një burim të veçantë 'ingress' në API-në e brendshme të Knative. Gloo e merr këtë API si konfigurimin e tij për të ofruar karakteristika tipike të PaaS, duke përfshirë modelin blue-green të shpërndarjes, zbatimin automatik të TLS, skedat e kohës dhe veçori të tjera të avancuara të ruterimit.

Pas pak kohe, ne vërejmë se pod-et tona janë zhdukur (pasi nuk kishte trafik në hyrje):

kubectl get pod -n default

Nuk janë gjetur burime.
kubectl get deployment -n default
EMRI                             DËSHIRUAR   AKTUAL   DERGIM I DËSHIRUAR   I DISPONUESHËM   MOSHA
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

Së fundmi, ne do të mundohemi t'i qasemi atyre. Të marrim URL-në për Knative Proxy është e lehtë dhe e thjeshtë me anë të glooctl:

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

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

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

Le të ekzekutojmë pak të dhëna me anë të cURL:

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

Knative ofron një pothuajse-PaaS për zhvilluesit mbi Kubernetes 'nga kutia', duke përdorur një gateway API Gloo me performancë të lartë dhe të plotë. Kjo shënim vetëm i preku lehtësisht numrin e gjithanshëm të mundësive të Knative, të cilat janë të disponueshme për t'u konfiguruar, si dhe veçori shtesë. Igloo është po ashtu!

Pavarësisht faktit se Knative është ende një projekt i ri, ekipi i tij lëshon versione të reja çdo gjashtë javë, duke filluar implementimin e veçorive të avancuara, si zbatimi automatik i TLS dhe auto-skalimi i panelit të kontrollit. Ka shanse të larta që për shkak të bashkëpunimit të kompanive të shumta të cloud, si dhe si bazë për ofertën e re Cloud Run nga Google, Knative mund të bëhet opsioni kryesor për organizimin e llogaritjeve pa server dhe PaaS në Kubernetes. Qëndroni të informuar!

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

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