On Tue, Nov 7, 2023 at 2:45 PM Catalin Muresan via RLUG <rlug@lists.lug.ro> wrote:
> Salut, > > inainte de toate, eu personal consider ca storage in K8s e o problema care > se poate rezolva doar cu costuri (scale) mari si daca vrei sa o faci cu 3 > servere si 3 disk-uri pe server sa nu te astepti la performanta. > > Momentan am 7 noduri (3 mastere si 4 "normale") care sunt suficient de utilizate sa vreau sa mai trag in curand de ele (nu mi-e clar daca in lateral sau in sus, mai vad). Nu mi-e atat de tare de Performanta(TM), chestiile cu adevarat importante le tin pe masini dedicate, thank you very much, dar sunt suficient de patit sa stiu ca pe la storage de-asta abstract incep sa intre gremlinii in sistem si e bine sa stii in ce feluri si-o ia cand si-o ia. > mai exista si OpenEBS si Longhorn (de la rancher) dar o sa te lovesti la > toate cam de aceeasi chestie: un write pe PV se "traduce" in vreo mult mai > multe api calls si writes si network communication decat daca ai avea > storage local. > Cred ca cea mai buna recomandare e sa ai multi-tier storage: NVME SSD, SATA > SSD, Magnetic si sa ai mai multe storageclass ca sa dai la fiecare > aplicatie exact ce ii trebuie: DB: nvme. backup: magnetic, etc. > Tine cont si ca sunt destui "consumatori" de storage care formeaza un > cluster (elasticsearch, cassandra, etc) si care rezista la un nod/volum sa > dispara si pentru care mult mai performant ar fi host storage decat cluster > storage. > > Elasticsearch am separat si-si face treaba, n-am motiv sa-l bag in kubernetes. La DB inca n-am fumat ce e necesar ca sa bag pokemoni suplimentari pe drumul de data path. Tot apar insa un numar de scenarii unde ar fi util un volum definit abstract. Pana acum am folosit doua extreme: un caz cu localpath cu date care stau bine mersi pe un nod si cateva configmaps/secrets cu scripturi si certificate pe care le tin ca yaml-uri. Grosul de date il tin in minio, care e insa simultan greoi de accesat prin s3 api daca vrei niste foldere pe disc si suficient de retardat sa regret ca m-am maritat cu el pt chestii mai de volum. Am vazut recent niste exemple cu rook si mi s-a parut suficient de elegant sa expuna o gama mai larga de scenarii (ma uitasem mai demult si la openebs si longhorn si nu m-au convins ca merita bataia de cap). poate mai bine ar fi sa monitorizezi IOPS, device IO queue, device > read/write block sizes, latenta, etc ca sa poti sa vezi exact de unde e. > Cam peste tot un block device are totusi un minimum de SLA: IOPS, > Bandwidth, latenta, etc. > > Da, aici nu stiu ce sa zic, poate e si neincrederea mea de vina. Folosesc pe post de cloud serviciul Flexible Computing de la Orange, care e un vmware cloud director pe care-l vand ei la kil, si e practic as-is, suportul a fost in cel mai bun caz inutil de cate ori am avut ceva treaba cu ei. De principiu merge, dar uneori se mai intampla niste transient voodoo pe care n-am cum sa mi-l explic daca e de la mine sau de la ei. De exemplu, mi s-a intamplat in doua ocazii diferite sa se duca api-ul de k8s in balarii pentru ca masterele aveau load pentru ca apiserverele erau in craci pentru ca etcd raspundea greu pentru ca ... masterele erau in load? Le-am scos manual din boscheti da' ar fi mai trist daca s-ar intampla asta cu ceva mai serios. Chestia cu iops si sla zici tu ceva, numai ca la astia am doua storage classes: "production" si "premium", adica scump si foarte scump. Initial am presupus ca sunt "hdd" si "ssd", dar n-as putea zice ca se comporta spectaculos. In plus, nu am reusit sa ma lamuresc din documentatia de la vmware cum se aloca quotas de iops si daca merita sa fac volume mai mari sau mai multe. Intr-o zi cu soare o sa ma ma sap dupa un benchmark suficient de portabil cat sa compar cu alte chestii dar pana atunci sa zicem ca vad jenant de mult iowait pt workload relativ modest. Niste detalii de horror stories cu minio ? Eu sunt la inceput dar m-am > lovit de una/alta. > O sa incerc sa dezvolt intr-un alt mail, dar pe scurt mi se pare un proiect care n-a depasit conceptele relativ simpliste si de homeuser/developer cu care pornise, chiar daca privind din afara suna fancy si scalabil. Multe din deciziile pe care le iei cand faci initial clusterul raman batute in cuie si nu scapi de ele decat cu export/import (lucru sugerat inclusiv de suport la orice problema mai complexa). -- P. _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug_lists.lug.ro
