Knative - k8s-baserad plattform-som-en-tjänst med serverlöst stöd

Kubernetes har utan tvekan blivit den dominerande plattformen för containerdistribution. Det ger möjlighet att kontrollera nästan vad som helst med hjälp av dess API:er och anpassade kontroller som utökar dess API:er med anpassade resurser.

Användaren måste dock fortfarande fatta detaljerade beslut om exakt hur applikationer ska distribueras, konfigureras, hanteras och skalas. Frågor om applikationsskalning, skydd och trafikflöde förblir på användarens gottfinnande. Detta skiljer Kubernetes från konventionella plattformar som en tjänst (PaaS), som Cloud Foundry och Heroku.

Plattformarna har ett förenklat användargränssnitt och riktar sig till applikationsutvecklare som oftast är med och ställer upp enskilda applikationer. Routing, distribution och mätvärden hanteras transparent för användaren av det underliggande PaaS-systemet.

Arbetsflödet från källa till sändning hanteras av PaaS genom att skapa en anpassad containeravbildning, distribuera den, konfigurera en ny rutt och DNS-underdomän för inkommande trafik. Allt detta startas på kommando git push.

Kubernetes tillhandahåller (avsiktligt) bara de centrala byggstenarna för sådana plattformar, vilket lämnar gemenskapen fritt att utföra arbetet själva. Hur sa Kelsey Hightower:

Kubernetes är en plattform för att bygga plattformar. Den bästa positionen för att starta, men inte för att avsluta.

Som ett resultat ser vi ett gäng Kubernetes-byggen, såväl som värdföretag som försöker skapa PaaS för Kubernetes, som OpenShift och Rancher. Mitt i den växande Kube-PaaS-marknaden går Knative, som grundades i juli 2018 av Google och Pivotal, in i ringen.

Knative var ett samarbete mellan Google och Pivotal, med lite hjälp från andra företag som IBM, RedHat och Solo.im. Det erbjuder liknande PaaS-saker som Kubernetes med förstklassigt stöd för serverlösa datorbaserade applikationer. Till skillnad från Kubernetes-versioner installeras Knative som ett tillägg på alla kompatibla Kubernetes-kluster och konfigureras via användarresurser.

Vad är Knative?

Knative beskrivs som "En Kubernetes-baserad plattform för att leverera och hantera arbetsbelastningar med hjälp av modern serverlös datoranvändning." Samtidigt som Knative fakturerar sig själv som en sådan plattform, skalar de aktivt behållare automatiskt i proportion till samtidiga HTTP-förfrågningar. Oanvända tjänster skalas så småningom ner till noll, vilket ger serverlös skalning på begäran.

Knative består av en uppsättning kontroller som installeras i alla Kubernetes-kluster och ger följande funktioner:

• bygga containeriserade applikationer från källkod (tillhandahålls av komponenten Bygga),
• ge åtkomst till inkommande trafik till applikationer (tillhandahålls av komponenten Servering),
• leverans och automatisk skalning av applikationer på begäran (även tillhandahålls av komponenten Servering),
• identifiera källorna till händelser som leder till programstarter (tillhandahålls av komponenten fälttävlan).

En nyckelkomponent är Serving, som tillhandahåller provisionering, automatisk skalning och trafikhantering för hanterade applikationer. Efter att du har installerat Knative har du fortfarande full tillgång till Kubernetes API, vilket tillåter användare att hantera applikationer vanlig sätt, och tjänar också till att felsöka Knative-tjänster, som arbetar med samma API-primitiver som dessa tjänster använder (moduler, tjänster, etc.).

Med hjälp av Serving automatiseras även blågrön trafikdirigering, vilket säkerställer trafikseparation mellan nya och gamla versioner av applikationen när användaren levererar en uppdaterad version av applikationen.

Knative själv är beroende av att installera en kompatibel ingångskontroll. I skrivande stund stöds denna artikel Gloo API Gateway и Istio Service Mesh. Den kommer att konfigurera tillgänglig ingång för att dirigera trafik till Knative-hanterade applikationer.

Istio Service Mesh kan vara ett stort beroende för Knative-användare som vill prova utan att installera Istio-kontrollpanelen, eftersom Knative bara beror på gatewayen.

Av denna anledning föredrar de flesta användare Gloo som en inkörsport till Knative, vilket ger en liknande uppsättning funktioner som Istio (för att endast använda Knative), samtidigt som de använder betydligt färre resurser och har lägre driftskostnader.

Låt oss testa Knative i aktion på montern. Jag kommer att använda ett nyinstallerat kluster som körs i GKE:

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

Låt oss börja installera Knative och Gloo. Detta kan göras i valfri ordning:

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

Vi kontrollerar att alla Pods har statusen "Kör":

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 är redo för routing, låt oss skapa en automatisk skalande Knative-tjänst (låt oss kalla det kservice) och dirigera trafik till den.

Knative-tjänster ger en enklare väg att leverera applikationer till Kubernetes än den konventionella Deployment+Service+Ingress-modellen. Vi kommer att arbeta med detta exempel:

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

Jag kopierade detta till en fil och använde det sedan på mitt Kubernetes-kluster på detta sätt:

kubectl apply -f ksvc.yaml -n default

Vi kan se resurserna som skapats av Knative i klustret efter att ha levererat vår 'helloworld-go' kservice:

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

Podden med vår 'helloworld-go'-bild lanseras när kservicen distribueras. Om det inte finns någon trafik kommer antalet poddar att reduceras till noll. Och vice versa, om antalet samtidiga förfrågningar överstiger en viss konfigurerbar tröskel, kommer antalet pods att öka.

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

Knative konfigurerar sin ingång med hjälp av en speciell 'ingress'-resurs i det interna Knative API. Gloo använder detta API som sin konfiguration för att tillhandahålla PaaS-liknande funktioner, inklusive en blågrön implementeringsmodell, automatisk TLS-tillämpning, timeouts och andra avancerade routingfunktioner.

Efter en tid ser vi att våra poddar har försvunnit (eftersom det inte fanns någon inkommande trafik):

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

Till slut ska vi försöka nå dem. Du kan enkelt och enkelt få URL:en för Knative Proxy med hjälp av glooctl:

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

Utan installerad glooctl du kan se adressen och porten i kubetjänsten:

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

Låt oss köra lite data med hjälp av cURL:

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

Knative tillhandahåller en nästan PaaS för utvecklare ovanpå färdiga Kubernetes med Gloos högpresterande API-gateway i full stack. Det här inlägget har bara skrapat på ytan av Knatives omfattande anpassningsalternativ och ytterligare funktioner. Samma sak med Gloo!

Trots att Knative fortfarande är ett ungt projekt släpper teamet nya versioner var sjätte vecka, och implementeringen av avancerade funktioner har börjat, såsom automatisk TLS-distribution, automatisk skalning av kontrollpanelen. Det finns en god chans att Knative, som ett resultat av samarbete mellan flera molnföretag, och som grunden för Googles nya Cloud Run-erbjudande, kan bli det primära alternativet för serverlös datoranvändning och PaaS på Kubernetes. Följ nyheterna!

Från redaktörerna för SouthBridge
Läsarnas åsikter är viktiga för oss, så vi ber dig att delta i en kort undersökning relaterad till framtida artiklar om Knative, Kubernetes, serverlös datoranvändning:

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Vill du fortsätta skriva artiklar och guider om Knative och serverlös datoranvändning?

• Ja tack.

• Nej tack.

28 användare röstade. 4 användare avstod från att rösta.

Källa: will.com