Kubernetes PersistentVolume konfiguráció

Virtualizáció

ELK (Elasticsearch+Logstash+Kibana) stacket próbálok létrehozni Kubernetessel. Tisztán tanulási céllal, minden egy minikube VM-ben van, amiben van 25Gb tárhelye.

Amit szeretnék megcsinálni: Logstashel folyamatosan tölteni az adatokat Elasticsearchbe és Kibana-val megjeleníteni végül. Ezen belül skálázódást szeretném kipróbálni, pontosabban a konfigurációját, hogyan tudnám elérni, hogy valami mentén skálázódjon ez a setup. Amire elsőként gondoltam, hogy van egy ES master pod és több data pod, alapból 1Gb tárhellyel. Ha fogytán a hely, a saját autoscale konfigom csinál új data pod-ot és remélhetőleg innentől majd abba mennek az indexek. Így tovább egészen mondjuk 10-20 data pod-ig. Remélem eddig még nem hibás az elepelképzelés.

Ahol megakadtam: hiába van elég sok jó leírás és példa konfiguráció a neten, rögtön egy elég alap dolgot nem sikerült megértenem. Csináltam egy 20Gb-s PersistentVolume-ot. Ez a minikube 

/usr/share/elasticsearch/data

könyvtárat használja. Ezek után megcsinálom a StatefulSet-et, ez lenne az, ami meg a megfelelő mennyiségű (egyelőre fix számú) data pod-ot létrehozza. Ennek a StatefulSet-nek a leírásába raktam a 

volumeClaimTemplates

-et ami az előbbi PersistentVolume-ot hivatkozza, továbbá beállítottam, hogy 1Gb-t igényeljen pod-onként. Ez azt eredményezi, hogy 1 pod elkészül, az összes többi pedig pending állapotban marad mert nem talál a PersistentVolumeClaim-hez PersistentVolume-ot.

Kérdésem: a PersistentVolume-ok és PersistentVolumeClaim-ok között 1:1 megfeleltetés kell legyen? Ebben az esetben mi történik 

/usr/share/elasticsearch/data

könyvtárban? Esetleg csináljak 20 könyvtárat minden egyes PersistentVolume-nak és ezek közül fognak majd "válogatni" a pod-ok mikor létrejönnek? Így kellene ennek működni, vagy alapból félreértettem a Kubernetes működését?
Köszönöm előre is a segítséget!

  • 955 megtekintés

( ricpet | 2018. 12. 28., p – 20:56 )

Jól érted. A PersistentVolume-ok és PersistentVolumeClaim-ek között 1:1 megfeleltetés kell. Vagy csinálnod kell kézzel annyi PersistentVolume-ot, ahány pod végül használni akar ilyet. Vagy pedig használhatsz valamilyen provisioner-t, ami ezt automatikusan elvégzi helyetted. Ez azt jelenti, hogy igényléskor csak egy storage class-ra hivatkozol, és akkor a storage class-hoz tartozó provisioner az igény megjelenésekor létrehozza a PersistentVolume-ot. A te esetedben tipikusan mindig létrehoz egy alkönyvtárat. Bár nem írtad, de gondolom hostpath típusú a PersistentVolume-od. A kulcsszó, amire rá kell keresned: hostpath provisioner. Ez nyilván csak egy gépes "cluster"-ben működik jól.

Sima hostPath helyett lehet azzal is jobban járnál ha a host ról, ami a minicube-ot futtatja kiexportálnál egy NFS konyvtárat(vagy többet, ha kell), és a kubernetesben ezt az NFS-t használnád hostPath helyett. Ha később több node-os könynyezetben fogsz dolgozni vagy ha esetleg lesz egy storage-od akkor ez a konfig közelebb fog állni a használható confighoz, de ilyen módon egy géppel is simán összerakható.

( o_O v | 2018. 12. 29., szo – 11:27 )

Az nem derult ki az irasodbol milyen kornyezetben probalod.

Amig ilyen keves adatmenyiseggel jatszol meg oke, hogy kubernetesben van utana rohadtul fajdalmas. Ugyan is a podok ki es be menenk ha a rendszer le es fel skalazza a nodok szamat. Erre persze lehet az a megoldas, hogy tartasz kulon "storage" nodeokat a kubernetesbe de ezzel meg mas problemak vannak. Jelenleg a kubernetesben nem lehet normalisan I/O-t limitalni egyes podoknak igy siman lehet, hogy egy alkalmazas megeszi a data node elol az I/O-t ez se egeszesges. Ha az ES-nek egy folyataba relocatelni kell indexeket akkor eleg sokat fogjak ragni a fuledet az emberek.. ,hogy miert nem megy az vagy amaz.

Az autoskalazas otleted meg fura pont a tarhely mennyiseget viszony jol elore ki lehet kalkulalni az alapjan skalazni eleg nagy butasag. Ha mar tarhelynel jarunk akkor erdemes hot/warm architekturat epiteni bar ez nalad ez a veszely nem all fent viszont jobb megoldas mint amit te gondolod. A masik problema ,hogy HPA-val csak ugy tudod megoldani ,hogy teszel moge egy prometeust, datadogot-t vagy barmi hasonlot metric szolgaltatast amibol kepes a kubernetes kiolvasni azt a erteket mikor kell skalaznia.

A harmadik es egyben legnagyobb problema ,hogy cloud kornyezetben a hozzacsatolt kulso diszkek sebessege eleg rossz aws-ben ugy-e gp2 a default ez eleg rossz van az io1 az meg rohadt draga szoval maradt a beepitett instance diszk aminek a prestetenciaja nem megoldhatatlan csak rohadt bonyolult foleg ha meg autoskalazni is szeretned oket.

Szoval nekem az a javaslatom ,hogy ne ragd kubernetesbe nagyon felesleges es nem add elonyt a klasszikus megoldasokhoz kepest. Sok mindenre jo a kubernetes de pont persistanciaba nem annyira jo.

--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer

> Az nem derult ki az irasodbol milyen kornyezetben probalod.
Mire gondolsz? Minikube VM-ben próbálom, szóval külön storage az nincs, csak ennek a VM-nek a tárhelye.

A skálázási rész igazából történhet más alapján is, amit alapból tud a Kubernetes az a CPU és a RAM, minden mást trükkösebb beállítani. Ezért próbálkoztam a tárhellyel, ott végülis nem triviális a dolog ha automatikusan akarod és ad teret próbálgatni a konfigurációkat.

Köszönöm a tippeket, szerintem ez másoknak hasznosabb lehet, akik majd betévednek ide, én egyelőre csak egy VM-en tudok szórakozni vele.