🥇Knative — a k8s alapú szolgáltatásplatform serverless támogatással

The dominant platform for deploying containers has undoubtedly become Kubernetes. It provides the ability to manage almost everything using its APIs and custom controllers that extend its API through custom resources.

However, the user still needs to make detailed decisions on how to deploy, configure, manage, and scale applications. Questions about application scaling, security, and traffic passage remain at the user's discretion. This distinguishes Kubernetes from regular 'platforms as a service' (PaaS), such as Cloud Foundry and Heroku.

Platforms have a simplified user interface, oriented towards application developers, who mostly deal with configuring individual applications. Routing, deployment, and metrics are transparently managed by the underlying PaaS system.

The workflow 'source code – delivery' is handled by PaaS by creating a custom container image, deploying it, setting up a new route, and a DNS subdomain for incoming traffic. All of this is launched on command git push.

In Kubernetes, only the basic building blocks for such platforms are intentionally provided, giving the community the opportunity to do this work themselves. As Kelsey Hightower said:

Kubernetes is a platform for building platforms. The best starting position, but not the finish.

As a result, we see a bunch of Kubernetes builds and hosting options trying to create PaaS for Kubernetes, such as OpenShift and Rancher. Against the backdrop of the growing Kube-PaaS market, Knative, created in July 2018 by Google and Pivotal, emerges.

Knative emerged as a result of the collaboration between Google and Pivotal, with some assistance from other companies such as IBM, RedHat, and Solo.im. It offers similar PaaS capabilities for Kubernetes with first-class support for serverless applications. Unlike Kubernetes builds, Knative is installed as an add-on on any compatible Kubernetes cluster, configured through custom resources.

What is Knative?

A Knative-t úgy írják le, mint «Kubernetes alapú platformot a munkaterhek kiszolgálására és kezelésére modern szerver nélküli számítástechnika segítségével». A Knative, mint ilyen platform, aktívan és automatikusan méretezi a konténereket az HTTP egyidejű kéréseinek megfelelően. A nem használt szolgáltatások végül nullára méretre csökkennek, lehetővé téve a kereslet szerinti méretezést a szerver nélküli számítástechnika stílusában.

A Knative egy olyan vezérlőkészletből áll, amelyeket bármely Kubernetes klaszterbe telepíthetünk, és a következő lehetőségeket biztosítja:

konténerizált alkalmazások összeállítása forráskódból (ezt a Build),
komponens biztosítja) hozzáférés biztosítása a bejövő forgalom számára az alkalmazásokhoz (ezt a),
Serving hozzáférés biztosítása a bejövő forgalom számára az alkalmazásokhoz (ezt a),
komponens biztosítja) eseményforrások meghatározása, amelyek az alkalmazások elindításához vezetnek (ezt a).

Eventing komponens biztosítja) A kulcsfontosságú komponens a Serving, amely a forgalom kiszolgálását, automatikus méretezést és a forgalom kezelését kínálja az irányított alkalmazások számára. A Knative telepítése után a felhasználóknak továbbra is teljes hozzáférésük van a Kubernetes API-hoz, így az alkalmazásokat

normál

módszerrel kezelhetik, valamint lehetőséget biztosít a Knative szolgáltatások hibakeresésére is, a szolgáltatások által használt API primitívekkel dolgozva (modulok, szolgáltatások stb.). A Serving segítségével a blue-green forgalomirányítás is automatizálva van, lehetővé téve a forgalom elosztását a felhasználó által frissített alkalmazás új és régi verziói között. és A Knative a kompatibilis ingress vezérlő telepítésétől függ. A cikk írásának időpontjában támogatott:Gloo API Gateway

Istio Service Mesh. Ez beállítja a rendelkezésre álló ingress-et a Knative által irányított alkalmazásokhoz történő forgalomirányításhoz. Az Istio Service Mesh nagy függőséget jelenthet a Knative felhasználók számára, akik szeretnék kipróbálni anélkül, hogy telepítenék az Istio irányító panelt, mivel a Knative csak a gateway-tól függ.

Ezért a legtöbb felhasználó a Gloo-t preferálja mint a Knative kaput, amely hasonló képességeket kínál az Istio-hoz hasonlóan (ha csak a Knative használati célját nézzük), és jelentősen kevesebb erőforrást használ, valamint alacsonyabb üzemeltetési költségeket eredményez.

Nézzük meg a Knative működését egy bemutatón. Egy frissen telepített klasztert fogok használni, amely a GKE-n fut:

kubectl get namespace
NÉV          ÁLLAPOT   KOR
default       Aktív     21h
kube-public   Aktív     21h
kube-system   Aktív     21h

Kezdjük el a Knative és a Gloo telepítését. Ezt bármilyen sorrendben megtehetjük:

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

Ellenőrizzük, hogy minden Pod "Fut" állapotban van:

