Zkušenosti s cloudem a Kubernetes

[Ondřej Palkovský]

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?

[Reklama]

[🇺🇦 cjohn]

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).

[wabi]

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.

[Ondřej Palkovský]

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ě.

[_Tomáš_]

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ě.

[Reklama]

[Mlocik97]

Používam MicroK8s od Canonicallu, a neviem si to vynachváliť, aj na menšie projekty mi to prijde vyhovujúce.

[Mlocik97]

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?

[_Tomáš_]

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.

[_Tomáš_]

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ů...

[Mlocik97]

á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ť.

[Ondřej Palkovský]

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....

[Ondřej Palkovský]

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?

[_Tomáš_]

á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í.

[wabi]

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.

[Johnny]

I když stojím spíše straně K8s, tak už dost dlouho nemá vyřešeno třeba toto - Containers startup throttling, 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.