Merge branch 'master' into markosz-3

src/bib/mybib.bib

@@ -429,5 +429,37 @@
 	title = {Lossless Audio Formats vs Lossy Audio Formats - A Complete Guide},
 	howpublished = {\url{https://www.musicgateway.com/blog/how-to/lossy-or-lossless-audio-formats}},
 	note = {Megtekintve: 2021-12-16}
+}
+
+
+@misc{libvirt_xml,
+	author = {},
+	title = {libvirt: XML format},
+	howpublished = {\url{https://libvirt.org/format.html}},
+	note = {Megtekintve: 2021-12-17}
+}
+
+
+@misc{ansible_docs,
+	title = {Ansible Documentation},
+	howpublished = {\url{https://docs.ansible.com/}},
+	note = {Megtekintve: 2021-12-17}
+}
+
+@misc{installing_kubefed,
+	title = {KubeFed documentation - Installing KubeFed},
+	howpublished = {\url{https://github.com/kubernetes-sigs/kubefed/blob/master/docs/installation.md}},
+	note = {Megtekintve: 2021-12-17}
+}
+
+@manual{man_tc,
+	title      = "TC(8) System Administration tools and Daemons",
+	%author        = "",
+	%organization  = "",
+	%address   = "",
+	edition   = "5.15.0",
+	year       = "2001",
+	month      = "December",
+	%note      = "",
+}
 
-}

src/content/birbnetes_impl.tex

@@ -61,7 +61,7 @@ Az előszűrés által adott sávszélesség megtakarítást nehéz megbecsülni
 		Eredeti Tanító minta részlet & 190 & 152 & 80.0\% \\
 		Erdei hangfelvétel madárcsiripeléssel & 1000 & 288 & 28.8\% \\
 		Erdő, kevés madárcsiripeléssel & 316 & 53 & 16.7\% \\
-		Erdőszél, este & 1500 & ? & ?\% \\
+		Erdőszél, este & 1500 & ? & ?\% \\ %TODO: Ezt ne felejtsem el kitölteni
 		\hline
 	\end{tabular}
 	\caption{Első fázisú \acrshort{mi} áteresztésének vizsgálata különböző hangmintákra}
@@ -76,7 +76,7 @@ Ennek a problémának a megoldására nyújt lehetőséget a peremhálózati ren
 
 A tervezés során fontosnak tartottam, hogy a rendszer többi komponensében minimális változtatásokat kelljen tenni. Az eredeti rendszer mikroszolgáltatás architektúrára épült, így az egyes komponensek felelőssége jól elkülönül. A megtervezett architektúrába könnyen beilleszthető extra funkcionalitás. 
 
-Mivel \textit{Kubefed} keretrendszert választottam az alkalmazásom futtatására, ezért egyértelmű volt, hogy a már meglévő alkalmazás komponenseken nem kell módosítani. Hiszen a \textit{Kubefed} csak kiegészíti a \textit{Kubernetes} funkcionalitását, amely az eredeti rendszer tervezésénél is meghatározó volt. Az első szintű \acrshort{mi} algoritmust ezekből az okokból egy újabb mikroszolgáltatásként terveztem meg. 
+Mivel \textit{KubeFed} keretrendszert választottam az alkalmazásom futtatására, ezért egyértelmű volt, hogy a már meglévő alkalmazás komponenseken nem kell módosítani. Hiszen a \textit{KubeFed} csak kiegészíti a \textit{Kubernetes} funkcionalitását, amely az eredeti rendszer tervezésénél is meghatározó volt. Az első szintű \acrshort{mi} algoritmust ezekből az okokból egy újabb mikroszolgáltatásként terveztem meg. 
 
 Az \acrshort{iot} eszközön futó szoftver \acrshort{http} interfészen keresztül tölti fel a mintákat. Az új mikroszolgáltatást proxy-ként terveztem meg, azaz egy ugyanolyan \acrshort{http} interfészt szolgál ki, mint a felhőben a hangfájlok fogadására szolgáló végpont. Ha az \acrshort{ml} algoritmus madárcsiripelést azonosít a mintában, akkor azt módosítás nélkül továbbküldi,  így az eszközök és a felhő számára is teljesen transzparens módon tud működni az új szolgáltatás. A megváltozott architektúráról \aref{fig:birbnetes_super_simple_services}.\ ábra ad vázlatos áttekintést. Ez a szolgáltatás egyformán futhat a felhőben, de a peremen is, nincsenek lokalitási kötöttségei.
 

src/content/glossary.tex

@@ -68,7 +68,6 @@
 	description={OpenXML standard kompatibilis XML fájlok halmaza \textit{ZIP} csomagban. A \textit{Microsoft} fejlesztette 2007-ben. Többek között a \textit{Microsoft Excel 2007} és újabb táblázatkezelők használják}
 }
 
-
 \newacronym{mdt}{MDT}{Model-Driven Telemetry}
 \newacronym{ai}{AI}{Artificial Intelligence}
 \newacronym{ml}{ML}{Machine Learning}
@@ -154,4 +153,6 @@
 \newacronym{rtde}{RTDE}{Real-time Data Exchange}
 \newacronym{rdp}{RDP}{Remote Desktop Protocol}
 \newacronym{cpu}{CPU}{Central Processing Unit}
-\newacronym{oci}{OCI}{Open Container Initiative}
+\newacronym{oci}{OCI}{Open Container Initiative}
+\newacronym{raid}{RAID}{Redundant Array of Independent Disks}
+\newacronym{ssd}{SSD}{Solid State Drive}

src/content/overview.tex

@@ -242,7 +242,7 @@ Az \textit{Azure \acrshort{iot} Edge} előnye, hogy egy kiforrott ipari megoldá
 \subsection{Kubernetes Federation}
 % Nem erre való, de jó erre
 
-A \textit{Kubernetes Federation} (Röviden \textit{Kubefed}) eredetileg a \textit{Kubernetes} projekt részeként született \cite{kubefed_old}. Később külön projektként folytatódott a fejlesztése. A projekt célja az, hogy több teljesen önálló \textit{Kubernetes} klaszter \enquote{fölé} egy egységes vezérlő réteget húzzon, ezzel megvalósítva a több klaszter egységes kezelését és felügyeletét \cite{kubefed_readme}. 
+A \textit{Kubernetes Federation} (Röviden \textit{KubeFed}) eredetileg a \textit{Kubernetes} projekt részeként született \cite{kubefed_old}. Később külön projektként folytatódott a fejlesztése. A projekt célja az, hogy több teljesen önálló \textit{Kubernetes} klaszter \enquote{fölé} egy egységes vezérlő réteget húzzon, ezzel megvalósítva a több klaszter egységes kezelését és felügyeletét \cite{kubefed_readme}. 
 
 Az üzemeltetés szempontjából, ezt úgy valósul meg, hogy kijelöl egy federáció vezérlő (federation controller) klasztert. Ez lesz az irányító klaszter (nagyjából olyan szerepe van mint a mester node-nak a klaszteren belül). Ehhez csatlakozik be a többi klaszter. Az egyes federált funkcionalitások megvalósítására egyedi \acrshort{api} objektumokat hoz létre. Ilyen objektumokkal tudjuk kezelni egységesen a multiklaszter erőforrásokat \cite{kubefed_userguide}. 
 
@@ -250,7 +250,7 @@ Implementáció szempontjából a federáció vezérlőre telepít és futtat ol
 
 Egy federált \textit{Kubernetes} környezetnek több felhasználása is lehet, de a felhasználási mintákban szinte alapvető, hogy az önálló klaszterek földrajzilag elhatárolva üzemelnek \cite{kubernetes_why_federation}. Ez megfeleltethető annak, ahogy a peremhálózati rendszerek és a felhő rendszerek is különállóan üzemelnek.
 
-Bár egyértelműen látszik, hogy a \textit{Kubefed} elsősorban nem a peremhálózati rendszerek által nyújtott elvárások kielégítésre lett kifejlesztve, általános klaszter federációs megoldásként viszont képes arra, hogy az ezen a téren támasztott elvárásoknak is megfelel.
+Bár egyértelműen látszik, hogy a \textit{KubeFed} elsősorban nem a peremhálózati rendszerek által nyújtott elvárások kielégítésre lett kifejlesztve, általános klaszter federációs megoldásként viszont képes arra, hogy az ezen a téren támasztott elvárásoknak is megfelel.
 
 Népszerűségének köszönhetően sok dokumentáció, leírás és egyéb segítség létezik hozzá. Emellett erősen épít a \textit{Kubernetes} szolgáltatásaira és tervezési mintáira. Ezeknek köszönhetően az üzemeltetése viszonylag egyszerű a \textit{Kubernetes} klaszterek terén jártas üzemeltetők számára.
 

src/content/test_system.tex

@@ -45,11 +45,11 @@ A teszt infrastruktúrát két szempontból bontottam fel: az egyik az előbb em
 
 \subsubsection{Futtató környezet}
 
-A környezetben szükség van a választott alkalmazás futtató keretrendszer (esetünkben \textit{Kubedfed}) futtatására. A \textit{Kubefed} lényegében több \textit{Kubernetes} klaszter fölé húzott közös vezérlési réteg. Ennek megfelelően virtuális gépeket csoportokra bontottam, adott csoportok egy-egy \textit{Kubernetes} klasztert valósítanak meg.
+A környezetben szükség van a választott alkalmazás futtató keretrendszer (esetünkben \textit{KubeFed}) futtatására. A \textit{KubeFed} lényegében több \textit{Kubernetes} klaszter fölé húzott közös vezérlési réteg. Ennek megfelelően virtuális gépeket csoportokra bontottam, adott csoportok egy-egy \textit{Kubernetes} klasztert valósítanak meg.
 
 Az egyes \textit{Kubernetes} klaszterek esetünkben az egyes adatközpontokat szimbolizálják. Egy ilyen klaszter jelöli a felhő adatközpontot, a többi klaszter pedig jelölheti a peremhálózati adatközpontokat vagy akár további felhőket is. A tesztelendő alkalmazások szempontjából, nincs számottevő különbség egy felhő vagy egy peremhálózati adatközpont belső működésében, ezért itt főképp csak az elnevezésükben térnek el.
 
-Az önálló \textit{Kubernetes} klaszterek fölé már lehet \textit{Kubefed} környezetet telepíteni. A telepített \textit{Kubefed} szoftver megfelelően modellezi a valós környezetben használt futtató környezetet, hiszen ugyanaz a szoftver. Telepítése és üzemeltetése között nincs különbség a valós és teszt környezetben.
+Az önálló \textit{Kubernetes} klaszterek fölé már lehet \textit{KubeFed} környezetet telepíteni. A telepített \textit{KubeFed} szoftver megfelelően modellezi a valós környezetben használt futtató környezetet, hiszen ugyanaz a szoftver. Telepítése és üzemeltetése között nincs különbség a valós és teszt környezetben.
 
 \subsubsection{Kliens}
 
@@ -91,28 +91,97 @@ A munka során a terveim alapján konkrétan megvalósított környezetem három
 	\label{fig:birb_edgemu_architecture}
 \end{figure}
 
-A \textit{Kubefed} federáció tagjai a \texttt{cloud}, \texttt{edge-1} és \texttt{edge-2} nevű klaszterek. Ezek közül a \texttt{cloud} nevű klaszter a federációt vezérlő klaszter.
+A \textit{KubeFed} federáció tagjai a \texttt{cloud}, \texttt{edge-1} és \texttt{edge-2} nevű klaszterek. Ezek közül a \texttt{cloud} nevű klaszter a federációt vezérlő klaszter.
+
+A klasztereknek és klienseknek természetesen nem csak egymással kell tudniuk kommunikálni. Előfordulhat, hogy szükségük van arra, hogy elérjék a publikus internetet is (például szoftverfrissítés letöltésére). Az ilyen típusú forgalom nem kívánatos a virtuális útválasztón. Mivel a környezetben csak a klaszterek és a kliensek közötti forgalom paramétereit szeretnénk befolyásolni, ezért felesleges a nem arra irányuló forgalom átvezetése. Emellett az extra forgalom bizonyos szélsőséges helyzetekben befolyásolhatja a mérési eredményeket is. Ennek megoldására minden alhálózatban két átjáró van, az egyik a virtuális útválasztó a másik a virtuális környezet által biztosított átjáró amelyen keresztül el lehet érni a publikus internetet.
 
 \subsection{Virtuális gépek és hálózat}
-% cloudinit
+
+A környezetet alkotó virtuális gépek futtatása nem függ egy konkrét virtualizációs platform implementációtól. Az egyetlen elvárás azzal szemben, hogy képes legyen virtuális gépeket és virtuális hálózatokat létrehozni és futtatni. 
+
+A virtuális gépek futtatásához \textit{libvirt}\footnote{\url{https://libvirt.org/}} környezetet használtam. 
+
+A \textit{libvirt} számára \acrshort{xml} formátumban lehet definiálni a virtuális gépeket és virtuális hálózatokat \cite{libvirt_xml}. A felépítés ezen lépésének automatizálására írtam egy egyszerű \gls{python} szkriptet, amely ilyen \acrshort{xml} definíciókat generál. Ezek importálásával \textit{libvirt}be, a virtuális gépek és a hálózati infrastruktúra készen állt.
+
+Négy virtuális hálózatot hoztam létre, ezeket \texttt{cloud}, \texttt{edge-1}, \texttt{edge-2} és \texttt{client}-nek neveztem el attól függően, hogy melyik virtuális gépeket szolgálja ki. Az útválasztó kivételével minden virtuális gépnek egy interfésze van, amely az adott hálózatra van csatlakoztatva. Az útválasztónak mind a négy hálózatba van interfésze. A hoszt által biztosított átjáró minden hálózatban jelen van. Az ide irányuló forgalom hálózati címfordítás segítségével a gazdagép címére fordul, így a virtuális gépek elérik az internetet is.
 
 \subsection{Operációs rendszer konfigurációja}
 
-% leírni mindhárom classt: kliens-emu, router, kubememe memeber
+
+Mivel a környezet 11 virtuális gépből áll, ezért ezeknek egyenként \enquote{kézzel} való telepítése időigényes lenne és könnyen lehetne hibát ejteni benne, amelynek megkeresése és javítása további időt igényelne. 
+
+Ezért a virtuális gépek telepítésére és alapvető konfigurációjának elvégzésére is automatizációs eszközöket használtam.
+
+Az operációs rendszer telepítése helyett inkább egy előre elkészített képfájlból dolgoztam. Az általam használt képfájl \textit{Ubuntu} \gls{linux} disztribúciót tartalmaz. A képfájlon előre fel van telepítve a \textit{Cloud Init}\footnote{\url{https://cloud-init.io/}} nevű eszköz, amely rendszer indulás közben elvégzi az operációs rendszer alapvető konfigurációját. Ilyen a gép hosztneve, (egyszerűsített) hálózati konfigurációja, és az \acrfull{ssh} kapcsolaton való bejelentkezéshez szükséges publikus kulcsok telepítése. 
+
+A \textit{Cloud Init} az egyedi konfigurációt egy második lemez képfájlról tölti be. A lemez képfájlok elkészítésére írtam egy egyszerű \gls{python} szkriptet.
+
+Mivel a \textit{Cloud Init} csak az alapvető rendszer konfigurációt hajtja végre, ezért a komplexebb/specifikus konfigurációk elvégzésére egy másik eszközt használtam. A \textit{Cloud Init} egy olyan működő konfiguráció állít be a virtuális gépen, amely lehetővé teszi, hogy be tudjunk arra jelentkezni \acrshort{ssh} kapcsolaton keresztül. Az \acrshort{ssh} kapcsolat tökéletesen megfelel arra, hogy \textit{Ansible}\footnote{\url{https://www.ansible.com/}} konfiguráció menedzsment eszközt használjunk.
+
+Az \textit{Ansible} egy deklaratív konfiguráció kezelő eszköz \cite{ansible_docs}. Az elvárt állapotot írjuk le, amelyhez az \textit{Ansible} automatikusan igazítani fogja a konfigurációs beállításokat az operációs rendszeren. Futás közben \acrshort{ssh} protokollon keresztül csatlakozik a konfigurálni kívánt hosztokra. Majd ellenőrzi, hogy minden beállítás egyezik-e az általunk elvárt állapottal. Ha valamelyik konfiguráció eltér, akkor azt automatikusan beállítja az elvárt állapotra.
+
+
+\textit{Ansible} segítségével, letöröltem felesleges szoftver komponenseket, feltelepítettem szükségeseket és beállítottam a végleges hálózati konfigurációt. 
+
+Annak érdekében, hogy a virtuális gépek az alhálózatok közti forgalmat a virtuális útválasztón keresztül küldjék, a többi forgalmat pedig a gazdagép átjáróján keresztül, statikus útválasztó tábla bejegyzéseket vettem fel minden gépen. Ahol minden gépen a többi alhálózathoz az átjáró a virtuális útválasztó, az alapértelmezett pedig a gazdagép átjárója. 
+
 
 \subsection{\textit{Kubernetes} telepítése}
 
+A \textit{KubeFed} használatához először szükség van arra, hogy legyenek működő \textit{Kubernetes} klasztereink, amelyeket federálni tudunk \cite{installing_kubefed}. 
 
-% Nginx ingress controller
+Egy \textit{Kubernetes} klaszter telepítésére több lehetőségünk is van. Rendelkezésünkre állnak disztribúciók, amelyek minimális konfigurációval egy teljes értékű klasztert képesek telepíteni. A telepítéshez a \textit{Kubespary}\footnote{\url{https://kubespray.io/}} disztribúciót használtam.
-% Longhorn storage class
 
-\subsection{\textit{Kubefed} telepítése}
+A \textit{Kubespray} alapvető konfigurációjában csak keveset módosítottam. Úgy állítottam be, hogy a három virtuális gépből egyet jelöljön ki \texttt{master} szerepre kettőt pedig \texttt{worker} szerepre. A Kubernetes telepítését egyenként végeztem el mindhárom klaszterre. 
+
+Sikeres telepítés után néhány alapvető komponenst szintén kézzel, \textit{Helm}\footnote{\url{https://helm.sh/}} segítségével telepítettem:
+\begin{itemize}
+	\item A perzisztens tárhely kezeléshez \textit{Longhorn}\footnote{\url{https://longhorn.io/}} \textit{Storage Class}-t telepítettem. A \textit{Longhorn} nem igényli külső adat tároló szerverek használatát, a \textit{Kubernetes} klasztert alkotó gépek saját tárhelyét használja.
+	\item A beérkező \acrshort{http} kérések fogadására, kezelésére és megfelelő mikroszolgáltatásokhoz irányítására \textit{Nginx}\footnote{\url{https://kubernetes.github.io/ingress-nginx/}} \textit{Ingress Controller}-t telepítettem. Ennek segítségével mikroszolgáltatások halmazával megvalósított szolgáltatás egy egységes \acrshort{http} interfészen érhetőek el.
+\end{itemize}
+
+
+\subsection{\textit{KubeFed} telepítése}
+
+A \textit{KubeFed} telepítéséhez követtem annak dokumentációját. A telepítés csak pár lépésből állt. 
+
+Első lépésként a \textit{Helm} segítségével telepítettem a \textit{KubeFed} vezérlését megvalósító komponenseket a \texttt{cloud} nevű klaszterbe. Ezek után a letöltöttem a \texttt{kubefedctl} nevű parancssoros alkalmazást, amely segítségével beléptettem mindhárom klasztert a federációba\footnote{A vezérlő klasztert is be kell léptetni annak érdekében, hogy a \textit{KubeFed} oda is ütemezzen alkalmazás komponenseket}. Ezek után lekérdeztem a klaszterek állapotát reprezentáló \acrshort{api} objektumot a \textit{Kubernetes} \acrshort{api} interfészén, ez megerősítette, hogy a federáció vezérlő mindhárom \textit{Kubernetes} klasztert eléri és tudja kezelni.
+
+Ezek után lehetőségem volt egyenként ki és be kapcsolni a \textit{KubeFed} által federált objektumok használatát, mint a federált névterek, federált konfigurációk vagy éppen federált \textit{deployment}-ek.
+
+\section{Erőforrás igények}
+
+Bár a rendszer erőforrás igénye nagyban függ a telepített alkalmazásoktól. Maga a környezet telepítése és futtatása is igényel valamennyi erőforrást. 
+
+\textit{Kubernetes} futtatásához, minden virtuális gépnek legalább 2 Gigabyte rendszer memória szükséges és két processzor mag \cite{kubernetes_docs}. Tapasztalataim viszont azt mutatják, hogy ez néha túl kevés tud lenni és különböző teljesítménybeli problémákba tudunk ütközni, ezért a \textit{Kubernetes}-t futtató virtuális gépeknek ajánlott legalább 4 Gigabyte memória allokálása. 
+
+Az útválasztó gépnek nincs szüksége sok memóriára a csomagok továbbítására, amíg nem használjuk másra, addig 512 Megabyte memória megfelel neki. 
+
+Elmondható ezek alapján, hogy a tesztkörnyezet futtatásához legalább 36.5 Gigabyte memóriára van szükség, ha a klienseket nem számoljuk.
+
+A kliensek száma és erőforrás igénye teljesen a használt alkalmazástól függ. Itt ezért kezdetben 2 Gigabyte memóriát allokáltam, majd később kibővítettem, amikor szükség volt rá.
+
+Processzor tekintetében nem fedeztem fel különösen nagy elvárásokat. Tapasztalataim szerint a rendszer stabilan működött egy 2011-ben gyártott négymagos \textit{Intel}\textregistered \textit{Core}\texttrademark i7-3770 processzoron. 
+
+A lemez elérések teljesítménye viszont egy jelentős tényező volt a rendszer teljesítménye szempontjából. A környezet önmagában stabilan üzemelt egy \acrshort{raid}5 tömbre telepítve, amelyet 8 darab 15.000 percenkénti fordulatú hagyományos mechanikus diszk alkotott. Viszont amint feltelepítettem a tesztelésre szánt alkalmazásokat a tárhely elérési késleltetés jelentősen megnőtt olyan mértékekig amik az alkalmazás instabil működését és átmeneti összeomlását okozták. Ezért mindenképpen ajánlott ilyen rendszert \acrshort{ssd} lemezekből álló tárhely tömbre telepíteni.
 
 
 \section{Környezet alkalmazása}
 
-% tc tutorial basically
+A tesztkörnyezetnek egyik fontos célja, hogy különböző hálózati paramétereket tudjon szimulálni. Ennek megvalósításáért a virtuális útválasztó felel. 
 
-%\section{Környezet értékelése}
+A szükséges hálózati funkciókat implementálja a \gls{linux} kernel. Ezért a virtuális gépen is ugyanolyan \textit{Ubuntu} operációs rendszer fut, mint a többin a környezetben. A virtuális gépen bekonfigurálásra kerültek a megfelelő útválasztó táblák és engedélyezve lett rajta az útválasztó funkcionalitás. Ennyi elég ahhoz, hogy működő kapcsolatot létesítsen az egyes alhálózatok között. 
 
-% fogom a pontokat a célokból és elmondom, hogy mindet tök királyul teljesítettem.
+A hálózati kondíciók szimulálásához a kernelbe \textit{Traffic Control} képességek tökéletesen használhatóak. A \textit{Traffic Control} a következő részekből áll \cite{man_tc}:
+\begin{itemize}
+	\item \textbf{Shaping} (formálás): Interfészről kimenő csomagok rátájának szabályozása. Nem csak sávszélesség szabályozásra alkalmas. Használható például az egyenetlen adatforgalom simítására is.
+	\item \textbf{Scheduling} (ütemezés): A csomagok küldésének idejét ütemezhetjük vele, alkalmas arra, hogy például késleltetést szimuláljunk. Csak kimenő csomagokra alkalmazható.
+	\item \textbf{Policing} (rendészet): Hasonló a formáláshoz, viszont a kimenő csomagok helyett a beérkezőkre vonatkozik.
+	\item \textbf{Dropping} (ejtés): Bizonyos szabályok alapján eldobhatunk csomagokat amelyek meghaladnak sávszélességi korlátokat. Ez mind a bejövő mind a kimenő forgalomra alkalmazható.
+\end{itemize}
+
+A kernelben lévő \textit{Traffic Control} konfigurálásához a \texttt{tc} nevű felhasználói módú eszközt tudjuk használni. A használatára egy példát mutat be \aref{ex:tc}.\ kódrészlet.
+
+\begin{lstlisting}[float=!ht,caption={10ms késleltetés konfigurálása egy interfészre \texttt{tc} használatával},label=ex:tc]
+	tc qdisc add dev enp1s0f2 root netem delay 10ms
+\end{lstlisting}

src/content/ursim_impl.tex

@@ -113,7 +113,7 @@ A fenti monolit demó átültetése alapos tervezést igényelt egy felhő és p
 
 \subsection{Architektúra}
 
-Mivel a \textit{Kubefed} keretrendszert választottam az alkalmazásom futtatására, így ennek megfelelően kellett megválasztanom annak felépítését. Az alkalmazást mikroszolgáltatás architektúrára terveztem. \textit{Kubefed} használatával lényegében az alkalmazásunk (egy vagy több) \textit{Kubernetes} klaszterben fut. A mikroszolgáltatás architektúra az ilyen környezetben azért jó, mert az alkalmazás komponensek egymás belső működésétől függetlenek. Így amíg az egyes komponensek egymás \acrshort{api} felületét elérik, nem számít, hogy hol és milyen környezetben futnak. Természetesen a felületek elérése is egy összetett probléma önmagában, ennek megoldásáról \aref{chapter:dynamic_scheduling}.\ fejezet értekezik.
+Mivel a \textit{KubeFed} keretrendszert választottam az alkalmazásom futtatására, így ennek megfelelően kellett megválasztanom annak felépítését. Az alkalmazást mikroszolgáltatás architektúrára terveztem. \textit{KubeFed} használatával lényegében az alkalmazásunk (egy vagy több) \textit{Kubernetes} klaszterben fut. A mikroszolgáltatás architektúra az ilyen környezetben azért jó, mert az alkalmazás komponensek egymás belső működésétől függetlenek. Így amíg az egyes komponensek egymás \acrshort{api} felületét elérik, nem számít, hogy hol és milyen környezetben futnak. Természetesen a felületek elérése is egy összetett probléma önmagában, ennek megoldásáról \aref{chapter:dynamic_scheduling}.\ fejezet értekezik.
 
 Ennek érdekében a tervezés első lépéseként felbontottam funkcionális egységekre a jelenlegi demonstráció vezérlését. A felbontásnál viszont itt nem csak a funkcionális egységek elkülönítését tartottam szem előtt. Mivel egy három rétegű architektúrára tervezek, ezért figyelembe kellett vennem annak elvárásait és adottságait.