grammar fixing in progress

This commit is contained in:
2019-12-12 01:40:21 +01:00
parent 61510d2f87
commit 8b3d4de355
7 changed files with 68 additions and 63 deletions

View File

@@ -31,7 +31,7 @@ Miután a klaszter minden tagja telepítésre került a további lépéseket a k
\subsection{Kubeless telep\'it\'ese}
A Kubeless telepítése négy lépésből áll. Először a metrics-server nevű komponens telepítésére kerül sor. Erre a Kubeless által használt Horizontal Pod Autoscaler miatt van szükség, ugyanis ez a komponens gyűjti számára a metrikákat a Podokról. Ennek telepítése nem csak a fejlesztők által elkészített YAML állomány applikálásából áll, ugyanis a metrics-server alapértelmezés szerint mutual TLS protokollal titkosítja a kommunikációját a Kubernetes klaszterrel. Erre nincs szükség ebben a klaszterben, ezért ki lehet kapcsolni ezt a viselkedést, amit egy kapcsolóval lehet megtenni. Ez jól automatizálható sed program használatával. A módosított YAML fájlt már applikálni lehet.
Ez után a második lépés az Nginx Ingress Controller telepítése. Itt nincs választási lehetőség, ugyanis a Kubelessbe ez a függőség erősen be van kötve. E komponens telepítéséhez két YAML állományt kell applikálni. Azért kettőt, mert van lehetőség menedzselt Kubernetesbe, valamint saját klaszterbe is telepíteni az Nginx Ingress Controllert. A két állomány közül az egyik minden Kubernetes környezet használata esetén alkalmazásra kell kerüljön, a másik pedig specifikus a felhasználó által használt Klaszter típusához, például Azure Kubernetes, vagy Google Container Engine és saját Kubernetes klaszterekhez külön-külön YAML állomány tartozik.
Ez után a második lépés az Nginx Ingress Controller telepítése. Itt nincs választási lehetőség, ugyanis a Kubelessbe ez a függőség erősen be van kötve. E komponens telepítéséhez két YAML állományt kell applikálni. Azért kettőt, mert van lehetőség menedzselt Kubernetes-be, valamint saját klaszterbe is telepíteni az Nginx Ingress Controllert. A két állomány közül az egyik minden Kubernetes környezet használata esetén alkalmazásra kell kerüljön, a másik pedig specifikus a felhasználó által használt Klaszter típusához, például Azure Kubernetes, vagy Google Container Engine és saját Kubernetes klaszterekhez külön-külön YAML állomány tartozik.
A Kubeless könnyebb kezelése érdekében a harmadik telepítésre kerülő komponens a kubeless parancssori interfész. Ezt a programot már a fejlesztők lefordították, így csupán a megfelelő verzió beszerzése szükséges, annak egy olyan könyvtárba mozgatása, ahol a bash parancssori értelmező keresi a futtatható programokat, például a /usr/local/bin/ könyvtárba.
@@ -40,9 +40,9 @@ Negyedik és utolsó lépésként a Kubeless klaszterbe telepítésére kerül s
Az itt leírt lépések bash szkript segítségével automatizálhatók.
\subsection{Knative telep\'it\'ese}
A Knative telepítése kevesebb komponens feltelepítéséből áll, azok telepítése viszont bonyolultabb. A rendszer telepítése előtt installálni kell az Istiot. Ezt a helm nevű Kuberneteshez készített csomagkezelő rendszer segítségével lehet, viszont a helmet is installálni kell. Ez az Ubuntu rendszerben lévő snap csomagkezelővel telepíthető. A snap abban különbözik az apt-tól, hogy az általa telepített csomagok és a függőségeik a rendszercsomagoktól és a rendszerben jelen lévő osztott könyvtáraktól függetlenek, de hatással lehetnek a rendszerre.
A Knative telepítése kevesebb komponens feltelepítéséből áll, azok telepítése viszont bonyolultabb. A rendszer telepítése előtt installálni kell az Istiot. Ezt a helm nevű Kubernetes-hez készített csomagkezelő rendszer segítségével lehet, viszont a helmet is installálni kell. Ez az Ubuntu rendszerben lévő snap csomagkezelővel telepíthető. A snap abban különbözik az apt-tól, hogy az általa telepített csomagok és a függőségeik a rendszercsomagoktól és a rendszerben jelen lévő osztott könyvtáraktól függetlenek, de hatással lehetnek a rendszerre.
A helm telepítése után inicializálni kell, amely az úgynevezett Tiller a Kubernetesbe telepítését, valamint információegyeztetést a Tiller és a helm között jelenti. Viszont ahhoz, hogy a Tiller a klaszterben a kívánt módosításokat el tudja végezni meg kell neki adni a megfelelő jogosultságokat. Erre úgy van lehetőség, hogy létre kell hozni egy új, úgynevezett Service Accountot, amely hasonlóan viselkedik a felhasználói fiókokhoz, viszont ezt Podokhoz lehet rendelni. A létrehozott Service Accounthoz pedig a cluster-admin jogosultságot kell rendelni. Ennél lehet kevesebb jogot adni a Tillernek, viszont egyetlen felhasználója lesz a klaszternek, így nincs szükség finomhangolt jogosultságkezelésre. Csak e két lépés után lehet inicializálni a helmet, valamint a Tillert.
A helm telepítése után inicializálni kell, amely az úgynevezett Tiller a Kubernetes-be telepítését, valamint információegyeztetést a Tiller és a helm között jelenti. Viszont ahhoz, hogy a Tiller a klaszterben a kívánt módosításokat el tudja végezni meg kell neki adni a megfelelő jogosultságokat. Erre úgy van lehetőség, hogy létre kell hozni egy új, úgynevezett Service Accountot, amely hasonlóan viselkedik a felhasználói fiókokhoz, viszont ezt Podokhoz lehet rendelni. A létrehozott Service Accounthoz pedig a cluster-admin jogosultságot kell rendelni. Ennél lehet kevesebb jogot adni a Tillernek, viszont egyetlen felhasználója lesz a klaszternek, így nincs szükség finomhangolt jogosultságkezelésre. Csak e két lépés után lehet inicializálni a helmet, valamint a Tillert.
Az Istio telepítésének megkezdése előtt létre kell hozni az általa bevezetett új objektumtípusokat, valamint egy külön névteret, ahova az Istio rendszer saját objektumai kerülhetnek. Ez számos YAML állomány applikálását jelenti. Ez után az Istio rendszert telepítő YAML állományt ki kell generáltatni a helmmel. A generálásnál lehetőség van megadni, az Istio mely komponensei ne települjenek. Nincs szükségünk például monitoring rendszerre, telemetria és jogosultságkezelő rendszerre. Ezeket parancssori paraméterrel lehet megadni. A generálás után létrehozott YAML fájl által leírt módosítások végrehajtását a megszokott módon kell végrehajtani.