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

changes

Browse Source
This commit is contained in:
Torma Kristóf 2019-12-12 17:47:44 +01:00
parent 5cd561fb97
commit 5f866cf307
Signed by: tormakris
GPG Key ID: DC83C4F2C41B1047
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
src/content/theory.tex
View File

@ -14,7 +14,7 @@ Platform as a Service típusú szolgáltatások alatt értjük azon szolgáltat
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 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. 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.
@ -43,7 +43,7 @@ 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 klaszterszintű 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.
@ -64,13 +64,13 @@ Logikailag különböző kontrollereket összefoglaló komponens \cite{kuebrnete
\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 1 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 komponenseit \aref{sec:container-runtime}, \aref{sec:kubelet} \'es \aref{sec:kube-proxy} alfejezetekben r\'eszletezem. 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}
\label{sec:container-runtime} \label{sec:container-runtime}