Kubernetes opciók

Címkék

Milyen kubernetes megoldást használtok production/dev/staging szinten?

Nem arra vagyok kíváncsi, hogy ki mit próbált ki pár napos telepítések alatt, hanem mi jutott el legalább addig a szintig, hogy stabilan futott pár hétig, hónapig és futottak benne saját telepítésű app-ok.

A leírásban megírhatod, hogy hol fut (on/off premises), hogy telepítetted és hogy frissíted.

Alap K8s
15% (53 szavazat)
RKE
2% (8 szavazat)
Minikube
2% (7 szavazat)
OpenShift
10% (38 szavazat)
OKD
2% (8 szavazat)
K3s
2% (9 szavazat)
MikroK8s
2% (6 szavazat)
Cloud szolgáltató megoldását használom (eks, gke, stb)
17% (62 szavazat)
Csak teszt szinten használtam / kipróbáltam kubernetest
8% (30 szavazat)
Más, leírom, nem mondom meg, stb.
5% (19 szavazat)
Csak az eredmény érdekel.
34% (122 szavazat)
Összes szavazat: 362

Hozzászólások

Szerkesztve: 2020. 11. 18., sze - 16:10

Fejlesztőként alap k8s-re szavaztam, mert a devops srácok szerencsére nagyjából elrejtik előlünk az implementációs részleteket, így fogalmam sincs.

Mostanság ArgoCD-t, meg Vend-et (ez lehet valami internal fejlesztés, Googleben nem találom) kezdenek el bevezetni, nem tudom, hogy a szavazás témakörébe tartozik-e, de elég impresszív mindkettő dev szempontból. Sokkal egyszerűbb lesz dev-teamen belül managelni a saját infrastruktúránkat.

Infrastructure as Code: típusos DSL infrastruktúra létrehozásához, code-completion, automatikus érték-validáció és dokumentáció IDE-ben.

Minimális kóddal/konfigurációval infrastruktúra létrehozása és managelése fejlesztői csapaton belül. DSL-API fejlesztő közelibb nyelvezettel devOps/sysadmin nyelvezet helyett.

Egyszerűbb karbantartás, debug fejlesztői oldalról: devOps azzal tud foglalkozni amivel szeretne: a fejlesztők tutujgatása helyett életet megkönnyítő toolsetek fejlesztésével.

Bizony ki. Épp most rakok össze megint egy új, dockerizált Java microservice-t Jenkins pipeline + k8s alapon úgy, hogy nagyjából csak copy-paste a példaproject, és szinte csak át kell nevezgetnem a dolgokat. Nem rossz, pár nap alatt megvan az egész Spring Boot configostul mindenestül, de jobb lenne, ha ezt mondjuk le lehetne rövidíteni mondjuk max. egy napra (oké, közben a fejlesztő kolleginát is mentorálom, így nyilván lassabb picit, hogy a nagy részét ő csinálja. Mondjuk a pipeline-t azt magamra vettem, pedig nagyon akarta volna azt is, de hát ugye a határidők...).

Túl sok a boilerplate, amit át kell nyálazni, meg ugye kód reviewn se mindegy, hogy "húbazd, ez egy nagy merge request, előbb eszek és leugrok egy cigire mielőtt nekiállok", vagy "egye fene, ezt a 10 sort átnézem még ebéd előtt"...

én sem szeretem, meg tudlak érteni.

 

(WARNING: ez nem systemd topic, ne kezdjünk bele... :)) egy kissé olyan nekem, mint a systemd: a francnak se kellett, de ha értelmesen van összerakva, és nem tákolva, akkor együtt lehet vele élni, még akár segíthet is: nem is ritkán!

szélsőségesen idealista, fősodratú hozzászólás

sajnos agyatlanul össze-vissza használunk mindent, így minden projektváltáskor egy másik hülyeségeit kell megtanulnom. Mindegyik lead/department azt húzta be amelyikhez épp kedve volt vagy amelyiket az ügyfél akarta vagy épp amelyik az adott évben épp valamiért a legmenőbb volt: k8s, openshift, Minikube...

