From 5dd6c45f4214d4cde4f9c608837a1871c72b3a30 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pomucz=20Tam=C3=A1s?= <pomucz@sch.bme.hu>
Date: Sun, 23 Mar 2025 23:02:12 +0100
Subject: [PATCH] Typo fixes

---
 readme.md | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/readme.md b/readme.md
index 2770504..5ba01cc 100644
--- a/readme.md
+++ b/readme.md
@@ -1,6 +1,6 @@
 # KSZK vCluster dokumentáció
 
-Ebben a repo-ban található a KSZK vCluster szolgáltatásának dokumentációja. Az az itt található anyagok előzettes kubernetes tudást feltételeznek, főként a szolgáltatás sajátosságainak ismertetésére készültek.
+Ebben a repo-ban található a KSZK vCluster szolgáltatásának dokumentációja. Az az itt található anyagok előzetes kubernetes tudást feltételeznek, főként a szolgáltatás sajátosságainak ismertetésére készültek.
 
 # Mi egy vCluster?
 
@@ -8,9 +8,9 @@ A KSZK korábban biztosított kubernetes szolgáltatást reszorton kívülre, ez
 
 Az új klaszterben a kubernetes szolgáltatást a Loft [vCluster](https://www.vcluster.com/docs/vcluster/introduction/what-are-virtual-clusters) termékére építjük. Ennek segítségével egy virtualizált kubernetes-t tudunk létrehozni. Ez implementáció szinten azt jelenti, hogy a host (azaz a tényleges "fizikai" klaszterben) egy podban elindítunk egy API szervert, a kliensek (pl. egy másik kör) ehhez az API szerverhez csatlakoznak, ez biztosítja a virtuális klasztert. A virtualizált API szerverhez külön virtualizált kontrollerek is tartoznak. Az alacsony szintű objektumokat (pl. pod, service, pvc) a virtuális klaszter és a host klaszter között egy szinkronizáló komponens "másolgatja".
 
-Például a virtuális klaszterben egy deployment létrehozásakor a virtuális deployment kontroller hoz hozzá létre replicaset-et, majd a virtuális replication controler hoz létre egy pod ot (továbbra is csak a vClusteren belül). Ezután a vCluster szinkronizáló komponense megtalálja a pod-ot és átmásolja a host klaszterbe, ahol a host scheduler node-hoz rendeli, majd a host klaszter részét képző kubelet-ek elindítják azt. A host kubeletek által beállított státuszt és eseményeket a szinkronizáló visszamásolja a vClusterbe. A magas szintű absztrakciók (pl. deployment, replicaset) sosem kerülnek át a host klaszterbe, csak az alcsony szintű tényleges erőforrásoknak megfelelők.
+Például a virtuális klaszterben egy deployment létrehozásakor a virtuális deployment kontroller hoz hozzá létre replicaset-et, majd a virtuális replication controler hoz létre egy pod ot (továbbra is csak a vClusteren belül). Ezután a vCluster szinkronizáló komponense megtalálja a pod-ot és átmásolja a host klaszterbe, ahol a host scheduler node-hoz rendeli, majd a host klaszter részét képző kubelet-ek elindítják azt. A host kubeletek által beállított státuszt és eseményeket a szinkronizáló visszamásolja a vClusterbe. A magas szintű absztrakciók (pl. deployment, replicaset) sosem kerülnek át a host klaszterbe, csak az alacsony szintű tényleges erőforrásoknak megfelelők.
 
-A felhasználó számára azt a képet mutatja, mintha egy önálló, teljes értékű klazterrel dolgozna, a virtualizációt ügyes trükkökkel elfedni. Az izoláció így egyértelművé válik, minden felhasználónknak egy saját vCluster instanse-t tudunk futtatni, melyen belül teljes cluster admin jogosultságokat tudunk adni. Lehetőség van akár saját CRD-k, operátorok, namespace-ek használatára is. A hozzáférés kezelést is teljesen ki tudjuk delegálni, saját RBAC objektumok létrehozása is lehetséges, így felhaszálóink másoknak jogosultságokat tudnak adni a saját vCluster-ükhöz, saját service account-okat hozhatnak létre például CI/CD pipeline-oknak. Egy cloud provider által biztosított kubernetes klaszterhez hasonlót tudunk nyújtani.
+A felhasználó számára azt a képet mutatja, mintha egy önálló, teljes értékű klaszterrel dolgozna, a virtualizációt ügyes trükkökkel elfedni. Az izoláció így egyértelművé válik, minden felhasználónknak egy saját vCluster instanse-t tudunk futtatni, melyen belül teljes cluster admin jogosultságokat tudunk adni. Lehetőség van akár saját CRD-k, operátorok, namespace-ek használatára is. A hozzáférés kezelést is teljesen ki tudjuk delegálni, saját RBAC objektumok létrehozása is lehetséges, így felhaszálóink másoknak jogosultságokat tudnak adni a saját vCluster-ükhöz, saját service account-okat hozhatnak létre például CI/CD pipeline-oknak. Egy cloud provider által biztosított kubernetes klaszterhez hasonlót tudunk nyújtani.
 
 # Hogyan tudok csatlakozni a vClusteremhez?
 
@@ -28,7 +28,7 @@ Ha a kubelogin alapú OIDC authentikáció nem felel meg bizonyos esetekben (pl.
 
 # Milyen limitációk vanak érvényben?
 
-Alapértelmetés szerint a vCluster instace-ek az alábbi resource quota alá tartoznak. (Ebbe bele tartozik a vCluster futtatásához szükséges komponensek által elfoglalt erőforrások is, tehát a ténylegesen felhasználható mennyiség egy kicsit kevesebb). Szükség szerint ezek természetesen megemelhetőek:
+Alapértelmezés szerint a vCluster instace-ek az alábbi resource quota alá tartoznak. (Ebbe bele tartozik a vCluster futtatásához szükséges komponensek által elfoglalt erőforrások is, tehát a ténylegesen felhasználható mennyiség egy kicsit kevesebb). Szükség szerint ezek természetesen megemelhetőek:
 ```
 requests.cpu: 20
 limits.cpu: 20
@@ -54,7 +54,7 @@ count/configmaps: 400
 count/persistentvolumeclaims: 40
 ```
 
-Ezek a limitációk nagyon megengedőek, sokkal magasabbak, mint a legtöbb általunk biztosított virtuális gépekhez alokált átlagos erőforrás mennyiség. Arra kérünk mindenkit, hogy nyugodtan használjon annyit, amennyire szüksége van rendszereket futtatni, fejlszteni, laborozni, akár tanulni, viszont aminek már nincs haszna az ne foglalja az erőforrásokat, ne felejtsünk itt futni dolgokat.
+Ezek a limitációk nagyon megengedőek, sokkal magasabbak, mint a legtöbb általunk biztosított virtuális gépekhez allokált átlagos erőforrás mennyiség. Arra kérünk mindenkit, hogy nyugodtan használjon annyit, amennyire szüksége van rendszereket futtatni, fejleszteni, laborozni, akár tanulni, viszont aminek már nincs haszna az ne foglalja az erőforrásokat, ne felejtsünk itt futni dolgokat.
 
 A kényelem kedvéért limit range-et is definiáltunk (ha nem adtok meg resoure limit / request-et ezek az alapértelmezettek), érdemes és kérünk is mindenkit, hogy ezeket manuálisan adják meg az alkalmazásnak megfelelő értékekre, ebben segít a vClusteren belül is elérhető metrics server (kubectl top parancsok).
 Az alapértelmezett limit range-ek:
@@ -73,9 +73,9 @@ cpu: 100m
 
 # Hogyan műdödik a hálózat?
 
-A vCluster egy nagy előnye, hogy minden tényleges munka a host klaszterben történik, így nincs semmi extra teljesítményvesztés, ennek köszönhetően a futtatok podok a host hálózatát használják, a host pod és sercive címtartományokból kapnak címeket. A kellő izoláció elérése végett a host klaszterben a vClusterek forgalma a vClusteren belülre, valamint a publikus internetre és az SCHNET kollegistáknak szánt hálózataira van korlátozva, vClusteren belüli pod-ból hozzáfértek így pl.: a 10.152.0.0/16-os IP-k hez is. Érdemes tudni, hogy házon belül a pod-ok a saját IP címükkel kommunikálak, házon kívülre pedig NAT-olásra kerülnek, azaz például egy kollegista IP (akár publikus akár privát) a 10.42.0.0/16-os tartományból fogja látni a pod forgalmát, még házon kívül a 152.66.208.10-es címről.
+A vCluster egy nagy előnye, hogy minden tényleges munka a host klaszterben történik, így nincs semmi extra teljesítményvesztés, ennek köszönhetően a futtatok podok a host hálózatát használják, a host pod és sercive címtartományokból kapnak címeket. A kellő izoláció elérése végett a host klaszterben a vClusterek forgalma a vClusteren belülre, valamint a publikus internetre és az SCHNET kollégistáknak szánt hálózataira van korlátozva, vClusteren belüli pod-ból hozzáfértek így pl.: a 10.152.0.0/16-os IP-k hez is. Érdemes tudni, hogy házon belül a pod-ok a saját IP címükkel kommunikálnak, házon kívülre pedig NAT-olásra kerülnek, azaz például egy kollégista IP (akár publikus akár privát) a 10.42.0.0/16-os tartományból fogja látni a pod forgalmát, még házon kívül a 152.66.208.10-es címről.
 
-A vCluster-ben lehetőség van LoadBalancer típusú service létrehozására, ekkor egy publikus IP cím kerül allokálása automatikusan. Ha a service-t ellátod a `kszk.bme.hu/IPPool: private` label-el, akkor a 10.44.0.0/16 os tartományból allokált privát címet fog kapni, mely csak kolis hálózaton belül érhető el. Privát címből nagyon sok van, publikusból lényegesen kevesebb, sajnos nincs módunk ezekre külön quota-t helyezni, így csak 2 LoadBalancer címet tudtok alokálni tartománytól függetlenül összesen, viszont ha tudnátok használni többet nyugodtan vegyétel fel velünk a kapcsolatot.
+A vCluster-ben lehetőség van LoadBalancer típusú service létrehozására, ekkor egy publikus IP cím kerül allokálása automatikusan. Ha a service-t ellátod a `kszk.bme.hu/IPPool: private` label-el, akkor a 10.44.0.0/16 os tartományból allokált privát címet fog kapni, mely csak kolis hálózaton belül érhető el. Privát címből nagyon sok van, publikusból lényegesen kevesebb, sajnos nincs módunk ezekre külön quota-t helyezni, így csak 2 LoadBalancer címet tudtok allokálni tartománytól függetlenül összesen, viszont ha tudnátok használni többet nyugodtan vegyétel fel velünk a kapcsolatot.
 
 # Hogyan tudok ingress-t használni?
 
@@ -87,8 +87,8 @@ Biztonsági okokból nem biztosítunk host clusteren keresztül ingress szolgál
     --repo https://kubernetes.github.io/ingress-nginx \
     --namespace ingress-nginx --create-namespace  -f ingress-controller/values.yaml
     ```
-- Az ingress controllert érdemes periódikusan frissíteni, a legújabb verzió telepítéséhez add ki az előbbi parancsot megint.
-- Mostmár fogod tudni használni az ingress erőforrásokat, viszont https tanusítványok beszerzése érdekében érdemes cert-manager-t is telepíteni a klaszterbe, ezt az előzőhez hasonlóan az alábbi két parancsal tudod megtenni:
+- Az ingress controllert érdemes periodikusan frissíteni, a legújabb verzió telepítéséhez add ki az előbbi parancsot megint.
+- Mostmár fogod tudni használni az ingress erőforrásokat, viszont https tanúsítványok beszerzése érdekében érdemes cert-manager-t is telepíteni a klaszterbe, ezt az előzőhez hasonlóan az alábbi két paranccsal tudod megtenni:
     ```
     helm repo add jetstack https://charts.jetstack.io --force-update
     ```
@@ -104,10 +104,10 @@ Biztonsági okokból nem biztosítunk host clusteren keresztül ingress szolgál
 
 # Hogyan tudok perzisztens tárhelyet használni?
 
-A KSZK klasztere tárhely szempontjából a memory elnevezésű rendszerünkre épít, ez egy 3 fizikai node-ból álló, összesen kb. 60 TB nyers tárkapacitással rendelkező [Ceph](https://ceph.io/) klaszter. A kubernetes klaszter ebből képes a megszokott PVC-k segytségével tárhelyet allokálni. Az alábbi storageclass-ok érhetőek el egy vClusterben:
+A KSZK klasztere tárhely szempontjából a memory elnevezésű rendszerünkre épít, ez egy 3 fizikai node-ból álló, összesen kb. 60 TB nyers tárkapacitással rendelkező [Ceph](https://ceph.io/) klaszter. A kubernetes klaszter ebből képes a megszokott PVC-k segítségével tárhelyet allokálni. Az alábbi storageclass-ok érhetőek el egy vClusterben:
 - memory-ssd: SSD-k által kiszolgált Ceph RBD alapú block storoge, gyors, egyszerű, a legtöbb esetben ezt érdemes használni.
 - memory-hdd: HDD-k által kiszolgált Ceph RBD alapú block storoge, lassabb mint az SSD variáns, de cserébe sok van belőle.
 - memory-ssd-rwx: SSD-k által kiszolgált CepfFS alapú ReadWriteMany támogatással rendelkező tárhely, akkor érdemes használni, ha szükséged van ReadWriteMany-re.
 - longhorn és longhorn-static: Deprekált régi tárhelymegoldásunk, ne használd.
 
-A storage-example mappában található egy példa PVC és pod definíció perzistens tárhely használatára.
\ No newline at end of file
+A storage-example mappában található egy példa PVC és pod definíció perzisztens tárhely használatára.
\ No newline at end of file
-- 
GitLab