Kubernetes a devenit, fără îndoială, platforma dominantă pentru implementarea containerelor. Oferă capacitatea de a controla aproape orice folosind API-urile și controlerele personalizate care își extind API-urile cu resurse personalizate.
Cu toate acestea, utilizatorul trebuie în continuare să ia decizii detaliate cu privire la modul exact de implementare, configurare, gestionare și scalare a aplicațiilor. Problemele legate de scalarea aplicației, protecție și fluxul de trafic rămân la latitudinea utilizatorului. Acest lucru diferențiază Kubernetes de platformele convenționale ca serviciu (PaaS), cum ar fi Cloud Foundry și Heroku.
Platformele au o interfață de utilizator simplificată și se adresează dezvoltatorilor de aplicații care sunt cel mai adesea implicați în configurarea aplicațiilor individuale. Rutarea, implementarea și valorile sunt gestionate în mod transparent pentru utilizator de sistemul PaaS subiacent.
Fluxul de lucru de la sursă la livrare este gestionat de PaaS prin crearea unei imagini de container personalizată, implementarea acesteia, configurarea unei noi rute și a unui subdomeniu DNS pentru traficul de intrare. Toate acestea sunt lansate la comandă git push.
Kubernetes (intenționat) furnizează doar elementele de bază pentru astfel de platforme, lăsând comunitatea liberă să-și facă singur munca. Cum :
Kubernetes este o platformă pentru construirea de platforme. Cea mai bună poziție pentru început, dar nu pentru terminare.
Drept urmare, vedem o mulțime de versiuni Kubernetes, precum și companii de găzduire care încearcă să creeze PaaS pentru Kubernetes, cum ar fi OpenShift și Rancher. Pe fondul pieței în creștere Kube-PaaS, Knative, fondată în iulie 2018 de Google și Pivotal, intră în ring.
Knative a fost o colaborare între Google și Pivotal, cu puțin ajutor din partea altor companii precum IBM, RedHat și Solo.im. Oferă lucruri PaaS similare cu Kubernetes, cu suport de top pentru aplicații bazate pe computer fără server. Spre deosebire de versiunile Kubernetes, Knative este instalat ca supliment pe orice cluster Kubernetes compatibil și configurat prin resursele utilizatorului.
Ce este Knative?
Knative este descrisă ca „O platformă bazată pe Kubernetes pentru livrarea și gestionarea sarcinilor de lucru folosind calcularea modernă fără server”. Knative, în timp ce se facturează ca o astfel de platformă, autoscală în mod activ containerele proporțional cu solicitările HTTP concurente. Serviciile neutilizate se reduc în cele din urmă la zero, oferind scalare la cerere în stil fără server.
Knative constă dintr-un set de controlere care se instalează în orice cluster Kubernetes și oferă următoarele capabilități:
- construirea de aplicații containerizate din codul sursă (furnizat de componenta Construi),
- asigurarea accesului la traficul de intrare la aplicații (furnizate de componentă Servire),
- livrarea și scalarea automată a aplicațiilor la cerere (furnizate și de componentă Servire),
- identificarea surselor de evenimente care duc la lansarea aplicației (furnizate de componentă Eveniment).
O componentă cheie este Servirea, care asigură furnizarea, scalarea automată și gestionarea traficului pentru aplicațiile gestionate. După instalarea Knative, aveți în continuare acces deplin la API-ul Kubernetes, permițând utilizatorilor să gestioneze aplicațiile obișnuit și servește, de asemenea, la depanarea serviciilor Knative, lucrând cu aceleași primitive API pe care le folosesc aceste servicii (module, servicii etc.).
Cu ajutorul Serviciului, rutarea traficului albastru-verde este, de asemenea, automatizată, asigurând separarea traficului între versiunile noi și cele vechi ale aplicației atunci când utilizatorul livrează o versiune actualizată a aplicației.
Knative în sine depinde de instalarea unui controler de intrare compatibil. La momentul scrierii acestui articol este acceptat и . Acesta va configura intrarea disponibilă pentru a direcționa traficul către aplicațiile gestionate de Knative.
Istio Service Mesh poate fi o mare dependență 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 poartă către Knative, oferind un set similar de capabilități cu Istio (în scopul de a utiliza numai Knative), folosind în același timp mult mai puține resurse și având costuri operaționale mai mici.
Să testăm Knative în acțiune pe stand. Voi folosi un cluster proaspăt instalat care rulează în GKE:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hSă începem să instalăm 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 dacă toate podurile sunt în starea „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 44sGloo este pregătit pentru rutare, să creăm un serviciu Knative cu scalare automată (să-l numim kservice) și să direcționăm traficul către acesta.
Serviciile Knative oferă o cale mai ușoară pentru livrarea aplicațiilor către Kubernetes decât modelul convențional Deployment+Service+Ingress. Vom lucra cu acest exemplu:
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 userAm copiat acest lucru într-un fișier, apoi l-am aplicat clusterului meu Kubernetes astfel:
kubectl apply -f ksvc.yaml -n defaultPutem 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 68sPodul cu imaginea noastră „helloworld-go” este lansat când kservice este implementat. Dacă nu există trafic, numărul de poduri va fi redus la zero. Și invers, dacă numărul de solicitări simultane depășește un anumit prag configurabil, numărul de poduri va crește.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative își configurează intrarea folosind o resursă specială „ingress” în API-ul Knative intern. Gloo folosește acest API ca configurație pentru a oferi funcții asemănătoare PaaS, inclusiv un model de implementare albastru-verde, aplicarea automată a TLS, expirări și alte funcții avansate de rutare.
După ceva timp, vedem că podurile noastre au dispărut (pentru că 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ă ajungem la ei. Puteți obține ușor și ușor adresa URL pentru Knative Proxy folosind glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Fara instalat glooctl puteți vedea adresa și portul în serviciul 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 77mSă 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ă dezvoltatorilor un sistem aproape PaaS, pe lângă Kubernetes-ul ieșit din cutie, folosind gateway-ul API de înaltă performanță, full-stack de la Gloo. Această postare nu a făcut decât să zgârie suprafața opțiunilor extinse de personalizare și a caracteristicilor suplimentare ale Knative. La fel și cu Gloo!
În ciuda faptului că Knative este încă un proiect tânăr, echipa sa lansează versiuni noi la fiecare șase săptămâni, iar implementarea funcțiilor avansate a început, precum implementarea automată a TLS, scalarea automată a panoului de control. Există șanse mari ca, ca urmare a colaborării dintre mai multe companii de cloud și ca bază a noii oferte Google Cloud Run, Knative să devină opțiunea principală pentru calculul fără server și PaaS pe Kubernetes. Urmăriți știrile!
De la editorii SouthBridge
Opiniile cititorilor sunt importante pentru noi, așa că vă rugăm să participați la un scurt sondaj legat de articolele viitoare despre Knative, Kubernetes, serverless computing:
Numai utilizatorii înregistrați pot participa la sondaj. , Vă rog.
Ar trebui să continui să scriu articole și ghiduri despre Knative și serverless computing?
-
Da, te rog.
-
Nu multumesc.
Au votat 28 utilizatori. 4 utilizatori s-au abținut.
Sursa: www.habr.com