Szerkesztve: 2020. 11. 18., sze - 17:09

A felsoroltak közül szinte mindegyiket sikerült már ügyfélnél látni/támogatni/építeni.

És mindegyikkel van szopás, nyilván nem azonos mértékű.

Na jó, a legnagyobb, szinte gigantikus szopást akkor láttam, amikor a kedves ügyfél a kubespray nevű cuccra izgult rá, az onprem rendszerének felépítéséhez, és kb. menet közben jött ki, hogy ez koncepcionálisan van elbaszva, de akkor már nem volt idő másik opciót keresniük.

Ha pedig valaki a szopásfaktort akarja csökkenteni, ahhoz a következő receptet tudom ajánlani:

- cattle, not pet (és ez legyen igaz a k8s clusteredre is!) - ergó vagy lakjál cloud szolgáltatónál, vagy legyen saját privát cloud megoldásod, vagy legyen rettentő sok számítógéped (ha a bare metál a mániád)
- IaC, lehetőleg mindenre
- ne keverd a rétegeket össze (tehát a csináljunk SDS-t ugyanabban a clusterban, amiben utána a volume-okat használni is akarjuk, az egy atombiztos módja az önszopatásnak)
- vagy legyen támogatásod egy vendortól, vagy legyen rászánva a megfelelő mennyiségű emberi erőforrás (csapat, sok idővel)

kiváncsiságból: mi van koncepcionálisan elbaszva a kubespraynél?

Több tényező együttműködése okozza szerintem:

- mindenre fel akar készülni, a "tudjon mindent is" hozzáállás
- ehhez egy olyan technológiát használ (Ansible), ami szintén mindenre próbál felkészült lenni, és ez már eleve korlátozza a hatékonyságát
- akik írták, nem látják át eléggé a feladatot, ezért biztosra próbálnak menni sok helyen - ez megintcsak hatékonysági gondokhoz vezet

A végeredmény az, hogy annyira nem hatékony a működése, hogy amit kézzel, egymás után kiadva a parancsokat is max. 1-2 óra alatt meg tudnék csinálni, az egy automatizált toolal ennek a többszörösébe kerül időben (egy 25 node-os cluster létrehozása 4-8 óra). Plusz vannak olyan műveletek, amik teljesen irreális mennyiségű időbe kerülnek (pl. hozzácsapni egy meglevő 25 node-os clusterhez plusz 2 node-ot - ez pár perc kézzel vs ismét 4-8 óra a kubespraynek - itt látszik, hogy valamit nagyon rosszul gondoltak át).

Nyilván ezzel a technológiával, ilyen opcióhalmaz mellett is meg lehetne ezt jól is csinálni, csak akkor jobban kéne érteni, hogy mi pontosan a feladat, és jobban kéne tudni használni az Ansible-t.

Még élesben nem használtam, csak egy videót néztem meg róla, de pl. nekem aki 1 klasztert kell kiépítsek és karbantartsak, nagy segítség, mivel egy upgrade/bővítés/módosítás esetén nem tudom sem a pontos folyamatot sem a megfelelő parancsokat. Ez nekem több nap előkészületet jelentene minden alkalommal. Aki ezt csinálja heti rendszerességgel, annak tényleg egyszerűbb és hatékonyabb lehet kézzel elvégezni a karbantartást.

A kubespray pár yaml-t átírva mindent megold nekem ami szükséges a karbantartáshoz. Az pedig, hogy ez 20-40 percébe kerül, nem 10 perc, mint kézzel, szerintem elfogadható.

2.13-as verzioban javitottak, hogy csak a szukseges ansible fact-eket gyujtik be node-okrol, az ami korabban leginkabb visszafogta a sebesseget es elotte valoban jopar ora is lehetett 10+ node-os cluster upgrade vele. De mult heten 3+35 node-os clustert telepitettem vele kevesebb mint 40 perc alatt.

