tormakris/knative-report-latex
1
0
Fork 0
Code Issues Pull Requests Releases Activity

more citations

Browse Source
This commit is contained in:
Torma Kristóf 2019-12-05 01:29:31 +01:00
parent fe8adcf5df
commit 507675fc12
Signed by: tormakris
GPG Key ID: DC83C4F2C41B1047
2 changed files with 212 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

178
src/bib/mybib.bib
View File

@ -89,9 +89,9 @@
}
@manual{kubernetes-nginx,
howpublished = {https://kubernetes.github.io/ingress-nginx/deploy/\#bare-metal},
howpublished = {https://kubernetes.github.io/ingress-nginx/},
note = {Megtekintve 2019-12-04},
title = {Installation Guide - Bare Metal}
title = {NGINX Ingress Controller}
}
@misc{github-issue-1,
@ -184,3 +184,177 @@
title = {Operating System (OS) Virtualization}
}
@manual{docker-layers,
howpublished = {https://medium.com/@jessgreb01/digging-into-docker-layers-c22f948ed612},
note = {Megtekintve 2019-12-04},
title = {Digging into Docker layers}
}
@manual{kubernetes-runtimes,
howpublished = {https://kubernetes.io/docs/setup/production-environment/container-runtimes/},
note = {Megtekintve 2019-12-04},
title = {Container runtimes}
}
@manual{kubernetes-concepts,
howpublished = {https://kubernetes.io/docs/concepts/},
note = {Megtekintve 2019-12-04},
title = {Concepts}
}
@manual{kube-apiserver,
howpublished = {https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/},
note = {Megtekintve 2019-12-04},
title = {kube-apiserver}
}
@manual{etcd,
howpublished = {https://etcd.io/docs/v3.4.0/learning/data\_model/},
note = {Megtekintve 2019-12-04},
title = {Data model}
}
@manual{kubernetes-api,
howpublished = {https://kubernetes.io/docs/concepts/overview/kubernetes-api/},
note = {Megtekintve 2019-12-04},
title = {The Kubernetes API}
}
@manual{kuebrnetes-controller,
howpublished = {https://kubernetes.io/docs/concepts/architecture/controller/},
note = {Megtekintve 2019-12-04},
title = {Controllers}
}
@manual{kubernetes-node-controller,
howpublished = {https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/nodes/node/\#node-controller},
note = {Megtekintve 2019-12-04},
title = {Node - Node Controller}
}
@manual{kuebrnetes-components,
howpublished = {https://kubernetes.io/docs/concepts/overview/components/},
note = {Megtekintve 2019-12-04},
title = {Kubernetes Components}
}
@manual{kubernetes-scheduler,
howpublished = {https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/},
note = {Megtekintve 2019-12-04},
title = {Kubernetes Scheduler}
}
@manual{kubernetes-kube-proxy,
howpublished = {https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/},
note = {Megtekintve 2019-12-04},
title = {kube-proxy}
}
@manual{kubernetes-service,
howpublished = {https://kubernetes.io/docs/concepts/services-networking/service/},
note = {Megtekintve 2019-12-04},
title = {Service}
}
@manual{kubernetes-volume,
howpublished = {https://kubernetes.io/docs/concepts/storage/volumes/},
note = {Megtekintve 2019-12-04},
title = {Volumes}
}
@manual{kubernetes-ingress-resource,
howpublished = {https://kubernetes.io/docs/concepts/services-networking/ingress/},
note = {Megtekintve 2019-12-04},
title = {Ingress}
}
@misc{kubeless,
howpublished = {https://itnext.io/kubeless-kubernetes-native-serverless-framework-3d0f96e03add},
note = {Megtekintve 2019-12-04},
title = {Kubeless --- Kubernetes Native Serverless Framework}
}
@manual{kubeless-api-deploy,
howpublished = {https://kubeless.io/docs/advanced-function-deployment/},
note = {Megtekintve 2019-12-04},
title = {Deploying Kubeless Functions using Kubernetes API}
}
@manual{kubeless-build,
howpublished = {https://kubeless.io/docs/building-functions/},
note = {Megtekintve 2019-12-04},
title = {Build process for functions}
}
@manual{istio-service-mesh,
howpublished = {https://istio.io/docs/concepts/what-is-istio/},
note = {Megtekintve 2019-12-04},
title = {What is Istio?}
}
@manual{istio-observer,
howpublished = {https://istio.io/docs/concepts/observability/},
note = {Megtekintve 2019-12-04},
title = {Observability}
}
@manual{istio-mgmt,
howpublished = {https://istio.io/docs/concepts/traffic-management/},
note = {Megtekintve 2019-12-04},
title = {Traffic Management}
}
@misc{knative,
howpublished = {https://containerjournal.com/topics/container-management/what-is-knative-and-what-can-it-do-for-you/},
note = {Megtekintve 2019-12-04},
title = {What is Knative, and What Can It Do for You?}
}
@manual{knative-serving,
howpublished = {https://knative.dev/docs/serving/},
note = {Megtekintve 2019-12-04},
title = {Knative Serving}
}
@manual{knative-eventing,
howpublished = {https://knative.dev/docs/eventing/},
note = {Megtekintve 2019-12-04},
title = {Knative Eventing}
}
@misc{knative-thoughts,
howpublished = {https://searchitoperations.techtarget.com/news/252469607/Knative-serverless-Kubernetes-bypasses-FaaS-to-revive-PaaS},
note = {Megtekintve 2019-12-04},
title = {Knative serverless Kubernetes bypasses FaaS to revive PaaS}
}
@manual{knative-gateweay,
howpublished = {https://knative.dev/v0.9-docs/serving/samples/knative-routing-go/},
note = {Megtekintve 2019-12-04},
title = {Routing across multiple Knative services - Go}
}
@manual{knative-autoscaler,
howpublished = {https://knative.dev/docs/serving/configuring-the-autoscaler/},
note = {Megtekintve 2019-12-04},
title = {Configuring the Autoscaler}
}
@manual{knative-autoscaler-component,
howpublished = {https://github.com/knative/serving/blob/master/docs/scaling/DEVELOPMENT.md},
note = {Megtekintve 2019-12-04},
title = {Autoscaling}
}
@misc{knative-gloo,
howpublished = {https://medium.com/solo-io/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-324753586f3a},
note = {Megtekintve 2019-12-04},
title = {Gloo, by Solo.io, is the first alternative to Istio on Knative}
}
@manual{knative-monitoring,
howpublished = {https://github.com/knative/docs/blob/master/docs/serving/accessing-metrics.md},
note = {Megtekintve 2019-12-04},
title = {Accessing Metrics}
}

72
src/content/theory.tex
View File

@ -19,12 +19,12 @@ A konténerizáció, vagy operációs rendszer szintű virtualizáció \cite{os-
Az elmúlt években kifejezetten népszerűvé vált, ugyanis a saját fejlesztésű szoftvercsomagokból gyorsan létrehozható egy nem módosítható konténer kép, ami ez után rövid idő alatt példányosítható. Ezáltal a fejlesztői és éles környezet teljesen ugyanaz lehet. További előnye, hogy egy szoftvercsomag gyorsan telepíthető, gyakran előre konfigurálva, anélkül, hogy bármi módosítást eszközölne a felhasználó a számítógépén. Természetesen erre van lehetőség virtuális gépekkel is, viszont egy-egy ilyen kép több helyet foglal, valamint futtatásához több erőforrásra van szükség.
\subsection{Docker}
A legnépszerűbb megvalósítása az operációs rendszer szintű virtualizációnak a Docker -melyet a szakdolgozatomban használt Kubernetes rendszer is használ. A Docker kihasználja a Linux operációs rendszer által nyújtott szolgáltatásokat az egyes konténerek izolálásához.
A legnépszerűbb megvalósítása az operációs rendszer szintű virtualizációnak a Docker \cite{docker-overview} -melyet a szakdolgozatomban használt Kubernetes rendszer is használ. A Docker kihasználja a Linux operációs rendszer által nyújtott szolgáltatásokat az egyes konténerek izolálásához.
Konténer képek létrehozására két lehetőség van. Az egyik egy már meglévő konténer képből futó konténer létrehozása, a kívánt módosítások elvégzése, a leállt konténerről nem módosítható pillanatkép készítése. Másik lehetőség egy úgynevezett Dockerfile létrehozása, ahol a kiinduló konténer kép megadására, valamint a módosítások lépésenkénti megadására van lehetőség. Ezeket a lépéseket rétegezetten hajtja végre a Docker, azaz minden lépés eredménye egy kép, amit a rendszer példányosít, és elvégzi a következő lépést. Ez lehetővé teszi a konténer kép építésének gyorsítását, ugyanis azokat a lépéseket nem szükséges újra végrehajtani, melyek eredménye nem változott. Fontos, hogy amennyiben egy réteg változik, az arra épülő rétegekhez tartozó lépéseket is újra végre kell hajtani. A Dockerfile használata lehetővé teszi a konténer képek létrehozásának automatizálását, melyet a szakdolgozatomban is kihasználtam.
Konténer képek létrehozására két lehetőség van. Az egyik egy már meglévő konténer képből futó konténer létrehozása, a kívánt módosítások elvégzése, a leállt konténerről nem módosítható pillanatkép készítése. Másik lehetőség egy úgynevezett Dockerfile létrehozása, ahol a kiinduló konténer kép megadására, valamint a módosítások lépésenkénti megadására van lehetőség. Ezeket a lépéseket rétegezetten \cite{docker-layers} hajtja végre a Docker, azaz minden lépés eredménye egy kép, amit a rendszer példányosít, és elvégzi a következő lépést. Ez lehetővé teszi a konténer kép építésének gyorsítását, ugyanis azokat a lépéseket nem szükséges újra végrehajtani, melyek eredménye nem változott. Fontos, hogy amennyiben egy réteg változik, az arra épülő rétegekhez tartozó lépéseket is újra végre kell hajtani. A Dockerfile használata lehetővé teszi a konténer képek létrehozásának automatizálását, melyet a szakdolgozatomban is kihasználtam.
\section{Kubernetes}
A Kubernetes egy Go nyelven írt, nyílt forráskódú konténer orkesztrációs platform, amely képes konténerek automatikus konfigurációjára, skálázására, valamint bizonyos hibák automatikus elhárítására. Több konténer technológiát támogat, köztük a Dockert is. Nagyon népszerű, gyors fejlesztés alatt álló projekt. Emiatt felhasználói és programozói interfésze gyakran változik, megkövetelve a ráépülő megoldásoktól a hasonló sebességű fejlesztést. Jól definiált interfésze miatt sok ráépülő, azt kiegészítő projekt létezik. Egy ilyen a Kubeless, amely segítségével Function as a Service megoldásokat lehet készíteni Kubernetes környezetben.
A Kubernetes egy Go nyelven írt, nyílt forráskódú konténer orkesztrációs platform, amely képes konténerek automatikus konfigurációjára, skálázására, valamint bizonyos hibák automatikus elhárítására. Több konténer technológiát \cite{kubernetes-runtimes} támogat, köztük a Dockert is. Nagyon népszerű, gyors fejlesztés alatt álló projekt. Emiatt felhasználói és programozói interfésze gyakran változik, megkövetelve a ráépülő megoldásoktól a hasonló sebességű fejlesztést. Jól definiált interfésze miatt sok ráépülő, azt kiegészítő projekt létezik. Egy ilyen a Kubeless, amely segítségével Function as a Service megoldásokat lehet készíteni Kubernetes környezetben.
Néhány fontosabb szolgáltatás, melyet a Kubernetes nyújt:
\begin{itemize}
@ -34,7 +34,7 @@ Néhány fontosabb szolgáltatás, melyet a Kubernetes nyújt:
\end{itemize}
\subsection{Kubernetes klaszter felépítése}
Egy Kubernetes klaszterben két típusú hosztgép lehet. Mindkettőből lehet több darab, de legalább egy-egy példány kötelező. \aref{fig:k8s-chart} \'abr\'an l\'athat\'o, hogy egy Kubernetes klaszter legal\'abb egy Masterből \'es Workerből \'ep\"ul fel, ezek egy-egy feladatot ell\'at\'o komponensekből \'allnak.
Egy Kubernetes klaszterben két típusú hosztgép lehet. Mindkettőből lehet több darab, de legalább egy-egy példány kötelező. \aref{fig:k8s-chart} \'abr\'an l\'athat\'o, hogy egy Kubernetes klaszter \cite{kubernetes-nodes} legal\'abb egy Masterből \'es Workerből \'ep\"ul fel, ezek egy-egy feladatot ell\'at\'o komponensekből \'allnak.
\begin{figure}[!ht]
\centering
@ -43,68 +43,68 @@ Egy Kubernetes klaszterben két típusú hosztgép lehet. Mindkettőből lehet t
\label{fig:k8s-chart}
\end{figure}
A Kubernetes Master felelős a klaszterben lezajló folyamatok irányításáért, a Slave-ek, vagy más néven Worker-ek, valamint az alkalmazások állapotának nyilvántartásáért. A klaszterben történő eseményekre válaszul klaszter szintű választ ad - például egy Pod elindítása.
A Kubernetes Master felelős a klaszterben lezajló folyamatok \cite{kubernetes-concepts} irányításáért, a Slave-ek, vagy más néven Worker-ek, valamint az alkalmazások állapotának nyilvántartásáért. A klaszterben történő eseményekre válaszul klaszter szintű választ ad - például egy Pod elindítása.
Egy Master node számos komponensből áll, ezek a Master egy-egy feladatáért felelnek. Több Master node futtatása esetén - úgynevezett multi-master mode - csak az API Server és az etcd komponensekből jön létre több példány, a többiből egyszerre csak egy példány lehet aktív.
Egy Master node számos komponensből áll, ezek a Master egy-egy feladatáért felelnek. Több Master node futtatása esetén - úgynevezett multi-master mode - csak az API Server \cite{kube-apiserver} és az etcd \cite{etcd} komponensekből jön létre több példány, a többiből egyszerre csak egy példány lehet aktív.
\subsection{API Server}
Az API-Server szolgálja ki a Kubernetes API-t, amelyen keresztül lehet interakcióba lépni a klaszterrel. A kiszolgált API REST alapú, JSON objektumokba csomagolva lehet az etcd-ben lévő információt lekérdezni vagy frissíteni. Ez egy kifejezetten fontos része egy klaszternek, meghibásodása esetén a klaszter konfigurációja igen nehézkes.
Az API-Server szolgálja ki a Kubernetes API-t \cite{kubernetes-api} , amelyen keresztül lehet interakcióba lépni a klaszterrel. A kiszolgált API REST alapú, JSON objektumokba csomagolva lehet az etcd-ben lévő információt lekérdezni vagy frissíteni. Ez egy kifejezetten fontos része egy klaszternek, meghibásodása esetén a klaszter konfigurációja igen nehézkes.
\subsection{Etcd}
A CoreOS által fejlesztett, nyílt forráskódú elosztott kulcs-érték tár. Itt kerül tárolásra, illetve innen lehet lekérdezni a klaszter, valamint az egyes komponensek állapotát. Egyes komponensek figyelik az itt található, nekik fontos kulcsokhoz tartozó értékeket, változás esetén elvégzik az esetleges módosításokat.
A CoreOS által fejlesztett, nyílt forráskódú elosztott kulcs-érték tár \cite{etcd} . Itt kerül tárolásra, illetve innen lehet lekérdezni a klaszter, valamint az egyes komponensek állapotát. Egyes komponensek figyelik az itt található, nekik fontos kulcsokhoz tartozó értékeket, változás esetén elvégzik az esetleges módosításokat.
\subsection{Controller Manager}
Logikailag különböző kontrollereket összefoglaló komponens. Az alábbi kontrollereket a komplexitás csökkentése érdekében fordították egy binárisba:
Logikailag különböző kontrollereket összefoglaló komponens \cite{kubernetes-controller} . Az alábbi kontrollereket a komplexitás csökkentése érdekében fordították egy binárisba:
\begin{itemize}
\item Node Controller: Egyes Node-ok elérhetetlenné válásának figyeléséért, erre történő reagálásért felelős.
\item Replication Controller: A klaszterben megfelelő számú Podok meglétéért felelős kontroller.
\item Node Controller \cite{kubernetes-node-controller} : Egyes Node-ok \cite{kubernetes-nodes} elérhetetlenné válásának figyeléséért, erre történő reagálásért felelős.
\item Replication Controller \cite{kuebrnetes-components} : A klaszterben megfelelő számú Podok meglétéért felelős kontroller.
\item Endpoints Controller: Service-ek és Podok társításáért felelős.
\item Service Account \& Token Controllers: Alapértelmezett felhasználói fiókok és API tokenek létrehozását hajtja végre néhány Namespace-hez.
\end{itemize}
\subsection{Scheduler}
A Scheduler, vagy Ütemező figyeli, mely Podok még nincsenek egy Slave node-hoz sem rendelve, majd hozzárendeli egyhez olyan módon, hogy a hozzárendelt node-on lévő erőforrások kielégítsék a Pod igényeit, valamint a terhelés legyen lehetőség szerint egyenlően elosztva a node-ok között.
A Scheduler \cite{kubernetes-scheduler} , vagy Ütemező figyeli, mely Podok még nincsenek egy Slave node-hoz sem rendelve, majd hozzárendeli egyhez olyan módon, hogy a hozzárendelt node-on lévő erőforrások kielégítsék a Pod igényeit, valamint a terhelés legyen lehetőség szerint egyenlően elosztva a node-ok között.
\subsection{Horizontal Pod Autoscaler}
A Horizontal Pod Autoscaler automatikusan skálázza a Podok számát egy Deploymentben a megfigyelt CPU használat alapján. Ez a megfigyelés 15 másodperces ciklusokban történik, majd a skálázási döntés a gyűjtött metrikák egy perces átlaga alapján zajlik.
A Horizontal Pod Autoscaler \cite{kubernetes-hpa} automatikusan skálázza a Podok számát egy Deploymentben a megfigyelt CPU használat alapján. Ez a megfigyelés 15 másodperces ciklusokban történik, majd a skálázási döntés a gyűjtött metrikák egy perces átlaga alapján zajlik.
\subsection{Slave Node}
A Kubernetes klaszter azon részét, ahol a telepített alkalmazások futnak Slave Node-nak, vagy bizonyos szakirodalomban Workernek hívják. Egy Slave Node az alábbi komponensekből áll:
A Kubernetes klaszter azon részét, ahol a telepített alkalmazások futnak Slave Node-nak, vagy bizonyos szakirodalomban Workernek \cite{kubernetes-nodes} hívják. Egy Slave Node az alábbi komponensekből áll:
\subsection{Container Runtime}
A konténerek futtatásáért felelős komponens. Képes használni többek között Docker, CRI-O és containerd konténer futtatási környezeteket.
A konténerek futtatásáért felelős komponens \cite{kubernetes-runtimes} . Képes használni többek között Docker, CRI-O és containerd konténer futtatási környezeteket.
\subsection{Kubelet}
Felelőssége, hogy a Podok specifikációjuk szerinti állapotban fussanak. A klaszter összes tagján kötelezően fut.
Felelőssége \cite{kubernetes-kubelet} , hogy a Podok specifikációjuk szerinti állapotban fussanak. A klaszter összes tagján kötelezően fut.
\subsection{Kube-Proxy}
UDP vagy TCP forgalom továbbítására képes komponens, amely minden Slave Node-on kötelezően fut.
UDP vagy TCP forgalom továbbítására képes komponens \cite{kubernetes-kube-proxy} , amely minden Slave Node-on kötelezően fut.
\section{Kubernetesben létrehozható objektumok}
A Kubernetesben többek között az alábbi objektumok hozhatók létre:
\subsection{Pod}
A Pod egy vagy több konténert összefogó logikai hoszt. Egy Podon belül lévő konténerek osztoznak a hálózaton és a háttértáron, valamint azonos a futtatási specifikációjuk. Ez azt jelenti, hogy az egy Podon belüli konténerek localhost-ként megtalálják egymást, valamint van lehetőség, hogy a konténerekben futó alkalmazások lássák a másik konténerben futó folyamatokat. Egy Kubernetes rendszerben a Pod a legkisebb egység, amit futásra lehet ütemezni.
A Pod \cite{kubernetes-pods} egy vagy több konténert összefogó logikai hoszt. Egy Podon belül lévő konténerek osztoznak a hálózaton és a háttértáron, valamint azonos a futtatási specifikációjuk. Ez azt jelenti, hogy az egy Podon belüli konténerek localhost-ként megtalálják egymást, valamint van lehetőség, hogy a konténerekben futó alkalmazások lássák a másik konténerben futó folyamatokat. Egy Kubernetes rendszerben a Pod a legkisebb egység, amit futásra lehet ütemezni.
\subsection{Deployment}
A Deployment segítségével deklaratívan leírható egy alkalmazást felépítő Podok és azok kívánt állapota. Lehetőség van megadni, hány replikát hozzon létre a rendszer. Hasonló módon lehet Podok állapotát frissíteni vagy egy korábbi állapotra visszatérni. Egy Deploymentben lehetőség van több Pod definiálására, ami alkalmazás komponensek lazább csatolását teszi lehetővé.
A Deployment \cite{kubernetes-deployment} segítségével deklaratívan leírható egy alkalmazást felépítő Podok és azok kívánt állapota. Lehetőség van megadni, hány replikát hozzon létre a rendszer. Hasonló módon lehet Podok állapotát frissíteni vagy egy korábbi állapotra visszatérni. Egy Deploymentben lehetőség van több Pod definiálására, ami alkalmazás komponensek lazább csatolását teszi lehetővé.
\subsection{Service}
A Podok bármikor törlődhetnek, valamint új példány jöhet belőlük létre. Minden Pod saját IP címmel rendelkezik, viszont szükség van valamilyen módszerre, aminek segítségével nyomon lehet követni, hogy egy Pod által nyújtott szolgáltatás milyen címen érhető el. Erre a problémára nyújt megoldást a Service, ami absztrakciót jelent a Podok felett.
A Podok bármikor törlődhetnek, valamint új példány jöhet belőlük létre \cite{kubernetes-service} . Minden Pod saját IP címmel rendelkezik, viszont szükség van valamilyen módszerre, aminek segítségével nyomon lehet követni, hogy egy Pod által nyújtott szolgáltatás milyen címen érhető el. Erre a problémára nyújt megoldást a Service, ami absztrakciót jelent a Podok felett.
\subsection{Volume}
A perzisztens adattárolás gyakori igény, főleg valamilyen állapotot számontartó alkalmazások esetében. A Podok alapvetően nem alkalmasak erre, ezért szükség van a Volume-okra, ami lehetővé teszi a perzisztens adattárolást Kubernetes környezetben.
A perzisztens adattárolás \cite{kubernetes-volume} gyakori igény, főleg valamilyen állapotot számontartó alkalmazások esetében. A Podok alapvetően nem alkalmasak erre, ezért szükség van a Volume-okra, ami lehetővé teszi a perzisztens adattárolást Kubernetes környezetben.
\subsection{Ingress}
Ingress erőforrás segítségével klaszteren belüli Service erőforrást lehet azon kívülre kiszolgálni. Ennek módját az Ingress erőforrás határozza meg, amelyet az Ingress Controller nevű klaszter szintű objektum szolgál ki.
Ingress \cite{kubernetes-ingress-resource} erőforrás segítségével klaszteren belüli Service erőforrást lehet azon kívülre kiszolgálni. Ennek módját az Ingress erőforrás határozza meg, amelyet az Ingress Controller \cite{kubernetes-ingress} nevű klaszter szintű objektum szolgál ki.
\section{Kubeless}
A Kubeless egy Go nyelven írt, nyílt forr\'askódú, Kubernetes rendszerbe épülő Function as a Service megoldás. Számos ehhez hasonló rendszer létezik, a Kubeless különlegessége abban rejlik, hogy a funkcionalitásának kis részéhez használ újonnan bevezetett logikát, szinte mindent a Kubernetes API kiegészítésével ér el. A keretrendszer támogat számos népszerű programnyelvet, például a Go, Python, Java, Javascript és C\# nyelveket.
A Kubeless \cite{kubeless} egy Go nyelven írt, nyílt forr\'askódú, Kubernetes rendszerbe épülő Function as a Service megoldás. Számos ehhez hasonló rendszer létezik, a Kubeless különlegessége abban rejlik, hogy a funkcionalitásának kis részéhez használ újonnan bevezetett logikát, szinte mindent a Kubernetes API kiegészítésével ér el. A keretrendszer támogat számos népszerű programnyelvet, például a Go, Python, Java, Javascript és C\# nyelveket.
Egy telepített függvény lefutását több esemény - úgynevezett trigger - kiválthatja. Ezek közül egy a http kérés, amelyet a szakdolgozatomban vizsgáltam. Emellett van lehetőség eseményvezérelt műkődésre is, például Kafka rendszerben tárolt üzenetek feldolgozására is.
Egy telepített függvény lefutását több esemény - úgynevezett trigger - kiválthatja. Ezek közül egy a http kérés \cite{kubeless-http} , amelyet a szakdolgozatomban vizsgáltam. Emellett van lehetőség eseményvezérelt műkődésre is \cite{kubeless-pubsub} , például Kafka rendszerben tárolt üzenetek feldolgozására is.
Lévén, hogy Function as a Service rendszerről van szó, a Kubeless-be telepítendő függvényeket sajátos módon kell megírni. \aref{code:hello-kubeless-go} k\'odr\'eszleten l\'athat\'o, hogy egy Kubeless specifikus csomagot kell import\'alni Go nyelven \'irt f\"uggv\'enyek eset\'eben. Szint\'en l\'atszik, hogy azon k\'iv\"ul egy\'eb t\"obblet teendő nincs.
Lévén, hogy Function as a Service rendszerről van szó, a Kubeless-be telepítendő függvényeket sajátos módon kell megírni. Ahogy \aref{code:hello-kubeless-go} k\'odr\'eszleten l\'athat\'o, hogy egy Kubeless specifikus csomagot kell import\'alni Go nyelven \'irt f\"uggv\'enyek eset\'eben.
\begin{lstlisting}[float=!ht,caption={Kubeless rendszerbe telep\'ithető Hello World k\'odr\'eszlet Go nyelven},label=code:hello-kubeless-go]
package kubeless
@ -118,11 +118,11 @@ func hello(event functions.Event, context functions.Context) (string, error) {
}
\end{lstlisting}
Mint az a fenti kódrészleten is látszik, a függvény első paraméterben megkapja a kiváltott eseményt, a másodikban pedig a futási kontextust, a visszatérése pedig egy karakterlánc, opcionálisan pedig egy keletkezett kivétel. Minden úgynevezett eseménykezelőnek ilyen szignatúrával kell rendelkeznie. Az eseményt leíró, functions.Event típusú paraméterben, például http kérés esetén annak törzsében, található adat.
Mint \aref{code:hello-kubeless-go} kódrészleten is látszik, a függvény első paraméterben megkapja a kiváltott eseményt, a másodikban pedig a futási kontextust, a visszatérése pedig egy karakterlánc, opcionálisan pedig egy keletkezett kivétel. Minden úgynevezett eseménykezelőnek ilyen szignatúrával kell rendelkeznie. Az eseményt leíró, functions.Event típusú paraméterben, például http kérés esetén annak törzsében, található adat.
Egy megírt függvényt telepíteni két módon lehet. Egy lehetőség közvetlen a Kubernetes API-t használva. Alternatíva és könnyítésként a Kubeless fejlesztői elkészítettek egy parancssoros programot, amelyet használva egyszerűen lehet telepíteni függvényeket, létrehozni triggereket, valamint beállítani a skálázást. Fontos, hogy telepítés közben nem jön létre automatikusan CPU limit egy-egy függvénynek, akkor sem, ha skálázást kérünk hozzá. Skálázáshoz a Kubeless a Horizontal Pod Autoscalert használja.
Egy megírt függvényt telepíteni két módon lehet. Egy lehetőség közvetlen a Kubernetes API-t \cite{kubeless-api-deploy} használva. Alternatíva és könnyítésként a Kubeless fejlesztői elkészítettek egy parancssoros programot, amelyet használva egyszerűen lehet telepíteni függvényeket, létrehozni triggereket, valamint beállítani a skálázást. Fontos, hogy telepítés közben nem jön létre automatikusan CPU limit egy-egy függvénynek, akkor sem, ha skálázást kérünk hozzá. Skálázáshoz a Kubeless a Horizontal Pod Autoscalert használja.
Mivel a Kubernetesben Podokat van lehetőség futtatni és ütemezni, a Kubeless függvényekből is Podokat kell létrehozni. Ez a folyamat, amely \aref{fig:kubeless-pod-creation} \'abr\'an megfigyelhető, részleteiben eltér programnyelvenként azok sajátosságai miatt.
Mivel a Kubernetesben Podokat van lehetőség futtatni és ütemezni, a Kubeless függvényekből is Podokat kell létrehozni. Ez a folyamat \cite{kubeless-build} , amely \aref{fig:kubeless-pod-creation} \'abr\'an megfigyelhető, részleteiben eltér programnyelvenként azok sajátosságai miatt.
\begin{figure}[!ht]
\centering
@ -133,14 +133,14 @@ Mivel a Kubernetesben Podokat van lehetőség futtatni és ütemezni, a Kubeless
A Podban futó konténer létrehozása során a Kubeless Controller a Debian nevű Docker képből indul ki. Először telepíti a programnyelv csomagjait, annak függőségeit és a kód binárissá fordításához szükséges eszközöket. Ez után felmásolja a kódot és a vele együtt, opcionálisan megadott függőségleíró állományt. A fordítási folyamat végén lefordítja a kódot. Ez a folyamat csak akkor lesz sikeres, ha a kód belepési függvényét tartalmazó fájlban meg van jelölve a Kubeless futtató környezet, mint függőség, ezáltal nincs szükség egyedi fordítóeszközre. Az elkészült, futtatható binárist megjelöli a rendszer, mint a képből futtatott konténer belépési pontját. Egy így készült Docker képet lehetőség van feltölteni a Docker Hubra, így későbbi használat során nincs szükség a folyamat újbóli futtatására.
Amennyiben http triggert hozunk létre egy függvényhez, létrejön egy Ingress objektum, amelyet kötelezően az NGINX Ingress Controller nevű Ingress Controller implementáció kell kiszolgálja, így annak telepítve kell lenni a klaszterben. Az Ingress Controller a megadott hosztnév - például function.example.com - alapján azonosítja, melyik függvényt kívánjuk meghívni.
Amennyiben http triggert hozunk létre egy függvényhez, létrejön egy Ingress objektum, amelyet kötelezően az NGINX Ingress Controller \cite{kubernetes-nginx} nevű Ingress Controller implementáció kell kiszolgálja, így annak telepítve kell lenni a klaszterben. Az Ingress Controller a megadott hosztnév - például function.example.com - alapján azonosítja, melyik függvényt kívánjuk meghívni.
Mivel a függvényekből Kubernetes objektumok lesznek, a terheléselosztás a rendszerben már létező mechanizmusokkal történik. Egy függvényt kiszolgáló Podok számának változása esetén a hozzájuk tartozó Ingress objektum nyomon követi a változást, így az NGINX Ingress Controller képes a beérkező kérések elosztására.
\section{Istio}
Az Istio egy nyílt forráskódú, Kubernetesbe épülő hálózati forgalom menedzselését elősegítő platform. Segítségével csökkenthető a nagy számú komponensből álló alkalmazások komplexitása.
Ezt a service mesh koncepciójának bevezetésével éri el. A service mesh egy alkalmazást felépítő mikroszervizek és ezek közötti interakciók összességét jelenti. Ahogy egy service mesh nő méretében és komplexitásában, egyre nehezebb átlátni és menedzselni. Az Isitio betekintést ad, és a belső működés irányítását nyújtja az egész service meshre.
Ezt a service mesh \cite{istio-service-mesh} koncepciójának bevezetésével éri el. A service mesh egy alkalmazást felépítő mikroszervizek és ezek közötti interakciók összességét jelenti. Ahogy egy service mesh nő méretében és komplexitásában, egyre nehezebb átlátni és menedzselni. Az Isitio betekintést ad \cite{istio-observer} , és a belső működés irányítását \cite{istio-mgmt} nyújtja az egész service meshre.
Az Istio többek között képes:
@ -154,17 +154,17 @@ Az Istio többek között képes:
Szakdolgozatomban, közvetve, az Istio terheléskiegyenlítő szolgáltatását is megvizsgálom, lévén, hogy a Knative azt használja, mint load balancert.
\section{Knative}
A Knative egy nyílt forráskódú, a Google által fejlesztett keretrendszer, amely a Kubernetesnél magasabb szintű absztrakciókat nyújt. Számos komponenséből a szakdolgozatban a serverless applikációk Kubernetes-be telepítését, futtatását megkönnyítő, úgynevezett Serving modult vizsgálom. Ezen kívül létezik még egy Eventing komponens, amely eseményvezérelt alkalmazások fejlesztéséhez biztosít segédeszközöket, valamint megold bizonyos gyakori problémákat.
A Knative \cite{knative} egy nyílt forráskódú, a Google által fejlesztett keretrendszer, amely a Kubernetesnél magasabb szintű absztrakciókat nyújt. Számos komponenséből a szakdolgozatban a serverless applikációk Kubernetes-be telepítését, futtatását megkönnyítő, úgynevezett Serving \cite{knative-serving} modult vizsgálom. Ezen kívül létezik még egy Eventing \cite{knative-eventing} komponens, amely eseményvezérelt alkalmazások fejlesztéséhez biztosít segédeszközöket, valamint megold bizonyos gyakori problémákat.
Nem kifejezetten Function as a Service megoldásról van szó, a nullára skálázás miatt emlegetik a Platform as a Service infrastruktúrák következő generációjaként, de funkcionalitása és működése remekül illeszkedik a FaaS szolgáltatásmodellhez is. Emellett a Kubernetesben már futó alkalmazásokat Knative-ba átrakni nem jelent szignifikáns munkát. Az érintett komponensek módosítására nincs szükség, csupán a Deploymenteket kell Knative Service-ekre átírni. Ezzel szemben a plusz funkciók, melyeket az átállással ki lehet használni jelentős előnyt jelentenek.
Nem kifejezetten Function as a Service megoldásról van szó \cite{kubeless-thoughts} , a nullára skálázás miatt emlegetik a Platform as a Service infrastruktúrák következő generációjaként, de funkcionalitása és működése remekül illeszkedik a FaaS szolgáltatásmodellhez is. Emellett a Kubernetesben már futó alkalmazásokat Knative-ba átrakni nem jelent szignifikáns munkát. Az érintett komponensek módosítására nincs szükség, csupán a Deploymenteket kell Knative Service-ekre átírni. Ezzel szemben a plusz funkciók, melyeket az átállással ki lehet használni jelentős előnyt jelentenek.
Lényeges újítás a tradicionális Kubernetes-hez képest az egyes alkalmazáskomponensek nullára skálázása, valamint a konkurencia alapú skálázás. Mindkettőt a magasabb szintű absztrakció teszi lehetővé, ugyanis bár ezek Knative nélkül is elképzelhető funkciók, ezek megvalósítása számos extra komponens bevezetését igényelné. A nullára skálázáshoz szükséges egy perzisztensen létező egység, a Knative esetében az Istio, valamint a Knative Shared Gateway nevű komponens töltik be ezen egység szerepét. Konkurencia alapú skálázás esetében is ugyanez a komponens végzi a kérések elosztását. Az egy Podra eső átlagos konkurens kérések megfigyeléséért egy úgynevezett Knative Autoscaler felel. Ez az egység hozza a fel és leskálázási döntéseket, valamint a megfigyelt konkurencia érték alapján a pánik ablak kezdetét és végét.
Lényeges újítás a tradicionális Kubernetes-hez képest az egyes alkalmazáskomponensek nullára skálázása, valamint a konkurencia alapú skálázás. Mindkettőt a magasabb szintű absztrakció teszi lehetővé, ugyanis bár ezek Knative nélkül is elképzelhető funkciók, ezek megvalósítása számos extra komponens bevezetését igényelné. A nullára skálázáshoz szükséges egy perzisztensen létező egység, a Knative esetében az Istio, valamint a Knative Shared Gateway \cite{knative-gateweay} nevű komponens töltik be ezen egység szerepét. Konkurencia alapú skálázás esetében is ugyanez a komponens végzi a kérések elosztását. Az egy Podra eső átlagos konkurens kérések megfigyeléséért egy úgynevezett Knative Autoscaler \cite{knative-autoscaler} felel. Ez az egység hozza a fel és leskálázási döntéseket, valamint a megfigyelt konkurencia érték alapján a pánik ablak kezdetét és végét.
A pánik ablak akkor lép érvénybe, ha rövid idő alatt nagy terhelés érkezik egy végpontra. Konkrétan a Service létrehozása során megadott célkonkurencia érték kétszerese, kevesebb, mint hat másodperc alatt. Csak a Knative által bevezetett, konkurencia - azaz egy Service-hez egyidőben beérkező kérések száma - alapú skálázás esetében értelmezhető a pánik ablak. Ekkor viszont nincs lehetőség nullára skálázásra, ugyanis legalább egy Podnak mindig léteznie kell. Pánik ablak során a Knative a konkurencia alapján kiszámolt szükséges Podok számának kétszeresét hozza létre. A terhelés stabilizálódása, vagy hatvan másodperc elteltével a Podok száma visszatér a megfigyelt stabil konkurencia alapján szükséges számúra. Az aktuális konkurencia kiszámítása a Service által létrehozott Podokra átlagolva kerül kiszámításra. Ebből a szükséges Podok számát az észlelt konkurenciát a Service létrehozása során megadott célkonkurenciával elosztva számolja ki a rendszer.
A pánik ablak \cite{knative-autoscaler-component} akkor lép érvénybe, ha rövid idő alatt nagy terhelés érkezik egy végpontra. Konkrétan a Service létrehozása során megadott célkonkurencia érték kétszerese, kevesebb, mint hat másodperc alatt. Csak a Knative által bevezetett, konkurencia - azaz egy Service-hez egyidőben beérkező kérések száma - alapú skálázás esetében értelmezhető a pánik ablak. Ekkor viszont nincs lehetőség nullára skálázásra, ugyanis legalább egy Podnak mindig léteznie kell. Pánik ablak során a Knative a konkurencia alapján kiszámolt szükséges Podok számának kétszeresét hozza létre. A terhelés stabilizálódása, vagy hatvan másodperc elteltével a Podok száma visszatér a megfigyelt stabil konkurencia alapján szükséges számúra. Az aktuális konkurencia kiszámítása a Service által létrehozott Podokra átlagolva kerül kiszámításra. Ebből a szükséges Podok számát az észlelt konkurenciát a Service létrehozása során megadott célkonkurenciával elosztva számolja ki a rendszer.
A Knative automatikusan elvégzi az Istio service mesh létrehozását minden telepített alkalmazáshoz, valamint a konfigurációjának frissen tartását, ezzel a felhasználóknak csak kivételes esetekben kell foglalkoznia. Lehetőség van Istio helyett Gloo használatára terheléskiegyenlítőként, de ilyenkor nem minden funkció érhető el. Előnye, hogy kevesebb erőforrást használ, mint az Istio. A szakdolgozatban azért döntöttem az előbbi használata mellett, mert úgy véltem a Knative fejlesztők azt helyezték fókuszba, azt támogatják. További kutatás tárgya lehet a két load balancer közti különbségek vizsgálata.
A Knative automatikusan elvégzi az Istio service mesh létrehozását minden telepített alkalmazáshoz, valamint a konfigurációjának frissen tartását, ezzel a felhasználóknak csak kivételes esetekben kell foglalkoznia. Lehetőség van Istio helyett Gloo \cite{knative-gloo} használatára terheléskiegyenlítőként, de ilyenkor nem minden funkció érhető el. Előnye, hogy kevesebb erőforrást használ, mint az Istio. A szakdolgozatban azért döntöttem az előbbi használata mellett, mert úgy véltem a Knative fejlesztők azt helyezték fókuszba, azt támogatják. További kutatás tárgya lehet a két load balancer közti különbségek vizsgálata.
Opcionálisan telepíthető monitoring eszközök segítségével megfigyelhetők a rendszer belső folyamatai, állapotai. Például lehetőség van megfigyelni egyebek mellett egyes függvények és Knative rendszer elemek processzor és memóriahasználatát, a skálázást végző komponens állapotát. A Knative Monitoring rendszere a megfigyelésre a Prometheus-t, vizualizációra a Grafana nevű szoftver használja. A naplóállományok feldolgozására Logstash-t és Elasitsearch-öt, az ezekből kinyert metrikák vizualizálására Kibana-t használ a rendszer. Beállítástól függően, de alapértelmezetten másodperces gyakorisággal vesz a Prometheus mintát a Knative állapotáról. Ez, illetve a Logstash folyamatok számottevő Input/Output műveletet generál, amely a klaszter teljesítményére negatív hatással lehet.
Opcionálisan telepíthető monitoring eszközök segítségével megfigyelhetők a rendszer belső folyamatai, állapotai. Például lehetőség van megfigyelni egyebek mellett egyes függvények és Knative rendszer elemek processzor és memóriahasználatát \cite{knative-monitoring} , a skálázást végző komponens állapotát. A Knative Monitoring rendszere a megfigyelésre a Prometheus-t, vizualizációra a Grafana nevű szoftver használja. A naplóállományok feldolgozására Logstash-t és Elasitsearch-öt, az ezekből kinyert metrikák vizualizálására Kibana-t használ a rendszer. Beállítástól függően, de alapértelmezetten másodperces gyakorisággal vesz a Prometheus mintát a Knative állapotáról. Ez, illetve a Logstash folyamatok számottevő Input/Output műveletet generál, amely a klaszter teljesítményére negatív hatással lehet.
A Serving komponens a Kubernetes és az Istio már meglévő szolgáltatásait felhasználva, azokra építve nyújtja többletszolgáltatásait. A Kubernetes API-t kiegészítve bevezet néhány új objektumtípust: