Implemented Markosz feedback
This commit is contained in:
@@ -26,10 +26,10 @@ Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a fel
|
||||
|
||||
Amellett, hogy a felhőszolgáltatások adaptációja növekvő tendenciát mutat, az internetre kapcsolt eszközök száma is szépen gyarapodik \cite{annualinternetreport}. Ehhez a felhasználói készülékek mellett jelentősen hozzájárul az utóbbi időben jelentős fejlődésnek örvendő \acrfull{iot} rendszerek egyre nagyobb volumenű alkalmazása \cite{iotadpotation}.
|
||||
|
||||
Ezek alapján a felhő szolgáltatásokat nyújtó \gls{adatkozpont}ok kapacitásukat mind számítási teljesítményben, mind rendelkezésre álló sávszélességre való tekintettel egyre növekvő elvárással szembesülnek. Mindazonáltal a \gls{vegeszkoz}öket összekötő hálózatok is jelentősen növekvő igényeknek néznek elébe. Mindeközben pedig egyre nagyobb igény mutatkozik arra, hogy az alkalmazásaink jó válaszidővel, alacsony késleltetéssel működjenek \cite{stateofart}.
|
||||
Ezek alapján a felhő szolgáltatásokat nyújtó \gls{adatkozpont}ok kapacitásukat mind számítási teljesítményben, mind rendelkezésre álló sávszélesség tekintetében egyre növekvő elvárással szembesülnek. Mindazonáltal a \gls{vegeszkoz}öket összekötő hálózatok is jelentősen növekvő igényeknek néznek elébe. Mindeközben pedig egyre nagyobb igény mutatkozik arra, hogy az alkalmazásaink jó válaszidővel, alacsony késleltetéssel működjenek \cite{stateofart}.
|
||||
|
||||
|
||||
\subsection{Felhős alkalmazásüzemeltetési eszközök}
|
||||
\subsection{Felhő alapú alkalmazásüzemeltetési eszközök}
|
||||
|
||||
\subsubsection{Alkalmazás Konténer}
|
||||
|
||||
@@ -38,45 +38,46 @@ 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
|
||||
\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}.
|
||||
\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 a \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ó), amelyet 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 példáula \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}.
|
||||
Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépek 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 telepítve van, í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}
|
||||
|
||||
Manapság egyre jobban terjed a konténer alapú szoftver fejlesztés és a felhő alapú megoldások \cite{containermarketshare}. Az egyik legnépszerűbb ilyen felhő implementáció a \textit{Kubernetes}. A \textit{Kubernetes} egy konténer orkesztrációs platform, amely felügyeli és kezeli az egyes alkalmazásokat vagy szolgáltatásokat megvalósító konténerek életciklusát egy multihoszt környezetben.
|
||||
Manapság egyre jobban terjed a konténer alapú szoftver fejlesztés és a felhő alapú megoldások \cite{containermarketshare}. Az egyik legnépszerűbb ilyen felhő platfrom a \textit{Kubernetes}. A \textit{Kubernetes} egy konténer orkesztrációs platform, amely felügyeli és kezeli az egyes alkalmazásokat vagy szolgáltatásokat megvalósító konténerek életciklusát multihoszt környezetben.
|
||||
|
||||
|
||||
Az életciklus kezelés mellett több hasznos szolgáltatást is nyújt. Ilyenek az automatikus szolgáltatás felderítés és terhelés elosztás, tárhely orkesztráció, konfiguráció kezelés. Bizonyos, megfelelően felkonfigurált helyzetekben a \textit{Kubernetes} képes alapszintű hibajavításra is, bizonyos szolgáltatások programozott újraindításával \cite{kubernetes_docs}.
|
||||
|
||||
Kubernetes klaszternek nevezzük azt a multihoszt környezetet, ahol több -- egymással hálózatba kötött -- számítógép (fizikai vagy virtuális) valósítja meg a \textit{Kubernetes} környezetet.
|
||||
|
||||
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.
|
||||
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) szerepek. 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.
|
||||
|
||||
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.
|
||||
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 a klaszter adminisztrátorai.
|
||||
|
||||
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.
|
||||
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 határozza meg. A \textit{Kubernetes} feladata ezt az állapotot elérni és fenntartani.
|
||||
|
||||
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.
|
||||
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.
|
||||
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} mennyi példánynak kell futnia.
|
||||
|
||||
Ezek mellett még rengeteg alkalmazás specifikus objektumot kezel 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.
|
||||
|
||||
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 \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.
|
||||
Az egységek 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.
|
||||
|
||||
Mikroszolgáltatásokkal az alkalmazások skálázása is jelentősen leegyszerűsödik. Míg egy monolit rendszerben a teljes alkalmazást skálázni kellett, ha nagyobb teljesítményre volt szükség, itt -- feltéve, hogy tisztában vagyunk vele, hogy mely komponensek jelentik a szűk keresztmetszetet -- elég csak a megfelelő szolgáltatásokat.
|
||||
|
||||
A mikroszolgáltatásoknak további előnyös jellemzője, hogy az egyes komponensek teljesen egyedül kezelik a saját belső adatstruktúrájukat. Az egyetlen kompatibilitási réteg, amelyet biztosítaniuk kell az az \acrfull{api} interfész. A mikroszolgáltatások teljesen szabadon változtathatják a belső struktúrájukat akár verziók között is. De nem csak az adatstruktúrával szemben van ekkora szabadságunk, hanem akár az alkalmazott programnyelv tekintetében is.
|
||||
|
||||
A mikroszolgáltatásoknak további előnyös jellemzője, hogy az egyes komponensek teljesen egyedül kezelik a saját belső adatstruktúrájukat. Az egyetlen kompatibilitási réteg, amelyet biztosítaniuk kell, az az \acrfull{api} interfész. A mikroszolgáltatások teljesen szabadon változtathatják a belső struktúrájukat akár verziók között is. De nem csak az adatstruktúrával szemben van ekkora szabadságunk, hanem akár az alkalmazott programnyelv tekintetében is.
|
||||
|
||||
\section{Peremhálózati rendszerek} % Szóval itt felvezetem hogy van ez a perem meme
|
||||
\label{sec:peremhalozati_rendszerek}
|
||||
|
||||
A felhő-számítástechnika tradicionális megközelítésben való alkalmazásában jelentős hatékonysági kérdések merülnek fel. Mint ahogy azt \aref{fig:overview_no_edge}.\ ábra is szemlélteti, ha az egyes \gls{vegeszkoz}ök közvetlenül kommunikálnak a felhőszolgáltatást nyújtó \gls{adatkozpont}tal, az lineárisan növekvő terhelést jelent, mind a köztes hálózatnak, mint az \gls{adatkozpont}nak. Emellett a megtett távolság miatt a késleltetés is növekszik.
|
||||
A felhő számítástechnika tradicionális megközelítésben való alkalmazásában jelentős hatékonysági kérdések merülnek fel. Mint ahogy azt \aref{fig:overview_no_edge}.\ ábra is szemlélteti, ha az egyes \gls{vegeszkoz}ök közvetlenül kommunikálnak a felhő szolgáltatást nyújtó \gls{adatkozpont}tal, az lineárisan növekvő terhelést jelent, mind a köztes hálózatnak, mint az \gls{adatkozpont}nak. Emellett a megtett távolság miatt a késleltetés is növekszik.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
@@ -91,21 +92,21 @@ A fent vázolt problémákra megoldást ígér a peremhálózati rendszerek alka
|
||||
|
||||
\subsection{Használt fogalmak}
|
||||
|
||||
A peremhálózat pontos definiálása egyelőre nem teljesen tisztázott mivel nem is egy egyszerű kérdés \cite{cureforedge, cloudflare_whatisedge}. Egyes források szerint a peremhálózati számítástechnika az magukon a \gls{vegeszkoz}ökön futtatott alkalmazások \cite{verge_whatisedge}, míg más források a felhő és a \gls{vegeszkoz}ök között elhelyezkedő számítási környezetre hivatkoznak így \cite{ibm_whatisedge}, illetve vannak források amelyek a határokat teljesen elmosva mindkettőt értelmezik \cite{cb_whatisedge, dataplace_whatisedge}
|
||||
A peremhálózat pontos definiálása egyelőre nem teljesen tisztázott, mivel nem is egy egyszerű kérdés \cite{cureforedge, cloudflare_whatisedge}. Egyes források szerint a peremhálózati számítástechnika az magukon a \gls{vegeszkoz}ökön futtatott alkalmazások \cite{verge_whatisedge}, míg más források a felhő és a \gls{vegeszkoz}ök között elhelyezkedő számítási környezetre hivatkoznak így \cite{ibm_whatisedge}, illetve vannak források amelyek a határokat teljesen elmosva mindkettőt beleértik \cite{cb_whatisedge, dataplace_whatisedge}.
|
||||
|
||||
A fogalom -- és a kapcsolódó fogalmak -- tisztázására és egységesítésére a \textit{Linux Foundation} egy nyitott szójegyzéket hozott létre \enquote{\textit{Open Glossary of Edge Computing}} néven\footnote{\url{https://www.lfedge.org/openglossary/}}. Ezt a szabadon elérhető szójegyzéket egyre több gyártó ismeri el és használja \cite{openglossary}.
|
||||
|
||||
A szójegyzék jelenlegi (2.0-ás verzió) kiadása alapján néhány fontosabb fogalmat az alábbiak szerint definiálhatunk:
|
||||
\begin{itemize}
|
||||
\item \textbf{Cloud Computing} (felhő számítástechnika): Egy olyan rendszer, amely igény-vezérelt hozzáférést biztosít megosztott erőforrásokhoz, beleértve a hálózatot tárolást és számítási kapacitást. Tipikusan kevés számú de nagy méretű regionális \gls{adatkozpont}okat használva.
|
||||
\item \textbf{Cloud Computing} (Felhő számítástechnika): Egy olyan rendszer, amely igény-vezérelt hozzáférést biztosít megosztott erőforrásokhoz, beleértve a hálózatot, tárolást és számítási kapacitást, tipikusan kevés számú, de nagy méretű regionális \gls{adatkozpont}okat használva.
|
||||
|
||||
\item \textbf{Edge Computing} (Perem számítástechnika): A számítási kapacitás eljuttatása hálózat logikai végpontjaiba, annak érdekében hogy ezzel növeljék a teljesítményt, csökkentsék a működtetési költségeket illetve növeljék a rendelkezésre állását a biztosított alkalmazásoknak és szolgáltatásoknak. [\dots]
|
||||
\item \textbf{Edge Computing} (Perem számítástechnika): A számítási kapacitás eljuttatása a hálózat logikai végpontjaiba, annak érdekében hogy ezzel növeljék a teljesítményt, csökkentsék a működtetési költségeket illetve növeljék a rendelkezésre állását a nyújtott alkalmazásoknak és szolgáltatásoknak. [\dots]
|
||||
|
||||
\item \textbf{Edge Cloud} (Perem felhő): felhő-szerű képességek az infrastruktúra peremén, amely -- a felhasználó perspektívájából -- hozzáférést enged \gls{elasztikus}an allokált számítási, adat tárolási és hálózati erőforrásokhoz. Többnyire észrevétlenül szolgál a centralizált privát- vagy publikus felhő kiterjesztéseként. A hálózat peremén telepített mikro-\gls{adatkozpont}okból épül fel. Időnként elosztott perem-felhőként hivatkoznak rá.
|
||||
|
||||
\item \textbf{Edge Data Center} (Perem-\gls{adatkozpont}): Olyan \gls{adatkozpont} amelyet a mennyire csak lehet a hálózat pereméhez lehet telepíteni szemben a hagyományos \gls{adatkozpont}okkal. Képes arra, hogy ugyanazokat a szolgáltatásokat nyújtsa, de önmagában egy sokkal kisebb skálán. [\dots] A \textit{perem} itt a telepítés helyére hivatott utalni. [\dots] Több perem-\gls{adatkozpont} egymással közvetlen kapcsolatban állhat, hogy ezzel biztosítsanak nagyobb kapacitást, migrációt meghibásodás elkerülés vagy terhelés elosztás céljából egy nagy virtuális \gls{adatkozpont}ként funkcionálva.
|
||||
|
||||
\item \textbf{Infrastructure Edge} (Infrastruktúra pereme): Számítási kapacitás a peremen tipikusan egy vagy több perem-\gls{adatkozpont} formájában megvalósítva, amelyet a szolgáltatói \gls{lastmile}ön telepítenek. Számítási, adattárolási és hálózati előforrások, amelyeket az infrastruktúra peremére telepítenek lehetővé teszi a felhőszerű szolgáltatások nyújtását, hasonlóképp mint a centralizált központi \gls{adatkozpont}okban. Ilyenek például az erőforrások \gls{elasztikus} allokációja. De mindezt alacsonyabb késleltetéssel és csökkentett adat továbbítási költségekkel, a magas fokú lokalizációnak köszönhetően szemben a centralizált vagy regionális \gls{adatkozpont}okkal.
|
||||
\item \textbf{Infrastructure Edge} (Infrastruktúra pereme): Számítási kapacitás a peremen, tipikusan egy vagy több perem-\gls{adatkozpont} formájában megvalósítva, amelyet a szolgáltatói \gls{lastmile}ön telepítenek. Számítási, adattárolási és hálózati előforrások, amelyeket az infrastruktúra peremére telepítenek és lehetővé teszik a felhőszerű szolgáltatások nyújtását, hasonlóképp mint a centralizált központi \gls{adatkozpont}okban. Ilyenek például az erőforrások \gls{elasztikus} allokációja, de mindezt alacsonyabb késleltetéssel és csökkentett adat továbbítási költségekkel, a magas fokú lokalizációnak köszönhetően szemben a centralizált vagy regionális \gls{adatkozpont}okkal.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
@@ -115,7 +116,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.
|
||||
|
||||
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.
|
||||
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
|
||||
@@ -124,9 +125,9 @@ Ez a fajta logikai \enquote{közelség} úgy valósul meg, hogy az úton, amelye
|
||||
\label{fig:overview_with_edge}
|
||||
\end{figure}
|
||||
|
||||
Az egyik ilyen jelentős előny a késeltetés javítása. A hálózati adattovábbításhoz szükséges időt jelentősen befolyásolja mind az, hogy fizikailag milyen távolságba kell eljuttatni az információt (a jelenlegi legerősebb limitáló faktor maga a fényebesség az optikai összeköttetések esetén) de sokkal inkább az, hogy hány csomóponton kell áthaladnia útközben a csomagnak \cite{server_location_matters}. Azzal, hogy a távolságot és a köztes csomópontok számát csökkentjük jelentős javulást tudunk elérni a késleltetésben.
|
||||
Az egyik ilyen jelentős előny a késeltetés csökkentése. A hálózati adattovábbításhoz szükséges időt jelentősen befolyásolja mindaz, hogy fizikailag milyen távolságba kell eljuttatni az információt (a jelenlegi legerősebb limitáló faktor maga a fényebesség az optikai összeköttetések esetén) de sokkal inkább az, hogy hány csomóponton kell áthaladnia útközben a csomagnak \cite{server_location_matters}. Azzal, hogy a távolságot és a köztes csomópontok számát csökkentjük, jelentős javulást tudunk elérni a késleltetésben.
|
||||
|
||||
Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetniük kell az egyes feleknek \cite{cloudflare_price_of_bandwidth}. Azzal, hogy az információnak kevesebb köztes csomóponton kell áthaladnia jelentős adatforgalmi költségeket lehet megtakarítani a köztes szolgáltatóknak. Különös tekintettel arra az esetre, ha az adatforgalom nem hagyja el a szolgáltatói hálózatot.
|
||||
Az adatforgalomért sok esetben az internet szolgáltatók között is fizetniük kell az egyes feleknek \cite{cloudflare_price_of_bandwidth}. Azzal, hogy az információnak kevesebb köztes csomóponton kell áthaladnia, jelentős adatforgalmi költségeket lehet megtakarítani a köztes szolgáltatóknak. Különös tekintettel arra az esetre, ha az adatforgalom nem hagyja el a szolgáltatói hálózatot.
|
||||
|
||||
% TODO: privacy
|
||||
|
||||
@@ -136,16 +137,16 @@ Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetni
|
||||
|
||||
\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.
|
||||
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.
|
||||
|
||||
% Itt le kell írni hogy van ez a két dolog
|
||||
Egy ilyen \enquote{szimbiózisban} a peremhálózati rendszerekre mint a felhős szolgáltatások kiterjesztéseként tekinthetünk \cite{7807196}. A peremhálózati rendszerek korábban említett két előnye, amelyek az alacsony késleltetés és csökkentett hálózati költségek, kiegészítik a felhős alkalmazásokat. A késleltetés érzékeny, vagy nagy adatot fogadó komponenseket kiszervezhetjük a peremre, ott akár még előfeldolgozást is végezhetünk az adatokon, így csökkentett mennyiségű és kevésbé késleltetés érzékeny adatokat kell csak eljuttatnunk a felhőbe, ezzel akár még a felhasználói élményt is javítva.
|
||||
Egy ilyen \enquote{szimbiózisban} a peremhálózati rendszerekre, mint a felhő alapú szolgáltatások kiterjesztéseként tekinthetünk \cite{7807196}. A peremhálózati rendszerek korábban említett két előnye, amelyek az alacsony késleltetés és csökkentett hálózati költségek, kiegészítik a felhő alapú alkalmazásokat. A késleltetés érzékeny, vagy nagy adatot fogadó komponenseket kiszervezhetjük a peremre, ott akár még előfeldolgozást is végezhetünk az adatokon, így csökkentett mennyiségű és kevésbé késleltetés érzékeny adatokat kell csak eljuttatnunk a felhőbe, ezzel akár még a felhasználói élményt is javítva.
|
||||
|
||||
A gyakorlatban a technológia adott arra, hogy szinte bármit a kiszervezzünk a központi felhőből a peremhálózati rendszerekre. Viszont a fent említett előnyök általában véve csak az alkalmazás valamely részegységében adnak értelmezhető hasznot. Fontos ezért a megfelelő architekturális tervezése az alkalmazásnak, illetve az alapos felmérése az igényeknek és a hasznoknak.
|
||||
A gyakorlatban a technológia adott arra, hogy szinte bármit kiszervezzünk a központi felhőből a peremhálózati rendszerekre. Viszont a fent említett előnyök általában véve csak az alkalmazás valamely részegységében adnak értelmezhető hasznot. Fontos ezért a megfelelő architekturális tervezése az alkalmazásnak, illetve az alapos felmérése az igényeknek és a hasznoknak.
|
||||
|
||||
|
||||
\section{Gyakorlati alkalmazás}
|
||||
Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek alkalmazásával jelentős javítást lehet elérni a fenti szempontokban.
|
||||
Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek alkalmazásával jelentős javulást lehet elérni a fenti szempontokban.
|
||||
|
||||
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}.
|
||||
|
||||
@@ -154,9 +155,9 @@ A dolgozatom részeként két konkrét alkalmazáson mutatom be a felhő és a p
|
||||
\section{Alkalmazás futtatási és fejlesztési keretrendszerek}
|
||||
\label{sec:frameworks}
|
||||
|
||||
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.
|
||||
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 megoldják. Í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.
|
||||
|
||||
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.
|
||||
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 és fedje el 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.
|
||||
|
||||
@@ -164,17 +165,17 @@ A feladatom megvalósításához több ilyen keretrendszert is megvizsgáltam, e
|
||||
|
||||
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.
|
||||
A keretrendszer komponensei lazán csatoltak. Ez lehetővé teszi, hogy 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.
|
||||
|
||||
A keretrendszert felépítő mikroszolgáltatások négy rétegbe sorolhatóak:
|
||||
\begin{itemize}
|
||||
\item \textit{Core Services Layer} (Központi szolgáltatások rétege): Ez a réteg tartalmazza az \textit{EdgeX} működéséhez elengedhetetlen komponenseket. Ezek felelnek az adatok és parancsok továbbításáért illetve a konfiguráció kezeléséért.
|
||||
\item \textit{Core Services Layer} (Központi szolgáltatások rétege): Ez a réteg tartalmazza az \textit{EdgeX} működéséhez elengedhetetlen komponenseket. Ezek felelnek az adatok és parancsok továbbításáért, illetve a konfiguráció kezeléséért.
|
||||
|
||||
\item \textit{Supporting Services Layer} (Támogató szolgáltatások rétege): Ez a réteg fogja össze a peremhálózaton működő analitikát, naplózást, ütemezést és tisztítási munkálatokat ellátó szolgáltatásokat. Ezek a szolgáltatásoknak valamilyen formában mindig szüksége lesz a központi réteg szolgáltatásaira hogy működjenek. Ezek a szolgáltatások teljesen opcionálisnak tekinthetőek.
|
||||
\item \textit{Supporting Services Layer} (Támogató szolgáltatások rétege): Ez a réteg fogja össze a peremhálózaton működő analitikát, naplózást, ütemezést és tisztítási munkálatokat ellátó szolgáltatásokat. Ezek a szolgáltatásoknak valamilyen formában mindig szüksége lesz a központi réteg szolgáltatásaira, hogy működjenek. Ezek a szolgáltatások teljesen opcionálisnak tekinthetőek.
|
||||
|
||||
\item \textit{Application Services Layer} (Alkalmazás szolgáltatások rétege): Ebben a rétegben található szolgáltatások felelnek a az információ külső szolgáltatásba való továbbításáért: a gyűjtött adatok feldolgozásáért átalakításáért és továbbküldéséért. Az itt elhelyezkedő szolgáltatások \enquote{funkcionális csővezetéket} valósítanak meg. Ami azt jelenti, hogy minden feldolgozandó adat egy folyamatot indít el, amelynek során az funkciókon keresztül jut el végül a küldésig.
|
||||
\item \textit{Application Services Layer} (Alkalmazás szolgáltatások rétege): Ebben a rétegben található szolgáltatások felelnek a az információ külső szolgáltatásba való továbbításáért: a gyűjtött adatok feldolgozásáért, átalakításáért és továbbküldéséért. Az itt elhelyezkedő szolgáltatások \enquote{funkcionális csővezetéket} valósítanak meg. Ami azt jelenti, hogy minden feldolgozandó adat egy folyamatot indít el, amelynek során az funkciókon keresztül jut el végül a küldésig.
|
||||
|
||||
\item \textit{Device Services Layer} (Eszköz szolgáltatások rétege): A rétegben elhelyezkedő szolgáltatások feladata a többi eszköz és szenzor fölé, egyfajta interfész megvalósítása. Egy szolgáltatás egy vagy több eszközt vagy szenzort kiszolgálhat annak natív protokollját használva. A natív protokollon érkező, vagy arra küldendő adatokat ezeknek a szolgáltatások a felelőssége átalakítani az \textit{EdgeX} többi rétegében használt közös formátumra alakítani.
|
||||
\item \textit{Device Services Layer} (Eszköz szolgáltatások rétege): A rétegben elhelyezkedő szolgáltatások feladata a többi eszközzel, szenzorral való interfész megvalósítása. Egy szolgáltatás egy vagy több eszközt vagy szenzort kiszolgálhat, annak natív protokollját használva. A natív protokollon érkező, vagy arra küldendő adatokat ezeknek a szolgáltatásoknak a felelőssége átalakítani az \textit{EdgeX} többi rétegében használt közös formátumra.
|
||||
\end{itemize}
|
||||
|
||||
Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a biztonságért és a rendszerfelügyeletért felelnek.
|
||||
@@ -185,9 +186,9 @@ Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a
|
||||
|
||||
A \textit{Project EVE} célja egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. \Gls{linux} alapokra épített operációs rendszerük neve az \textit{EVE-OS}. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az \textit{EVE}-OS jelenleg támogat \textit{Docker} konténereket, virtuális gépeket és \textit{Kubernetes} klasztereket, viszont utóbbi támogatása erősen kezdetleges.
|
||||
|
||||
A projekt tervezése során kiemelt figyelmet fordítottak a a teljesítmény optimalizálásra. Lehetőség van az operációs rendszerben hogy a processzor és GPU erőforrásokat az egyes alkalmazások számára dedikáltan rendelje hozzá, valamint lehetséges távolról befolyásolni a processzor, memória, hálózat és egyéb erőforrások ütemezését. Mindezek mellett hangsúlyosak a biztonsági szempontok is mind hardveresen és szoftveresen is: A nem használt \acrshort{io} portokat ki lehet kapcsolni. A használt szoftverek távoli és automatizált frissítése is lehetséges. Az EVE-OS a rajta futó alkalmazásoknak további védelmet nyújt a policy alapú, elosztott tűzfal alkalmazásával. A fejlesztők igyekeznek az rendszert úgy konfigurálni, hogy az biztonságos alapbeállításokkal rendelkezzen.
|
||||
A projekt tervezése során kiemelt figyelmet fordítottak a teljesítmény optimalizálásra. Lehetőség van az operációs rendszerben arra, hogy a processzor és GPU erőforrásokat az egyes alkalmazások számára dedikáltan rendelje hozzá, valamint lehetséges távolról befolyásolni a processzor, memória, hálózat és egyéb erőforrások ütemezését. Mindezek mellett hangsúlyosak a biztonsági szempontok is mind hardveresen és szoftveresen is: A nem használt \acrshort{io} portokat ki lehet kapcsolni. A használt szoftverek távoli és automatizált frissítése is lehetséges. Az EVE-OS a rajta futó alkalmazásoknak további védelmet nyújt a policy alapú, elosztott tűzfal alkalmazásával. A fejlesztők igyekeznek a rendszert úgy konfigurálni, hogy az biztonságos alapbeállításokkal rendelkezzen.
|
||||
|
||||
Az EVE-OS a különböző futtatókörnyezeteket backendként definiálja. A rendszert képes egyszerre több backendhez csatlakozni egy időben. Ilyen backend lehet a felhőben vagy helyileg telepített. Egyszerre képes futtatni Kubernetes klaszterben lévő alkalmazásokat, virtuális gépeket és konténereket.
|
||||
Az EVE-OS a különböző futtatókörnyezeteket backendként definiálja. A rendszer képes egyszerre több backendhez csatlakozni egy időben. Ilyen backend lehet a felhőben vagy helyileg telepített. Egyszerre képes futtatni Kubernetes klaszterben lévő alkalmazásokat, virtuális gépeket és konténereket.
|
||||
|
||||
A különböző backendek támogatása azzal jár, hogy ezeket egységes absztrakt interfészen keresztül kell tudnia kezelnie. Ennek az lehet a hátránya, hogy az elérhető funkcionalitások között a legkisebb közös halmazt szolgálja ki a felhasználó számára. A konkrét platformok egyéni előnyeinek kiaknázásra nem sok lehetőséget ad.
|
||||
|
||||
@@ -199,7 +200,7 @@ A többi bemutatott megoldással szemben az \textit{Akarino Edge Stack} egy spec
|
||||
|
||||
Ezek a specifikációk lefednek számos, a peremhálózati számítástechnika esetében releváns felhasználási területet, például a valós idejű játékokat, videófeldolgozást és elosztott gépi tanulást. A specifikációk megalkotása során cél a komplexitás minimalizálása véges számú lehetséges konfiguráció alkalmazásával. A specifikációk biztonsági szempontokból validálásra kerülnek.
|
||||
|
||||
Lévén ezek csak specifikációk és tervrajzok. Az egyes kiadások nem szoftver termékek, hanem dokumentumok. Az egyes kiadásokban böngészhetünk az alkalmazási területünknek legmegfelelőbb tervrajzok közül és ezeket ingyenesen elérthetjük.
|
||||
Lévén ezek csak specifikációk és tervrajzok, az egyes kiadások nem szoftver termékek, hanem dokumentumok. Az egyes kiadásokban böngészhetünk az alkalmazási területünknek legmegfelelőbb tervrajzok között és ezeket ingyenesen elérthetjük.
|
||||
|
||||
% TODO Majd megemlíteni, hogy ezt is megnéztem esküTM
|
||||
|
||||
@@ -207,7 +208,7 @@ Lévén ezek csak specifikációk és tervrajzok. Az egyes kiadások nem szoftve
|
||||
|
||||
A \textit{KubeEdge} egy \textit{Kubernetes}re épülő rendszer, amely kiterjeszti annak képességeit peremhálózati rendszerek kezelésével \cite{kubeedge_docs}. Így lehetővé teszi a konténerizált alkalmazások futtatását a peremhálózaton. Architektúrája két részből épül fel, a központi felhőből és a peremhálózatól.
|
||||
|
||||
A központi felhőben található fő komponensek a \textit{CloudHub} és az \textit{EdgeController}. Az előbbi egy kommunikációs interfész, amely a peremhálózatot megvalósító szervergépekkel kommunikál. Felelőssége megoldani hogy az információ a lehető legnagyobb valószínűséggel eljusson azokhoz. Ennek érdekében egy átmeneti tárolót is fenntart a küldés alatt álló üzenetekhez. Az utóbbi magukért a szervergépek menedzselésért felel.
|
||||
A központi felhőben található fő komponensek a \textit{CloudHub} és az \textit{EdgeController}. Az előbbi egy kommunikációs interfész, amely a peremhálózatot megvalósító szervergépekkel kommunikál. Felelőssége megoldani, hogy az információ a lehető legnagyobb valószínűséggel eljusson azokhoz. Ennek érdekében egy átmeneti tárolót is fenntart a küldés alatt álló üzenetekhez. Az utóbbi magukért a szervergépek menedzselésért felel.
|
||||
|
||||
A peremhálózaton megtalálható a kommunikációs interfész párja \textit{Edged} néven. Emellett itt fut a \textit{KubeEdge} saját \textit{Pod} életciklus kezelője és meta adat tárolója. Emellett tartalmaz még egy \textit{EventBus} nevű komponenst is, amely a peremhálózaton belüli kommunikációért felel.
|
||||
|
||||
@@ -223,16 +224,15 @@ A rendszer két fő részből áll. Az egyik az \acrshort{aws} felhőben futó s
|
||||
|
||||
A két fő rész képes bizonyos ideig egymástól teljesen függetlenül üzemelni. Ha megszakad az összeköttetés a perem és a felhő rendszer között, akkor a peremhálózati rendszer képes továbbra is zavartalanul kiszolgálni az \acrshort{iot} eszközöket.
|
||||
|
||||
A szolgáltatás árazása az első tízezer csatlakoztatott eszköz esetében havi szinten \$0.16, viszont ebben az árban egyéb \acrshort{aws} szolgáltatások nem tartoznak bele, ami egy konkrét alkalmazás esetében jóval magasabb költségeket is eredményezhet
|
||||
A szolgáltatás árazása az első tízezer csatlakoztatott eszköz esetében havi szinten \$0.16, viszont ebben az árban egyéb \acrshort{aws} szolgáltatások nem tartoznak bele, ami egy konkrét alkalmazás esetében jóval magasabb költségeket is eredményezhet.
|
||||
|
||||
\subsection{Azure \acrshort{iot} Edge}
|
||||
|
||||
Sajnos itt egyértelműen úgy értelmezik a peremhálózati rendszereket, mint ami konkrétan az \acrshort{iot} eszközökön fut, így ez a feladat megoldása szempontjából nem alkalmas. Jelen bemutatása csak a teljesebb kép bemutatását szolgálja.
|
||||
|
||||
Sajnos itt egyértelműen úgy értelmezik a peremhálózati rendszereket, mint ami konkrétan az \acrshort{iot} eszközökön fut, így ez a feladat megoldása szempontjából nem alkalmas. Jelen leírás csak a teljesebb kép bemutatását szolgálja.
|
||||
|
||||
Az \textit{Azure \acrshort{iot} Edge} egy a \textit{Microsoft} által fejlesztett menedzselt (szintén \acrshort{paas}) platform. A rendszer lehetőséget nyújt \acrshort{iot} eszköztár menedzselésére, azokon távoli frissítéseket végezni és az önálló eszközök állapotát megfigyelni. Szükség esetén irányított beavatkozásra is lehetőséget ad egyes eszközökön.
|
||||
|
||||
A rendszer felépítése három fő komponensből áll. Az első az \textit{\acrshort{iot} Edge modules} amely a konkrét futtatható alkalmazásokat jelenti. Ezeknek a futtatásáért felel az \textit{\acrshort{iot} Edge runtime} amelyet az \acrshort{iot} eszközökön kerül telepítésre. És maga a \textit{cloud-based interface} amely a rendszer távoli monitorozásáért és kezeléséért felel.
|
||||
A rendszer felépítése három fő komponensből áll. Az első az \textit{\acrshort{iot} Edge modules} amely a konkrét futtatható alkalmazásokat jelenti. Ezeknek a futtatásáért felel az \textit{\acrshort{iot} Edge runtime} amelyet az \acrshort{iot} eszközökön kerül telepítésre. És maga a \textit{cloud-based interface}, amely a rendszer távoli monitorozásáért és kezeléséért felel.
|
||||
|
||||
A rendszer üzembe helyezéséhez az \acrshort{iot} eszközökön kizárólag az \textit{Azure \acrshort{iot} Edge} csomag telepítése szükséges. Az eszköz regisztrálása után központilag van lehetőség alkalmazásmodulok telepítésére.
|
||||
|
||||
@@ -242,17 +242,18 @@ 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) 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}.
|
||||
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}.
|
||||
|
||||
Implementáció szempontjából a federáció vezérlőre telepít és futtat olyan szolgáltatásokat, amelyek hozzáférnek a \textit{Kubernetes} \acrshort{api} felületéhez, illetve a megfelelő proxykon keresztül a többi klaszter \acrshort{api} felületéhez is. Így képesek olvasni az ott meghatározott egyedi objektumokat és annak megfelelően a megfelelő klaszterekben natív objektumokat létrehozni.
|
||||
|
||||
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.
|
||||
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 többszörösen megfeleljen.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
% TODO: Még lehetne írni jókat erről
|
||||
|
||||
|
||||
Reference in New Issue
Block a user