Zkušenosti s cloudem a Kubernetes

[_Tomáš_]

ale řadu věci také značně zesložiťuje, vždyť implementace k8s trvá do produkce několik let (moje praxe z českého prostředí) a pořád nastávají i několikadenní výpadky (nedávna zkušenost z banky). To řešení není dostatečně připravené na širší nasazení, jakýkoliv debugging je obrovský až nemožný problém, post-mortem analýzy skoro nemožné, chybí dospělý resource management, saturovat 10Gbps+ linky je skoro nemožné (přitom dnes už fyzicky používáme i 100Gbps mezi servery) atd. atd.

Podle mě to má smysl až když jsou splněný následující body:
* mám víc dodavatelů software a potřebuji pro ně jednotné běhové prostředí, se kterým si poradí i průměrný vývojář
* provozujeme toho opravdu hodně, potřebujeme automatické horizontální škálování a load-balancing
* s tím související automatické logování na jedno místo (nám se logy neztrácí, ale můžeme mít zatím jen štěstí)
* máme schopný tým adminů, kteří se o to postarají (a na oplátku nemusí řešit zákoutí každé nasazované aplikace)
* aplikace jsou jasně definovaného formátu (komunikace přes http, bezstavové, ideálně bez potřeby zapisovat na disk persistentní data)

Jinak je to podle mě špatně vybraný nástroj. Autor vlákna operuje s nejmenšími VPS, které Amazon nabízí, to prostě nemůže fungovat. Naopak máme zkušenost, že pokud je hardware dimenzovaný dostatečně, je cluster stabilní.

S (ne)dospělostí administrace, logování a debuggingu souhlasím. U Openshiftu bych doplnil bych ještě značnou nestabilitu instalačních skriptů. Dost překotný vývoj, zpětná kompatibilita nic moc.

Pro menší provozy se určitě v konečném důsledku vyplatí si to pronajmout jako službu od RedHatu nebo Amazonu. Jakkoliv ty ceny možná vypadají "draze".

--------------

Ad efektivita: pokud je mým primárním cílem efektivita, nepoužiji Kubernetes. Ono technicky vzato i ty VPS jsou vlastně neefektivní oproti dedikovanému serveru, že?

--------------

Dohromady s tím pracuju docela rád, myslím, že až projekt dospěje a admini se ho naučí nastavit, bude to přínosem pro mnoho vývojářů. Ale je to jen pro určité případy užití, jako obvykle, there is no such thing as a silver bullet.

Jo, s tím co jsi napsal plně souhlasím, jen to bohužel vidím nasazované jen špatně, všichni předpokládají, že se vlastně administratory nebudou potřebovat a vše obstarají vývojáři... To je vlastně i případ tohoto vlákna. Kubernetes ale vyžaduje daleko více přípravy, odměnou za to je šance na flexibilnější provoz, pokud se z toho neudělá zoo.

VPS může mít overhead skoro neměřitelný, ale také značný, však víme.

Na kubernetes mi vlastně asi nejvíce vadí ta obrovská code base (2 mio řádků v současnosti), to je něco tak monstrózního, že to může rychle přerůst přes hlavu.

[Reklama]

[Ondřej Palkovský]

Já si pořád nejsem jistý, jestli je problém ve mně, že jsem zvolil K8.

AWS - tam mám firemní prostředí, jednoduchá web aplikace, RDS. Díky omezení AWS nelze vytvořit na těch menších mašinkách dostatek podů, takže tam je asi tak 3x tolik paměti, než by to v reálně potřebovalo. Množství režijních podů je v K8 docela vysoké...

DigitalOcean - to je spíš hobby projekt, kde tak nějak jde o to, aby to nežralo zbytečně moc peněz (na druhou stranu to používá pár desítek tisíc lidí...). Před tím to v podstatě mohlo běžet úplně bez problému na 1GB stroji, teď tam mám 2x4GB a vypadá, to, že to konečně poběží.

