
Dominantna platforma za uvođenje kontejnera zasigurno je Kubernetes. Omogućuje upravljanje gotovo svim, koristeći svoje API-je i korisničke kontrolere koji proširuju njegov API putem korisničkih resursa.
Ipak, korisnik i dalje mora donijeti detaljne odluke o tome kako točno uvesti, konfigurirati, upravljati i skalirati aplikacije. Na korisniku ostaje pitanja o skaliranju aplikacije, sigurnosti i propuštanju prometa. Ovo Kubernetes razlikuje od običnih 'platforma kao usluga' (PaaS), kao što su Cloud Foundry i Heroku.
Platforme imaju pojednostavljeno korisničko sučelje, orijentirane na programere aplikacija koji se najčešće bave konfiguriranjem pojedinačnih aplikacija. Usmjeravanje, uvođenje i metrike transparentno upravljaju osnovnim sustavom PaaS.
Radni proces 'izvorni kod – isporuka' obrađuje PaaS stvaranjem korisničke slike kontejnera, njenim uvođenjem, konfiguriranjem nove rute i DNS poddomene za dolazni promet. Sve to pokreće se po komandi. git push.
U Kubernetesu (namjerno) nude se samo osnovni blokovi za takve platforme, omogućujući zajednici da obavi taj posao sama. Kao :
Kubernetes je platforma za izgradnju platformi. Najbolja pozicija za početak, ali ne i za završetak.
Kao rezultat toga, vidimo skupinu Kubernetes izdanja, kao i hosting koji pokušavaju stvoriti PaaS za Kubernetes, poput OpenShift i Rancher. Na pozadini rastućeg tržišta Kube-PaaS, na scenu dolazi Knative, stvoren u srpnju 2018. godine od strane Googlea i Pivotal.
Knative je rezultat zajedničkog rada Googlea i Pivotal, uz malo pomoći drugih kompanija, poput IBM-a, RedHat-a i Solo.im. Pruža slične PaaS mogućnosti za Kubernetes s vrhunskom podrškom za aplikacije koje se temelje na serverless računarstvu. Za razliku od Kubernetes izdanja, Knative se instalira kao dodatak na bilo koji kompatibilni Kubernetes klaster, konfigurira se putem korisničkih resursa.
Što je Knative?
Knative je opisan kao „Platforma temeljena na Kubernetesu za isporuku i upravljanje radnim opterećenjima putem modernog besposlužnog računarstva“. Knative, predstavljajući se kao takva platforma, aktivno automatski skalira kontejnere proporcionalno broju istodobnih HTTP zahtjeva. Neiskorištene usluge na kraju se skaliraju na nulu, osiguravajući skaliranje po potrebi u stilu besposlužnog računarstva.
Knative se sastoji od skupa kontrolera koji se instaliraju u bilo koji Kubernetes klaster i osiguravaju sljedeće mogućnosti:
- izgradnju kontejneriziranih aplikacija iz izvorne koda (osigurava komponenta Build),
- osiguranje pristupa dolaznom prometu aplikacijama (osigurava komponenta Serving),
- isporuku i automatsko skaliranje aplikacija prema zahtjevu (također osigurava komponenta Serving),
- utvrđivanje izvora događaja koji pokreću aplikacije (osigurava komponenta Eventing).
Ključna komponenta je Serving, koja osigurava isporuku, automatsko skaliranje i upravljanje prometom za upravljane aplikacije. Nakon instalacije Knativea, i dalje postoji potpuni pristup Kubernetes API-ju, što omogućava korisnicima da upravljaju aplikacijama na uobičajen način, kao i da služe za otklanjanje grešaka Knative usluga, radeći s istim API primitivima koje te usluge koriste (moduli, usluge itd.).
Kroz Serving se također automatizira blue-green usmjeravanje prometa, osiguravajući podjelu prometa između novih i starih verzija aplikacije prilikom isporuke korisnikom ažurirane verzije aplikacije.
Sam Knative ovisi o instalaciji kompatibilnog ingress kontrolera. U trenutku pisanja ovog članka podržani su i . On će postaviti dostupni ingress za usmjeravanje prometa prema aplikacijama koje se upravljaju putem Knativea.
Istio Service Mesh može postati velika ovisnost za korisnike Knativea koji žele isprobati bez instalacije Istio kontrolne ploče, budući da Knative ovisi samo o gatewayu.
Zbog toga većina korisnika preferira Gloo kao pristupnik za Knative, koji pruža sličan skup mogućnosti kao Istio (govoreći o namjeni korištenja samo Knative), a također koristi značajno manje resursa i donosi manje operativne troškove.
Pogledajmo Knative u akciji na demonstraciji. Koristit ću svježe instalirani klaster, pokrenut u GKE:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hZapočnimo instalaciju Knative i Gloo. To se može učiniti u bilo kojem redoslijedu:
# ставим 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
# ...Provjeravamo da su svi Pods u statusu '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 je spreman za usmjeravanje, hajde da kreiramo automatski skalabilnu uslugu Knative (nazovimo je kservice) i usmjerimo promet prema njoj.
Knative servisi pružaju lakši put za isporuku aplikacija u Kubernetes — u usporedbi sa standardnim modelom Deployment+Service+Ingress. Radit ćemo s ovim primjerom:
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 userKopirao sam ovo u datoteku, a zatim primijenio na moj Kubernetes klaster na sljedeći način:
kubectl apply -f ksvc.yaml -n defaultMožemo pregledati resurse koje je Knative kreirao u klasteru nakon isporuke našeg 'helloworld-go' kservice:
kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68sPod s našom slikom 'helloworld-go' pokreće se prilikom implementacije kservice. Ako nema prometa, broj podova će se smanjiti na nulu. I obrnuto, ako broj simultanih zahtjeva premaši određenu konfigurabilnu prag vrijednost, broj podova će rasti.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative postavlja svoj ingress koristeći posebni 'ingress' resurs unutar Knative API-ja. Gloo bilo kojeg API koristi kao svoju konfiguraciju za pružanje osobina svojstvenih PaaS-u, uključujući blue-green model implementacije, automatsko primjenjivanje TLS-a, vremenske limite i druge napredne značajke usmjeravanja.
Nakon nekog vremena primijetili smo da su naši pod-ovi nestali (jer nije bilo dolaznog prometa):
kubectl get pod -n default
Nema pronađenih resursa.
kubectl get deployment -n default
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
helloworld-go-fjp75-deployment 0 0 0 0 9m46sNa kraju ćemo pokušati doći do njih. Dobiti URL za Knative Proxy lako i bez problema možete preko glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Bez postavljenog glooctl možete provjeriti adresu i port u kube servisu:
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 77mPustit ćemo malo podataka pomoću cURL-a:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!Knative nudi gotovo-PaaS za programere iznad 'kutijskog' Kubernetes-a, koristeći visokoučinkovit funkcionalni API gateway Gloo. Ova bilješka samo je lagano dotaknula širok spektar Knative mogućnosti dostupnih za konfiguraciju, kao i dodatnih značajki. Slično vrijedi i za Gloo!
Iako je Knative još uvijek mlad projekt, njegov tim izdaje nove verzije svake šest tjedana, a implementacija naprednih funkcija, kao što su automatsko raspoređivanje TLS-a, automatsko skaliranje upravljačke ploče, je započela. Postoji velika vjerojatnost da bi se suradnjom brojnih cloud tvrtki, kao i kao osnove nove ponude Cloud Run od Google-a, Knative mogao postati osnovni izbor za organizaciju serverless računalstva i PaaS u Kubernetesu. Ostanite informirani!
Iz uredništva SouthBridge
Vaše je mišljenje važno, stoga vas molimo da sudjelujete u malom anketnom istraživanju vezanom uz buduće članke o Knative, Kubernetesu, serverless računalstvu:
Samo registrirani korisnici mogu sudjelovati u anketi. , molimo.
Treba li nastaviti pisati članke i vodiče o Knative i serverless računalstvu?
Da, molim vas.
Hvala, ne treba.
Glasovalo je 28 korisnika. Suzdržalo se 4 korisnika.
Izvor: habr.com
