some changes
This commit is contained in:
@@ -38,7 +38,9 @@ Egy alkalmazás konténer általánosságban egy önálló csomag, amely tartalm
|
||||
Az alkalmazás konténerek koncepciójának megvalósítására egy népszerű implementáció a \textit{Docker}, amely a \gls{linux} kernelben található izolációs szolgáltatásokra épít. Ezzel valósítja meg, hogy a konténerek egymástól független környezetben tudjanak futni. Egyetlen szoftver erőforrás, amin közösen osztoznak az a kernel maga.
|
||||
|
||||
% TODO: Átírni OCI-re
|
||||
Dockerben az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépekhez képfájlaihoz képest kisebb méretűek. Ezeket a képfájlokat az alkalmazás fejlesztése után készítjük és az alkalmazás konténer indításához használjuk \cite{docker_docs}.
|
||||
\textit{Docker} használatakor, az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Kezdetben ez a képfájl formátum \textit{Docker} projekt által tervezett saját formátum volt. Később erre alapozva jött létre az \acrfull{oci} által készített \textit{Image Format Specification} (képfájl formátum specifikáció) amely a manapság használt szinte minden kontér futtató környezet támogat \cite{oci_format_docs}. Ennek köszönhetően a \textit{Docker} környezetben épített képfájlok használhatóak más alternatíváknál is, mint a \textit{Podman} \cite{podman_docs}.
|
||||
|
||||
Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépekhez képfájlaihoz képest kisebb méretűek. Építése során a kívánt szoftver komponenseket (lefordított bináris, scriptek program fájlok, könyvtárak stb.) egy kiinduló képfájlba másoljuk bele. Ez a kiinduló képfájl lehet egy üres környezet, de lehet valamilyen operációs rendszer disztribúció felhasználói módú program környezete. Olyan képfájlok is léteznek, amelyekbe egy adott futtatókörnyezet már előre van telepítve, így csak a kész programunkat kell a megfelelő helyre tenni. Futtatáskor a konténer futtató környezet ezeket a képfájlokat használja fel a konténer fájlrendszerének felépítéséhez, a benne található alkalmazás futtatásához \cite{docker_docs}.
|
||||
|
||||
\subsubsection{Kubernetes}
|
||||
|
||||
@@ -50,15 +52,19 @@ Kubernetes klaszternek nevezzük azt a multihoszt környezetet, ahol több -- eg
|
||||
|
||||
A klaszteren belül két jól elkülöníthető szerepkört definiálunk, ezek a master (mester) és a worker (munkás) szereprek. A master felel az erőforrások elosztásáért, a konténerek workerhez rendeléséért és összességében a klaszter irányításáért. A workerek felelnek a konkrét alkalmazásunkhoz tartozó konténerek futtatásáért.
|
||||
|
||||
Egy \textit{Kubernetes} környezetben különböző objektumokat definiálunk, amelyekkel leírhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezek az objektumok közül a legkisebb kezelhető egység a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos névtereken, ilyen a hálózati vagy a folyamatok névtere.
|
||||
A klaszterünk felügyelete és kezelése az általa kiszolgált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával történik. Ezt az interfészt elérhetik a klaszterben futó szoftverek, de akár a klaszteren kívüli alkalmazások és azokon keresztül pedig az klaszter adminisztrátorai.
|
||||
|
||||
% Ide még bőven lehet írni
|
||||
Egy \textit{Kubernetes} környezetben, az \acrshort{api}-n keresztül különböző objektumokat definiálunk, amelyekkel leírhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezeket az objektumokat a \textit{Kubernetes} dekleratív módon kezeli. Azaz az objektumok segítségével egy állapotot írhatunk le, amely a klaszter elvárt állapotát jelképezi. A \textit{Kubernetes} feladata ezt az állapotot elérni és fenntartani.
|
||||
|
||||
Eggyel \enquote{nagyobb} objektum ezeknél a \textit{Deployment}, a \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le. A \textit{Kubernetes} klaszter törekszik a \textit{Deployment}ben megfogalmazott állapot elérésére és fenntartására.
|
||||
Ezek az objektumok közül a legegyszerűbb példa a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos erőforrás névtereken, ilyen a hálózati vagy a folyamatok névtere. Azaz az egy \textit{Pod}-on belül futó két konténer a megfelelő rendszerhívásokkal tájékozódhat a másik konténerben futó folyamatok létezéséről. Illetve a hálózati kommunikációs erőforrásokat közösen használják.
|
||||
|
||||
A \textit{Podok} életciklusának (létrehozás, törlés) kezelésére a \textit{Deployment} objektum nyújt megoldást. A \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le. Milyen \textit{Podból} és mennyi példánynak kell futnia.
|
||||
|
||||
Ezek mellett még rengeteg alkalmazás specifikus objektumot ad rendelkezésünkre a \textit{Kubernetes}. Sőt, mindemellett lehetőség van arra, hogy egyedi erőforrás objektumokat is definiáljunk. Amelyekkel könnyedén bővíthetjük a klaszterünk funkcionalitását.
|
||||
|
||||
\subsubsection{Mikroszolgáltatások}
|
||||
|
||||
A mikroszolgáltatás modell egy újkeletű architekturális megközelítés a szoftver fejlesztésben. Ebben a megközelítésben egyfunkciós modulokat tervezünk és fejlesztünk, amelyek jól definiált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával kommunikálnak egymással \cite{microservices}. Ennek hála, amíg egy komponens teljesíti az elvárt \acrshort{api} definíciót, addig szabadon kicserélhető
|
||||
A mikroszolgáltatás modell egy újkeletű architekturális megközelítés a szoftver fejlesztésben. Ebben a megközelítésben egyfunkciós modulokat tervezünk és fejlesztünk, amelyek jól definiált \acrshort{api} használatával kommunikálnak egymással \cite{microservices}. Ennek hála, amíg egy komponens teljesíti az elvárt \acrshort{api} definíciót, addig szabadon kicserélhető
|
||||
|
||||
Az egységek a fejlesztése, és tesztelése sokkal gyorsabb ütemben tud haladni a kisebb kódbázis miatt. A rajtuk eszközölt fejlesztések sokkal hamarabb kerülhetnek ki az éles rendszerbe, hiszen a változtatásuk nem érinti a teljes rendszert, ezért könnyebb őket frissíteni, vagy valamilyen szélsőséges esemény hatására visszaállni egy korábbi változatra.
|
||||
|
||||
@@ -109,7 +115,7 @@ A szójegyzék jelenlegi (2.0-ás verzió) kiadása alapján néhány fontosabb
|
||||
|
||||
Az előbbiek alapján ez a dolgozat peremhálózati \gls{adatkozpont}oknak azokat tekinti, amelyek logikailag -- és valamilyen szinten fizikailag is -- a felhő és a \gls{vegeszkoz}ök között helyezkednek el. Ezen a tartományon értelmezve \enquote{közel} áll a \gls{vegeszkoz}höz.
|
||||
|
||||
Ezt a fajta logikai \enquote{közelség} úgy valósul meg, hogy az úton, amelyet egy hálózati üzenetnek be kell járnia a \gls{vegeszkoz}től a felhőig, a peremhálózati \gls{adatkozpont}ot a lehető legközelebb igyekszünk helyezni a \gls{vegeszkoz}höz. Következésképp egy hálózati csomagnak jelentősen rövidebb utat kell bejárnia a peremhálózati \gls{adatkozpont}ig, mint a központi megfelelőjéig. Egy ilyen architektúra vázlatát mutatja be \aref{fig:overview_with_edge}.\ ábra. Az \gls{adatkozpont} \enquote{közelebb} helyezése a végeszközökhöz számos előnnyel jár.
|
||||
Ez a fajta logikai \enquote{közelség} úgy valósul meg, hogy az úton, amelyet egy hálózati üzenetnek be kell járnia a \gls{vegeszkoz}től a felhőig, a peremhálózati \gls{adatkozpont}ot a lehető legközelebb igyekszünk helyezni a \gls{vegeszkoz}höz. Következésképp egy hálózati csomagnak jelentősen rövidebb utat kell bejárnia a peremhálózati \gls{adatkozpont}ig, mint a központi megfelelőjéig. Egy ilyen architektúra vázlatát mutatja be \aref{fig:overview_with_edge}.\ ábra. Az \gls{adatkozpont} \enquote{közelebb} helyezése a végeszközökhöz számos előnnyel jár.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
@@ -128,7 +134,7 @@ Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetni
|
||||
% Privacy/Security
|
||||
|
||||
|
||||
\section{felhő és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók
|
||||
\section{Felhő és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók
|
||||
|
||||
Ugyan a peremhálózati adatközpontok alkalmazása önmagában sok előnnyel kecsegtet, fontos megjegyezni, hogy a peremhálózati rendszerek nem fogják és nem is tervezik kiváltani a tradicionális megközelítést. Sokkal inkább azt kiegészítve szimbiózisban tudnak igazán érvényesülni.
|
||||
|
||||
@@ -143,18 +149,20 @@ Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek
|
||||
|
||||
Jelenleg is már több alkalmazásnál is használják, vagy tervezik használni. Ilyenek például az önvezető járművek \cite{liu2019edge}, ipari rendszerek távfelügyelete \cite{hao2020cloud}, betegfelügyelet \cite{wang2020secure}, felhő alapú játék szolgáltatások \cite{edge_gaming}, okos otthonok és városok \cite{shi2016edge} és még sok minden más területen \cite{edge_companies}.
|
||||
|
||||
A dolgozatom részeként két konkrét alkalmazáson mutatom be a felhő és a peremhálózati rendszerek használatát. Ezek az alkalmazások korábban elkészült munkákon alapulnak, amelyeken jól demózhatóak az előnyök. Ezeknek a megvalósítását a \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
|
||||
A dolgozatom részeként két konkrét alkalmazáson mutatom be a felhő és a peremhálózati rendszerek használatát. Ezek az alkalmazások korábban elkészült munkákon alapulnak, amelyeken jól demózhatóak az előnyök. Ezeknek a megvalósítását a \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
|
||||
|
||||
\section{Alkalmazás futtatási és fejlesztési keretrendszerek}
|
||||
\label{sec:frameworks}
|
||||
|
||||
% itt le lehet írni, hogy igazából mit is kell egy keretrendszernek tudnia
|
||||
Ahhoz, hogy az alkalmazásunkat könnyen tudjuk egy felhő és peremhálózati környezetben futtatni érdemes egy már létező keretrendszert használni. Az ilyen keretrendszerek nagyban megkönnyítik a fejlesztést, hiszen az adott alkalmazási terület általánosan felmerülő problémáit és kérdéseit megoldja. Így az alkalmazás fejlesztőinek nem szükséges azzal foglalkozni, hogy pontosan hogy indul el az alkalmazásuk egyik vagy másik helyen, mert ezt elfedi előlük a keretrendszer.
|
||||
|
||||
A feladatom megvalósításához több keretrendszert is megvizsgáltam, ezeket az alábbiakban általánosságban részletezem. A feladat specifikus elvárásokat pedig \aref{chapter:running_on_the_edge}.\ fejezetben fejtem ki.
|
||||
Egy ilyen keretrendszernél szükség van arra, hogy lehetőséget biztosítson egyes alkalmazás komponenseket a peremhálózati adatközpontban futtatni, másokat pedig a központi felhőben. Biztosítson valamilyen beavatkozható logikát arra, hogy egy alkalmazás mely adatközpontban kerül futtatásra. Elfedje az egyes futtató adatközpontok sajátosságait.
|
||||
|
||||
A feladatom megvalósításához több ilyen keretrendszert is megvizsgáltam, ezeket az alábbiakban általánosságban részletezem. A feladat specifikus elvárásokat pedig \aref{chapter:dynamic_scheduling}.\ fejezetben fejtem ki.
|
||||
|
||||
\subsection{EdgeX Foundry}
|
||||
|
||||
Az \textit{EdgeX Foundry} egy mikroszolgáltatásokból felépülő környezet, amelynek a célja az, hogy a perem alkalmazások fejlesztésénél gyakran felmerülő feladatokat ellátó komponensek egységesek legyenek \cite{edgexfoundry_docs}.
|
||||
Az \textit{EdgeX Foundry} egy mikroszolgáltatásokból felépülő környezet, amelynek a célja az, hogy a perem alkalmazások fejlesztésénél gyakran felmerülő feladatokat ellátó komponensek egységesek legyenek \cite{edgexfoundry_docs}.
|
||||
|
||||
A keretrendszer komponensei lazán csatoltak. Ez lehetővé teszi, hogy akár az előbb bemutatott három szintű peremhálózati architektúránál akár több réteget is bevezessünk. A komponensek mind platform függetlenek és a megfelelő környezetben egymástól függetlenül bárhol futtathatóak.
|
||||
|
||||
@@ -205,7 +213,7 @@ A peremhálózaton megtalálható a kommunikációs interfész párja \textit{Ed
|
||||
|
||||
Az alkalmazás komponensek ugyanúgy képesek kommunikálni egymással, mint egy \textit{Kubernetes} környezetben a perem és a központi felhő komponensek között. Ugyanazok a monitorozó, felügyeleti és ütemezős eszközök működnek mindkét oldalán a rendszernek. Ezáltal a \textit{KubeEdge} lehetővé teszi, hogy a hagyományos formában felépített mikroszolgáltatás alapú alkalmazások komponenseit kiszervezze a peremhálózatra. Viszont bizonyos helyzetekben az alkalmazásnak a felelőssége megoldani, hogy áthidalja az olyan helyzeteket, amikor nem áll rendelkezésre kapcsolat a központi felhővel. Ahhoz, hogy ezt megoldja, a \textit{Kubernetes} klaszteren belül használt hálózati plugin segítségével kiterjeszti és összekapcsolja a \textit{Pod} hálózatot.
|
||||
|
||||
Mindennek köszönhetően a \textit{KubeEdge} platformon futtatható alkalmazások fejlesztése nagyon könnyű, hiszen az szinte teljesen megegyezik a mikroszolgáltatás alapú alkalmazások fejlesztésével. Cserében a \textit{KubeEdge} nem implementál dinamikus ütemezési megoldásokat. Az egyes alkalmazásokat kézzel kell a kívánt peremhálózati szerverek valamelyikéhez rendelni. Ez jelentősen megnehezíti a skálázását az alkalmazásoknak, hiszen nem tudják a peremhálózatokra telepített több számítógép által nyújtott terhelés eloszlási lehetőségeket kihasználni\cite{kubeedge_crds}.
|
||||
Mindennek köszönhetően a \textit{KubeEdge} platformon futtatható alkalmazások fejlesztése nagyon könnyű, hiszen az szinte teljesen megegyezik a mikroszolgáltatás alapú alkalmazások fejlesztésével. Cserében a \textit{KubeEdge} nem implementál dinamikus ütemezési megoldásokat. Az egyes alkalmazásokat kézzel kell a kívánt peremhálózati szerverek valamelyikéhez rendelni. Ez jelentősen megnehezíti a skálázását az alkalmazásoknak, hiszen nem tudják a peremhálózatokra telepített több számítógép által nyújtott terhelés eloszlási lehetőségeket kihasználni \cite{kubeedge_crds}.
|
||||
|
||||
\subsection{\acrshort{aws} \acrshort{iot} Greengrass}
|
||||
|
||||
@@ -232,4 +240,14 @@ Az \textit{Azure \acrshort{iot} Edge} előnye, hogy egy kiforrott ipari megoldá
|
||||
|
||||
|
||||
\subsection{Kubernetes Federation}
|
||||
% Nem erre való, de jó erre
|
||||
% 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}.
|
||||
|
||||
Az üzemeltetés szempontjából, ezt úgy valósul meg, hogy kijelöl egy federáció vezérlő (federation controller) klaszter. 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}.
|
||||
|
||||
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 geológiailag 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 többszörösen megfeleljen.
|
||||
|
||||
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ű az olyan illetők számára aki már jártas a \textit{Kubernetes} klaszterek terén.
|
||||
|
||||
Reference in New Issue
Block a user