A Kubernetes kétségtelenül a konténerek telepítésének domináns platformjává vált. Lehetővé teszi szinte bármi vezérlését az API-k és az API-kat egyéni erőforrásokkal bővítő egyéni vezérlők segítségével.
A felhasználónak azonban részletes döntéseket kell hoznia az alkalmazások telepítésének, konfigurálásának, kezelésének és méretezésének pontos módjáról. Az alkalmazások méretezésével, védelmével és a forgalomáramlással kapcsolatos kérdések továbbra is a felhasználó mérlegelési körébe tartoznak. Ez megkülönbözteti a Kubernetes szolgáltatást a hagyományos platformoktól (PaaS), mint például a Cloud Foundry és a Heroku.
A platformok egyszerűsített felhasználói felülettel rendelkeznek, és azokat az alkalmazásfejlesztőket célozzák meg, akik leggyakrabban egyéni alkalmazások beállításában vesznek részt. Az útválasztást, a telepítést és a mérőszámokat a felhasználó számára átláthatóan kezeli az alapul szolgáló PaaS-rendszer.
A forrástól szállításig munkafolyamatot a PaaS kezeli egyéni tárolókép létrehozásával, üzembe helyezésével, új útvonal és DNS-aldomain beállításával a bejövő forgalom számára. Mindez parancsra indul git push.
A Kubernetes (szándékosan) csak az alapvető építőelemeket biztosítja az ilyen platformokhoz, így a közösség szabadon végezheti el a munkát. Hogyan :
A Kubernetes egy platform platformok építésére. A legjobb pozíció az induláshoz, de nem a befejezéshez.
Ennek eredményeként egy csomó Kubernetes buildet látunk, valamint olyan hosting cégeket, amelyek megpróbálják létrehozni a PaaS-t Kubernetes számára, mint például az OpenShift és a Rancher. A növekvő Kube-PaaS piac közepette ringbe lép a 2018 júliusában a Google és a Pivotal által alapított Knative.
A Knative a Google és a Pivotal együttműködése volt, némi segítséggel más cégektől, mint például az IBM, a RedHat és a Solo.im. A Kuberneteshez hasonló PaaS dolgokat kínál, kiváló támogatással a kiszolgáló nélküli számítástechnikai alkalmazásokhoz. A Kubernetes buildekkel ellentétben a Knative bővítményként telepíthető bármely kompatibilis Kubernetes-fürtre, és felhasználói erőforrásokon keresztül konfigurálható.
Mi az a Knative?
A Knative leírása szerint „Kubernetes-alapú platform a munkaterhelések szállítására és kezelésére modern szerver nélküli számítástechnikával”. A Knative, miközben ilyen platformként számlázza magát, aktívan skálázza a konténereket az egyidejű HTTP-kérések arányában. A fel nem használt szolgáltatások végül nullára skálázódnak, kiszolgáló nélküli stílusú igény szerinti méretezést biztosítva.
A Knative egy sor vezérlőből áll, amelyek bármelyik Kubernetes-fürtbe telepíthetők, és a következő képességekkel rendelkeznek:
- konténeres alkalmazások építése forráskódból (az összetevő által biztosított Épít),
- hozzáférést biztosít az alkalmazások bejövő forgalmához (ezt az összetevő biztosítja Szolgáló),
- igény szerinti alkalmazások szállítása és automatikus méretezése (szintén az összetevő biztosítja Szolgáló),
- az alkalmazások elindításához vezető események forrásainak azonosítása (az összetevő által biztosított Esemény).
A kulcsfontosságú összetevő a kiszolgálás, amely biztosítja a felügyelt alkalmazások kiépítését, automatikus skálázását és forgalomkezelését. A Knative telepítése után továbbra is teljes hozzáféréssel rendelkezik a Kubernetes API-hoz, amely lehetővé teszi a felhasználók számára az alkalmazások kezelését rendes módon, és a Knative szolgáltatások hibakeresésére is szolgál, ugyanazokkal az API-primitívekkel dolgozva, amelyeket ezek a szolgáltatások használnak (modulok, szolgáltatások stb.).
A Kiszolgálás segítségével a kék-zöld forgalomirányítás is automatizálódik, biztosítva a forgalom elkülönítését az alkalmazás új és régi verziói között, amikor a felhasználó az alkalmazás frissített verzióját szállítja.
Maga a Knative egy kompatibilis bemeneti vezérlő telepítésétől függ. A cikk írásakor támogatott и . Konfigurálja az elérhető bemeneteket, hogy a forgalmat a Knative által felügyelt alkalmazásokhoz irányítsa.
Az Istio Service Mesh nagy függőséget jelenthet a Knative-felhasználók számára, akik az Istio vezérlőpult telepítése nélkül szeretnék kipróbálni, mivel a Knative csak az átjárótól függ.
Emiatt a legtöbb felhasználó a Gloo-t részesíti előnyben, mint átjárót a Knative-hoz, amely az Istiohoz hasonló képességeket biztosít (csak a Knative használatához), ugyanakkor lényegesen kevesebb erőforrást használ és alacsonyabb működési költségekkel jár.
Teszteljük a Knative működését a standon. Egy frissen telepített fürtöt fogok használni, amely a GKE-ben fut:
kubectl get namespace
NAME STATUS AGE
default Active 21h
kube-public Active 21h
kube-system Active 21hKezdjük el a Knative és a Gloo telepítését. Ezt bármilyen sorrendben meg lehet tenni:
# ставим 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 az összes pod „Futó” állapotban van-e:
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 44sA Gloo készen áll az útválasztásra, hozzunk létre egy automatikusan skálázó Knative szolgáltatást (nevezzük kservice-nek), és irányítsuk rá a forgalmat.
A Knative szolgáltatások egyszerűbb utat biztosítanak az alkalmazások Kuberneteshez való eljuttatásához, mint a hagyományos Deployment+Service+Ingress modell. Ezzel a példával 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 userEzt egy fájlba másoltam, majd a következő módon alkalmaztam a Kubernetes-fürtömre:
kubectl apply -f ksvc.yaml -n defaultMegtekinthetjük a Knative által létrehozott erőforrásokat a fürtben a „helloworld-go” kézbesítése után kservice:
kubectl get pod -n default
NAME READY STATUS RESTARTS AGE
helloworld-go-fjp75-deployment-678b965ccb-sfpn8 2/2 Running 0 68sA 'helloworld-go' képpel ellátott pod a kservice üzembe helyezésekor indul el. Ha nincs forgalom, akkor a podok száma nullára csökken. És fordítva, ha az egyidejű kérések száma meghalad egy bizonyos konfigurálható küszöböt, a pod-ok száma növekedni fog.
kubectl get ingresses.networking.internal.knative.dev -n default
NAME READY REASON
helloworld-go TrueA Knative a belső Knative API speciális „belépési” erőforrásával konfigurálja a belépést. A Gloo ezt az API-t használja konfigurációjaként a PaaS-szerű szolgáltatások biztosításához, beleértve a kék-zöld telepítési modellt, az automatikus TLS-érvényesítést, az időtúllépéseket és más fejlett útválasztási szolgáltatásokat.
Egy idő után azt látjuk, hogy a podink eltűntek (mivel nem volt bejövő forgalom):
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 9m46sVégül megpróbáljuk elérni őket. Könnyen és egyszerűen megszerezheti a Knative Proxy URL-címét glooctl:
glooctl proxy url --name knative-external-proxy
http://35.190.151.188:80Telepítés nélkül glooctl a címet és a portot láthatja a kube szolgáltatásban:
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 77mFuttassunk néhány adatot a cURL használatával:
curl -H "Host: helloworld-go.default.example.com" http://35.190.151.188
Hello Knative user!A Knative szinte PaaS-t biztosít a fejlesztők számára a már kész Kubernetes mellett a Gloo nagy teljesítményű, full-stack API-átjárójával. Ez a bejegyzés csak a felszínét karcolta meg a Knative kiterjedt testreszabási lehetőségeinek és további funkcióinak. Ugyanez a Gloo-val!
Annak ellenére, hogy a Knative még fiatal projekt, csapata hathetente ad ki új verziókat, és megkezdődött a fejlett funkciók megvalósítása, mint például az automatikus TLS telepítés, a vezérlőpult automatikus skálázása. Jó esély van rá, hogy több felhőcég együttműködésének eredményeként, valamint a Google új Cloud Run-ajánlatának alapjaként a Knative a szerver nélküli számítástechnika és a Kubernetes PaaS elsődleges lehetőségévé válhat. Kövesd a híreket!
A SouthBridge szerkesztőitől
Számunkra fontos az olvasók véleménye, ezért kérjük, vegyen részt egy rövid felmérésben a Knative, Kubernetes, szerver nélküli számítástechnikával kapcsolatos jövőbeni cikkekhez kapcsolódóan:
A felmérésben csak regisztrált felhasználók vehetnek részt. , kérem.
Folytassam a cikkek és útmutatók írását a Knative és a szerver nélküli számítástechnikáról?
-
Igen, kérem.
-
Nem köszönöm.
28 felhasználó szavazott. 4 felhasználó tartózkodott.
Forrás: will.com