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

grammar fixing in progress

Browse Source
This commit is contained in:
Torma Kristóf 2019-12-12 01:40:21 +01:00
parent 61510d2f87
commit 8b3d4de355
Signed by: tormakris
GPG Key ID: DC83C4F2C41B1047
7 changed files with 68 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/content/abstract.tex
View File

@ -8,13 +8,13 @@
%---------------------------------------------------------------------------- %----------------------------------------------------------------------------
\chapter*{Kivonat}\addcontentsline{toc}{chapter}{Kivonat} \chapter*{Kivonat}\addcontentsline{toc}{chapter}{Kivonat}
Napjainkban egyre elterjedtebb a webes alkalmazások fejlesztése során kisebb részegységek fejlesztése, melyeknek saját felelősségük is lehet. Ezzel a kódbázis növekedése nem vonzza maga után a kódbázis átláthatatlanságát. Erre egy megold\'as a Function as a Service architekt\'ura. Napjainkban egyre elterjedtebb a webes alkalmazások fejlesztése során kisebb részegységek fejlesztése, melyeknek saját felelősségük is lehet. Ezzel a kódbázis növekedése nem vonzza maga után annak az átláthatatlanságát. Erre egy megold\'as a Function as a Service architekt\'ura.
Fennáll viszont a probléma, hogy az egyes részek akkor is készen állnak kérések fogadására, ha nincs rájuk szükség, ezzel feleslegesen foglalva erőforrásokat. Szintúgy gyakori probléma a váratlanul megjelenő, nagy terhelésre a lassú válaszreakció. Ez a probléma legtöbbször nem egy rosszul elkészített alkalmazásból adódik, hanem a futtató környezet adottsága. Fennáll viszont a probléma, hogy az egyes részek akkor is készen állnak kérések fogadására, ha nincs rájuk szükség, ezzel feleslegesen foglalva az erőforrásokat. Szintúgy gyakori probléma a váratlanul megjelenő, nagy terhelésre a lassú válaszreakció. Ez a probléma legtöbbször nem egy rosszul elkészített alkalmazásból adódik, hanem a futtató környezet adottsága.
A Knative ezt a problém\'at oldja meg. Lehetővé teszi az egyes részegységek nullára skálázását, valamint képesek szolgáltatások gyors skálázására a megjelenő konkurens kérésekkel arányosan. A Knative ezt a problém\'at oldja meg. Lehetővé teszi az egyes részegységek nullára val\'o skálázását, tov\'abb\'a a megjelenő konkurens kérésekkel arányosan k\'epes a szolg\'altat\'asok gyors sk\'al\'az\'as\'ara.
A szakdolgozat keretein belül a Knative ezen funkciójának működését vizsgálom. Ehhez kidolgoztam m\'er\'eseket, melyek betekint\'est ny\'ujtanak a rendszer belső műk\"od\'es\'ebe. Feladatom r\'eszek\'ent a kidolgozott m\'er\'eseket, valamint azok eredm\'enyeinek al\'izis\'et automatiz\'altam, ami felgyors\'itja az eredm\'enyek \'ertelmez\'es\'et. A szakdolgozat keretein belül a Knative ezen funkciójának működését vizsgálom. Ehhez kidolgoztam m\'er\'eseket, melyek betekint\'est ny\'ujtanak a rendszer belső műk\"od\'es\'ebe. Feladatom r\'eszek\'ent a kidolgozott m\'er\'eseket, valamint azok eredm\'enyeinek anal\'izis\'et automatiz\'altam, ami felgyors\'itja az eredm\'enyek \'ertelmez\'es\'et.
Dolgozatom kifejezetten hasznos lehet azoknak, akik d\"onteni pr\'ob\'alnak a Knative haszn\'alata mellett, vagy meg szeretn\'ek tudni, hogy műk\"odik ez a rendszer. Dolgozatom kifejezetten hasznos lehet azoknak, akik d\"onteni pr\'ob\'alnak a Knative haszn\'alata mellett, vagy meg szeretn\'ek tudni, hogy műk\"odik ez a rendszer.

2
src/content/closing.tex
View File

