VELDRANE: to neznam. Chtel sem na to pouzit rancher, ktery je trochu flexibilnejsi nez OS pro mne.
Pripadne napisu, nejak sesumarizuju. Rancher prave dokaze vyresit hodne veci sam a ma vlastni installator k8s, takze tohle jde relativne rychle.

MARTEN: Pokud mas nejakou zkusenost s Openshiftem, proc nezkusit okd, kde uz je spousta veci vyresena. Priznam se ze teda nevim jakej je soucasnej stav toho projektu ale 3.x verze byly vcelku slusne. Obecne radim to stavet nad nakejma virtualkama a ne barematalu (par lidi melo tento chorej napad a je z toho akorat mrzeni). Co budes resit je jak dostat trafic dovnitr a ven, jak spolu budou ty ci ony sluzby komuňikovat, kde a jak deplojnout statefull komponenty jak databaze atd.
Hele je to na nakou delsi debatu, jestli chces posli mi sz a muzem to po telefonu nebo whatsappu probrat.

Svoje k8s si muzes postavit taky ale zabere Ti to vic casu protoze spoustu veci si musis poresit po vlastni ose (sdnku - je jich mabiliarda, registry, autentizaci, ingress, egress, monitoring, deployment atd apod). Ne ze by to neslo, je to dokonce moc hezka prace kde se hodne veci naucis ale docela casove narocna i pro cloveka co o tom trochu vi.

Obecne to neni blbej napad, protoze pokud budes mit pak vyresenej deployment do takovyho prostredi, pak je vcelku burt jestli ho budes hostovat u sebe v on-premu nebo treba v azure v aks.

MARTEN: a potřebuješ Kubernetes, nestačil by ti docker swarm? Použiješ existující docker-compose, nemusíš se učit Kubernetes, zerodowntime to umí. Záleží jak moc pokročilé věci od toho potřebuješ.

INDIAN: To te fakt obdivuju, protoze takovouhle trpelivost sem nikdy nemel :).

Nejvic sem miloval chybky v modulech, zpusobeny treba nakym nekompatibilnim python modulem nebo knihovnou. Jo jako fakt miluju ten tool, ale chapu ze asi lip to udelat neslo. To bylo pro me vzdycky hrozny mrzeni psat nejakou ansible roli.

INDIAN: V tomhle pripade kimsufi (takze osekane ovh :)). Ale to jedu fakt jen na infra, misto instalovani treba gitlab bez dockeru. Proc chci kubernetes misto toho, tak je nasazovani, tedy update na novou verzi. S docker-compose je to trochu zdlouhave a rozumne neudelam zero downtime. Plus se chci priucit. Nejaky cloud klidne pouziju pak na projekty co si vydelaji, ale treba na spousteni workeru v jenkinsu to lezlo trochu do penez. V pripade projektu co potrebuji treba vice ram taky. Takze na to vlastni je levnejsi vzit server za $20 a vedet ze tam narvu vse. Je mi jasne ze to nebude super lehke. Ale jinak mam zkusenost s Openshiftem (uzivatelsky?) a linux a tak. Takze ne vse bych se musel ucit. Spis jestli tou cestou jit nebo zustat u docker-compose ktery je proste simple. I kdyz pro nejake sdilene volume mezi serverama, LB a dalsi je to zase vic prace v nem nez K8S

Ma nekdo zkusenost a byl by ochoten chvili brainstormovat o provozovani docker + kubernetes? O co jde. Mam nejake budget servery, protozuju si tam jenkins, gitlab (obecne veci kolem CI) a chci bezet vetsinou svoje projekty. Co resim je jak to pojmout, aby si neudelal tezky zivot. Ted mam vse na dockeru s docker-compose a funguje to. Ale na dalsim serveru si zacinam hrat s Rancherem. Co si nejsem uplne jist, jestli prevest vse do kubernetes, nebo svoje tooly nechat v dockeru. Uz i jen z dovudu, ze kazdy server muze mit malinko jiny vykon (vse ssd a dostatek ram, ale clovek nikdy nevi). Vse ted bezim na kimsufi.
Neresil nekdo podobne dilema? Rad se naucim cele kubernetes, ale nechci si tim zase pripravit projekt na dalsi mesic jen tak.

INDIAN: :)) Ano je to zvracena predstava, ale kdyz ja mam proste s tema modulama blby zkusenosti. Ve vsech asi peti pripadech (vic jich chvala bohu nebylo) kdy sem psal nakou rozsahlejsi roli a rikal sem si "napisu to hezky jak se patri", to vzdycky skoncilo nasranim, zoufalstvim a prepsani inkriminovanych pasazi do shellu. Ale co ja vim treba je uz se za th u dobu situace zlepsila :)

JON: to co pise KING (data caching container) je univerzalnejsi reseni, bude lip fungovat ve vsech situacich kdyz se pod otoci, premigruje na jinej node apod.

JON: Pri mych zkusenostech s ansiblem a jeho moduly bych volil shell :)). Je to jistota a clovek neprijde o nervy

VELDRANE: jen jsem se chtel ujistit a pripadne zeptat na ten modul. Ale spis se vrhnu tema cestama pro k8s nativnejsima, nez se to externe snazit ovladat.

JON: mno a ? Hadam ze i z ansiblu pustis kubectl a nebo bude k dispozici nejakej (asi nedopecenej jak uz to u ansiblu byva..) modul kterej to vosefuje.

JON:

pokud mas dobre technicky vyreseny tohle:
2. tato data se v clusteru lokalne rozkopirujou tak, aby kazdy pod ve StatefulSetu mela vlastni kopii

tak asi nic lepsiho nez tohle nevymyslis:
Asi bych mohl nejak sesynchronizovat ty InitContainery, ze by tu opravdovou praci udelal jen jeden, ale je to takove neohrabane.

neohrabane to muze byt a nemusi (zalezi dost jak neohrabane je to samotne rozkopirovani dat v clusteru), jde o to jak vymyslis synchronizaci tech initcontaineru, jake mas moznosti (naivni pristup ten prvni treba udela lockfile, a ty dalsi tak pochopi ze uz to nekdo za ne resi, kdyz lockfile zmizi tak hotovo, ale zas aby to nevyhnilo pokud padne ten pracovni initcointainer)

VELDRANE: jako ze ansiblem tahat za kuberneti API?

JON: heie na to bych si asi napsal nakou ansible roli (a to ten tool fakt nenavidim :))

Mam kuberneti dotaz: potreboval bych dosahnout nasledujiciho postupu pri deploynuti nove verze aplikace, ktera bezi jako StatefulSet

1. z externiho uloziste se stahnou aktualni run-time data (dost velika)
2. tato data se v clusteru lokalne rozkopirujou tak, aby kazdy pod ve StatefulSetu mela vlastni kopii
3. appka se pusti jako StatefulSet o X podech, kazdy pod ma vlastni kopii dat

Nechci, aby si kazdy pod porizoval tu kopii z externiho uloziste sam (zahlti to linku, zbytecne se Xkrat bude tahat to same). Nedari se mi k tomu nic moc najit - mozna jen nevim co googlit. Idealni by bylo, kdybych nejak mohl spustit jeden InitContainer pro celej StatefulSet - ale to imho nejde, InitContainer je vazanej k Podu.
Asi bych mohl nejak sesynchronizovat ty InitContainery, ze by tu opravdovou praci udelal jen jeden, ale je to takove neohrabane.