🥇Knative — plattform som en tjänst baserad på k8s med serverless-stöd

Den dominerande plattformen för distribution av containrar har utan tvekan blivit Kubernetes. Det ger möjlighet att hantera nästan allt med sina API:er och användarkontroller som utökar dess API genom anpassade resurser.

Användaren måste dock fortfarande fatta detaljerade beslut om hur man exakt distribuerar, konfigurerar, hanterar och skalrar applikationer. Frågor kring applikationsskalning, säkerhet och trafikhantering ligger i användarens händer. Detta särskiljer Kubernetes från vanliga "plattformar som en tjänst" (PaaS), såsom Cloud Foundry och Heroku.

Plattformarna har ett förenklat användargränssnitt och är inriktade på applikationsutvecklare som oftast arbetar med att konfigurera enskilda applikationer. Routing, distribution och metrik hanteras transparent för användaren av den underliggande PaaS-systemet.

Arbetsflödet "källkod – leverans" hanteras av PaaS genom att skapa en anpassad containerbild, distribuera den, konfigurera en ny rutt och DNS-underdomän för inkommande trafik. Allt detta startas med kommandot git push.

I Kubernetes (medvetet) tillhandahålls endast de grundläggande byggstenarna för sådana plattformar, vilket ger samhället möjlighet att göra detta arbete själva. Som Kelsey Hightower sa:

Kubernetes är en plattform för att bygga plattformar. Bästa utgångsläget, men inte stället för slutet.

Som resultat ser vi en mängd Kubernetes-versioner och värdtjänster som försöker skapa PaaS för Kubernetes, såsom OpenShift och Rancher. Mot bakgrund av den växande Kube-PaaS-marknaden gör Knative entré, vilket skapades i juli 2018 av företagen Google och Pivotal.

Knative uppstod som ett resultat av 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-funktioner för Kubernetes med förstklassigt stöd för applikationer baserade på serverlösa beräkningar. Till skillnad från Kubernetes-versioner installeras Knative som en tillägg på vilken kompatibel Kubernetes-kluster som helst och konfigureras via anpassade resurser.

Vad är Knative?

Knative beskrivs som "En Kubernetes-baserad plattform för distribution och hantering av arbetslast med hjälp av modern serverlös databehandling". Knative, som utger sig för att vara en sådan plattform, skalar automatiskt containrar proportionellt mot samtidiga HTTP-förfrågningar. Oanvända tjänster skalas i slutändan ner till noll, vilket ger on-demand skalning i stil med serverlös databehandling.

Knative består av en uppsättning kontrollerare som installeras i en hvilken Kubernetes-kluster och erbjuder följande funktioner:

byggande av containeriserade applikationer från källkod (erbjuds av komponenten Build),
tillhandahållande av inkommande trafik till applikationerna (erbjuds av komponenten Serving),
leverans och automatisk skalning av applikationer på begäran (även erbjuds av komponenten Serving),
definiering av händelsekällor som leder till körning av applikationer (erbjuds av komponenten Eventing).

En nyckelkomponent är Serving, som tillhandahåller leverans, automatisk skalning och trafikhantering för hanterade applikationer. Efter installation av Knative finns fortfarande full åtkomst till Kubernetes API, vilket gör att användare kan hantera applikationer på ett vanligt sätt och också fungerar för att felsöka Knative-tjänster, och arbetar med samma API-primitiver som dessa tjänster använder (moduler, tjänster etc.).

Med Serving automatiseras också blue-green trafikrutning, vilket möjliggör trafikdelning mellan nya och gamla versioner av applikationen när användaren distribuerar en uppdaterad version av applikationen.

Knative förlitar sig på installationen av en kompatibel ingresskontroller. Vid tidpunkten för skrivandet stöds Gloo API Gateway och Istio Service Mesh. Den kommer att ställa in en tillgänglig ingress för att dirigera trafik till applikationer hanterade av Knative.

Istio Service Mesh kan bli ett stort beroende för användare av Knative som vill prova det utan att installera Istios kontrollpanel, eftersom Knative endast är beroende av gatewayen.

Av den anledningen föredrar de flesta användare Gloo som gateway för Knative, som erbjuder en liknande uppsättning funktioner som Istio (när det gäller användningsändamålet endast för Knative), och använder dessutom betydligt färre resurser och ger lägre driftkostnader.

Låt oss testa Knative i aktion på en testmiljö. Jag kommer att använda en nyinstallerad 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 installationen av 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
# ...

Kontrollera att alla Pods är i status "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 är redo för routing, låt oss skapa en automatisk skalbar Knative-tjänst (som vi kallar kservice) och styra trafik till den.

Knative-tjänster erbjuder en enklare väg för att leverera applikationer i Kubernetes — jämfört med den traditionella modellen Deployment+Service+Ingress. Låt oss arbeta med ett sådant 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 tillämpade det på min Kubernetes-kluster på följande sätt:

kubectl apply -f ksvc.yaml -n default

Vi kan se de resurser som Knative har skapat i klustret efter att vår 'helloworld-go' har levererats 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 bild 'helloworld-go' startas vid distributionen av kservice. Om det inte finns någon trafik kommer antalet pods att minska till noll. Och om antalet samtidiga förfrågningar överskrider ett inställningsbart tröskelvärde 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:et. Gloo tar denna API som sin konfiguration för att tillhandahålla PaaS-egenskaper, inklusive blue-green distributionsmodell, automatisk TLS-tillämpning, tidsgränser och andra avancerade ruttfunktioner.

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

kubectl get pod -n default

Inga resurser hittades.
kubectl get deployment -n default
NAMN                             ÖNSKAD   NUVARANDE   UPP-DATUM   TILLGÄNGLIG   ÅLDER
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

Till sist kommer vi att försöka nå dem. Att få URL:en för Knative Proxy är enkelt och smidigt med hjälp av glooctl:

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

Utan installerat glooctl kan du se adressen och porten i kube-servicen:

kubectl get svc -n gloo-system knative-external-proxy
NAMN                     TYP           KLUSTER-IP     EXTERN-IP      PORT(AR)                      ÅLDER
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
Hej Knative-användare!

Knative erbjuder nästan-PaaS för utvecklare ovanpå 'ur kartong' Kubernetes, med en högpresterande, fullständig API-gateway Gloo. Detta meddelande tar endast en liten del av det omfattande utbudet av Knative-funktioner som är tillgängliga för anpassning, samt ytterligare funktioner. Detsamma gäller för Gloo!

Även om Knative fortfarande är ett ungt projekt släpper teamet nya versioner var sjätte vecka, och avancerade funktioner såsom automatisk TLS-distribution och automatisk skalning har påbörjats. Det finns en stor chans att Knative, genom samarbetet med många molnföretag och som grund för Googles nya Cloud Run-erbjudande, kan bli det primära alternativet för serverlösa beräkningar och PaaS i Kubernetes. Håll ögonen öppna för nyheter!

Från redaktionen SouthBridge
Vi värdesätter läsarens åsikter, så vi ber dig att delta i en liten undersökning om framtida artiklar om Knative, Kubernetes, serverlösa beräkningar:

Endast registrerade användare kan delta i omröstningen. Logga in, tack.