- proti variantě instalovat si vlastní servery to je opravdu příjemná změna. Upgrady těch normálních systémů jsou regulérní peklo. Věci typu ansible jsou taky peklo.
- běhat si kontejnery v nějakých variantách dockeru ručně mi připadá podobné peklo; ingresy v K8 fungují moc pěkně (ano, před tím jsem si něco jako ingres implementoval sám. O kód, který nenapíšu, se nemusím starat)
- věchny aplikace (s výjimkou jedné, která tam ještě neběží) jsou bezstavové a nepoužívají lokální data (u té jedné to je vědomé rozhodnutí, ne všechno musí být škálovatelné...a tady škálovatelnost znamená buď velké zesložitění kódu nebo velkou konstantu)
- idea mi připadá dobrá. Provedení....prostě mám pocit, že to nějak drhne. Jak tady někdo psal - post mortem analýza je prostě problém. Ono najít, že ty problémy, které mám, jsou způsobeny nedostatkem paměti, když se to jenom začalo chovat podivně a nikde nic o OOM nebylo...

Jinak taky psát tyhle clusterovací věci Go mi taky nepřipadá jako šťastná volba.

[wabi]

Já si pořád nejsem jistý, jestli je problém ve mně, že jsem zvolil K8.

Mno a kolik Vám tedy těch aplikačních podů dohromady běží?

Možná byste si přeci jen vystačil jen s kontejnery, bez K8s. Buď jednoduše přes docker compose, nebo tu někdo v diskuzi kdysi zmiňoval, že Docker Swarm je poměrně snadný na údržbu (jestli si to dobře pamatuju). Ingress jde nahradit instalací haproxy jako reverzní proxy (dost jednoduše za předpokladu, že nemáte automatické škálování). Vyřeší o load-balancing a je to poměrně jednoduché na konfiguraci.

Ansible je peklo, když si autor nedá pozor na odchytávání chybových stavů a nedá si práci skripty udělat idempotentní (zdravím RedHat a jeho instalaci OpenShiftu - je férové ale dodat, že ta instalace je tak rozsáhlá, že je to pochopitelné). Jinak to funguje imo moc pěkně, mám ho radši než Puppet. Kvalita rolí v Galaxy je v tomto ohledu ale dost variabilní.

Pokud na K8s trváte, pak se obávám, že to bude chtít silnější servery. V tuto chvíli je K8s na provoz nákladné řešení (časově, požadavky na znalosti, výkon). Bylo by krásné, kdyby to v budoucnu bylo jinak, ale prozatím bohužel.

[XTCH]

- běhat si kontejnery v nějakých variantách dockeru ručně mi připadá podobné peklo; ingresy v K8 fungují moc pěkně (ano, před tím jsem si něco jako ingres implementoval sám. O kód, který nenapíšu, se nemusím starat)

Omlouvám se za možný offtopic, ale jak u nízkonákladových projektů hostovaných například na DigitalOcean řešíte zveřejnění služby (případně ingressu jako reverzního proxy), aby byla veřejně dostupná?

Používáte jejich load balancer (za 10 dolarů měsíčně), nebo to řešíte nějak jinak?

[Ondřej Palkovský]

- běhat si kontejnery v nějakých variantách dockeru ručně mi připadá podobné peklo; ingresy v K8 fungují moc pěkně (ano, před tím jsem si něco jako ingres implementoval sám. O kód, který nenapíšu, se nemusím starat)

Omlouvám se za možný offtopic, ale jak u nízkonákladových projektů hostovaných například na DigitalOcean řešíte zveřejnění služby (případně ingressu jako reverzního proxy), aby byla veřejně dostupná?

Používáte jejich load balancer (za 10 dolarů měsíčně), nebo to řešíte nějak jinak?

