Egyik ügyfélnek telebeszélte a fejét $vendor, hogy ami manapság nem konténer az idejétmúlt (lol), ezért szeretnék ha letesztelnénk a route server megoldásaikat konténerekkel. Jelenleg három környezet van BIRD és FRR virtuális gépekkel: (1) tradicionális peering fabric, ahol mindenki peerel a route serverekkel is és egymással is, (2)egy virtuális hosting környezet ahol a tenantok közötti routing megy BGP-vel, de itt csak a route server-el peerel mindenki egymással nem, (3) és végül egy black hole alapú tűzfal megoldás ahol a route serverek az AS minden tagját tudják arra rávenni BGP-vel és URPF-el, hogy bizonyos prefixeket tiltson ha kell. Fontos kiemelni hogy ezek mindenhol "csak" control-plane funkciók, azaz a data path-ban nincsennek benne, hanem a full-mesh leküzdésére szolgálnak, továbbá különböző BGP attribútumokkal útvonal manipulációra vannak használva, azaz sávszél és load igénye alig van, de ha pl. a második környezetben mind a 4 letérdel, akkor minden megáll, tehát a HA fontos lenne.
Én kicsit vonakodom ettől, mert nem nagyon találok kész koncepciót ilyesmire (mert lehet gányolás), viszont lehetne spórolni rengeteg VM erőforrást, hozná a konténer világ minden előnyét (és hátrányát), és mindig van kedvem munkaidőben új dolgot tanulni amiért még fizetnek is :)
- Figyelembe véve az igényeket kell nekem a container orchestration vagy elég a sima Docker, esetleg compose?
- Ha kell a container orchestration, melyik lehet jobb ilyen célra? Nem világos még, hogy az instance-ok (BIRD vagy FRR konténerek) 179-es portját hogyan tudom betámadni kivülről, mert ha jól látom ezek a rendszerek valami DNS alapú load balancing-al dolgoznak...
- Amikor erre keresgélek, mindenhol felbukkan a Calico ami egy nativ BGP routing megoldásnak látszik konténer környezetekben, de ha jól értem ez inkább a sok konténer hálózatait hivatott hirdetni a fizikai hálózat felé?
- Nyilván nincs tapasztalatunk container orchestration üzemeltetéssel és az első teszt is inkább funkcionális lenne. A next-next-finish alternativák pl. minikube, micro8s vagy K3s mehetnek production-be, vagy ezek csak tesztelésre jók?
- Egyéb javaslat amire érdemes figyelnem?
Köszönöm.
Hozzászólások
Ebben a helyzetben szerintem a vendort kellene megkérni, hogy csináljon erre egy PoC-ot és mutassa be, hogy mire képes az ő rendszere.
Abból azért sok mindent lehet tanulni és közben a kérdéseidre is választ kaphatsz.
Tesztelni csak akkor tesztelnék, ha külön fizetnek érte nekem. Végül is a vendor akarja eladni a cuccát, nem?
...úgyis jönnek...
Nem. Lehet hogy azzal a résszel picit félrevittem a dolgot. A vendor úgy jött a képbe, hogy a hosting megoldásoknál vannak konténer rendszerek (pl. OpenShift) és ők nyomatják ezt a mantrát, hogy minden is konténer kell hogy legyen. Emiatt meg kellett vizsgálniuk mi megy most VM-en és ezen a szűrőn akadt fent a sok route server virtuális gép, amit ha lehet akkor most optimalizálni kellene.
Igazából az Internet hajnala óta open source szerverek, később virtuális gépek a route serverek de van aki szerint a következő lépés a konténer.
Ahogy latom a route serverek az alapinfra reszei es nelkuluk nincs halozatotok. Tenyleg kontenerben lenne a helyuk?
Jogos kérdés, de akkor ennyi erővel mondhatná a sysadmin kolléga, hogy "eddig közvetlenül szerveren futott az Nginx, tényleg konténerben a helye most?"
Nem kerül ez holnapra élesbe, ahogy fentebb irták inkább csak PoC lenne ez, aminek lehet az eredménye negativ, viszont nem tudom mennyire valid érv azt mondani, hogy a konténerek nem valók fontos dolog futtatására :)
Volt régebben egy post, hogy ki mire használ konténert és elég nagy volt a szórás; van aki CI/CD-n kivül mást nem tenne rá, más meg őrülten migrál.
Atterni kontenerizalt infrara nem egy konnyu dolog. Azt kell megerteni hogy mindennel nem is lehet. Pl. monolitikus app-ot folosleges is migralni. Le szoltuk beszelni az ugyfelet arrol, hogy 10GB-os imagekben tarolt DB-t, app-ot stb-t tartalmazo kontenereket futtatgasson (at kellene designolni a szoftvert es meg le is fejleszteni :D).
Van ahol 2-2,5 fel ev volt az atteres ugy hogy csomo minden maradt szepen VM-eken. De van hogy egy felhobe valo "atugras" is evekig tart az on-prem VM-krol es szolgaltatasokrol valahova.
Hat ez is egy szakma keremalasan :D
Hat nem feltetlen ertek veled egyet. Hogy a viharba ne lehetne/erne meg egy monolitot kontenerizalni. Egy monolitot is lehet skalazni, legfeljebb nem reszenkent, ahogy microservice vilagban tesszuk, hanem egyben az egeszet. De a monolit nem azt jelenti, hogy egy peldanyban fut. Radasul egy monolit eseten is hasznos lehet bizonhos resource alapu izolacio. De ugyanugy profitalhat a monolit abbol, hogy a fuggosegeivel egyutt kerul szallitasra.
"at kellene designolni a szoftvert" az eleg nagy baj, ha at kell designolni az egesz szoftvert, hiszen a kontener is csak egy kutya kozonseges processz. Kb barmit el lehet inditani kontenerben, amit el lehet inditani hagyomanyosan (user spaceban legalabbis tuti). A kontener egy marek namespace meg egy csipet cgroup jah meg par capability.
Coding and ADHD should be best friends
nem azt mondtam hogy mindent at kell designolni hanem hogy LEHET hogy atkell.
A kontener meg meg egy csomo mas minden is. Pl. attol fuggoen milyen storage drivert hasznalsz alatt elojohetnek problemak. Vegyunk pl egy java alkalmazst 1.8-as jvm-el, ami mondjuk millio kis allomanyban tarolja a userek adatait es mindig updateli ha kell userenkent. Ennek az alkalmazasnak percenkent 10K kerest kell kiszolgalnia es ugyanennyiszer updatelni allomanyokat sajat maga alatt.
Ez az alkalmazas nagyon jol mukodhet on-prem, de futtasd nyugodtan atdesignolas nelkul contenereben. Csak ne csodalkozz ha az overlayfs2-nel elfogynak a host rendszeren a fileleirok es hogy a sys es iowate az egekben lesz. Arrol nem is beszelve, hogy a jvm-ek adhatunk tobb memoriat, mint amit a containernek engedelyezunk es le is fogja harapni (aztan jonnek az Out-ofMemory errorok) :D
Szoval szerinted ezt nem kell atdesinolni, hogy mondjuk egy nosql-ben legyenek az adatok pl?
A mai napig irnak a fenti programohiz hasonlokat mindenhol (nem csak a kozigazgatasban, ahol ez a meno architektura :D ), hanem meg a versenyszektorban is. Nincs a frontend es a backend kulonvalasztva, stb. stb. Jo lenen ha minimum komponensekre szednek az alkalmazast megha egy nagy gombocban is fut. De gyakran egyetlen nagy valamibe van behanyva minden.
Mindegy. En lattam mar ilyet is es olyat is.
Az emlitett memoria problemara van JVM fix, Java-t kell upgradelni, vagy a megfelelo kapcsolot be kell allitani.
A user adatok tarolasa pedig egy erdekes kerdes. Ugye eleve igenyesebb helyeken a kontener immutable. Szoval azokat egyaltalan nem a kontenerben kell tarolni. Innentol viszont lehet olyan storage/volume megoldas talalni, ami illeszkedik az alkalmazashoz, egyaltalan nem kell layer fs hozza. Ha minden kotel szakad akar a host fs-t is be lehet tolni.
Coding and ADHD should be best friends
"Jo lenen" jo lenne, de ahogy most sincs szetszedve es mukodik ugyanugy egy kontenerben is mukodni fog. Es igen a skalazhatosag szempontjabol mindegy ilyen esetben, hogy kontenerben fut vagy nem. Viszont a skalazason kivul meg van par dolog amit nyujt egy kontener, pl a fuggosegekkel valo szallitas, isolacio es resource limitek
Coding and ADHD should be best friends
ertelek es hidd el egyet is ertek veled csomo midnenben, de nem ilyen fekete feher a dolog, ahogy kepzeled.
A java-t nem lehet alatt updatelni, mert azzal a software ujrairasa jarna (amugy ez mar atalakitas - redesign, time, money).
A 10k file kezelese parhuzamosan megeszi az IO-t, nem nem fog mukodni a contextswithing miatt. A load az egekben lesz es nem, nem fog kereseket elfogadni a program ha kontenerizaljak. Ne erts felre on-prem is akadozni fog, de nem all be mint egy szog.
Resource limiteket siman be lehet allitani cgroups-al containerizacio nelkul is, tehat ez nem elony ebben az esetben. Sot pont azert lehet beallitani kontenerekben is, mert a host kernel adja ezt a feature-t. Ennek semmi koze a kontenerizaciohoz, pont forditva, azert lehet contenarizalni, mert van cgroups (Linuxon).
A fuggosegekkel valo szallitas a fenti alkalmazasnal teljesen mindegy, mert mint mondtam minden egybe van csomagolva. Ott vannak a jar-ok egymas hegyan-hatan a konyvtarakban. Azaz semmi elonye nincs a kontenerizacionak ebben az esetben sem.
A fenti alkalmazast egyszeruen nem szabad/nem lehet kontenerben futtatni, mert nem fog mukodni akar hiszed akar nem. Vagy igenis at kell alakitani, ahogy te is irtad (java update, file-ok lecserelese, stb.) ami bizony nem csak a fejlesztoknek feladata hanem penzugyi kerdes is. Barmit lehe ttechnologiailag, de a penzugyi kerdesek azonnal megfoghatjak a technologiat egy hatalmas stop-al. :D
Hidd el eleg regota nyomom a container business-t es nem kis projektekben vettem reszt. Tudom mit beszelek. Nem hogy kontnerizalni nem egyszeru, de meg felhoben levo VM-ekre sem atvinni egy egy alkalmazast, pedig az aztan virtualis geprol virtulais gepre koltoztetest jelent. :D
"fekete feher a dolog, ahogy kepzeled" nem az. maradjunk annyiban, hogy te valoszinuleg tulgondolod, en meg alul amirol most beszelunk. Es tok elhiszem, hogy pl Kubernetesbe nem lehet/erdemes atteni az alkalmazas. De a Kube egy teljes platform. Amire en gondolok az meg egy kontener, ami chroot + namespacek + cgroups. Mert az egy kontener, minden mas meg a korites hozza. https://www.youtube.com/watch?v=8fi7uSYlOdc&vl=en
"java-t nem lehet alatt updatelni" Igy elso hallasrta, akkor kb valami nem szupportalt java verzion vagytok eleve (Java 8-ban benne van a flag). Ez most kontenerizaciotol fuggetlenul erdemes idonkent frissiteni.
"mert azzal a software ujrairasa jarna" upgradeltem par java projektet, de sem ujrairni nem kellett az egeszet, se teljesen atalkitani a sw-t, ahonnan indul a beszelgetes. Tudom vannak kornyezetek, ahol egy karakter atirasa is iszonyatos koltseg, es en nem is irtam, hogy zero koltseggel lehet kontenerbe tenni, mert ilyen amugy sincs, es nem is lehet elvarni.
"A 10k file kezelese parhuzamosan megeszi az IO-t, nem nem fog mukodni a contextswithing miatt." azt nem ertem mi a kulonbseg akozott, hogy a host fajlrendszeren van a 10k file, meg akozott, hogy a host file rendszere mountolva van egy kontenerben? Megint az az erzesem, hogy te valami bonyolult platformban gondolkozol, en meg arrol beszelek, hogy koppra ugyanazt az FS-t odaadhatod egy kontenernek, amit a hoston futo processznek adnal, es pont ugyanazt az IO teljesitmenyt fogod kapni (leven semilyen koztes reteg nincsen a storyban).
"Azaz semmi elonye nincs a kontenerizacionak ebben az esetben sem." Az, hogy van-e elonye, es meg lehet-e csinalni az ket kulonbozo dolog. En az utobbirol beszelek.
"hanem penzugyi kerdes is" igen, de a) nem mondtam, hogy zero koltseg es b) eddig technologiarol beszelgettunk.
Hidd el, pontosan tudom mit nevezunk kontenernek, hogy mit adnak ehhez a koncepciohoz az egyes megoldasok, es pontosan ezert tudom, hogy a kontener egy kutya kozonseges processz. Barmit el lehet inditani kontenerben, de! nem lehet barmint betolni egy kontener orchestratorba! Hiszen ott az orchestrator hozza a sajat kis dolgait, amikkel mar lehet, hogy nem kompatibilis az alkalmazas.
Coding and ADHD should be best friends
Lehet en ertem felre a leirasodat, de abbol az jott le, hogy route servereket hasznaltok es nincs full mesh a halozatban, tehat ha nincs route server akkor nincs mukodo halozatotok, ugy pedig szerintem kicsit nehez felhuzni azt a kornyezetet (pl.: k8s, swarm stb), amin a route serverek futnanak.
Kicsit tyuk tojas kerdes.
Kubernetessel siman lehet olyat csinalni, hogy elinditod halozat nelkul, majd az adott clusteren megfelelo privillegiumokkal, mountokkal meg default network namespace oroklessel elinditod a Calico-t, ami bekonfolja a halozatot, amit hasznal utanna a Kube.
Coding and ADHD should be best friends
Lehetni lehet, de vannak nagyon kellemetlen mellékhatásai. A Node már akkor Schedulable amikor a calico-node pod még csak indulgat és nincs pod networking. Ezt a többi infrastruktúra pod változó hatékonyságú módon reagálja le. Ha valaki erre akar elindulni akkor mindenképp érdemes a nidhogg-al megismerkedni, illetve legalább 1.18-as cluster-autoscaler-t használni ami kezeli a nidhogg által a Node-ra aggatott ideiglenes Tainteket.
Ennél sokkal egyszerűbb ha már a kubelet előtt meg van minden. Elvileg, mert ezt még nem volt időnk kipróbálni hogy tényleg működik-e. Mivel a Calico-t - jelenlegi állás szerint - ki akarjuk dobni a jövőben, ezért nem is öltünk bele sok időt.
"nidhogg" ezt koszi nem ismertem.
Nekem kicsit tervezesi hiba szagu, ha egy rendszer nincs erre felkeszitve, hogy nem tud rendesen elindulni (ertsd megpusztul, hiszen akkor ujra fog indulni). Amikor meg lesz halozat el fog indulni.
Valamint ez kikuszobolheto, ha mondjuk ip alapu liveness checket teszunk melle, es akkor nem hazudja azt a kubeletnek, hogy o bizony jol erzi magat.
Mi megvagyunk minden kulnosebb trukkozes nelkul, igaz csak 25e production clustert uzemeltetunk, ami persze nem fed le minden usecaset, szoval tok elhiszem, hogy ti pont belefutottatok ilyenbe.
"Ennél sokkal egyszerűbb ha már a kubelet előtt meg van minden." igez ezt is lehet, igy viszont a calico fuggetlenul kell uzemeltetni a clustertol. Pro es kontra.
"ki akarjuk dobni a jövőben" ennek meg szabad tudni az okat?
Coding and ADHD should be best friends
A jelenlegi stack nem tökéletes - és még finom voltam. A probléma egyébként az hogy a calico-node pod ~70 másodpercet vár - legalábbis a naplója szerint - mire felhúzná a pod networkinget. Ez egy ismert hiba a calico-ban, de most nem fogom tudni neked előkeresni a GitHub issue-t. Szabin vagyok, januárig elő sem akarom venni a céges notebookot.
Míg a calico vár a kiam-agent pod is megpróbál elindulni, de a healthcheck pár másodperc után lelövi - igen, ez sem szerencsés, ezt is workaroundolni kellene. A gond a szinte azonnal, mert van egy rövid időszak amikor a kiam-agent úgy néz ki hogy fut, a nidhogg leveszi a taintet és a scheduler elindíthat production podot is a node-on. Ha ez összejön akkor a production pod az EC2 instance role-t fogja látni és nem azt amit "felannotált" magának. Hogy ezt hogy kezeli az meg attól a csapattól függ aki implementálta.
Nagyon sok mindennek történelmi okai vannak, tipikus "organikusan fejlődőtt" stack olyan mélyen hard kódolt indirekt függőségekkel a környezet felé, hogy hozzányúlni már sokkal rizikósabb mint magát a workloadot migrálni egy új, remélhetőleg rendesen meg is tervezett megoldásra. Szóval ettől akarunk szabadulni és tiszta lappal kezdeni.
A calico-t azért akarjuk kidobni mert igazából felesleges jelenleg. Mivel a cluster amúgy is egy dedikált VPC-ben fog futni a pod-ok kaphatnak abból közvetlenül IP címeket. Erre az AWS-nek van saját CNI-je és akkor nem kell tunnelezni, nem kell Layer 3-on route-olni a forgalmat, van Layer 2-es direkt kapcsolat.
Hat azt, hogy tokeletes en sem mondom, van egy rakas fejleszteni valo, valamennyire jaratos vagy az issue trackerben. De amit te irtal iott s azert tobb bolygo egyuttallasaval tortenik a baj. De persze vannak hibak, amik egyeseket jobban sujtanak mint masokat.
Azt a 70 masodpercet ugy ertetted, hogy a kiadod a parancsot, es kb 70sec amig lesz halozat, vagy ugy, hogy elindul pod, es aztan 70 masodpercet idozik a node controllerben?
Az infot meg koszi, make sense :)
Coding and ADHD should be best friends
A nem tökéleteset a mi stack-ünkre értettem, nem a calico-ra. Azt annyira mélyen nem ismerem, hogy ilyen sarkalatos véleményem legyen róla. Egy ismerősöm szerint aminek nem tudod legalább fél óráig sorolni a hibáit, a problémáit, azt nem is ismered eléggé.
Mi a 10.1.0.0/16-ot használjuk a pod networkre és a 10.2.0.0/16-ot a CluterIP service-eknek. A calico-node pod elindul, csatlakozik is az RR podokhoz, az állapota Ready de kb. 70 másodpercig nem veszi fel route bejegyzéseket. A kiam-agent az APIserver-hez csatlakozna a 10.2.0.1-en amit a k8s-proxy által felvett DNAT szabályok rendben átdobnak egy konkrét 10.1.x.y címre. Ez azonban a route bejegyzések hiánya miatt elmegy a default gateway felé, ami természetesen eldobja a csomagot.
Ezt lehet workaroundolni a kiam-agent oldalán, de vannak más 3rd party szolgáltatások most és a jövőben is. Ha nem állnánk át egy új környezetre akkor persze megoldanánk, de arra a rövid időre már felesleges extra energiát beleölni.
Akkor lehet a ti kiveteletek erositi a szabalyt, amit mondtam :) Jo lenne latni az issuet, mert ennyibol nehez megmondani mi lehet a hatterben (eleg bonyolult a cucc amugy)
Mi nem AWS-en csinalunk rohadt sok clustert, es nincs bajunk az AWS specifikus agenttel. ;) Ha csak annyit csinalna az az agent, hogy hoppa nem tudok csatlakozni a megadott cimhez itt a veg, akkor a kubelet ujrainditana a podot, es addighra mar ott lenne a route, es masodjara mar mukodne. Azt persze tovabbra sem latom, hogy milyen tenyleges problemat okoz ez a rendszerben (a 70sec-es cluster inditasi tobbleten tul), el is csesz valamit?
Coding and ADHD should be best friends
Okoz tényleges problémát is, sajnos. Nem tudom ismered-e a kiam-agent-et. Az úgy működik hogy az AWS magic IP címére - 169.254.169.254 - felvesz egy DNAT iptables rulet és az arra kimenő forgalmat magára irányítja. Így amikor egy pod az AWS SDK-t használva keresi az EC2 instance role-t a kiam-agent - és utána a kiam-server - kapja a kérést, megnézni milyen annotation van a podon, assume-olja azt a role-t és azt a session-t adja vissza.
Nálunk ez történik:
- Elindul egyszerre a kiam-agent és a calico-node pod.
- A calico-node felhúzza a CNI-t, de még 70 másodpercig nem elérhető a pod network.
- A kiam-agent readiness checkje zöld, mivel csak shallow check-et végez. Nem ellenőrzi hogy tud-e az APIserver-hez csatlakozni, csak azt hogy listenel-e valami lokális porton. Ezt egy későbbi verzióban javították.
- A nidhogg törli a kiam-agent taintjét a node-ról.
- Nincs több taint a node-on, a scheduler beütemezhet új production podokat a node-ra.
- A kiam-agent eltimeoutol az APIserver-hez csatlakozás során - keresi a kiam-server ClusterIP Service-t. A k8s-proxy az APIserver - 10.2.0.1 - IP címét egy valós pod networkös IP címre oldja fel - 10.1.x.y. Mivel a pod network route-ja még nincsenek meg ez elmegy az VPC routere felé, aka default gateway. Mivel az AWS routere csak eldobja a forgalmat - mintha blackhole lenne - ezért nincs ICMP üzenet, leketyeg a teljes timeout.
- A nidhogg visszarakja a taintet, de ha a scheduler a korábban már ütemezett podokat nem költözteti el.
- A pod elindul és kívánt AWS role helyett a Kubernetes worker node role-ját fogja megkapni. Ezzel nagy eséllyel nem fér hozzá a számára szükséges AWS resource-okhoz. Ha a fejlesztők ügyesek voltak, akkor a pod terminál, ha nem akkor folyamatosan újrapróbálkozik. Ha ez egy ősrégi legacy kód, akkor azt már senki nem fogja javítani.
Szóval meg lehet ezt workaroundolni, de költözés előtt már nem érdemes effortot ölni bele.
Csak azt akartam kiemelni a legelső hozzászólásommal hogy az hogy a Kubernetes manage-eli azt a szolgáltatást ami magát a Kubernetes network-öt építi fel okozhat nem várt problémákat is. Amikor mi elkezdtük a calico-t használni - még mesh és nem RR módban - nem volt sem kiam-agent, sem nidhogg. Ezeket utólag vezettük be és ezek "rontották el" a korábban jól működő calicot. Külön-külön minden teljesen rendben van, így együtt azonban egy szép race conditiont adnak ki.
Koszi es sajnalom, hogy igy szivtok.
Coding and ADHD should be best friends
Marmint mirol inditod el? Felcsattintasz egy ISO-t az idrac/ilo stb mgmt-jen es telepited?
1. Konténerizálni többféleképpen lehet, mivel több aspektusában lehet a processzt virtualizálni. Egy kötelező elem van, az a file system virtualizálás (kb. mintha chrootban futna cucc). Az összes többi virtualizálás opcionális.
2. A helyes kérdés, hogy a mi a cél. Ha csak a file system virtualizálás előnyeit akarja valaki learatni (a userspace függetlenné válik a futtató host os-től = lehet pl. egy centoses cuccot szinte bármilyen Linux disztribúción változatlan formában futtatni), akkor az nagyon egyszerűen megoldható. A többi virtualizációnál (pl. network) lehetnek nehézségek.
3. Ha az orkesztráció előnyeit nem tudjuk vagy akarjuk kihasználni (mert úgy sincs sok értelme mozgatni a gépek között a cuccost, plusz alkalmazásrétegben simán lehet redundanciát építeni, nincs szükség HA/load balancing megoldásra a platform rétegben), akkor egy sima docker is elég lehet (akár docker-compose-ból tolva a deploymentet). Ez kb. pont ugyanazt a processzmenedzsment élményt fogja hozni, mintha natív módon futna az os-en a processz.
Csak azert, mert meg lehet csinalni valamit, nem jelenti, hogy kene is. :)
Az a mondás, hogy a microk8s az mehet prod-ba, amennyiben nincsenek extra igényeid, akkor teljesen megfelel (pl valami spec CSI, vagy CNI). Most már lehet belőle cluster-t is csinálni, kb. 5 perc felrakni snap-ból, és összekapcsolni a cluster elemeket.
kerdes mit nevezunk extra igenynek.
Köszi, az ubuntu*com szerint is "production-ready" és "enterprise-grade", kíváncsi leszek a gyakorlat is ezt fogja-e mutatni.
Köszönöm mindenkinek a hozzászólást, jelenleg ez a terv: