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 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). Az adott vCluster limitációit a felhasználás jellege alapján határozzuk meg minden felhasználónknak külön. Szükség szerint ezek természetesen megemelhetőek. Egy példa ezekre a limitekre itt található:

requests.cpu: 10
limits.cpu: 10

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

requests.ephemeral-storage: 20Gi
limits.ephemeral-storage: 20Gi
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

A meghatározott limitációk általában sokkal megengedőbbek, 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.209.121-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.

A host klaszter podjai a Schönherz hálózatáról megcímezhető IP címeket kapnak. Ez azt jeleni, hogy nemcsak a saját IP-jét használja a pod amikor kifelé kommunikál, de azt is, hogy kolin belülről a pod IP címét használva el lehet érni azt. A nemkívánatos hozzáférések elkerülése érdekében a vClusterekhez alapértelmezés szerint létrehozásra kerül egy NetworkPolicy, ami korlátozza a forgalmat csak a vClusteren belülre ingress irányban. Ez a policy a host klaszterben kerül létrehozásra, a vClusteren belül nem látszik. Hátránya ennek, hogy a kubernetes network policy-k működése miatt mivel ez a policy engedélyez a vClusteren-en belül minden kommunikációt, és a NetworkPolicy szabályai additívak, ezért ennél szigorúbb korlátozás létrehozása nem lehetséges a vClusteren belül ingress irányban. Ez persze csak ingress irányban érvényes, egress irányban a network policy-k a megszokott módon működnek. Az alapértelmezett ingress korlátozás a service-ekre is vonatkozik, így egy LoadBalancer service is csak a vClusteren belülről lesz alapértelmezés szerint elérhető. Egy megengedőbb ingress network policy létrehozásával feloldható a korlátozás, tehát ha egy podra pl. egy mindent megengedő ingress policy kerül, akkor pod IP-je kolin belülről közvetlenül elérhetővé válik, valamint egy publikus LoadBalancer service mögötti pod globálisan elérhetővé válik. Kérés esetén az alapértelmezett ingress policy kikapcsolható, ekkor a vCluster használójának lesz a felelősége a nemkívánatos külső hozzáférés korlátozása.

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 helm chart a szükséges network policy-t is létre fogja hozni. 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.

A perzisztens tárhelyekről naponta biztonsági mentés készül. Ennek ellenére ajánljuk a fontosabb adatok alkalmazás szintű biztonsági mentésének beállítását.