Virtual Kubernetes Clusters (vcluster)

HUP
Papp Lajos előadása a HWSW free! meetup-sorozat 2022. október 20-i KUBERNETES tematikájú állomásán hangzott el.

A Kubernetes alapvetően namespace-eket használ egy clusteren belüli izolációs doboz biztosításához, ezért fejlesztőként egy clusterhez gyakran csak pár kiválasztott, vagy akár csak egyetlen egy namespace-en férünk hozzá. Hogyan tudok egy ilyen környezetben kipróbálni (helm-mel telepíteni) egy olyan eszközt, ami cluster szintű jogosultságokat kér? Például egy másik ingress controllert (traefik / nginx), vagy tesztelném valamelyik service mesh-t (istio / linkerd2), vagy csak játszanék a cert-managerrel. Erre is jó a vcluster!

Üzemeltetőként pedig ahelyett, hogy sok kis clustert üzemeltetnék (több ügyfélnek vagy dev/qa/pre környezetek), egy fizikai clusteren tudok olyan hatást kelteni, hogy aki a vclustert használja, azt fogja gondolni, ő cluster-admin, azonban a külső clusteren valójában csak podokat tud futtatni.

Ismerjük meg a vcluster különböző felhasználási eseteit, és azt is, hogyan működik.

( asm v | 2023. 02. 06., h – 21:03 )

Hasznalja ezt vki vmire? (ugyertem a kiprobalason kivul vmi ertelmesre)

Nem használjuk, de el tudom képzelni, ma is jött valami ügyfél hogy a nyomi upstream helm chartja ClusterRole-t akar csinálni; de jó lehet kisebb /egyszerűbb use-case-ű clusterek konszolidálására, ilyesmik.

Az érdekes kihívás, hogy hogyan kezeli a különböző provisionereket PVC/LoadBalancer Service-k stb., a CustomResource-okat a hálózatot; most, hogy ezt leírtam, van egy olyan érzésem, hogy néha inkább bonyolítaná, mint egy egyszerűsítené a dolgokat.

A videot elnezve elgondolkodtam azon, hogy a kisebb CI/dev/test/staging akarmi kornyezeteket ossze lehetne-e vonni igy, de ezzel csak jobban eltavolodnank a prod konfigjatol, amibol meg csak gond lehet. Az a havi parszaz dollar, amibe kerul nehany plusz EKS/AKS/GKE nem biztos hogy er ekkora kockazatot.

Meg az jutott eszembe, hogy az ilyen eldobhato (rovid eletu) EKS clusterekhez kepest megvan az az elonye, hogy gyorsabban letrehozhato es torolheto. Egy EKS letrehozasa mindenestol (+ VPC, EC2 node-ok, stb.) tobb mint 10 percig tarthat terraformmal. Mondjuk ehhez meg ki- es beskalazas kell, ami szinten par perc lehet.

Nalunk az alakult ki, hogy eldobhato clusterra Kind clustert inditunk localhoston. Csak nyilvan ez nem epitheto bele egy CI-ba. Ha vki mindenaron egy cloudon futo CI-t szeretne egy tetszoleges nem a hosztolt appokat erinto modositasra (ingress controller, fluentd, ...) akkor vegulis a vcluster egy eszkoz lehet ra. De nekem az a felelmem, hogy ha tok sok meloval osszeraknank egy ilyen CI-t, akkor az egy prod/referencia konfigtol eltorzult env-en futna, fene tudja milyen kulonbsegekbol johetnek elo hibak kesobb.

Ha engem kérdezel sok értelme nincs, ha kell egy külön cluster sokból nem tart egy új EKS-t felhúzni (vagy azzal ekvivalenst bárhol máshol)... A monitoringot/operation feladatokat pedig így is össze lehet közös felületre terelni, nincs szükség igazából közös clusterre ahhoz, hogy egy csapat tudja üzemeltetni az összeset. Ezen kívül az egyik legnagyobb hátránya a shared clusternek továbbra is megmarad, nevezetesen, hogy nem tudsz verziót upgrade-elni, amíg az összes tenant nem készül fel, tehát a legagilisabb csapatoknak is várni kell a leglassabbakra.

Ha jol ertem a vcluster sajat control-plane-nel (kulon api-server es tarsai) rendelkezik, akkor az miert ne lehetne eltero k8s verzioju? A syncernek kell tudnia lekezelni a kulonbsegeket, amit eleg nagy melo lehet lekezelni. Mondjuk ebbol kovetkezik, hogy az N verzioju syncer csak az N-1, N-2... host cluster verziokat ismerheti, jovobeli N+1-rol nincs informacioja. Tehat vclusterrel inkabb elore lehet szaladni, nem lemaradni a tobbiektol.

( kallo | 2023. 02. 07., k – 16:08 )

tök jól hangzik, remélem hamarosan openshiftre is lesz.