Egyebkent olykor igen soknak tunik mi mindent csinal, neha feleslegesnek is, ezek egyik resze a mindenfele elo ellenorzesek amiket megcsinal, masik resze meg nyilvan a tobb mindenre is jo legyen alapon (cloud-ok/on-prem, debian/centos/stb. melyik cni-t telepitse, milyen csi-t stb.) ami egyik megoldasnal kell masiknal nincs.

Vannak boven hibai azert kozel sem tokeletes ez sem, viszont cserebe eleg reszletesen testreszabhato valtozokkal, annelkul hogy nagyon at kellene irni. Persze ha sok extra dolgot is akarnak kezelni akkor vagy le vannak maradva vele vagy nem tul kitesztelt dolog lesz belole, 3.0-as verziot lassan otletelik ahol felmerult alap dolgokra fokuszaljanak es kiegeszito dolgokra meg mar ugyis kb mindent kiadnak helm chartkent es hasznaljak majd azokat, meglatjuk mi lesz belole.

az ami korabban leginkabb visszafogta a sebesseget

Hát én mást is láttam. Volt pl. egy lépés, valami olyasmi lehetett, hogy "csináljunk /etc/hosts fájlt minden node-ra, amiben benne van az összes node", vagy valami ehhez hasonló. Ez a lépés a 25 node-os clusterre nem futott le fél óra alatt, és közben a CPU-t és a memóriát is felzabálta (konkrétan a default párhuzamossággal 8GB RAM nem volt elég a gépnek, az OOM killer ölte meg az Ansible-t, aztán -f 1 mellett már hajlandó volt végigmenni).

A lépést magát sem értettem (miért is kéne minden node-ot a hosts fájlba beírni? hát a DNS mi a szent szarra való???), azt se, hogy ezt miért kell minden node-ra újra és újra előállítani (ha már programozni nem tudunk, és ezért ez egy nagyon sok percig tartó műveletté válik), de leginkább azt nem, hogy erre miért nem jó egy shell script ami pár MB memória és max. néhány másodperc CPU felhasználásával elő tudja ezt állítani.

De mult heten 3+35 node-os clustert telepitettem vele kevesebb mint 40 perc alatt

Ezek szerint fejlődőképesek.

Ha hosts file letrehozas 25 node-on fel oraig tartott akkor ott egyeb gond lesz, ennyire nem lassu se kubespray se ansible.

Hogy mire "kell" meg ugyanolyan lesz mint mas nem k8s clustereknel is szokas beallitani, hogy ha dns-el vagy annak eleresevel gond van az onmagaban ne kavarja meg a clustert hogy nem talaljak meg egymast a node-ok.

Ha hosts file letrehozas 25 node-on fel oraig tartott akkor ott egyeb gond lesz, ennyire nem lassu se kubespray se ansible.

Persze, írtam én is ansible scripteket, nyilván nem üzemszerű ez a tempó. De ez mégiscsak egy "produktum", amitől azt várjuk, hogy beindítom, és elvégzi a feladatát, nem azt, hogy nekem kell a motorháztető alatt megszerelni az elcsettintett módon megírt kódot.

szokas beallitani, hogy ha dns-el vagy annak eleresevel gond van az onmagaban ne kavarja meg a clustert

Na jó, de

- ez állítólag egy mindenféle környezethez IS jól hozzáidomítható tool, tehát akkor legyen arra opció, hogy óhajtok-e ilyet vagy sem,
- valójában a node-oknak egyáltalán nincs arra szükségük, hogy egymást névvel tudják megtalálni; a master node-oknak kell tudniuk egymásról, plusz az összes node-nak az API szerver VIP címéről, ezen felül mindent IP címmel csinálnak, ami pedig benne van az adatbázisban.

