diff --git a/src/content/theory.tex b/src/content/theory.tex
index 76d48f0..d7db33b 100644
--- a/src/content/theory.tex
+++ b/src/content/theory.tex
@@ -163,7 +163,7 @@ Nem kifejezetten Function as a Service megoldásról van szó \cite{knative-thou
 
 Mint kor\'abban eml\'itettem, lényeges újítás a tradicionális Kubernetes-hez képest az egyes alkalmazáskomponensek nullára skálázása, valamint a konkurencia alapú skálázás. Mindkettőt a magasabb szintű absztrakció teszi lehetővé, ugyanis bár ezek Knative nélkül is elképzelhető funkciók, ezek megvalósítása számos extra komponens bevezetését igényelné. A nullára skálázáshoz szükséges egy perzisztensen létező egység, a Knative esetében az Istio, valamint a Knative Shared Gateway \cite{knative-gateweay} nevű komponens töltik be ezen egység szerepét. Konkurencia alapú skálázás esetében is ugyanez a komponens végzi a kérések elosztását. Az egy podra eső átlagos konkurens kérések megfigyeléséért egy úgynevezett Knative Autoscaler \cite{knative-autoscaler} felel. Ez az egység hozza a fel- és leskálázási döntéseket, valamint a megfigyelt konkurencia érték alapján a pánik ablak \cite{knative-autoscaler-component} kezdetét és végét.
 
-A pánik ablak akkor lép érvénybe, ha rövid idő alatt nagy terhelés érkezik egy végpontra. Konkrétan a Service létrehozása során megadott célkonkurencia érték kétszerese \'erkezik, kevesebb, mint 6 másodperc alatt. Csak a Knative által bevezetett, konkurencia - azaz egy Service-hez egyidőben beérkező kérések száma - alapú skálázás esetében értelmezhető a pánik ablak. Ekkor viszont nincs lehetőség nullára skálázásra, ugyanis legalább egy Podnak mindig léteznie kell. Pánik ablak során a Knative a konkurencia alapján kiszámolt szükséges podok számának kétszeresét hozza létre. A terhelés stabilizálódása, vagy 60 másodperc elteltével a podok száma visszatér a megfigyelt stabil konkurencia alapján szükséges számúra. Az aktuális konkurencia kiszámítása a Service által létrehozott podokra átlagolva kerül kiszámításra. Ebből a szükséges podok számát az észlelt konkurenciát a Service létrehozása során megadott célkonkurenciával elosztva számolja ki a rendszer. 
+A pánik ablak akkor lép érvénybe, ha rövid idő alatt nagy terhelés érkezik egy végpontra. Konkrétan a Service létrehozása során megadott célkonkurencia érték kétszerese \'erkezik, kevesebb, mint 6 másodperc alatt. Csak a Knative által bevezetett, konkurencia - azaz egy Service-hez egyidőben beérkező kérések száma - alapú skálázás esetében értelmezhető a pánik ablak. Ekkor viszont nincs lehetőség nullára skálázásra, ugyanis legalább egy Podnak mindig léteznie kell. Pánik ablak során a Knative a konkurencia alapján kiszámolt szükséges podok számának kétszeresét hozza létre. Vagy a terhelés stabilizálódása vagy 60 másodperc elteltével a podok száma visszatér a megfigyelt stabil konkurencia alapján szükséges számúra. Az aktuális konkurencia kiszámítása a Service által létrehozott podokra átlagolva kerül kiszámításra. Ebből a szükséges podok számát az észlelt konkurenciát a Service létrehozása során megadott célkonkurenciával elosztva számolja ki a rendszer. 
 
 A Knative automatikusan elvégzi az Istio service mesh létrehozását minden telepített alkalmazáshoz, valamint a konfigurációjának frissen tartását, ezzel a felhasználóknak csak kivételes esetekben kell foglalkoznia. Lehetőség van Istio helyett Gloo \cite{knative-gloo} használatára terheléskiegyenlítőként, de ilyenkor nem minden funkció érhető el. Előnye, hogy kevesebb erőforrást használ, mint az Istio. A szakdolgozatban azért döntöttem az előbbi használata mellett, mert úgy véltem a Knative fejlesztők azt helyezték fókuszba, azt támogatják. További kutatás tárgya lehet a két load balancer közti különbségek vizsgálata.