To není off-topic Ano, používám jejich loadbalancer, je to HA a s ingresy to funguje pěkně (akorát jsem tam myslím zapnul ten Proxy protokol). Btw, neumí to IPv6, takže pokud chcete IPv6, tak buď vlastní mašinku (neclusterovanou.....) nebo doufat, že do K8 časem IPv6 dorazí taky. AWS myslím taky IPv6 do K8 neumí (nejsem si úplně jistý). Applové chtějí někdy od června, aby jejich aplikace byly schopny fungovat IPv6 only, takže tohle začne být prohodně lidí nutnost.

Jinak jeden špek: poměrně dost adres z DigitalOcean není vidět z Ruska (řeším přesměrováním ruska Route53 regional DNS přes minimašinku v AWS) a teď jsem narazil na to, že některé (naštěstí jen některé...) adresy v DO pro změnu blokuje nějaká státní služba v USA...

[Reklama]

[Ondřej Palkovský]

Mno a kolik Vám tedy těch aplikačních podů dohromady běží?

Je to v podstatě jedna aplikace, takže tam trvale běží 5 deploymentů, tzn. 7 podů + nějaké 3 nepodstatné cronjoby. Celkový počet běžících podů je 43.... 

[Zabanovaný Anonymní Troll]

 

1. Tvl kazdej kdo delal s Cludem vi a vidi, ze je to jeste v plenkach a ze nektere vnitrni utroby jsou shit. A ty z toho delas jeste vetsi shit. Vyber si jeden Cloud (AWS) a ten tvl pouzivej a ty shity a nastrahy co tam jsou se nauc. Nebo nam napis kolik jsi usetri za DigitalOcean.

2. Zapomen na databazi co ti pojede na produkci ve tvojem dockeru. Ses pos ral ne...

3. Naco tam chces valit Kibanu - CloudWatch Insights ti nestaci? Si stezujes a delas si to akorat slozitejsi.

4. Kubernetess no comment. Nikdy jsem s tim nedelal. Ale vsechny co znam pouzivaji v AWS Docker a je to i default kontejner pro mnoho sluzeb. Tak nevymyslej pitchoviny.

5. V praci pouzivame ECS namisto EC2, na jednotlive aplikace je to lepsi z hlediska udrzby.

6. Ja mam soukrome EC2 kde mi bezi web server, mam tam preventivne kazdy den cron na restart po pulnoci, protoze se to bylo schopne po par dnech sprajcnout. Proc, nevim. Ale kdybych mel ECS, asi bych nemel tento problem.

[wabi]

"Kolikrát shit napíšeš, tolikrát jsi člověkem?"

Kubernetess no comment. Nikdy jsem s tim nedelal. Ale vsechny co znam pouzivaji v AWS Docker a je to i default kontejner pro mnoho sluzeb. Tak nevymyslej pitchoviny.

https://en.wikipedia.org/wiki/Anecdotal_evidence

Mno a kolik Vám tedy těch aplikačních podů dohromady běží?

Je to v podstatě jedna aplikace, takže tam trvale běží 5 deploymentů, tzn. 7 podů + nějaké 3 nepodstatné cronjoby. Celkový počet běžících podů je 43.... 

V tom případě si myslím, že vlastní K8s cluster udržovat nechcete. Konkrétně zmiňované AWS ECS by Vám mohlo vyhovovat - nad rámec EC2 instancí nestojí zas tolik a dostanete výhody kontejnerů bez nutnosti se o to nějak moc starat - AWS vše potřebné na instance instaluje automaticky a "aktualizace" nodů v clusteru probíhá přidáním nové instance a zrušením té staré.

Jediná nevýhoda je, že je to yet-another konfigurační systém, byť je K8s hodně podobný (jen se tam ty věci jako pody apod. jmenují trochu jinak).

[kojot4]

Ja mam soukrome EC2 kde mi bezi web server, mam tam preventivne kazdy den cron na restart po pulnoci, protoze se to bylo schopne po par dnech sprajcnout. Proc, nevim. Ale kdybych mel ECS, asi bych nemel tento problem.

