🥇Knative — platform som en tjeneste baseret på k8s med support for serverless

Kubernetes er uden tvivl den dominerende platform til implementering af containere. Den giver mulighed for at styre næsten alt ved hjælp af sine API'er og brugerdefinerede controllere, der udvider dens API via brugerdefinerede ressourcer.

Brugeren skal dog stadig træffe detaljerede beslutninger om, hvordan applikationerne skal implementeres, konfigureres, styres og skaleres. Spørgsmål vedrørende skaleringsapplikationer, sikkerhed og trafikfordeling forbliver op til brugeren. Dette adskiller Kubernetes fra almindelige "platforme som en service" (PaaS), som f.eks. Cloud Foundry og Heroku.

Platforme har et forenklet brugergrænseflade, der er målrettet mod applikationsudviklere, som oftest beskæftiger sig med konfiguration af individuelle applikationer. Routing, implementering og målinger styres gennemsigtigt for brugeren af basessystemet PaaS.

Workflowet "kildekode – levering" håndteres af PaaS ved at oprette et brugerdefineret containerbillede, implementere det, konfigurere en ny rute og DNS-underdomæne til indgående trafik. Alt dette starter vedkommende git push.

I Kubernetes (bevidst) gives kun de grundlæggende byggesten til sådanne platforme, hvilket giver samfundet mulighed for at udføre dette arbejde selv. Som Kelsey Hightower sagde:

Kubernetes er en platform for at bygge platforme. Den bedste startposition, men ikke finis.

Som et resultat ser vi et hav af Kubernetes-bygninger samt hostingtjenester, der forsøger at oprette PaaS til Kubernetes, som f.eks. OpenShift og Rancher. På baggrund af det voksende marked for Kube-PaaS kommer Knative på banen, skabt i juli 2018 af Google og Pivotal.

Knative er resultatet af et samarbejde mellem Google og Pivotal med en smule assistance fra andre virksomheder som IBM, RedHat og Solo.im. Den tilbyder lignende PaaS-funktioner for Kubernetes med førsteklasses support til applikationer baseret på serverløse computeringer. I modsætning til Kubernetes-bygninger installeres Knative som et tillæg på enhver kompatibel Kubernetes-kluster og konfigureres via brugerdefinerede ressourcer.

Hvad er Knative?

Knative er beskrevet som "En Kubernetes-baseret platform til distribution og administration af arbejdsbelastninger ved hjælp af moderne serverløse computingtjenester." Knative skalerer automatisk containere proportionalt med samtidige HTTP-anmodninger og skalerer inaktive tjenester ned til nul, hvilket giver efterspørgselsbaseret skalering i stil med serverløs computing.

Knative består af et sæt controllere, der installeres i enhver Kubernetes-klynge og giver følgende funktionaliteter:

opbygning af containeriserede applikationer fra kildekode (tilvejebragt af komponenten Build),
tilvejebringelse af adgang for indgående trafik til applikationer (tilvejebragt af komponenten Serving),
levering og automatisk skalering af applikationer efter behov (også tilvejebragt af komponenten Serving),
definering af hændelseskilder, der udløser applikationer (tilvejebragt af komponenten Eventing).

En vigtig komponent er Serving, som leverer distribution, automatisk skalering og trafikstyring for administrerede applikationer. Efter installation af Knative er der stadig fuld adgang til Kubernetes API, hvilket gør det muligt for brugerne at administrere applikationer på en almindelig måde samt at udføre fejlfinding af Knative-tjenester ved at arbejde med de samme API-primitiver, som disse tjenester bruger (moduler, tjenester osv.).

Med Serving automatiseres også blue-green trafikroutering, hvilket sikrer opdeling af trafik mellem nye og gamle versioner af applikationen, når brugeren leverer en opdateret version af applikationen.

Knative afhænger selv af installationen af en kompatibel ingress-controller. På tidspunktet for artiklens skrivning understøttes Gloo API Gateway og Istio Service Mesh. Den vil konfigurere en tilgængelig ingress til at rute trafik til de af Knative-administrerede applikationer.

Istio Service Mesh kan blive en stor afhængighed for Knative-brugere, der ønsker at prøve det uden at installere Istio-kontrolpanelet, da Knative kun afhænger af gateway.

Af denne grund foretrækker de fleste brugere Gloo som gateway til Knative, som tilbyder et lignende sæt funktioner som Istio (hvis man kun ser på brugen af Knative), men bruger betydeligt færre ressourcer og giver lavere driftsomkostninger.

Lad os teste Knative i aktion i et miljø. Jeg vil bruge et nyinstalleret kluster kørende i GKE:

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

Lad os begynde installationen af Knative og Gloo. Dette kan gøres i vilkårlig rækkefølge:

# ставим 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 tjekker, at alle Pods er 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 er klar til at rute, lad os oprette en automatisk skalerbar Knative-tjeneste (lad os kalde den kservice) og dirigerer trafik til den.

Knative-tjenester giver en nemmere måde at levere applikationer i Kubernetes på — sammenlignet med den almindelige model Deployment+Service+Ingress. Vi vil arbejde med et eksempel som dette:

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 bruger

Jeg kopierede dette til en fil og anvendte det på mit Kubernetes-kluster på denne måde:

kubectl apply -f ksvc.yaml -n default

Vi kan se ressourcerne oprettet af Knative i klustret efter levering af vores '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'en med vores billede 'helloworld-go' starter ved implementering af kservice. Hvis der ikke er trafik — vil antallet af pods blive reduceret til nul. Og omvendt, hvis antallet af samtidige forespørgsler overstiger en konfigurerbar tærskel — vil antallet af pods stige.

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

Knative konfigurerer sin ingress ved hjælp af en særlig 'ingress'-ressource i Knative's interne API. Gloo tager denne API som sin konfiguration for at tilbyde PaaS-specifikke funktioner, herunder blue-green deployments, automatisk anvendelse af TLS, timeout og andre avancerede routing-funktioner.

Efter noget tid ser vi, at vores pods er forsvundet (da der ikke var indgående trafik):

kubectl get pod -n default

Ingen ressourcer fundet.
kubectl get deployment -n default
NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

Til sidst prøver vi at få kontakt til dem. Det er let og ubesværet at få URL'en til Knative Proxy ved hjælp af glooctl:

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

Uden en installeret glooctl kan vi se adressen og porten i 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

Lad os køre lidt data vha. cURL:

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

Knative tilbyder næsten-PaaS til udviklere oven på 'ud-af-æsken' Kubernetes, ved at bruge den højt ydende, fuldfunktions API gateway Gloo. Denne note berørte kun let det omfattende antal muligheder Knative tilbyder til konfiguration samt yderligere funktioner. Det samme gælder for Gloo!

Selvom Knative stadig er et ungt projekt, udgiver teamet nye versioner hver sjette uge, og der er begyndt at blive implementeret avancerede funktioner som automatisk TLS-udrulning og automatisk skalering af kontrolpanelet. Der er en stor sandsynlighed for, at samarbejdet mellem mange cloud-udbydere, samt som grundlag for Googles nye Cloud Run-tilbud, kan gøre Knative til det primære valg for serverløse beregninger og PaaS i Kubernetes. Hold øje med opdateringer!

Fra redaktionen af SouthBridge
Vi værdsætter læsernes mening, så vi beder dig deltage i en lille undersøgelse om fremtidige artikler om Knative, Kubernetes og serverløse beregninger:

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.