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ő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?

A KSZK korábban biztosított kubernetes szolgáltatást reszorton kívülre, ezt egy namespce delegálásával valósítottuk meg. A kubernetes jogosultságkezelése sajnos limitált, és nem biztosít erős izolációt a kliensek között, a megfelelő izoláció elérése érdekében tehát csak nagyon alacsony szintű jogosultságokat tudtunk adni.

Az új klaszterben a kubernetes szolgáltatást a Loft vCluster 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 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ű 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?

• Először is szükséged lesz a kubelogin kubectl exension-re. Ezt a linkelt repo-ban található instrukciók alapján tudod telepíteni tetszőleges operációs rendszerre. Jussel el addig, hogy a kubectl oidc-login version parancs működjön.

• Állítsd be az ebben a repo-ban található kubeconfig.yaml file-ba a vClustered URL jét a server: https://vc-test.kszk.bme.hu sorban.

• Ezután a kubeconfig.yaml file-t használva tudsz csatlakozni (pl. export KUBECONFIG=path/to/repo/kubeconfig.yaml, vagy másold be a home-od ban a ~/.kube mappába config-ra átnevezve). Amikor először használod elő fog ugrani a böngésződben egy Microsoft bejelentkező képernyő, ahová a SCHAcc-oddal tudsz belépni.

Hogyan tudok másoknak hozzáférést adni?

Az authentikáció alapvetően SCH Account segítségével történik Microsoft Entra-n keresztül, ide ugyan azokkal az adatokkal tudsz belépni, mint AuthSCH-n amikor nem eduID-t használsz, annyi a különbség, hogy itt két lépcsős azonosítást is be kell állítani. Amikor mi létrehozzuk a klasztert beállítunk egy (vagy akár több) cluster-admin jogosultságot adó ClusterRoleBinding-ot az igénylők SCH Account jára. Ilyen ClusterRoleBinding-okat te is létre tudsz hozni, így nem kell foglalkozni az authentikáció beállításával, csak az authorizációval, mindenki a SchACC-ával tud authentikálni. Egy példa ClusterRoleBinding megtalálható az authentication mappában.

Ha a kubelogin alapú OIDC authentikáció nem felel meg bizonyos esetekben (pl. CI/CD, valakinek nem mükszik, nincs SchACC-a) service account-ok is használhatóak a megszokott módon. Érdemes arra figyelni, hogy a legtöbb klaszerben megszokott certificate-authority-data mezőre itt nincs szükség a kubeconfig-ban, mivel az API szerver publikusan megbízható cert-et használ. A serviceaccount-oknak szánt kubeconifgra egy példa található az authentication mappában.

Milyen limitációk vanak érvényben?

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

requests.memory: 60Gi
limits.memory: 60Gi

requests.ephemeral-storage: 40Gi
limits.ephemeral-storage: 40Gi
requests.storage: "600Gi"
memory-ssd.storageclass.storage.k8s.io/requests.storage: "100Gi"
memory-ssd-rwx.storageclass.storage.k8s.io/requests.storage: "100Gi"
memory-hdd.storageclass.storage.k8s.io/requests.storage: "500Gi"

services.nodeports: 3
services.loadbalancers: 3 # Ebből csak 2-t tudtok használni, lásd lentebb

count/endpoints: 400
count/pods: 40
count/services: 400
count/secrets: 400
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 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:

default: # Limit
ephemeral-storage: 1Gi
memory: 1Gi
cpu: "1"

defaultRequest: # Request
ephemeral-storage: 40Mi
memory: 128Mi
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 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 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?

Biztonsági okokból nem biztosítunk host clusteren keresztül ingress szolgáltatást a vClustereknek, így ingress erőforrások használatához egy saját ingress kontroller telepítése szükséges, ehhez segítségképpen található egy minta helm konfiguráció az ingress-controller mappában (nem kell azt használni, csak példának van). A telepítés lépései:

• Legyen helm a gépeden
• Add ki a következő parancsot:

  helm upgrade --install ingress-nginx ingress-nginx --atomic\
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace  -f ingress-controller/values.yaml

• 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

  helm upgrade --install cert-manager jetstack/cert-manager --atomic \
  --namespace cert-manager --create-namespace  -f cert-manager/values.yaml

• A cert manager-nek még szüksége van egy ClusterIssuer létrehozására, ebben találhatóak az ACME szerver adatai, amivel a tanusítványt tudja kérni, erre található egy példa a cert-manager mappában:

  kubectl apply -f cert-manager/cluster-issuer.yaml

• A ingress és CertManager használatára található egy példa az ingress-controller mappában

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 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ó perzisztens tárhely használatára.