kubectl get pod -n knative-serving
NÉV                                         KÉSZ   ÁLLAPOT    ÚJRATÖLTÉS   KOR
activator-5dd55958cc-fkp7r        1/1     Fut      0          7m32s
autoscaler-fd66459b7-7d5s2       1/1     Fut      0          7m31s
autoscaler-hpa-85b5667df4-mdjch   1/1     Fut      0          7m32s
controller-85c8bb7ffd-nj9cs      1/1     Fut      0          7m29s
webhook-5bd79b5c8b-7czrm         1/1     Fut      0          7m29s
kubectl get pod -n gloo-system
NÉV                                               KÉSZ   ÁLLAPOT    ÚJRATÖLTÉS   KOR
discovery-69548c8475-fvh7q                 1/1     Fut      0          44s
gloo-5b6954d7c7-7rfk9                      1/1     Fut      0          45s
ingress-6c46cdf6f6-jwj7m                   1/1     Fut      0          44s
knative-external-proxy-7dd7665869-x9xkg    1/1     Fut      0          44s
knative-internal-proxy-7775476875-9xvdg    1/1     Fut      0          44s

A Gloo készen áll a forgalom irányítására, hozzunk létre egy automatikusan skálázódó Knative szolgáltatást (hívjuk kservice-nek), és irányítsuk rá a forgalmat.

A Knative szolgáltatások könnyebb utat biztosítanak az alkalmazások Kubernetes-be történő szállításához — az általános Deployment+Service+Ingress modellhez képest. Ezen a példán fogunk dolgozni:

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

Ezt átmásoltam a fájlba, majd így alkalmaztam a Kubernetes klaszteremre:

kubectl apply -f ksvc.yaml -n default

Megnézhetjük a Knative által a klaszterben létrehozott erőforrásokat, miután leszállítottuk a ‘helloworld-go’-t. kservice:

kubectl get pod -n default
NÉV                                                        KÉSZ   ÁLLAPOT    ÚJRATÖLTÉS   KOR
helloworld-go-fjp75-deployment-678b965ccb-sfpn8   2/2     Fut      0          68s

A Pod a ‘helloworld-go’ képpel a kservice telepítése közben indul el. Ha nincs forgalom, a podok száma csökkenhet nullára. Éppen ellenkezőleg, ha a párhuzamos kérések száma meghalad egy beállítható küszöbértéket, a podok száma növekedni fog.

kubectl get ingresses.networking.internal.knative.dev -n default
NÉV              KÉSZ   OK
helloworld-go     Igaz

A Knative a belső Knative API segítségével egy speciális 'ingress' erőforrással állítja be az ingressét. A Gloo ezt az API-t használja a PaaS-hoz tartozó tulajdonságok, így a blue-green telepítési modell, az automatikus TLS alkalmazása, a timeoutok és más fejlett routing funkciók biztosításához.

Egy idő elteltével azt látjuk, hogy a podjaink eltűntek (mivel nem volt bejövő forgalom):

kubectl get pod -n default

Nincs erőforrás található.
kubectl get deployment -n default
NÉV                             KÍVÁNT   JELENLEGI   Frissítve   ELÉRHETŐ   KOR
helloworld-go-fjp75-deployment   0         0         0            0           9m46s

Végül megpróbáljuk elérni őket. A Knative Proxy URL-jét könnyen és egyszerűen megkaphatjuk a következő parancs használatával: glooctl:

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

Nincs telepítve glooctl megnézhetjük az címet és a portot a kube szolgáltatásban:

kubectl get svc -n gloo-system knative-external-proxy
NÉV                     TÍPUS           CLUSTER-IP     EXTERNAL-IP      PORT(S)                      KOR
knative-external-proxy   LoadBalancer   10.16.11.157   35.190.151.188   80:32168/TCP,443:30729/TCP   77m

Futtassunk néhány adatot a cURL segítségével:

curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Helló Knative felhasználó!

A Knative szinte PaaS-t biztosít a fejlesztőknek a 'dobozból' való Kubernetes felett, a nagy teljesítményű, teljes funkcionalitású Gloo API gateway használatával. Ez a megjegyzés csak enyhén érintette a Knative széleskörű testreszabási lehetőségeit és további funkcióit. Ugyanez érvényes a Gloo-ra is!

Bár a Knative még mindig fiatal projekt, a csapata hathetente ad ki új verziókat, és elkezdték a fejlett funkcionalitások, például az automatikus TLS telepítést és az automatikus skálázás megvalósítását. Nagy lehetőség van arra, hogy számos felhőszolgáltató közötti együttműködés eredményeként, valamint a Google új Cloud Run ajánlásának alapjaként a Knative fő lehetőséggé válhat a serverless számítások és a PaaS terén a Kubernetesben. Kövessétek a híreket!

A SouthBridge szerkesztőségétől
Fontos számunkra az olvasók véleménye, ezért kérjük, vegyen részt egy rövid felmérésben a Knative-ről, a Kubernetes-ről és a serverless számításokról szóló jövőbeli cikkekkel kapcsolatban:

Csak a regisztrált felhasználók vehetnek részt a szavazáson. Kérem, jelentkezzen be., kérem.