🥇Knative — platformă ca servicii bazată pe k8s cu suport pentru serverless

Platforma dominantă pentru desfășurarea containerelor este, fără îndoială, Kubernetes. Acesta oferă posibilitatea de a gestiona aproape totul, folosind API-urile sale și controlerii utilizați de utilizator, care extind API-ul prin resurse personalizate.

Cu toate acestea, utilizatorul încă trebuie să ia decizii detaliate despre modul în care va desfășura, configura, gestiona și scala aplicațiile. Deciziile legate de scalarea aplicației, securitate și rutează traficul rămân la discreția utilizatorului. Acest aspect face ca Kubernetes să se deosebească de platformele obișnuite de tip „platformă ca serviciu” (PaaS), precum Cloud Foundry și Heroku.

Platformele au o interfață simplificată pentru utilizatori, fiind orientate către dezvoltatorii de aplicații care se ocupă frecvent cu configurarea aplicațiilor individuale. Rutarea, desfășurarea și metricile sunt gestionate transparent pentru utilizator de către sistemul de bază PaaS.

Fluxul de lucru „cod sursă – livrare” este gestionat de PaaS prin crearea unei imagini personalizate a containerului, desfășurarea acesteia, configurarea unei noi rute și a unui subdomeniu DNS pentru traficul entranț. Toate aceste procese sunt inițiate prin comanda git push.

În Kubernetes (intentionat) sunt oferite doar blocurile fundamentale pentru astfel de platforme, lăsând comunității posibilitatea de a-și realiza această muncă singură. Așa cum a spus Kelsey Hightower:

Kubernetes este o platformă pentru construirea platformelor. Este cea mai bună poziție de pornire, dar nu și de finalizare.

Ca urmare, observăm o serie de construcții Kubernetes, precum și furnizori de găzduire care încearcă să creeze PaaS pentru Kubernetes, precum OpenShift și Rancher. Pe fondul unei piețe în creștere pentru Kube-PaaS, își face apariția Knative, creat în iulie 2018 de către companiile Google și Pivotal.

Knative a rezultat dintr-o colaborare între Google și Pivotal, cu o mică contribuție din partea altor companii, cum ar fi IBM, RedHat și Solo.im. Oferă funcții PaaS similare pentru Kubernetes cu suport de primă clasă pentru aplicațiile bazate pe calcul fără server. Spre deosebire de construcțiile Kubernetes, Knative se instalează ca un plugin pe orice cluster Kubernetes compatibil, fiind configurat prin resurse personalizate.

Ce este Knative?

Knative este descris ca fiind „O platformă bazată pe Kubernetes pentru livrarea și gestionarea sarcinilor de lucru folosind calculul fără server modern”. Anunțându-se ca o astfel de platformă, Knative scalează automat containerele proporțional cu cererile HTTP simultane. Serviciile neutilizate ajung în cele din urmă să scaleze la zero, oferind scalare la cerere în stilul calculului fără server.

Knative este compus dintr-un set de controllere, instalate în orice cluster Kubernetes, care oferă următoarele capabilități:

construirea aplicațiilor containerizate din codul sursă (furnizată de componenta Build),
oferirea accesului pentru traficul extern către aplicații (furnizată de componenta Serving),
livrarea și scalarea automată a aplicațiilor la cerere (de asemenea, furnizată de componenta Serving),
definirea surselor de evenimente care duc la lansarea aplicațiilor (furnizată de componenta Eventing).

Componenta cheie este Serving, care oferă livrarea, scalarea automată și gestionarea trecerii traficului pentru aplicațiile gestionate. După instalarea Knative, rămâne acces complet la API-ul Kubernetes, permițând utilizatorilor să gestioneze aplicațiile în mod obișnuit, precum și să depaneze serviciile Knative, lucrând cu aceleași primitive API pe care aceste servicii le utilizează (module, servicii etc.).

