Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Ondřej Palkovský 01. 06. 2020, 10:33:26
-
Jaké jsou vaše zkušenosti s kubernetes? Přesunul jsem během posledního půl roku několik aplikací do různých cloudů (AWS EKS, DigitalOcean K8) a... mám z toho takové rozporuplné pocity.
Plusy:
- Opravdu funkční CI/CD od začátku do konce, to je moc fajn
- Odpadá problém s udržováním serverů, kompatibility knihoven/balíčků atd.
- Snadné vytvoření testovacího prostředí
- Ingress + letsencrypt.... moc příjemná kombinace
Ale...
- (nesouvisí s K8) - o365 SMTP servery jsou nespolehlivé; takže musím implementovat vlastní frontu odesílání zpráv (původně jsem to dával MTA lokálně)... ale to je asi obecně vlastnost cloudu - develop for failure
- Navzdory tomu, že se jedná o pár malých aplikací, tak musím nainstalovat všechny možné i nemožné nástroje pro monitoring, které najdu. Což znamená rozchodit si vedle elastic, kibanu, prometheus, filebeat na nodech, posílání kubernetes eventů (!!!!!! - jak je možné, že tohle K8 není schopno vůbec logovat standardně?) abych vůbec tušil, co se tam děje. V podstatě kvůli malému prostředí musím instalovat enterprise log management. Ne, že by to nebylo "dobré", ale normálně to bez toho jde. V K8 to bez toho vůbec nejde.
- Neschopnost reportovat pád Cron úlohy. Existuje možnost to napsat do pravidel promethea (- který mám nainstalovaný integrací z gitlabu, takže to nejde customizovat..?), která je hodně přes ruku. Ale teď jsem rozchodil stahování eventů, možná to půjde vytáhnout z toho. V každém případě - tohle je šílené.
- Vypnutý swap. V jednom případě mi několik let běžely 4 aplikace na jednom t2.micro (1GB paměti), HAProxy na t2.nano (512MB). Prakticky bez výpadku. Totéž mi teď běží na 3-nodovém K8 clusteru (3x2GB), a už jsem několikrát narazil na OOM, která pozabíjí půlku prostředí. Smutné je, že jsem to zatím nebyl schopen dohledat....
- Žádný fencing ve standardní instalaci. Pro jednoduchost jsem si rozeběhl Postgres v K8. Bohužel nějak došlo k panicu cilia, což odřezalo node od sítě. Databáze (StatefulSet) běžela na tomto nodu - a konec. Všechno dole. Pokud by byl nakonfigurovaný Fencing, tak stačilo ten izolovaný node vypnout/rebootovat a bylo by to v pohodě. Fencing/STONITH je naprosto základní součástí jakéhokoliv clusterovacího řešení za posledních 20 let... to, že to součástí K8 není (někdo si dal práci a udělal na to projekt, ale myslím, že tam nemá Cloud služby) na mě vrhá dojem, že ta technologie je hlavně "cool"
Můj pocit: deployment aplikací - super. Spolehlivost, schopnost dohledat problém - strašné. Když něco nefunguje, tak je to na dlouho. Jaké jsou vaše zkušenosti?
-
Nemyslim si zeby bol K8s vhodny pre teba. Vsak su to male apky tak by som isiel na opsless riesenie v podobe funkcii.
Napr. v AWS pouzivam Lambda funkcie spolu s CloudWatch events ako "cron". Error handler na najvyssej urovni funkcie mi reportujte problemy spolu s backtrace-om priamo na Slack. Samozrejme errors mozes vidiet aj v CloudWatch logs. Pokial by som to silou mocou chcel tak logy mozem streamovat do AWS ES. Aj plne webove aplikacie mam riesene cez Lambda (podla poctu requestov uz niekedy moze byt vhodnejsie ECS + Fargate - opat opsless) - tych par requestov za den v mojom pripade mi zvladne Python+Zappa+Flask+Lambda bez problemov.
Mam pocit ze sa snazis natlacit oldschool svet do cloudu - nikdy mi napr. nechybal fencing - proste vyuzijem, co cloud ponuka - napr AWS Aurora PostgreSQL a nechavam na cloud providera aby to riesil. Napr. jednym klikom switchnem role slave-master medzi regionmi.
V case cloudu som uz vyrastol z toho aby som si manazoval vsetko sam, ked to si na par klikov (ok Terraform/CloudFormation poziadaviek) vyrobim celu infrastrukturu. Nedavam ani svojim "serverom" pet mena, vsetko je pre mna "cattle" (https://medium.com/@Joachim8675309/devops-concepts-pets-vs-cattle-2380b5aab313).
-
Také si nejsem jistý, zda používáte správný nástroj.
Z naší zkušenosti:
* databáze do Dockeru nikdy (jak je to u jiných implementací kontejnerů se stabilitou souborového systému nemám zkušenost)
* pokud toho neprovozujete mnoho, je administrace clusteru příliš drahá (jak sám píšete)
Plusy platí přesně jak píšete.
Kubernetes považuji za enterprise nástroj, takže se pak nedivím, že pro jeho provoz potřebuji enterprise prostředí a schopné administrátory. Pokud se mi to nechce udržovat / mám příliš malý use-case, ale rád bych využil výhod, které kontejnery přináší, jsou tu služby jako AWS ECS nebo OpenShift Online. Vyjde to rozhodně levněji a dá se to provozovat i v jednom.
-
No... mně připadá, že enterprise cluster by měl mít vyřešený např. ten fencing (aby to bylo na enterprise úrovni), měl by mít vyřešené posílání eventů a alertů (což možná nakonec dám nějak dohromady, akorát to nevypadá jako "běžné" řešení) a třeba ten swap by IMO měl být aspoň volitelně. Můžeme sice tvrdit, že enterprise = garance/limity, k OOM nemůže dojít, ale to je pak trochu problém, pokud nějaký typ provozu má v tomhle výkyvy.
A teď se dozvídám, že stabilita FS je na pováženou....
Lambda mi připadá z hlediska ladění problémů ještě horší než kontejnery.
ECS jsem nezkoušel, ale obecně vzato to levnějc rozhodně nevyjde. Mně tady trošku přijde blbý, že se jedná o pár aplikací, které nemají zas tak velký provoz... až na to, že to používá pár desítek tisíc lidí. A ve výsledku měla t2.micro mašinka lepší výsledky než teď ten K8 cluster.... a nejhorší na tom je, že nevidím, že bych to něco udělal vyloženě špatně.
-
jsem staromódní, podle mě standardním unixem dosáhnu lepších provozních vlastnostní než tímhle za daleko méně práce, ale klienti to chtějí, jsou ochotný za to zaplatit a vůbec se nediví, že dnes v enterprise prostředí je potřeba snad 10x více zdrojů na stejné aplikace.
Overlay fs je opravdu super pro databáze, naprosto zhodí jakékoliv záruky uložení dat (fsync(2)) a serilizaci transakcí, databáze pak vůbec nemůže tušit, jestli data jsou opravdu uložená persistentně. Jediné komu to opravdu nevadí je asi Mongodb, to umí ztrácet data samo o sobě.
-
Používam MicroK8s od Canonicallu, a neviem si to vynachváliť, aj na menšie projekty mi to prijde vyhovujúce.
-
jsem staromódní, podle mě standardním unixem dosáhnu lepších provozních vlastnostní než tímhle za daleko méně práce, ale klienti to chtějí, jsou ochotný za to zaplatit a vůbec se nediví, že dnes v enterprise prostředí je potřeba snad 10x více zdrojů na stejné aplikace.
Overlay fs je opravdu super pro databáze, naprosto zhodí jakékoliv záruky uložení dat (fsync(2)) a serilizaci transakcí, databáze pak vůbec nemůže tušit, jestli data jsou opravdu uložená persistentně. Jediné komu to opravdu nevadí je asi Mongodb, to umí ztrácet data samo o sobě.
Tak dajme príklad, ako v čistom Linuxe jednoducho poriešiš to že máš 20 fyzických serverov (20 nodes) pre aplikáciu. Ako poriešiš load balancing, aby si nepretažil jeden node a ostatné sa neflákali?
-
Tak dajme príklad, ako v čistom Linuxe jednoducho poriešiš to že máš 20 fyzických serverov (20 nodes) pre aplikáciu. Ako poriešiš load balancing, aby si nepretažil jeden node a ostatné sa neflákali?
Cest je hodně, záleží na aplikaci. Pokud to bude obyčejný html statický web, dám před to nginx balancer, scriptem budu sbírat aktuální zatížení (cpu, disk, ram či cokoliv) jednotlivých serverů a podle toho měnit konfiguraci weight pro upstream (změna conf souborů a reload), případně server dočasně vyřadím. Reakční doba při přetížení serveru je do cca minuty.
Pokud aplikace bude složitější a bude chtít třeba zapisovat na disk, musím tam přidat nějaký nfs/cifs/glusterfs/fuse. Ani kubernetes to neumí genericky pro každou aplikaci a aplikace musí s takovým během počítat.
-
potřeba dělat distribuované systémy tady je několik desetiletí, weby jako wikipedia běží i bez kubernetes a dalších cloudových vylepšení. Jen teď přichází asi nová generace IT lidí, pro které kubernetes je jediným řešením problémů...
-
áno, ale protože Kubernetes veľa vecí značne zjednodušuje. To že to jde aj bez neho neznamená že teraz by sme nemali K8s používať.
-
Mně se ten koncept docela líbí - teď jsem vyhodil prá nodů, nahradil je jinýma (s víc pamětí) a byla to skoro nulová práce. Super.
Databáze má data na PersistentVolume a na tom IMO overlayfs nebude, takže to mi připadá v zásadě v pohodě.
Jenže: před tím se mi to celý složilo, protože (asi) jedna aplikace vyžrala paměť. Kdyby byl swap - není problém. Ale takhle mi to v podstatě sundalo celý prostředí (ony ty Linuxy bez swapu se nechovaj v případě nedostatku paměti zrovna hezky). A nejhorší je, že to je zpětně skoro nedohledatelné.... posílání eventu do elasticu funguje tak, že to nějaký eventy neposílá (že bych si to nakonec musel napsat sám...?)
Mně to připadá fajn, ale nějak mi to zatím nepřipadá enterprise....
-
Používam MicroK8s od Canonicallu, a neviem si to vynachváliť, aj na menšie projekty mi to prijde vyhovujúce.
Já jsem to on-site používal také, ale když jsem teď migroval věci do cloudu, tak jsem -logicky- šáhnul po managed kubernetes. Používáš to ve více-nodové konfiguraci?
-
áno, ale protože Kubernetes veľa vecí značne zjednodušuje. To že to jde aj bez neho neznamená že teraz by sme nemali K8s používať.
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.
Nápady a algoritmy, které výrazně zjednoduššují práci "uživatelům" se mi v tom líbí, ale implementace je takové malé peklo. Nemám rád složité služby, unix není příliš uživatelský přívětivý a proto asi vznikají podobné technologie, které se zase vzhlídly v komplexnosti, to je ale na škodu.
Výměna serveru v clusteru je přece běžná věc, i na starém debian s kickstart scriptem a ipxe to šlo zautomatizovat bez jakéhokoliv zásahu a výpadku služeb, jen se to moc nedělalo. Kubernetes pro mě nepřináší nic co jsem dříve již nepoužíval, pouze to balí do balíčku jako jednu službu a teď mě živí, řeším jeho implementace do produkčního prostředí.
-
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.
-
I když stojím spíše straně K8s, tak už dost dlouho nemá vyřešeno třeba toto - Containers startup throttling (https://github.com/kubernetes/kubernetes/issues/3312), a zrovna to bych od Enterprise clusteru očekával a přijde mi to docela důležité.
Jinak s tím pracuju také docela rád, ale nikomu bych to nenutil. I ta složitost se dá zvládnout, líbí se mi, že když nepotřebuju custom Ingress ani ReplicaController, tak to prostě nemusím mít, a spousta věcí se musí řešit i bez k8s, třeba konfigurace/opravnění atd.
Myslím že k8s jde správným směrem.
-
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.
-
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.
-
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.
-
- 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?
-
- 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...
-
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....
-
;D ;D ;D
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.
-
;D ;D ;D
"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).
-
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
-
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.
-
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á.