Kubernetes har utvilsomt blitt den dominerende plattformen for containerdistribusjon. Det gir muligheten til å kontrollere nesten hva som helst ved å bruke API-ene og tilpassede kontrollere som utvider API-ene med tilpassede ressurser.
Imidlertid må brukeren fortsatt ta detaljerte avgjørelser om nøyaktig hvordan de skal distribuere, konfigurere, administrere og skalere applikasjoner. Problemer med applikasjonsskalering, beskyttelse og trafikkflyt forblir etter brukerens skjønn. Dette skiller Kubernetes fra konvensjonelle plattformer som en tjeneste (PaaS), som Cloud Foundry og Heroku.
Plattformene har et forenklet brukergrensesnitt og er rettet mot applikasjonsutviklere som oftest er med på å sette opp individuelle applikasjoner. Ruting, distribusjon og beregninger administreres transparent for brukeren av det underliggende PaaS-systemet.
Kilde-til-skip-arbeidsflyten håndteres av PaaS ved å lage et tilpasset containerbilde, distribuere det, sette opp en ny rute og DNS-underdomene for innkommende trafikk. Alt dette startes på kommando git push.
Kubernetes (med vilje) gir bare kjernebyggesteinene for slike plattformer, og lar fellesskapet stå fritt til å gjøre jobben selv. Hvordan :
Kubernetes er en plattform for å bygge plattformer. Den beste posisjonen for start, men ikke fullføring.
Som et resultat ser vi en haug med Kubernetes-bygg, så vel som vertsselskaper som prøver å lage PaaS for Kubernetes, som OpenShift og Rancher. Midt i det voksende Kube-PaaS-markedet går Knative, grunnlagt i juli 2018 av Google og Pivotal, inn i ringen.
Knative var et samarbeid mellom Google og Pivotal, med litt hjelp fra andre selskaper som IBM, RedHat og Solo.im. Den tilbyr lignende PaaS-ting som Kubernetes med førsteklasses støtte for serverløse databaserte applikasjoner. I motsetning til Kubernetes-bygg, er Knative installert som et tillegg på en hvilken som helst kompatibel Kubernetes-klynge og konfigurert gjennom brukerressurser.
Hva er Knative?
Knative beskrives som "En Kubernetes-basert plattform for å levere og administrere arbeidsbelastninger ved hjelp av moderne serverløs databehandling." Mens Knative fakturerer seg selv som en slik plattform, automatisk skalerer containere aktivt i forhold til samtidige HTTP-forespørsler. Ubrukte tjenester skaleres til slutt ned til null, og gir serverløs skalering på forespørsel.
Knative består av et sett med kontrollere som installeres i en hvilken som helst Kubernetes-klynge og gir følgende funksjoner:
- bygge containeriserte applikasjoner fra kildekoden (levert av komponenten Bygge),
- gi tilgang til innkommende trafikk til applikasjoner (levert av komponenten Servering),
- levering og automatisk skalering av applikasjoner på forespørsel (også levert av komponenten Servering),
- identifisere kildene til hendelser som fører til applikasjonslanseringer (levert av komponenten Eventing).
En nøkkelkomponent er Serving, som gir klargjøring, automatisk skalering og trafikkstyring for administrerte applikasjoner. Etter at du har installert Knative, har du fortsatt full tilgang til Kubernetes API, slik at brukere kan administrere applikasjoner ordinære måte, og tjener også til å feilsøke Knative-tjenester, og arbeider med de samme API-primitivene som disse tjenestene bruker (moduler, tjenester, etc.).
Ved hjelp av Serving automatiseres også blågrønn trafikkruting, noe som sikrer trafikkseparasjon mellom nye og gamle versjoner av applikasjonen når brukeren leverer en oppdatert versjon av applikasjonen.
Knative selv er avhengig av å installere en kompatibel ingress-kontroller. I skrivende stund støttes denne artikkelen и . Den vil konfigurere tilgjengelig inngang for å rute trafikk til Knative-administrerte applikasjoner.
Istio Service Mesh kan være en stor avhengighet for Knative-brukere som ønsker å prøve det uten å installere Istio-kontrollpanelet, siden Knative bare avhenger av gatewayen.
Av denne grunn foretrekker de fleste brukere Gloo som en inngangsport til Knative, og gir et lignende sett med funksjoner som Istio (for det formål å kun bruke Knative), samtidig som de bruker betydelig færre ressurser og har lavere driftskostnader.
La oss teste Knative i aksjon på standen. Jeg skal bruke en nyinstallert klynge som kjører i GKE:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hLa oss begynne å installere Knative og Gloo. Dette kan gjøres i hvilken som helst rekkefø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 sjekker at alle Pods er i «Running»-statusen:
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 er klar for ruting, la oss lage en Knative-tjeneste med automatisk skalering (la oss kalle den kservice) og rute trafikk til den.
Knative-tjenester gir en enklere vei til å levere applikasjoner til Kubernetes enn den konvensjonelle Deployment+Service+Ingress-modellen. Vi skal jobbe med dette eksemplet:
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 userJeg kopierte dette til en fil, og brukte det på Kubernetes-klyngen på denne måten:
kubectl apply -f ksvc.yaml -n defaultVi kan se ressursene opprettet av Knative i klyngen etter å ha levert 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 68sPoden med vårt 'helloworld-go'-bilde lanseres når kservice er distribuert. Hvis det ikke er trafikk, vil antall pods reduseres til null. Og omvendt, hvis antallet samtidige forespørsler overstiger en viss konfigurerbar terskel, vil antallet pods øke.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueKnative konfigurerer sin ingress ved å bruke en spesiell 'ingress'-ressurs i den interne Knative API. Gloo bruker denne API-en som sin konfigurasjon for å tilby PaaS-lignende funksjoner, inkludert en blågrønn distribusjonsmodell, automatisk TLS-håndhevelse, tidsavbrudd og andre avanserte rutingfunksjoner.
Etter en tid ser vi at podene våre har forsvunnet (fordi det ikke var noen innkommende trafikk):
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 9m46sTil slutt skal vi prøve å nå dem. Du kan enkelt og enkelt få URL for Knative Proxy ved å bruke glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Uten installert glooctl du kan se adressen og porten i kube-tjenesten:
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 77mLa oss kjøre noen data ved å bruke cURL:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!Knative gir en nesten-PaaS for utviklere på toppen av ut-av-boksen Kubernetes ved å bruke Gloos høyytelses, full-stack API-gateway. Dette innlegget har bare skrapet i overflaten av Knatives omfattende tilpasningsmuligheter og tilleggsfunksjoner. Samme med Gloo!
Til tross for at Knative fortsatt er et ungt prosjekt, slipper teamet deres nye versjoner hver sjette uke, og implementeringen av avanserte funksjoner har begynt, slik som automatisk TLS-distribusjon, automatisk skalering av kontrollpanelet. Det er en god sjanse for at Knative, som et resultat av samarbeid mellom flere skyselskaper, og som grunnlaget for Googles nye Cloud Run-tilbud, kan bli det primære alternativet for serverløs databehandling og PaaS på Kubernetes. Følg med på nyhetene!
Fra redaktørene til SouthBridge
Lesernes meninger er viktige for oss, så vi ber deg delta i en kort spørreundersøkelse relatert til fremtidige artikler om Knative, Kubernetes, serverløs databehandling:
Kun registrerte brukere kan delta i undersøkelsen. , vær så snill.
Bør jeg fortsette å skrive artikler og guider om Knative og serverløs databehandling?
-
Ja takk.
-
Nei takk.
28 brukere stemte. 4 brukere avsto.
Kilde: www.habr.com