@ -7,7 +7,7 @@ A méréseim alapján számos következtetést le lehet vonni a Knative és a Ku
A Kubeless a Knative-val szemben sokkal egyszerűbb skálázási mechanizmust alkalmaz. Nem számít, hogy a terhelés milyen karakterisztikával éri el a skálázási határt, ha a processzor használat meghaladja az előre beállított értéket, felskálázza a függvényt. Eme egyszerűség hátránya, hogy nem képes gyorsan reagálni a rövid idő alatt megnövekedő terhelésre. Fontosnak tartom megemlíteni, hogy annak ellenére, hogy ez az egyszerűbb rendszer, a Knative esetében nem ütköztem olyan hibába, amely meggátolta volna a rendszer használatát. A Kubeless a Knative-val szemben sokkal egyszerűbb skálázási mechanizmust alkalmaz. Nem számít, hogy a terhelés milyen karakterisztikával éri el a skálázási határt, ha a processzor használat meghaladja az előre beállított értéket, felskálázza a függvényt. Eme egyszerűség hátránya, hogy nem képes gyorsan reagálni a rövid idő alatt megnövekedő terhelésre. Fontosnak tartom megemlíteni, hogy annak ellenére, hogy ez az egyszerűbb rendszer, a Knative esetében nem ütköztem olyan hibába, amely meggátolta volna a rendszer használatát.
\section{Tov\'abbi kutat\'asi lehetős\'egek} \section{Tov\'abbi kutat\'asi lehetős\'egek}
Az általam elvégzett munka számos irányba folytatható. Érdekes lehet ugyanezen méréseket elvégezni olyan klaszteren, amelynek több Worker is tagja. Ez \'altal a Workerek k\"oz\"otti \"utemez\'es elem\'ez\'es\'ere is lehetős\'eg ny\'ilik. Emellett \'erdemes lehet menedzselt Kubernetesbe - p\'eld\'aul Google Kubernetes Engine-be - telep\'itett Knative viselked\'es\'enek vizsg\'alata. Az általam elvégzett munka számos irányba folytatható. Érdekes lehet ugyanezen méréseket elvégezni olyan klaszteren, amelynek több Worker is tagja. Ez \'altal a Workerek k\"oz\"otti \"utemez\'es elem\'ez\'es\'ere is lehetős\'eg ny\'ilik. Emellett \'erdemes lehet menedzselt Kubernetes-be - p\'eld\'aul Google Kubernetes Engine-be - telep\'itett Knative viselked\'es\'enek vizsg\'alata.
Az elkészített Python programok és bash szkriptek felhasználhatók akár a Knative további mérései során, vagy kisebb adaptációkkal könnyen felhasználható másik rendszerek mérésére. Hasonlóan, az eszközkészlet továbbfejlesztése, komplexebb ábrák, azok finomítása hasznos és érdekes további fejlesztési irány lehet. Az elkészített Python programok és bash szkriptek felhasználhatók akár a Knative további mérései során, vagy kisebb adaptációkkal könnyen felhasználható másik rendszerek mérésére. Hasonlóan, az eszközkészlet továbbfejlesztése, komplexebb ábrák, azok finomítása hasznos és érdekes további fejlesztési irány lehet.

2
src/content/create-functions.tex
View File

@ -55,6 +55,6 @@ spec:
value: "Py" value: "Py"
\end{lstlisting} \end{lstlisting}
Az elkészített függvényen, valamint a Docker Image-eket leíró Dockerfile-okat Git verziókezelőrendszerrel kezeltem, a létrehozott repository-t a GitHub szolgáltatásba feltöltöttem. Ez lehetővé tette a Travis Continuos Integration/Continuos Delivery rendszer használatát. Ezt arra használtam, hogy a változások nyugtázása után, valamint azok GitHubra történő feltöltése után a Docker Image-ek automatikusan épüljenek meg, valamint kerüljenek fel a Docker Hubra. Fontos, hogy ez nem feltétlen jelenti, hogy a Kubernetesben éppen futó, vagy később létrejövő Podok a legfrissebb Image-et fogják használni. Ahhoz szükség van vagy a latest nevű címkét használni, vagy az ImagePullPolicy nevű opciót bekapcsolni a Knative Service, vagy Kubernetes Deployment definiálásánál. Az elkészített függvényen, valamint a Docker Image-eket leíró Dockerfile-okat Git verziókezelőrendszerrel kezeltem, a létrehozott repository-t a GitHub szolgáltatásba feltöltöttem. Ez lehetővé tette a Travis Continuos Integration/Continuos Delivery rendszer használatát. Ezt arra használtam, hogy a változások nyugtázása után, valamint azok GitHubra történő feltöltése után a Docker Image-ek automatikusan épüljenek meg, valamint kerüljenek fel a Docker Hubra. Fontos, hogy ez nem feltétlen jelenti, hogy a Kubernetes-ben éppen futó, vagy később létrejövő Podok a legfrissebb Image-et fogják használni. Ahhoz szükség van vagy a latest nevű címkét használni, vagy az ImagePullPolicy nevű opciót bekapcsolni a Knative Service, vagy Kubernetes Deployment definiálásánál.
Az elkészített függvények Kubelessbe telepítése a korábban telepített parancssori interfész segítségével lehetséges. A függvény telepítése, ahhoz http végpont csatolása, valamint a skálázás létrehozása különálló parancs. Skálázás esetében a processzor limit alkalmazása a függvény telepítését végző parancs argumentumaként adható meg. Ebből adódóan skálázás esetén nem lehet csak a skálázás telepítését végrehajtó parancsot kiadni. A Kubeless függvények telepítését megkönnyítendő, elkészítettem egy bash nyelven írt szkriptet, amely paramétereként elvárja a függvény és az állomány nevét, ami tartalmazza azt, illetve a futtató környezet nevét és azt, hogy kell-e skálázás. Ezek alapján kiadja a szükséges parancsokat helyesen paraméterezve. Ezáltal a parancssori interfész helyes használatát gyorsabbá és könnyebbé tettem. Az elkészített függvények Kubelessbe telepítése a korábban telepített parancssori interfész segítségével lehetséges. A függvény telepítése, ahhoz http végpont csatolása, valamint a skálázás létrehozása különálló parancs. Skálázás esetében a processzor limit alkalmazása a függvény telepítését végző parancs argumentumaként adható meg. Ebből adódóan skálázás esetén nem lehet csak a skálázás telepítését végrehajtó parancsot kiadni. A Kubeless függvények telepítését megkönnyítendő, elkészítettem egy bash nyelven írt szkriptet, amely paramétereként elvárja a függvény és az állomány nevét, ami tartalmazza azt, illetve a futtató környezet nevét és azt, hogy kell-e skálázás. Ezek alapján kiadja a szükséges parancsokat helyesen paraméterezve. Ezáltal a parancssori interfész helyes használatát gyorsabbá és könnyebbé tettem.

6
src/content/introduction.tex
View File

@ -3,12 +3,12 @@
\chapter{\bevezetes} \chapter{\bevezetes}
%---------------------------------------------------------------------------- %----------------------------------------------------------------------------
Feladatom a Knative keretrendszer automatiz\'alt telep\'it\'ese, majd sk\'al\'az\'asi k\'epess\'eg\'enek vizsg\'alata, aminek r\'eszek\'ent l\'etre kell hozzak f\"uggv\'enyeket, melyek seg\'its\'eg\'evel a vizs\'g\'alat elv\'egezhető. Nincs specifik\'alva milyen infrastrukt\'ur\'at haszn\'aljak, viszont nem rendelkezem a feladathoz sz\"uks\'eges nagy teljes\'itm\'enyű sz\'am\'it\'og\'epekkel, ez\'ert a Cloudlab \cite{cloudlab} \'altal biztos\'itott szervereken kell dolgozzak. Feladatom a Knative keretrendszer automatiz\'alt telep\'it\'ese, majd sk\'al\'az\'asi k\'epess\'eg\'enek vizsg\'alata, aminek r\'eszek\'ent l\'etre kell hozzak f\"uggv\'enyeket, melyek seg\'its\'eg\'evel a vizsg\'alat elv\'egezhető. Nincs specifik\'alva milyen infrastrukt\'ur\'at haszn\'aljak, viszont nem rendelkezem a feladathoz sz\"uks\'eges nagy teljes\'itm\'enyű sz\'am\'it\'og\'epekkel, ez\'ert a Cloudlab \cite{cloudlab} \'altal biztos\'itott szervereken kell dolgozzak.
Mivel 2017-\'ota tagja vagyok a Sch\"onherz Koll\'egiumban műk\"odő Koll\'egiumi Sz\'am\'it\'astechnikai K\"ornek, ahol k\"ul\"onf\'ele Linux alap\'u rendszerek, valamint a koll\'egiumi h\'al\'ozat \"uzemeltet\'es\'evel foglalkozom, ez\'ert Linuxos \'es h\'al\'ozatos alaptud\'asom a szakdolgozat kezd\'esekor jelentős volt. Mivel 2017-\'ota tagja vagyok a Sch\"onherz Koll\'egiumban műk\"odő Koll\'egiumi Sz\'am\'it\'astechnikai K\"ornek, ahol k\"ul\"onf\'ele Linux alap\'u rendszerek, valamint a koll\'egiumi h\'al\'ozat \"uzemeltet\'es\'evel foglalkozom, ez\'ert Linuxos \'es h\'al\'ozatos alaptud\'asom a szakdolgozat kezd\'esekor jelentős volt.
Kont\'eneriz\'aci\'oval \'es a Dockerrel a T\'emalaborat\'orium tant\'argy keretein bel\"ul ismerkedtem meg, az\'ota napi szinten haszn\'alom. Mivel k\"ul\"on\"osen \'erdekel a szoftverfejleszt\'essel kapcsolatos folyamatok automatiz\'aci\'oja, ez\'ert igyekszem olyan folyamatokat is automatiz\'alni, melyeket a feladatom nem specifik\'alt, ilyen p\'eld\'aul a m\'er\'esi eredm\'enyekből kezdetleges grafikonok gener\'al\'asa. Az erre kialak\'itott rendszer m\'eg a munka kezd\'ese előtt megfogalmaz\'odott bennem. Az automatiz\'aci\'ohoz Python \'es bash nyelven \'irt programokat \'es szkripteket haszn\'altam, ugyanis ezeket a nyelveket ismerem. Kont\'eneriz\'aci\'oval \'es a Dockerrel a T\'emalaborat\'orium tant\'argy keretein bel\"ul ismerkedtem meg, az\'ota napi szinten haszn\'alom. Mivel k\"ul\"on\"osen \'erdekel a szoftverfejleszt\'essel kapcsolatos folyamatok automatiz\'aci\'oja, ez\'ert igyekszem olyan folyamatokat is automatiz\'alni, melyeket a feladatom nem specifik\'alt, ilyen p\'eld\'aul a m\'er\'esi eredm\'enyekből kezdetleges grafikonok gener\'al\'asa. Az erre kialak\'itott rendszer m\'eg a munka kezd\'ese előtt megfogalmaz\'odott bennem. Az automatiz\'aci\'ohoz Python \'es Bash nyelven \'irt programokat \'es szkripteket haszn\'altam, ugyanis ezeket a nyelveket ismerem.
A Knative-val m\'eg nem dolgoztam, ez\'ert a munk\'at irodalomkutat\'assal kezdtem, eg\'esz pontosan a sk\'al\'az\'od\'asi lehetős\'egek megismer\'es\'evel, valamint a belső rendszerek felt\'erk\'epez\'es\'evel. Ez ut\'an l\'attam neki a telep\'it\'es automatiz\'al\'as\'anak \'es a f\"uggv\'enyek l\'etrehoz\'as\'anak \'es a m\'er\'esek kidolgoz\'as\'anak. A Knative-val m\'eg nem dolgoztam, ez\'ert a munk\'at irodalomkutat\'assal kezdtem, eg\'esz pontosan a sk\'al\'az\'od\'asi lehetős\'egek megismer\'es\'evel, valamint a belső rendszerek felt\'erk\'epez\'es\'evel. Ezut\'an l\'attam neki a telep\'it\'es automatiz\'al\'as\'anak, a f\"uggv\'enyek l\'etrehoz\'as\'anak \'es a m\'er\'esek kidolgoz\'as\'anak.
Dolgozatom felt\'etelezi, hogy az olvas\'o rendelkezik alapvető Linuxos \'es webes technol\'ogi\'akkal kapcsolatos tud\'assal. Dolgozatom felt\'etelezi, hogy az olvas\'o rendelkezik alapvető Linuxos \'es webes technol\'ogi\'akkal kapcsolatos tud\'assal.

6
src/content/preparation.tex
View File

@ -31,7 +31,7 @@ Miután a klaszter minden tagja telepítésre került a további lépéseket a k
\subsection{Kubeless telep\'it\'ese} \subsection{Kubeless telep\'it\'ese}
A Kubeless telepítése négy lépésből áll. Először a metrics-server nevű komponens telepítésére kerül sor. Erre a Kubeless által használt Horizontal Pod Autoscaler miatt van szükség, ugyanis ez a komponens gyűjti számára a metrikákat a Podokról. Ennek telepítése nem csak a fejlesztők által elkészített YAML állomány applikálásából áll, ugyanis a metrics-server alapértelmezés szerint mutual TLS protokollal titkosítja a kommunikációját a Kubernetes klaszterrel. Erre nincs szükség ebben a klaszterben, ezért ki lehet kapcsolni ezt a viselkedést, amit egy kapcsolóval lehet megtenni. Ez jól automatizálható sed program használatával. A módosított YAML fájlt már applikálni lehet. A Kubeless telepítése négy lépésből áll. Először a metrics-server nevű komponens telepítésére kerül sor. Erre a Kubeless által használt Horizontal Pod Autoscaler miatt van szükség, ugyanis ez a komponens gyűjti számára a metrikákat a Podokról. Ennek telepítése nem csak a fejlesztők által elkészített YAML állomány applikálásából áll, ugyanis a metrics-server alapértelmezés szerint mutual TLS protokollal titkosítja a kommunikációját a Kubernetes klaszterrel. Erre nincs szükség ebben a klaszterben, ezért ki lehet kapcsolni ezt a viselkedést, amit egy kapcsolóval lehet megtenni. Ez jól automatizálható sed program használatával. A módosított YAML fájlt már applikálni lehet.
Ez után a második lépés az Nginx Ingress Controller telepítése. Itt nincs választási lehetőség, ugyanis a Kubelessbe ez a függőség erősen be van kötve. E komponens telepítéséhez két YAML állományt kell applikálni. Azért kettőt, mert van lehetőség menedzselt Kubernetesbe, valamint saját klaszterbe is telepíteni az Nginx Ingress Controllert. A két állomány közül az egyik minden Kubernetes környezet használata esetén alkalmazásra kell kerüljön, a másik pedig specifikus a felhasználó által használt Klaszter típusához, például Azure Kubernetes, vagy Google Container Engine és saját Kubernetes klaszterekhez külön-külön YAML állomány tartozik. Ez után a második lépés az Nginx Ingress Controller telepítése. Itt nincs választási lehetőség, ugyanis a Kubelessbe ez a függőség erősen be van kötve. E komponens telepítéséhez két YAML állományt kell applikálni. Azért kettőt, mert van lehetőség menedzselt Kubernetes-be, valamint saját klaszterbe is telepíteni az Nginx Ingress Controllert. A két állomány közül az egyik minden Kubernetes környezet használata esetén alkalmazásra kell kerüljön, a másik pedig specifikus a felhasználó által használt Klaszter típusához, például Azure Kubernetes, vagy Google Container Engine és saját Kubernetes klaszterekhez külön-külön YAML állomány tartozik.
A Kubeless könnyebb kezelése érdekében a harmadik telepítésre kerülő komponens a kubeless parancssori interfész. Ezt a programot már a fejlesztők lefordították, így csupán a megfelelő verzió beszerzése szükséges, annak egy olyan könyvtárba mozgatása, ahol a bash parancssori értelmező keresi a futtatható programokat, például a /usr/local/bin/ könyvtárba. A Kubeless könnyebb kezelése érdekében a harmadik telepítésre kerülő komponens a kubeless parancssori interfész. Ezt a programot már a fejlesztők lefordították, így csupán a megfelelő verzió beszerzése szükséges, annak egy olyan könyvtárba mozgatása, ahol a bash parancssori értelmező keresi a futtatható programokat, például a /usr/local/bin/ könyvtárba.
@ -40,9 +40,9 @@ Negyedik és utolsó lépésként a Kubeless klaszterbe telepítésére kerül s
Az itt leírt lépések bash szkript segítségével automatizálhatók. Az itt leírt lépések bash szkript segítségével automatizálhatók.
\subsection{Knative telep\'it\'ese} \subsection{Knative telep\'it\'ese}
A Knative telepítése kevesebb komponens feltelepítéséből áll, azok telepítése viszont bonyolultabb. A rendszer telepítése előtt installálni kell az Istiot. Ezt a helm nevű Kuberneteshez készített csomagkezelő rendszer segítségével lehet, viszont a helmet is installálni kell. Ez az Ubuntu rendszerben lévő snap csomagkezelővel telepíthető. A snap abban különbözik az apt-tól, hogy az általa telepített csomagok és a függőségeik a rendszercsomagoktól és a rendszerben jelen lévő osztott könyvtáraktól függetlenek, de hatással lehetnek a rendszerre. A Knative telepítése kevesebb komponens feltelepítéséből áll, azok telepítése viszont bonyolultabb. A rendszer telepítése előtt installálni kell az Istiot. Ezt a helm nevű Kubernetes-hez készített csomagkezelő rendszer segítségével lehet, viszont a helmet is installálni kell. Ez az Ubuntu rendszerben lévő snap csomagkezelővel telepíthető. A snap abban különbözik az apt-tól, hogy az általa telepített csomagok és a függőségeik a rendszercsomagoktól és a rendszerben jelen lévő osztott könyvtáraktól függetlenek, de hatással lehetnek a rendszerre.
A helm telepítése után inicializálni kell, amely az úgynevezett Tiller a Kubernetesbe telepítését, valamint információegyeztetést a Tiller és a helm között jelenti. Viszont ahhoz, hogy a Tiller a klaszterben a kívánt módosításokat el tudja végezni meg kell neki adni a megfelelő jogosultságokat. Erre úgy van lehetőség, hogy létre kell hozni egy új, úgynevezett Service Accountot, amely hasonlóan viselkedik a felhasználói fiókokhoz, viszont ezt Podokhoz lehet rendelni. A létrehozott Service Accounthoz pedig a cluster-admin jogosultságot kell rendelni. Ennél lehet kevesebb jogot adni a Tillernek, viszont egyetlen felhasználója lesz a klaszternek, így nincs szükség finomhangolt jogosultságkezelésre. Csak e két lépés után lehet inicializálni a helmet, valamint a Tillert. A helm telepítése után inicializálni kell, amely az úgynevezett Tiller a Kubernetes-be telepítését, valamint információegyeztetést a Tiller és a helm között jelenti. Viszont ahhoz, hogy a Tiller a klaszterben a kívánt módosításokat el tudja végezni meg kell neki adni a megfelelő jogosultságokat. Erre úgy van lehetőség, hogy létre kell hozni egy új, úgynevezett Service Accountot, amely hasonlóan viselkedik a felhasználói fiókokhoz, viszont ezt Podokhoz lehet rendelni. A létrehozott Service Accounthoz pedig a cluster-admin jogosultságot kell rendelni. Ennél lehet kevesebb jogot adni a Tillernek, viszont egyetlen felhasználója lesz a klaszternek, így nincs szükség finomhangolt jogosultságkezelésre. Csak e két lépés után lehet inicializálni a helmet, valamint a Tillert.
Az Istio telepítésének megkezdése előtt létre kell hozni az általa bevezetett új objektumtípusokat, valamint egy külön névteret, ahova az Istio rendszer saját objektumai kerülhetnek. Ez számos YAML állomány applikálását jelenti. Ez után az Istio rendszert telepítő YAML állományt ki kell generáltatni a helmmel. A generálásnál lehetőség van megadni, az Istio mely komponensei ne települjenek. Nincs szükségünk például monitoring rendszerre, telemetria és jogosultságkezelő rendszerre. Ezeket parancssori paraméterrel lehet megadni. A generálás után létrehozott YAML fájl által leírt módosítások végrehajtását a megszokott módon kell végrehajtani. Az Istio telepítésének megkezdése előtt létre kell hozni az általa bevezetett új objektumtípusokat, valamint egy külön névteret, ahova az Istio rendszer saját objektumai kerülhetnek. Ez számos YAML állomány applikálását jelenti. Ez után az Istio rendszert telepítő YAML állományt ki kell generáltatni a helmmel. A generálásnál lehetőség van megadni, az Istio mely komponensei ne települjenek. Nincs szükségünk például monitoring rendszerre, telemetria és jogosultságkezelő rendszerre. Ezeket parancssori paraméterrel lehet megadni. A generálás után létrehozott YAML fájl által leírt módosítások végrehajtását a megszokott módon kell végrehajtani.

101
src/content/theory.tex
View File

@ -3,28 +3,28 @@
\label{sec:theory} \label{sec:theory}
\section{Felhő alapú szolgáltatások rendszerezése} \section{Felhő alapú szolgáltatások rendszerezése}
A felhő alapú számítástechnikában \cite{cloud} a felhasználó elől elrejtve, a szolgáltató erőforrás halmazán elosztva megvalósított szolgáltatásokat értjük, amit jellemzően virtualizációs technológiára építenek. Négy szolgáltatási modellt különböztetünk meg: SaaS \cite{saas} (Software as a Service, Szoftver, mint Szolgáltatás, például: Office 365), FaaS \cite{faas} (Function as a Service, Függvény, mint Szolgáltatás, például: Amazon Lambda), PaaS \cite{paas} (Platform as a Service, Platform, mint Szolgáltatás, például: Oracle Cloud Platform) és IaaS \cite{iaas} (Infrastructure as a Service, Infrastruktúra, mint Szolgáltatás, például: Microsoft Azure). A felhő alapú számítástechnikában \cite{cloud} a felhasználó elől elrejtve, a szolgáltató erőforrás halmazán elosztva megvalósított szolgáltatásokat értjük, amit jellemzően virtualizációs technológiára építenek. Négy szolgáltatási modellt különböztetünk meg: SaaS \cite{saas} (Software as a Service, Szoftver, mint Szolgáltatás, például: Office 365), FaaS \cite{faas} (Function as a Service, Függvény, mint Szolgáltatás, például: Amazon Lambda), PaaS \cite{paas} (Platform as a Service, Platform, mint Szolgáltatás, például: Oracle Cloud Platform) és IaaS \cite{iaas} (Infrastructure as a Service, Infrastruktúra, mint Szolgáltatás, például: Microsoft Azure). A tov\'abbiakban ezen szolg\'altat\'asmodellek angol nyelvű megnevez\'es\'et fogom haszn\'alni.
A Software as a Service szolgáltatási modellben a felhasználó egy kész szoftvercsomag használati jogát vásárolja meg vagy bérli. Ez azért felhő alapú szolgáltatás, mert a szoftver a szolgáltató infrastruktúráján fut. A végfelhasználóknak nincs rálátásuk a futó kódra vagy az infrastruktúrára. Ebből adódóan az üzemeltetési feladatok nem mérnöki jellegűek, legtöbbször csak a felhasználói fiókok adminisztrációjára van lehetőség. A Software as a Service szolgáltatási modellben a felhasználó egy kész szoftvercsomag használati jogát vásárolja meg vagy bérli. Ez azért felhő alapú szolgáltatás, mert a szoftver a szolgáltató infrastruktúráján fut. A végfelhasználóknak nincs rálátásuk a futó kódra vagy az infrastruktúrára. Ebből adódóan az üzemeltetési feladatok nem mérnöki jellegűek, legtöbbször csak a felhasználói fiókok adminisztrációjára van lehetőség.
A Function as a Service nem csak egy szolgáltatási modell, hanem megkövetel egy bizonyos szoftver architektúrát is. Az FaaS-t használó szoftverek függvényekből állnak. Ezek hasonlóak a tradicionális szoftverekben ismeretes függvényekhez, annyi különbséggel, hogy a bemeneti paraméterekre és a visszatérési értékre szabhat megkötéseket egy FaaS platform. A feltöltött függvények egy URL-en érhetők el, melyeket megnyitva az adott függvény lefut. Erre a futásra rálátása a felhasználónak nincs, csak a visszatért eredményt kapja meg. A felhasználó számára még a futtató környezet is ismeretlen. Emiatt a függvényeket csak a szolgáltató által nyújtott platformon lehet futtatni, tesztelni. Ez, valamint a nagyszámú komponensre bontott szoftver architektúra megnehezíti a hibakeresést, és a hibák előfordulási okának megtalálását. A Function as a Service nem csak egy szolgáltatási modell, hanem megkövetel egy bizonyos szoftverarchitektúrát is. Az FaaS-t használó szoftverek függvényekből állnak. Ezek hasonlóak a tradicionális szoftverekben ismeretes függvényekhez, annyi különbséggel, hogy a bemeneti paraméterekre és a visszatérési értékre szabhat megkötéseket egy FaaS platform. A feltöltött függvények egy URL-en érhetők el, melyeket megnyitva az adott függvény lefut. Erre a futásra rálátása a felhasználónak nincs, csak a visszatért eredményt kapja meg. A felhasználó számára még a futtató környezet is ismeretlen. Emiatt a függvényeket csak a szolgáltató által nyújtott platformon lehet futtatni, tesztelni. Ez, valamint a nagyszámú komponensre bontott szoftverarchitektúra megnehezíti a hibakeresést, és a hibák előfordulási okának megtalálását is.
Platform as a Service típusú szolgáltatások alatt értjük azon szolgáltatásokat, melyek lehetővé teszik egy elkészült alkalmazás futtatását egy, a szolgáltató által menedzselt platformon. A szolgáltatás felhasználójának csak a saját alkalmazásával felmerülő problémákat kell megoldania, a fizikai szervereket, operációs rendszert, valamint a middleware-t – ami lehet például Java futtatókörnyezet, vagy Kubernetes konténer orkesztrációs platform - a szolgáltató biztosítja. Ezek mellett gyakran adatbázis szolgáltatást is igénybe lehet venni. Egy PaaS platformon telepített alkalmazásban hibák keresése külön megfontolásokat nem igényel, a helyben és távolban futtatott példányok között különbség nincsen. Platform as a Service típusú szolgáltatások alatt értjük azon szolgáltatásokat, melyek lehetővé teszik egy elkészült alkalmazás futtatását egy, a szolgáltató által menedzselt platformon. A szolgáltatás felhasználójának csak a saját alkalmazásával felmerülő problémákat kell megoldania, a fizikai szervereket, operációs rendszert, valamint a middleware-t - ami lehet például Java futtatókörnyezet vagy Kubernetes konténer orkesztrációs platform - a szolgáltató biztosítja. Ezek mellett gyakran adatbázis szolgáltatást is igénybe lehet venni. Egy PaaS platformon telepített alkalmazásban hibák keresése külön megfontolásokat nem igényel, a helyben és távolban futtatott példányok között nincsen különbség.
Egy Infrastructure as a Service típusú szolgáltatás keretében a szolgáltató egy virtuális gépet nyújt a végfelhasználóknak. Erre a gépre tetszőleges operációs rendszer telepíthető. Ezt a szolgáltató legtöbb esetben legfeljebb monitoring lehetőségekkel bővíti. E szolgáltatási modell keretében üzemeltetett alkalmazással kapcsolatban fordul elő a legtöbb mérnöki probléma, ugyanis a hálózaton és a virtuális gépeket futtató szerverek nagy rendelkezésre állásán kívül a szolgáltató nem vállal semmilyen garanciát. Míg például a Platform as a Service szolgáltatások esetében az alkalmazás terheléstől függő skálázását a szolgáltató garantálta, erről és az ezzel kapcsolatban felmerülő problémák megoldásáról a felhasználónak kell gondoskodnia. Mindezért cserébe a felhasználónak behatása, illetve rálátása van a futtató környezetre. Egy Infrastructure as a Service típusú szolgáltatás keretében a szolgáltató egy virtuális gépet nyújt a végfelhasználóknak. Erre a gépre tetszőleges operációs rendszer telepíthető. Ezt a szolgáltató legtöbb esetben legfeljebb monitoring lehetőségekkel bővíti. E szolgáltatási modell keretében üzemeltetett alkalmazással kapcsolatban fordul elő a legtöbb mérnöki probléma, ugyanis a hálózaton és a virtuális gépeket futtató szerverek nagy rendelkezésre állásán kívül a szolgáltató nem vállal semmilyen garanciát. Míg például a Platform as a Service szolgáltatások esetében az alkalmazás terheléstől függő skálázását a szolgáltató garantálta, erről és az ezzel kapcsolatban felmerülő problémák megoldásáról a felhasználónak kell gondoskodnia. Mindezért cserébe a felhasználónak behatása - illetve rálátása van a futtató környezetre.
\section{Konténerizáció} \section{Konténerizáció}
A konténerizáció, vagy operációs rendszer szintű virtualizáció \cite{os-virt} alatt egy fizikai vagy virtuális számítógépen futó operációs rendszer egymástól független partíciókra osztását értjük. Általában szerverek virtualizálására használják. Számítógépek virtualizációjától \cite{dockervirt} lényeges eltérés, hogy a kernel - az operációs rendszer hardware-t kezelő része - nem kell fusson minden példányon, viszont hasonlóság, hogy a dinamikusan csatolt osztott könyvtárak minden konténerben külön betöltésre kerülnek a memóriába. A konténerizáció, vagy operációs rendszer szintű virtualizáció \cite{os-virt} alatt egy fizikai vagy virtuális számítógépen futó operációs rendszer egymástól független partíciókra osztását értjük. Általában szerverek virtualizálására használják. Számítógépek virtualizációjától \cite{dockervirt} lényeges eltérés, hogy a kernel - az operációs rendszer hardware-t kezelő része - nem kell fusson minden példányon, viszont hasonlóság, hogy a dinamikusan csatolt osztott könyvtárak minden konténerben külön betöltésre kerülnek a memóriába.
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. 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 ezutá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 is szükség van.
\subsection{Docker} \subsection{Docker}
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. 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 \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. 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} \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 \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. 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 is. 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: Néhány fontosabb szolgáltatás, melyet a Kubernetes nyújt:
\begin{itemize} \begin{itemize}
@ -34,7 +34,7 @@ Néhány fontosabb szolgáltatás, melyet a Kubernetes nyújt:
\end{itemize} \end{itemize}
\subsection{Kubernetes klaszter felépítése} \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 \cite{kubernetes-nodes} 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ő. A \ref{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] \begin{figure}[!ht]
\centering \centering
@ -43,66 +43,69 @@ Egy Kubernetes klaszterben két típusú hosztgép lehet. Mindkettőből lehet t
\label{fig:k8s-chart} \label{fig:k8s-chart}
\end{figure} \end{figure}
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. 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 klaszterszintű 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 \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. 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} \subsection{API Server}
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. 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} \subsection{Etcd}
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. 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} \subsection{Controller Manager}
Logikailag különböző kontrollereket összefoglaló komponens \cite{kuebrnetes-controller} . 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{kuebrnetes-controller}. Az alábbi kontrollereket a komplexitás csökkentése érdekében fordították egy binárisba:
\begin{itemize} \begin{itemize}
\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 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 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 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. \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} \end{itemize}
\subsection{Scheduler} \subsection{Scheduler}
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. 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} \subsection{Horizontal Pod Autoscaler}
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. 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 1 perces átlaga alapján zajlik.
\subsection{Slave Node} \subsection{Slave Node}
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: 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 komponenseit \aref{sec:container-runtime}, \aref{sec:kubelet} \'es \aref{sec:kube-proxy} alfejezetekben r\'eszletezem.
\subsection{Container Runtime} \subsection{Container Runtime}
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. \label{sec: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.
\subsection{Kubelet} \subsection{Kubelet}
Felelőssége \cite{kubernetes-kubelet} , hogy a Podok specifikációjuk szerinti állapotban fussanak. A klaszter összes tagján kötelezően fut. \label{sec:kubelet}
A kubelet \cite{kubernetes-kubelet} felelőss\'ege, hogy a podok specifikációjuk szerinti állapotban fussanak. A klaszter összes tagján kötelezően fut.
\subsection{Kube-Proxy} \subsection{Kube-Proxy}
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. \label{sec:kube-proxy}
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} \section{Kubernetes-ben létrehozható objektumok}
A Kubernetesben többek között az alábbi objektumok hozhatók létre: A Kubernetes-ben többek között az alábbi objektumok hozhatók létre:
\subsection{Pod} \subsection{Pod}
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. 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} \subsection{Deployment}
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é. 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 a 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 az alkalmazás komponensek lazább csatolását teszi lehetővé.
\subsection{Service} \subsection{Service}
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. 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} \subsection{Volume}
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. 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} \subsection{Ingress}
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. 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} \section{Kubeless}
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. 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, a Python, a Java, a Javascript és a 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 \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. 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. 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. 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.
@ -118,61 +121,62 @@ func hello(event functions.Event, context functions.Context) (string, error) {
} }
\end{lstlisting} \end{lstlisting}
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. Mint \aref{code:hello-kubeless-go} kódrészleten is látszik, a függvény első paraméter\'eben 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 \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. 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 \cite{kubeless-build} , amely \aref{fig:kubeless-pod-creation} \'abr\'an megfigyelhető, részleteiben eltér programnyelvenként azok sajátosságai miatt. Mivel a Kubernetes-ben 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] \begin{figure}[!ht]
\centering \centering
\includegraphics[width=120mm, keepaspectratio]{figures/kubeless_pod_creation.png} \includegraphics[width=120mm, keepaspectratio]{figures/kubeless_pod_creation.png}
\caption{Kubeless f\"uggv\'enyből Pod l\'etrehoz\'asa} \caption{Kubeless f\"uggv\'enyből pod l\'etrehoz\'asa}
\label{fig:kubeless-pod-creation} \label{fig:kubeless-pod-creation}
\end{figure} \end{figure}
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. 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. Ezutá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 bel\'epé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 \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. 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. 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 lesz a beérkező kérések elosztására.
\section{Istio} \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. Az Istio egy nyílt forráskódú, Kubernetes-be é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 \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. 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: Az Istio többek között képes:
\begin{itemize} \begin{itemize}
\item Forgalom irányítására, \item forgalom irányítására,
\item Autentikáció, autorizáció és titkosítás biztosítására, \item autentikáció, autorizáció és titkosítás biztosítására,
\item Házirendek definiálására, azok érvényesítésére, \item házirendek definiálására, azok érvényesítésére,
\item Automatikus monitoring és naplózása alkalmazás komponenseknek futtatására. \item automatikus monitoringja és naplózása az alkalmazás komponenseknek futtatásának.
\end{itemize} \end{itemize}
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. 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} \section{Knative}
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. 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.
Nem kifejezetten Function as a Service megoldásról van szó \cite{knative-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. Nem kifejezetten Function as a Service megoldásról van szó \cite{knative-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 Kubernetes-ben 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 \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. 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 \cite{knative-autoscaler-component} kezdetét és végét.
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 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 \'erkezik, kevesebb, mint 6 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 60 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 \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. 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 \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. 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 Elasticsearch-ö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 \cite{knative-crd} : 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 \cite{knative-crd}, melyeket \aref{sec:service} pontt\'ol \aref{sec:revision} pontig r\'eszletezek.
\subsection{Service} \subsection{Service}
\label{sec:service}
Egy alkalmazás vagy egy alkalmazáskomponens leírására egyetlen absztrakciót biztosít. A Knative-ban a Service egy Route-ra és egy Configurationre képződik le, valamint ezek orkesztrálását végzi. E két objektummal teljesen kiváltható a használata. A belső objektumok állapotait a Service kontrollere továbbítja a Kubernetes API-n keresztül, mintha sajátja lenne. Egy alkalmazás vagy egy alkalmazáskomponens leírására egyetlen absztrakciót biztosít. A Knative-ban a Service egy Route-ra és egy Configurationre képződik le, valamint ezek orkesztrálását végzi. E két objektummal teljesen kiváltható a használata. A belső objektumok állapotait a Service kontrollere továbbítja a Kubernetes API-n keresztül, mintha sajátja lenne.
\subsection{Route} \subsection{Route}
A Route, vagy útvonal egy hálózati végpontot biztosít egy alkalmazáshoz. Ez egy hosszú életű, stabil, http protokollon keresztül elérhető végpontot jelent, amelyet egy vagy több Revision szolgál ki. Alapértelmezés szerint a legfrissebb Revision felé irányítja a forgalmat a rendszer, de van lehetőség több ilyen objektum között elosztani a forgalmat bizonyos százalékos arányban. Hasonlóan, egy Route képes minden mögötte lévő Revision számára a rendszeren kívülről is elérhető aldomaint allokálni. A Route vagy útvonal egy hálózati végpontot biztosít egy alkalmazáshoz. Ez egy hosszú életű, stabil, http protokollon keresztül elérhető végpontot jelent, amelyet egy vagy több Revision szolgál ki. Alapértelmezés szerint a legfrissebb Revision felé irányítja a forgalmat a rendszer, de van lehetőség több ilyen objektum között elosztani a forgalmat bizonyos százalékos arányban. Hasonlóan, egy Route képes minden mögötte lévő Revision számára a rendszeren kívülről is elérhető aldomain-t allokálni.
Ez a funkcionalitás hasonlít a Kubernetes Service objektuméra, valamint az Ingress objektum bizonyos funkcióit is tartalmazza, adaptálja a Knative rendszerre. Ez a funkcionalitás hasonlít a Kubernetes Service objektuméra, valamint az Ingress objektum bizonyos funkcióit is tartalmazza, adaptálja a Knative rendszerre.
@ -180,6 +184,7 @@ Ez a funkcionalitás hasonlít a Kubernetes Service objektuméra, valamint az In
Szükség van alkalmazások, azok komponenseinek elvárt állapotának leírására. Kubernetes rendszerben erre a Deployment szolgál, ennek párja a Knative-ban a Configuration. Emellett ez az objektum tartja számon és hozza létre a Revisionöket, ahogy az elvárt állapot módosul. Szükség van alkalmazások, azok komponenseinek elvárt állapotának leírására. Kubernetes rendszerben erre a Deployment szolgál, ennek párja a Knative-ban a Configuration. Emellett ez az objektum tartja számon és hozza létre a Revisionöket, ahogy az elvárt állapot módosul.
\subsection{Revision} \subsection{Revision}
\label{sec:revision}
A Revision egy nem módosítható verziója egy alkalmazás kódjának, valamint konfigurációjának. Ez a gyakorlatban egy konténer képet jelent. Létrehozásuk a megfelelő Configuration objektum módosításával lehetséges. A Revision egy nem módosítható verziója egy alkalmazás kódjának, valamint konfigurációjának. Ez a gyakorlatban egy konténer képet jelent. Létrehozásuk a megfelelő Configuration objektum módosításával lehetséges.
Azok a Revisionök, melyek nem érhetők el egy Route-on keresztül sem, törlésre kerülnek. Viselkedésük hasonló a Podokéhoz, ilyen objektumokra képződnek le. Azok a Revisionök, melyek nem érhetők el egy Route-on keresztül sem, törlésre kerülnek. Viselkedésük hasonló a podokéhoz, ilyen objektumokra képződnek le.