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}