Sziasztok!
Kisebb dolgokra mennyire ajánlanátok a MicroK8s-et production környezetbe? Használja valaki? A doksi alapján erre _is_ készült, tehát mehet prodba, csak azért kíváncsi lennék személyes tapasztalatokra. Kicsit furán hangzik, de a dockeres környezetet szeretném cserélni, különböző dolgok miatt (pl. secret kezelés csak swarm-al megy, de akkor meg a network más, stb.stb.) Hosszú távon úgyis a Kubernetres a defacto irány, ezzel meg nem 2 irányban kellene szórakoztatnom magam, hanem ami dev és pici prod az microk8s, ami meg on-prem az marad ami, ami meg cloud provider, az meg megint marad az. Cserébe nem dockerrel/podmannal játszanék, hanem a kicsi deployment is ugyanaz lenne, mint a nagyok.
A kérdés h. mennyire stabil tapasztalatok alapján ez az egész?
Köszi!
Hozzászólások
Lassan 2.5 éve üzemeltetek microk8s clustert prodban, nincs gond a stabilitásával, verzió frissitések is gondtalanok. Viszont amit javasolni tudok, a bépitett addonokat ne használd.
Mekkora méretben ha nem titkos infó? Gondolok itt a podok számára, esetleges komplexitásra (pl. rook/ceph is van-e benne?).
Elkezdtem azon töprengeni h. ha ez megbízható és clusterelhető is, akkor sokkal könnyebb lenne bevetni egy olyan helyen ahol a kollégák kubernetes tudása (infra szempontból) nem olyan mély.
Kb 4000 körüli pod/cluster, kiprobaltam a rookcephet is, nemvolt vele gond, de egyenlőre maradt a longhorn, illetve mostmár marad is amig AKS be nem költözünk(lesz onprem hci-nk elvileg).
Csak az infra oldali komplexitás véget szerintem majdnem mindegy melyiket választok, rke2-t is elég egyszerű configolni, de igazabol kubeadm se túl nagy történet. Annyi hogy kubapi elé ezeknél kell egy LB, de ezt kb 10p összerakni keepalived+nginx komboval.
Microk8s hez még annyi, hogy igaz hogy régen probaltam már de anno ubuntun kivül mással nem ment, hiába snapböl jön. Szóval ez vedd figyelmbe, hogy megfelel e nektek, hogy ubuntuhoz vagytok kötve.
Köszi szépen! Ez sok és hasznos infó. Alapvetően most Ubuntun akarom összerakni a single node-os storyt Docker helyére, itt biztosan jól érzi magát. Céges környezetben meg játszom a gondolattal, h. esetleg Oracle Cloud Native Env helyett ez, csak ugye ott jön képbe az RHEL/OL vonal támogatottsága, amit alaposabban meg kell vizsgálni majd.
Most első körben egy Portainer + Microk8s-re gondoltam a Docker swarm/Portainer helyett, mert hosszabb távon a kubernetesre átállást kellene erőltetni a fejlesztőknél is és így sokkal egységesebb lenne az egész infra és folyamat is.
Nalunk local dev envként a fejelesztőnek docker compose van és ezen nem is tervezek változtatnia, valószínűleg helye válogatja, de nálunk a fejelesztők egy jó része ha lenne valami hiba a k8s-el localba nem tudná megoldani, szóval csak magamat szivanám meg vele. Meg a dev+staging szerver meg hasonloan van felépitve mint a prod, cicd vel szóval a dev abba nem kell belenyuljon, egyedül adott általunk fejlesztet alkalmazás helm chartjához values.yaml van lerakva a repoba envenként illetve a docker fileok, de ott is elvalik a local,dev és a többi env. Egyéb dependenciák mint pl db, meg tarraformal vannak felhúzva minden projechez (kubernetes+helm provider)
Ja egyebkén OL vonalal jól müködik az rke2, ha úgyolyan szemlélettel setupolod ahogy microk8s-t tehát sajat addonjai nélkül akkor a különbség kb a kubelet dir lesz amit így belegondolva szerintem csi drivereket leszámitva seminnek nemkellett megadjak soha. Szóval simán használható alkalmazasoldarol úgynazzal a configal vegyesen is.
Az egyik helyen teljesen zökldmezőben vagyok a fejlesztőkkel, mert se Dockert, se Kubernetest-t nem láttak még. Így merült fel bennem h. a DEV is legyen valami Kube (erre itt a microk8s vagy a Kind), nem szórakoztatnám magam kétféle environmenttel.
De teljesen jó az is amit írsz, csak gondolom ott a fejlődési görbe más lehetett. Első körben gondolom a DEV konténerizált.
Ez az rke2 is érdekes. Fura, eddig nem kerestem ilyen lightweight Kubernetes dolgokat, erre most rögtön kapok annyi tanácsot h. győzzek olvasni meg tesztelni :)
Ami aztilleti ezis zöldmező project volt, aztán időközben régi projecteket is elkezdtünk átvenni mellé. Szóval amúgy a deveknek is az első dockeres/composeos alapokat én raktam le, vannak amugy olyan fejlesztők a csapatban akik ezelött még nem használtak dockert. Ezel párhuzamosan épült a k8s környzet is. Én ahogy észrevetem fejlesztők egy jó része komfortosabban elnyomkodja a docker desktop gui-ját, részemről meg nem nagy efort, hogy ezt megtehesék :) náluk localba úgye fogod szögre ugynazt a configot futtani mint a szerveren.
Igazából nézegettem ezt a microk8s-t, de elsőre még olyan fura ez a single-node setup nekem. Főleg mondjuk egy podman/docker felálláshoz képest.
Pl most azon malmozok h. meg lehet-e egyáltalán csinálni olyasmire az infrastruktúrát így piciben és kompaktban. Nyilván nem kérem h. oldd meg nekem, de hátha lenne ezekre ötlet (ami persze docker-es felállással so-so jól is menne).
1. Egy gépem van, azon kéne 443-at meg 80-at Ingress-re betolni, de a gépnek 1 pub IP-je van, így elég kanyargós a szitu, mert egy metallb-t nem tudok odaképzelni. Vagy az Ingress-nek NodePort és kész? Prodban? :) Aztán lehet nekem marad ki a kicsi Kubernetes dolog, de eddig v. AWS LB v. nagyobb, BGP-s metallb volt amit csináltam, most meg vakarózok h. aha, jó ötlet volt ez, de most hogy lesz nekem networköm?
2. Internal service access (szintén a picisége miatt lehet csak béna vagyok): pl. egy VPN amin a belső szolgáltatásokat éri el az adott társaság (pl. redis és hasonlók). Simán betol az ember egy tailscale-t/pritunl-t mint nagyban és hajrá?
3. A saját addonjaival mi a baj, azt miért nem ajánlod? Egész sok official addon van ahogy nézegettem a doksit (pl. cert-manager). Nem tartják karban v. mi a gond velük?
Ja és h. ontopic legyek: lehet h. nem lesz ebből DEV-re semmise, csak egy kóbor gondolat volt h. eleve Kube kompatibilisen teremtem meg a környezetet. Ez a Kind dolog pl. egészen jól néz ki és Podman Desktopba is bele lett integrálva, innentől lehet "böködni" :)
Single-node mellet is hasznalhatod nyugodtan a metallb-t, ha csak egy ip-d van akkor lehet fel venni /32 re poolt, kikapcsolni az autoasign-t, ingressen servicen meg megadod anotáciobol melyik poolbol kérje az ip-t, ha több ip van meg ottvan az L2Advertisement. Nodeportot szerintem engedd el, nem kulturált 80,443 miatt böviteni azon a port rangen amit alapból ad.
Feltételezem vpnt kapnának úgyis a usreid, teljesne jó azt használni, akiknek kell ehez hozáférés kerüljenek másik vlanba, clusterek is kapjanak önállo vlant, onnan már úgy tüzfalazol ahogy szeretnél, hogy ki mihez férjen hozzá.
Saját addonokal az a gond, hogy nem frissül csak k8s verziováltásonként, és akkor is csak ha ki be kapcsolod, plusz személyreszabni se lehet rendesen pláne nem infrastructure as code jellegel.
Emellet mondjuk én nem szivesen viszek olyat semmilyen környzetbe amiről nem tudom pontoson hogy van beállítva, utólag szarabb vele foglalkozni mint elsőre normálisan megcsinálni.
Csak a feedback végett, tényleg működik így. Sosem próbáltam és nem is tűnt realisztikusnak, de simán megvan h. /32-vel felvettem a metallb-n, aztán ingress controlleren belőttem h. akkor type loadbalancer, annotációban megkapta h. metallb xy pool (nyilván amiben az egyszem /32 van) és láss csodát, a host IP címén már ott is van az ingress controllerem. Zseniális, köszi :)
A VPN-t már kicsit tovább is gondoltam, csinálok valami lokális bridge-et, arra megy egy metallb, oda megy az internal ingress és akkor kb. ugyanaz mint egy nagyobb rendszerben. Azon meg akár lehet L2advert is, hiszen csak belül van.
Ez az egész mikro (single node) Kube nagyon távol volt eddig tőlem, meg az is h. pl. 1 pub IP-m van, nincs egy egész tartományom BGP-vel mondjuk 2 edgre routerre kötve, stb. De egészen durva h. mennyire meg lehet valósítani a downscalinget ezzel a cuccal.
Szép szám a 4000, grat! Megtudhatom - üzleti titkok nélkül - hogy ebből mennyi a sidacar vagy valami istio? Illetve mennyi az infra (közmű, szükséges cuccok) és mennyi az üzleti alkalmazás?
Nem használunk service mesh-t, Bár idővel tervben van, mert sok microservice van. A nagyja üzleti alkalmazás illetve annak a dependenciái, nálunk minden kubernetesben fut cloudtivepg,galera,cratedb,redis,elasticseaech stb és ez azért elégé megdobja a számokat.
Ha localban szeretnel kubernetest, akkor szerintem arra ez egy kifejezetten jo es alkalmas eszkoz: https://kind.sigs.k8s.io/
Elonye, hogy "csak" docker kell hozza.
En fejlesztoi kornyezetbe integralva talalkoztam vele, szerintem ez meg rugalmasabb egy fokkal, mint a microk8s, konnyebb es gyorsabb telepiteni illetve eldobni, es ujrakezdeni mindent (ha persze erre van igeny).
microk8s esetében csak a "snap"-el van a gond, ha egy terméket építesz rá, mivel azokon a helyeken ahol "dark site"-ként telepítenék (azaz olyan helyre, ahol nincs internet), ott elég sok akadályba lehet ütközni, s ott inkább a vanilla kubernetes felépítése lehet egy jobb megoldás. Ráadásul, ilyen esetben elég jól meg lehet ismerni belőle az apróbb részleteket is - persze felesleges, hogy ha nem erről van szó.
Amúgy a microk8s-et én is csak javasolni tudom, könnyen használható multi-node clusterben, ingressekkel, stb. szépen.
Igazából az air-gapped telepítést is meg lehet oldani, létezik snap store proxy pl. az OS package-ket is le lehet szedni egy private repo-ba, még a livepatch, Ubuntu Pro is működik rendesen. A microk8s addonokhoz meg annyi megjegyzés, hogy valóban meg lehet oldani mindent egy pure microk8s telepítéssel, pl. metallb addon helyett lehet charm-ból is felrakni kényelmesen.
Csak kiváncsiságból, pl metallb addonnal mi lehet a probléma, elvileg "hivatalos" addon. Layer 2 módban nekem ment.
https://blog.claryel.hu
Nincsen vele gond, én is használom. Hosszabb távon szerintem érdemesebb az alap microk8s-t használni, és minden mást charm-ból felrakni hozzá. Ezt pl. elég aktívan karbantartják: https://charmhub.io/metallb
Érdemes mégnézni a k3s-t is, mint alternatívát.
Eees a k0s is alternativa, plane ha IoT endpointokat akarsz managelni :D
Na ez durva, felírom és vmikor meg fogom nézni mert minimal dolgokra egészen jópofa dolognak néz ki.
nem csak minimalban jo, de igen, foleg arra hasznaluk mi is. Ha nem minimalba kell tolni akkor megy valamyik felhobe EKS, AKS, GKS ala aztan jovan
Állítólag (szigorúan olvasás során szerzett infók alapján, nem tapasztalat) nagyobb az overheadje, mint a microk8s-nek. Személyes elfogultságból meg azt mondanám h. hobbi és saját projekteknél az Ubuntu/Debian vonal jobban bejön. Tudom h. csak lazán kapcsolódik a Suse-hoz, de mégiscsak kapcsolódik :)
Nem tudom miert szamit annyira ez az overhead. Az eroforrasok nagy reszet nem a k8s infra hanem a telepitett deployment-ek eszik meg. Sokkal zavarobb ha valami nem mukodik, pl. nem tudsz kiprobalni egy network policy-t mert a fejlesztoi k8s nem tamogatja, es csak uat vagy preprod rendszeren lehet kitesztelni.
En nem tudok nyilatkozni hogy milyen prod-ban, de fejlesztokent eleg sokmindent kiprobaltam, mikrok8s, docker desktop built in k8s-el, rancher desktop k3s-el. De mindig mindennel volt valami szivas, hol a verzio követes volt gond(docker desktop), hol az ingressel volt baja, hol a networking volt gond. Fejlesztoi szempontbol a legkevesebb gond es maximalis kompatibilitas a minikube-al volt docker enginnel. Meg lehet adni milyen verziot szeretnel, meg lehet adni az eroforraslimitet, CPU, RAM, stb ... Standard dolgokat hasznal, soha nem volt gond sem ingress-el, se istio-val, ment a network policy-k is. De nem tudom milyen stabil prod-ban, de lehet futtatni virtualizació-ban. Nem egy lightweight cucc, de nagyon standard.