From 5f866cf307140c86702d44499e45bc44093c2bf2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Torma=20Krist=C3=B3f?= Date: Thu, 12 Dec 2019 17:47:44 +0100 Subject: [PATCH] changes --- src/content/theory.tex | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/content/theory.tex b/src/content/theory.tex index d7db33b..a397e41 100644 --- a/src/content/theory.tex +++ b/src/content/theory.tex @@ -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. \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. @@ -43,7 +43,7 @@ Egy Kubernetes klaszterben két típusú hosztgép lehet. Mindkettőből lehet t \label{fig:k8s-chart} \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. @@ -64,13 +64,13 @@ Logikailag különböző kontrollereket összefoglaló komponens \cite{kuebrnete \end{itemize} \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} 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} -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} \label{sec:container-runtime}