Knative - platform-as-a-service na nakabatay sa k8s na may suportang walang server

Walang alinlangan na ang Kubernetes ay naging nangingibabaw na platform para sa pag-deploy ng container. Nagbibigay ito ng kakayahang kontrolin ang halos anumang bagay gamit ang mga API at custom na controller nito na nagpapalawak ng mga API nito gamit ang mga custom na mapagkukunan.

Gayunpaman, dapat pa ring gumawa ng mga detalyadong desisyon ang user tungkol sa eksaktong paraan kung paano i-deploy, i-configure, pamahalaan, at sukatin ang mga application. Ang mga isyu sa pag-scale ng application, proteksyon, at daloy ng trapiko ay nananatili sa pagpapasya ng user. Ibinubukod nito ang Kubernetes sa mga kumbensyonal na platform bilang serbisyo (PaaS), gaya ng Cloud Foundry at Heroku.

Ang mga platform ay may pinasimple na user interface at naglalayon sa mga developer ng application na kadalasang kasangkot sa pagse-set up ng mga indibidwal na application. Ang pagruruta, pag-deploy, at mga sukatan ay malinaw na pinamamahalaan sa user ng pinagbabatayan na sistema ng PaaS.

Ang source-to-ship workflow ay pinangangasiwaan ng PaaS sa pamamagitan ng paggawa ng custom na larawan ng container, pag-deploy nito, pag-set up ng bagong ruta at DNS subdomain para sa papasok na trapiko. Ang lahat ng ito ay inilunsad sa utos git push.

Ang Kubernetes (sinasadya) ay nagbibigay lamang ng mga pangunahing bloke ng pagbuo para sa mga naturang platform, na nagbibigay-daan sa komunidad na malayang gawin ang gawain mismo. Paano Sabi ni Kelsey Hightower:

Ang Kubernetes ay isang platform para sa pagbuo ng mga platform. Ang pinakamahusay na posisyon para sa pagsisimula, ngunit hindi pagtatapos.

Bilang resulta, nakikita namin ang isang grupo ng mga build ng Kubernetes, pati na rin ang mga kumpanyang nagho-host na sumusubok na gumawa ng PaaS para sa Kubernetes, gaya ng OpenShift at Rancher. Sa gitna ng lumalaking merkado ng Kube-PaaS, ang Knative, na itinatag noong Hulyo 2018 ng Google at Pivotal, ay papasok sa ring.

Ang Knative ay isang pakikipagtulungan sa pagitan ng Google at Pivotal, na may kaunting tulong mula sa ibang mga kumpanya gaya ng IBM, RedHat at Solo.im. Nag-aalok ito ng mga katulad na bagay sa PaaS sa Kubernetes na may nangungunang suporta para sa mga serverless computing-based na application. Hindi tulad ng mga build ng Kubernetes, naka-install ang Knative bilang isang add-on sa anumang katugmang cluster ng Kubernetes at na-configure sa pamamagitan ng mga mapagkukunan ng user.

Ano ang Knative?

Ang Knative ay inilarawan bilang "Isang Kubernetes-based na platform para sa paghahatid at pamamahala ng mga workload gamit ang modernong serverless computing." Ang Knative, habang sinisingil ang sarili bilang tulad ng isang platform, ay aktibong nag-autoscale ng mga container sa proporsyon sa mga kasabay na kahilingan sa HTTP. Ang mga hindi nagamit na serbisyo sa kalaunan ay bumababa sa zero, na nagbibigay ng on-demand na scaling na walang server.

Binubuo ang Knative ng isang set ng mga controller na nag-i-install sa anumang Kubernetes cluster at nagbibigay ng mga sumusunod na kakayahan:

• pagbuo ng mga containerized na application mula sa source code (ibinigay ng component Magtayo),
• pagbibigay ng access sa papasok na trapiko sa mga application (ibinigay ng component Serving),
• paghahatid at awtomatikong pag-scale ng mga application on demand (ibinigay din ng component Serving),
• pagtukoy sa mga pinagmumulan ng mga kaganapan na humahantong sa paglulunsad ng application (ibinigay ng component Pagdating).

Ang pangunahing bahagi ay ang Serving, na nagbibigay ng provisioning, auto-scaling, at pamamahala ng trapiko para sa mga pinamamahalaang application. Pagkatapos i-install ang Knative, mayroon ka pa ring ganap na access sa Kubernetes API, na nagpapahintulot sa mga user na pamahalaan ang mga application ordinaryong paraan, at nagsisilbi rin upang i-debug ang mga serbisyo ng Knative, gumagana sa parehong mga primitive ng API na ginagamit ng mga serbisyong ito (mga module, serbisyo, atbp.).

Sa tulong ng Serving, ang asul-berde na pagruruta ng trapiko ay awtomatiko din, na tinitiyak ang paghihiwalay ng trapiko sa pagitan ng bago at lumang mga bersyon ng application kapag naghatid ang user ng na-update na bersyon ng application.