Ano, taky mám soukromě v ec2 server a občas vyžaduje restarty, zejména když nějaký velmi šikovný robot začne ládovat http požadavky. Nicméně restart jednou denně mi nepřijde optimální, osobně používám route53 healthcheck a přes SNS si posílám výpadky a pak do minuty od výpadku restartuji, zveřejnil jsem to jako open source projekt, více tady:
https://github.com/koss822/misc/tree/master/Aws/route53-healthcheck-instance-reboot

[by_cx]

Ano, taky mám soukromě v ec2 server a občas vyžaduje restarty, zejména když nějaký velmi šikovný robot začne ládovat http požadavky. Nicméně restart jednou denně mi nepřijde optimální, osobně používám route53 healthcheck a přes SNS si posílám výpadky a pak do minuty od výpadku restartuji, zveřejnil jsem to jako open source projekt, více tady:
https://github.com/koss822/misc/tree/master/Aws/route53-healthcheck-instance-reboot

Pracoval jsem s člověkem, který podobné hacky instaloval do produkce a od té doby mi přijde značně nevhodné psát takovéto věci veřejně na fórech. Pak se může najít někdo další, kdo to bude mít za dobrý nápad. Tohle si může člověk dovolit jen v infrastruktuře, která na to je postavená a nebo kde nezáleží na tom, že ta služba v lepším případě chvíli, v horším třeba půl dne, nepojede.

Jinak by mohl být problém v tomhle:

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html

Malé instance bez creditu mohou přestat prakticky reagovat. Třeba t3.nano po vyčerpání CPU creditu poběží asi jen na 10 % výkonu CPU.

[Ondřej Palkovský]

1. Tvl kazdej kdo delal s Cludem vi a vidi, ze je to jeste v plenkach a ze nektere vnitrni utroby jsou shit. A ty z toho delas jeste vetsi shit. Vyber si jeden Cloud (AWS) a ten tvl pouzivej a ty shity a nastrahy co tam jsou se nauc. Nebo nam napis kolik jsi usetri za DigitalOcean.

Managed kubernetes na AWS stojí $876 za rok. To je na hobby projekt docela hodně. Samozřejmě je otázka, jestli je K8 zrovna dobrá volba, ale ono je to takový dvousečný - můj dojem byl, že AWS je na velké množství malých serviců cenově pitomý, ta cloud-nezávislost, když to má člověk nakonfigurované na K8 je docela fajn. Integrace s gitlabem... no, na začátku jsem si myslel, že je moc fajn, teď po cca. půlroce zjišťuju, že to zas až tolik nepřináší.

2. Zapomen na databazi co ti pojede na produkci ve tvojem dockeru. Ses pos ral ne...

Na druhou stranu, tohle nejsou žádný služby, na kterých by závisel něčí život, nebo kde bychom přišli o nějaký peníze, když to chvilku nepojede (i když je to blbý). Tak proč ne?

3. Naco tam chces valit Kibanu - CloudWatch Insights ti nestaci? Si stezujes a delas si to akorat slozitejsi.

Protože tam rvu spoustu věcí - SQS DeadLetter queue pro případné dohledání, že mi něco nezpracovala lambda, filebeatem tam rvu logy z webserveru, kde jede toho provozu docela hodně, hážu tam i nějaké metriky a přes webhook mi tam teď něco loguje i to K8 a loguju tam komplet logy z aplikací z toho K8 včetně custom parsingu některých logů z aplikací, aby se dal rychle dohledat problém. S CloudWatch insights nemám moc zkušenosti...ale ta kibana je zrovna docela triviální na konfiguraci a instalaci, takže tam zrovna spokojenost.

6. Ja mam soukrome EC2 kde mi bezi web server, mam tam preventivne kazdy den cron na restart po pulnoci, protoze se to bylo schopne po par dnech sprajcnout. Proc, nevim. Ale kdybych mel ECS, asi bych nemel tento problem.

Mně předtím běžel právě ten provoz, který mám na K8, na t2.micro. BEZ RESTARTU. Pravidelné restarty jsou...no, to už od Tebe zaznělo několikrát... Ale udržovatelnost toho prostředí prostě není dobrá.