De asemenea, prin Serving se automatizează rutarea blue-green a traficului, asigurând împărțirea traficului între versiunile noi și cele vechi ale aplicației la livrarea unei versiuni actualizate a aplicației de către utilizator.

Însuși Knative depinde de instalarea unui controler ingress compatibil. La momentul redactării acestui articol, sunt acceptate Gloo API Gateway și Istio Service Mesh. Acesta va configura ingress-ul disponibil pentru rutarea traficului către aplicațiile gestionate prin Knative.

Istio Service Mesh poate deveni o dependență mare pentru utilizatorii Knative care doresc să îl încerce fără a instala panoul de control Istio, deoarece Knative depinde doar de gateway.

Din acest motiv, majoritatea utilizatorilor preferă Gloo ca gateway pentru Knative, oferind un set similar de funcționalități cu Istio (dacă ne referim la scopul utilizării doar pentru Knative), utilizând în același timp semnificativ mai puține resurse și având costuri operaționale mai mici.

Să vedem Knative în acțiune pe un stand. Voi folosi un cluster nou instalat, rulat în GKE:

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

Să începem instalarea Knative și Gloo. Acest lucru se poate face în orice ordine:

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

Verificăm că toate Pods sunt în stare „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 este gata să routeze, să creăm un serviciu Knative cu scalare automată (să-l numim kservice) și să îi direcționăm traficul.

Serviciile Knative oferă o modalitate mai simplă de livrare a aplicațiilor în Kubernetes — comparativ cu modelul tradițional de Deployment+Service+Ingress. Vom lucra cu un exemplu de acest tip:

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: Utilizator Knative

Am copiat aceasta într-un fișier, apoi l-am aplicat în clusterul meu Kubernetes astfel:

kubectl apply -f ksvc.yaml -n default

Putem vizualiza resursele create de Knative în cluster după livrarea ‘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-ul cu imaginea noastră ‘helloworld-go’ se lansează la desfășurarea kservice-ului. Dacă nu există trafic — numărul de pod-uri va fi redus la zero. Și invers, dacă numărul de cereri simultane depășește o anumită valoare limită configurabilă — numărul de pod-uri va crește.

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

Knative își configurează ingress-ul folosind un resursă specială de tip ‘ingress’ din API-ul său intern. Gloo folosește acest API ca parte a configurației sale pentru a oferi caracteristici specifice PaaS, inclusiv modelul de desfășurare blue-green, aplicarea automată a TLS, timeout-uri și alte caracteristici avansate de rutare.

După un timp, observăm că pod-urile noastre au dispărut (deoarece nu a fost trafic de intrare):

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

În cele din urmă, vom încerca să le accesăm. Obținerea URL-ului pentru Knative Proxy se face ușor și simplu folosind glooctl:

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

Fără instalat glooctl poți verifica adresa și portul în kube service:

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

Să rulăm câteva date folosind cURL:

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

Knative oferă aproape-PaaS pentru dezvoltatori deasupra Kubernetes „din cutie”, folosind un gateway API Gloo complet funcțional și de înaltă performanță. Această notă a atins doar superficial o varietate vastă de opțiuni de configurare disponibile în Knative, precum și caracteristici suplimentare. La fel și cu Gloo!

Deși Knative este încă un proiect tânăr, echipa sa lansează versiuni noi la fiecare șase săptămâni, iar implementarea caracteristicilor avansate, cum ar fi desfășurarea automată TLS și scalarea automată a panoului de control, a început. Există o probabilitate mare ca, datorită colaborării dintre numeroase companii de cloud și ca bază pentru noua ofertă Cloud Run de la Google, Knative să devină opțiunea principală pentru organizarea calculelor serverless și PaaS în Kubernetes. Rămâneți la curent cu noutățile!

Din partea redacției SouthBridge
Ne pasă de opinia cititorilor, așa că vă cerem să participați la un scurt sondaj legat de articolele viitoare despre Knative, Kubernetes și computația serverless:

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.