Ang Knative mismo ay nakasalalay sa pag-install ng isang katugmang ingress controller. Sa oras ng pagsulat ng artikulong ito ay suportado Gloo API Gateway и Istio Service Mesh. Iko-configure nito ang magagamit na pagpasok upang iruta ang trapiko sa mga application na pinamamahalaan ng Knative.

Ang Istio Service Mesh ay maaaring maging malaking dependency para sa mga user ng Knative na gustong subukan ito nang hindi ini-install ang Istio control panel, dahil nakadepende lang ang Knative sa gateway.

Para sa kadahilanang ito, mas gusto ng karamihan sa mga user ang Gloo bilang gateway sa Knative, na nagbibigay ng katulad na hanay ng mga kakayahan sa Istio (para sa layunin ng paggamit lamang ng Knative), habang gumagamit din ng mas kaunting mga mapagkukunan at pagkakaroon ng mas mababang mga gastos sa pagpapatakbo.

Subukan natin ang Knative in action sa stand. Gumagamit ako ng bagong naka-install na cluster na tumatakbo sa GKE:

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

Simulan natin ang pag-install ng Knative at Gloo. Ito ay maaaring gawin sa anumang pagkakasunud-sunod:

# ставим 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
# ...

Sinusuri namin na ang lahat ng Pod ay nasa katayuang "Tumatakbo":

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

Handa na si Gloo para sa pagruruta, gumawa tayo ng auto-scaling Knative service (tawagin natin itong kservice) at iruta ang trapiko papunta dito.

Nagbibigay ang mga serbisyo ng Knative ng mas madaling landas sa paghahatid ng mga application sa Kubernetes kaysa sa kumbensyonal na modelo ng Deployment+Service+Ingress. Makikipagtulungan kami sa halimbawang ito:

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

Kinopya ko ito sa isang file, pagkatapos ay inilapat ito sa aking Kubernetes cluster sa ganitong paraan:

kubectl apply -f ksvc.yaml -n default

Maaari naming tingnan ang mga mapagkukunang ginawa ng Knative sa cluster pagkatapos ihatid ang aming 'helloworld-go' kservice:

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

Ang pod na may aming 'helloworld-go' na imahe ay inilunsad kapag ang kservice ay na-deploy. Kung walang trapiko, ang bilang ng mga pod ay mababawasan sa zero. At kabaligtaran, kung ang bilang ng mga sabay-sabay na kahilingan ay lumampas sa isang tiyak na na-configure na threshold, ang bilang ng mga pod ay tataas.

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

Kino-configure ng Knative ang pagpasok nito gamit ang isang espesyal na mapagkukunan ng 'ingress' sa panloob na Knative API. Ginagamit ng Gloo ang API na ito bilang configuration nito upang magbigay ng mga feature na tulad ng PaaS, kabilang ang isang blue-green na modelo ng deployment, awtomatikong pagpapatupad ng TLS, timeout, at iba pang advanced na feature sa pagruruta.

Pagkaraan ng ilang oras, nakita namin na nawala ang aming mga pod (dahil walang papasok na trapiko):

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

Sa wakas, susubukan naming maabot sila. Madali at madali mong makukuha ang URL para sa Knative Proxy gamit glooctl:

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

Nang walang naka-install glooctl makikita mo ang address at port sa serbisyo ng 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

Magpatakbo tayo ng ilang data gamit ang cURL:

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

Nagbibigay ang Knative ng halos-PaaS para sa mga developer bukod pa sa mga out-of-the-box na Kubernetes gamit ang high-performance, full-stack API gateway ng Gloo. Ang post na ito ay nag-scratch lamang sa ibabaw ng malawak na mga pagpipilian sa pagpapasadya at karagdagang mga tampok ng Knative. Ganun din kay Gloo!

Sa kabila ng katotohanan na ang Knative ay isang batang proyekto pa rin, ang koponan nito ay naglalabas ng mga bagong bersyon tuwing anim na linggo, at ang pagpapatupad ng mga advanced na feature ay nagsimula na, gaya ng awtomatikong pag-deploy ng TLS, awtomatikong pag-scale ng control panel. May magandang pagkakataon na, bilang resulta ng pakikipagtulungan sa pagitan ng maraming kumpanya ng cloud, at bilang batayan ng bagong pag-aalok ng Cloud Run ng Google, ang Knative ay maaaring maging pangunahing opsyon para sa serverless computing at PaaS sa Kubernetes. Sundan ang balita!

Mula sa mga Editor ng SouthBridge
Mahalaga sa amin ang mga opinyon ng mga mambabasa, kaya hinihiling namin sa iyo na makilahok sa isang maikling survey na nauugnay sa mga artikulo sa hinaharap tungkol sa Knative, Kubernetes, serverless computing:

Ang mga rehistradong user lamang ang maaaring lumahok sa survey. Mag-sign in, pakiusap

Dapat ko bang ipagpatuloy ang pagsusulat ng mga artikulo at gabay tungkol sa Knative at serverless computing?

• Oo pakiusap.

• Salamat nalang.

28 mga gumagamit ang bumoto. 4 user ang umiwas.

Pinagmulan: www.habr.com