nyilván nem üzemszerű ez a tempó. De ez mégiscsak egy "produktum", amitől azt várjuk, hogy beindítom, és elvégzi a feladatát

Az egyeb gond alatt azt ertettem, hogy nehezen hiszem hogy ansible vagy kubespray hibaja volt az a lassusag, inkabb oprendszer, network stb. . Mintha azt mondanad az oracle db lassu pedig azt mondtak gyors lesz, mikozben a kenyerpiriton probalod futtatni.

 

legyen arra opció, hogy óhajtok-e ilyet vagy sem

--skip-tags etchosts

alap k8s, AKS, illetve telkó ügyfélnel is volt saját brandelt megoldása

Openshift, nagyvállalat beszállítója vagyunk, az ő rendszerünkbe deployolunk.

Azok akik k3s-re szavaztak K3OS-sel használják, vagy valami "rendes" Linuxra rakva?

En ugy latom, hogy igazan megbizhato rendszer szeretne az cloud megoldast valaszt, vagy osszerak egy openshift rendszert. Vagy kombinaltan cloudban az openshift. Persze local fejlesztoi rendszernek jo lehet egy minikube, mikrokube, de eles kornyezetbe nem raknam.

Szerkesztve: 2020. 11. 18., sze - 21:46

Alap, onprem, puppetből felrántva Debian alapra, néhol pedig AKS es GKE. Ésszel hasznalva mind jó.

Nekünk kb. 30 clusterünk megy 150 host / 4000 POD / 3500 service; AWS + GiantSwarm managed / Terraform + home grown deployer (Ansible kéne, de a kollégák idegenkedtek) + Jenkins pipeline deployol Gitből

- automatizálás, automatizálás (fentebb írta vl, nagyon fontos: maga a cluster is eldobható kell legyen / cattle not pet)

- egy deployment nem deployment

- bizonyos méret felett elkél a segítség -- nem érdemes magad futtatnod  -- és egy clusterrel képtelenség lefedni

Nem teljesen ideovalo kerdes, de a kommenteket olvasva felmerult bennem. Magyar multiknal porog ennyire a kontenerezes? (paran irtatok, hogy nem csak fejlesztoi oldalon, de mar uzemeltetoin is Openshift, etc van) En Nemet multi leanyvallalatanal dolgozom, de sem nalunk, sem az anyacegnel hire hamva nincs sem a Kubernetesnek, sem semmi hasonlonak... Sot meg egy arva devOpsal sem talalkoztam... :P (autoipari beszallitok vagyunk)

Én is dolgozok egy német multival, szintén autóipar. Ők is eléggé le vannak maradva technológiailag. Mindent amit bevezetnek hónapogik/évekig tesztelnek (azaz sokszor már rég elavult amire bevezetik), bármilyen infrastrukturális módosítás hónapokba telik náluk, stb. A hatékonyságuk erősen tart a nullához.

A devops és az új technológiák azok inkább a startup világba illenek, mint az őskövület multik világába. Ez idővel szerintem vissza is üthet nekik. Szerintem is fontos a biztonság és a stabilitás, de egy egyensúlyra kellene inkább törekedni.

Nekem pedig AWS lambda alternativat javasoljatok!:)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Amazon EKS. K9S toollal szoktam nyomulni, de mint fejlesztő, nem vagyok jogosult az infrát bántani, csak az alkalmazások telepítésével és üzemeltetésével foglalkozom. Ha hozzá kell nyúlni az infrához, akkor erre van megfelelő tudású és jogosítványú csapat.

Szerkesztve: 2020. 11. 19., cs - 10:50

Onpremises OKD, amit kitartó shell script mágiával OpenShift-é varázsol a DevOps.

Minikube-ra szavaztam, mert lokál gépen az fut. Fenn a céges felhőben f***tudja. :D

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Nalunk most pont RKE/Rancher megy. Erdekes, hogy OpenShift mennyi szavazatot kapott.