Május végén online meet-up-ot tartottunk a következő témában . A konténerekről, a Kubernetesről és az általános orchestrationről beszélgettünk, az infrastruktúra kiválasztásának szempontjairól és még sok másról. A résztvevők megosztották saját gyakorlati eseteiket.
Résztvevők:
- Jevegny Potapov, a „ITSumma” vezérigazgatója. A kliensek több mint fele már tér át vagy szeretne áttérni a Kubernetesre.
- Dmitrij Stoljarov, a „Flant” műszaki igazgatója. Több mint 10 éves tapasztalattal bír a konténer rendszerekkel.
- Denisz Remcsukov (más néven Eric Oldmann), az argotech.io ügyvezető igazgatója, volt RAO EES. Ígérte, hogy mesél a „véres” vállalati tapasztalatokról.
- Andrej Fedorovszkij, a „News360.com” műszaki igazgatójaMiután egy másik játékos megvásárolta a céget, felelős a különféle ML és AI projektekkel, valamint az infrastruktúráért.
- Ivan Kruglov, rendszer mérnök, volt Booking.com.Az az ember, aki saját kezével nagyon sok mindent tett a Kubernetes-szel.
Témák:
- A résztvevők meglátásai a konténerekről és az orchestrationről (Docker, Kubernetes és egyebek); amit a gyakorlatban kipróbáltak vagy elemeztek.
- Eset: A cégnél az infrastruktúra fejlesztési tervet készítenek évekre. Hogyan hoznek döntéseket a meglévő infrastruktúra konténerekre és Kubernetesre való átkonvertálásáról?
- Problémák a cloud-native világában, mi hiányzik, fantáziáljunk, mi fog holnap történni.
Érdekes vita alakult ki, a résztvevők véleményei annyira eltérőek voltak és annyi megjegyzést váltottak ki, hogy meg kell osztani ezeket veletek. Van , alább pedig a vita összefoglalója.
A Kubernetes már standard vagy kiváló marketing?
„Mi a Kuberneteshez (a szerkesztő megjegyzése) akkor jutottunk el, amikor még senki sem tudott róla. Akkor tértünk rá, amikor még nem is létezett. Már előbb akartuk” — Dmitrij Stoljarov
Kép a Reddit.com-ról
5-10 évvel ezelőtt rengeteg eszköz létezett, de nem volt egységes standard. Félévente új termékek bukkantak fel, sőt nem egy. Először a Vagrant, majd a Salt, a Chef, a Puppet,… „és félévente újraépíted az infrastruktúrádat. Öt adminisztrátorod van, akik folyamatosan a konfigurációk átírásával foglalkoznak” — emlékezik vissza Andrej Fedorovszkij. Szerinte a Docker és a Kubernetes „eltompította” a többit. A Docker az utolsó öt évben standard lett, a Kubernetes pedig az utolsó két évben. És ez jó az iparnak..
Dmitrij Sztojlarov és csapata imádja a Kubert. Olyan eszközt kerestek, még mielőtt megjelent volna, és akkor találtak rá, amikor még senki sem ismerte. Jelenleg, a kényelem érdekében, nem fogadnak el ügyfeleket, ha úgy ítélik meg, hogy nem tudják integrálni náluk a Kubernetest. Dmitrij szavai szerint a cégnek "rengeteg hatalmas sikeres története van a régi, elavult rendszerek átformálásáról".
A Kubernetes nemcsak konténer-orkesztáció, hanem egy fejlett API-val, hálózati munkakomponenssel, L3 terheléselosztással és Ingress vezérlőkkel rendelkező konfigurációkezelő rendszer, amely viszonylag egyszerűvé teszi az erőforrások kezelését, a skálázást és az alsó rétegektől való absztrakciót.
Sajnos az életünkben mindent meg kell fizetni. És ennek az adónak nagy a mértéke, különösen, ha egy jól fejlett infrastruktúrával rendelkező cég Kubernetre való átállásáról beszélünk – véli Ivan Kruglov. Ő szabadon dolgozhatott volna hagyományos infrastruktúrával rendelkező cégnél is, és a Kubernettel is. A lényeg, hogy megértsük a cég és a piac sajátosságait. De például Evgeny Potapov számára, aki a Kubernetest bármilyen konténer-orkesztáló eszközre általánosítaná, ez a kérdés nem áll fenn.
Evgeny párhuzamot vont a 1990-es évek helyzetével, amikor az objektum-orientált programozás jelent meg a komplex alkalmazások programozásának módjaként. Abban az időben folytak a viták, és új eszközök jelentek meg, amelyek támogatták az OOP-t. Ezután jelentek meg a mikroszervizek, mint módja a monolitikus koncepcióktól való elmenekülésnek. Ez pedig a konténerek és azok kezelésére szolgáló eszközök megjelenéséhez vezetett. "Azt gondolom, hamarosan elérkezünk ahhoz az időhöz, amikor nem merül fel a kérdés, hogy érdemes-e mikroszolgáltatásként kis alkalmazásokat írni; alapértelmezés szerint mikroszolgáltatásként fogják írni őket" – állítja. Hasonlóképpen, a Docker és a Kubernetes idővel standard megoldássá válik, anélkül hogy választásra lenne szükség.
A stateless adatbázisok problémája
Fotó:
Manapság sok recept található a adatbázisok Kubernetes-en történő indítására. Még arra is létezik módszer, hogyan lehet elkülöníteni azt a részt, amely a lemezes I/O-t kezeli, a feltételezhetően alkalmazásra kész résztől. Lehetséges, hogy a jövőben az adatbázisok annyira átalakulnak, hogy egy dobozban lesznek elérhetők, ahol az egyik rész Docker és Kubernetes segítségével is beállítható, míg a másik rész az infrastruktúrában, külön szoftverrel, a tároló rész biztosítva lesz? Az adatbázisok termékként átalakulnak?
Ez a leírás hasonlít a sorok menedzsmentjére, de a hagyományos adatbázisok esetében a megbízhatóságra és az információk szinkronizációjára vonatkozó követelmények sokkal magasabbak, véli Andrej. A cache hit arány a normál adatbázisokban 99% körül mozog. Ha a worker leáll, újat indítanak, és a cache-t „újraélesztik” a nulláról. Amíg a cache nem élesedik újra, a worker lassan működik, tehát nem terhelhető felhasználói forgalommal. Amíg nincs felhasználói forgalom, a cache nem élesedik. Ez egy zárt kör.
Dmitrij teljesen ellene van, - a kvórumok és a shardolás megoldják a problémát. De Andrej ragaszkodik ahhoz, hogy ez a megoldás nem mindenkinek megfelelő. Bizonyos helyzetekben megfelelő lehet a kvórum, de ez extra terhelést jelent a hálózatra. A NoSQL adatbázisok nem minden esetben megfelelőek.
A meetup résztvevői két táborra szakadtak.
Denisz és Andrej azt állítják, hogy minden, ami a lemezekre íródik — adatbázisok és egyéb — a jelenlegi Kuber ökoszisztémában lehetetlen. A Kubernetes-ben lehetetlen megőrizni a termelői adatok integritását és konzisztenciáját. Ez egy alapvető jellemző. Megoldás: hibrid infrastruktúra.
Még a modern cloud native adatbázisok, mint a MongoDB és Cassandra, vagy az üzenetsorok, mint a Kafka vagy RabbitMQ, folyamatos adat tárolást igényelnek a Kubernetes-en kívül.
Evgeny ellenzi: „A Kuberen lévő adatbázisok orosz jellegű trauma, vagy közel-vállalati probléma, amely összefügg azzal, hogy Oroszországban nincs Cloud Adoption.” A kis- vagy közepes méretű vállalatok nyugaton a felhő. Az Amazon RDS adatbázisok használata egyszerűbb, mint saját magunknak dolgozni a Kubernetes-szel. Oroszországban a Kubert „on-premise” használják, és az adatbázisokat átköltöztetik, amikor próbálnak megszabadulni a dzsungeltől.
Dmitrij szintén nem értett egyet azzal az állítással, hogy adatbázisokat nem lehet tárolni a Kubernetes-en: „Az adatbázisok különböznek egymástól. Ha egy hatalmas relációs adatbázist szeretnél ültetni — akkor semmiképp sem. Ha valami kicsit és cloud native-t szeretnél beültetni, ami lelkileg felkészült a fél-ephemer életre, minden rendben lesz.” Dmitrij azt is megemlítette, hogy az adatbázis-kezelő eszközök nem készültek fel sem Docker-re, sem Kuber-re, ezért jelentős nehézségek merülnek fel.
Iván biztos abban, hogy még ha el is vonatkoztatunk a stateful és stateless fogalmaktól, a Kubernetes vállalati megoldásainak ökoszisztémája még nincs kész. A Kuberen nehéz fenntartani a jogszabályi és szabályozó hatóságok követelményeit. Például lehetetlen olyan identity megoldást létrehozni, amely szigorú garanciákat igényel a szerver azonosítására, egészen a hardverig, amely a szerverekbe kerül. Ez a terület fejlődik, de egyelőre nincs rá megoldás.
A résztvevőknek nem sikerült megállapodniuk, így ebben a részben nem lesz következtetés. Inkább adunk pár gyakorlati példát.
1. eset. A „megaszabályozó” kiberbiztonsága Kubernetesen kívüli adatbázisokkal
Fejlett kiberbiztonsági rendszer esetén a konténerek és az orkestrálás használata lehetővé teszi a támadások és behatolások elhárítását. Például egy megaszabályozónál Dennis és csapata egy orkestrátor és egy tanított SIEM-szolgáltatás összekapcsolását valósította meg, amely valós időben elemzi a naplókat, és meghatározza a támadás, betörés vagy hiba folyamatát. Támadás esetén, ha valamit megpróbálnak letölteni, vagy váltságdíjas vírus behatolásakor, az orkestrátoron keresztül gyorsabban elindítja a konténereket az alkalmazásokkal, mint ahogy azok megfertőződnek, vagy mint ahogy a támadó megtámadja őket.
2. eset. A Booking.com adatbázisainak részleges átköltözése Kubernetesre
A Booking.com alapadatbázisa a MySQL aszinkron replikációval – van egy mester és egy teljes hierarchia a slave-ekből. Amikor Iván elhagyta a céget, az a projekt futott, hogy átköltözzön a slave, amelyeket bizonyos kár mellett lehet „kiiktatni”.
A fő adatbázison kívül van egy Cassandra telepítés egy saját írású orkestrációval, amelyet még azelőtt készítettek, hogy a Kubernetes a mainstreambe került volna. Ebből a szempontból nincsenek problémák, de a helyi SSD-n van persistent adatbázisa. A távoli tárolók, még egy adatközpont keretein belül sem használhatók a magas késleltetés miatti problémák miatt.
A harmadik adatbáziskategória a Booking.com keresőszolgáltatása, ahol minden szolgáltatási csomópont egy adatbázis. Az erőfeszítések a keresőszolgáltatás Kubernetesre való átköltöztetésére nem jártak sikerrel, mert minden csomópont 60–80 GB helyi tárolóval rendelkezik, amelyet nehéz „elindítani” és „felmelegíteni”.
Végül a keresőmotor nem költözött át Kubernetesre, és Iván nem gondolja, hogy a közeljövőben újabb kísérletek történnének. A MySQL adatbázis félig átkerült: csak a slave-ek, amelyeket nem félelmetes „kiiktatni”. A Cassandra remekül „megtalálta a helyét”.
Az infrastruktúra választása, mint feladat, egy általános megoldás nélkül
Fotó:
Tegyük fel, hogy van egy új cégünk, vagy olyan cég, amelynek egy része még a régi módszerekkel épült. Évekre tervezik az infrastruktúra fejlesztését. Hogyan hozzák meg a döntést, hogy építsenek-e infrastruktúrát konténerekre és Kubernetestre vagy sem?
Azok a cégek, akik a nanoszekundumokért versenyeznek, kívül esnek a vitán. Az egészséges konzervativizmus megtérül a megbízhatóság szempontjából, de vannak cégek, akiknek érdemes új megközelítéseket fontolóra venniük.
Ivan: „Most minden bizonnyal felkezdéném a céget felhőben, pusztán azért, mert gyorsabb”, bár nem feltétlenül olcsóbb. A kockázati tőke fejlődésével a startupoknak, amelyeknek van pénzük, nincsenek nagy problémáik, és a fő feladat - meghódítani a piacot.
Ivan úgy véli, hogy a jelenlegi infrastruktúra fejlettsége a választás kritériuma. Ha a múltban komoly befektetések történtek, és az működik, akkor nincs értelme átalakítani. Ha viszont az infrastruktúra nem fejlődött, és problémák vannak az eszközökkel, a biztonsággal és a monitorozással, akkor érdemes körülnézni a disztribúciós infrastruktúrában.
A adót mindenképpen be kell fizetni, és Ivan azt fizetné, amely a jövőben lehetővé tenné számára, hogy kevesebbet fizesse. „Mert csak azért, mert egy vonaton utazom, amelyet mások működtetnek, sokkal messzebbre jutok, mint ha egy másik vonatra ülnék, amelybe nekem kellene üzemanyagot töltenem.— mondja Ivan. Amikor egy cég új, és a latency igények — tízmillisekundumok, Ivan a „szolgáltatók” irányába nézne, ahol ma már a klasszikus adatbázisokat „csomagolják”. Ők beállítanak egy replikációs láncot, amely automatikusan átkapcsol failover esetén, és így tovább...
Kis cég esetén, néhány szerverrel Kuberneten, nincs értelme — állítja Andrei. De ha a cég azt tervezi, hogy meghaladja a száz szervert, akkor szükség van automatizálásra és erőforrás-kezelő rendszerre. Az esetek 90%-a igazolja a kiadásokat. Ez független a terheléstől és az erőforrásoktól. Mindenkinek, a startupoktól kezdve a nagy cégekig, amelyek milliós közönséggel rendelkeznek, érdemes fokozatosan a konténer-orkesztráló termékek felé nézni. „Igen, ez valóban a jövő”, — biztos benne Andrei.
Denis két fő kritériumot nevezett meg — skálázhatóság és működésének stabilitása. Olyan eszközöket fog választani, amelyek a legjobban megfelelnek ennek a feladatnak. „Ez lehet egy otthon összerakott névtelen gép, amin a Nutanix Community Edition fut. Lehet egy második vonal, például alkalmazás Kubernetes alatt, amelynek háttérben adatbázisa van, amely reprodukálódik és meghatározott RTO és RPO paraméterekkel rendelkezik” (helyreállítási idő/pont célok — példák).
Jevegin felvetette a lehetséges problémát a munkaerővel. Jelenleg a piacon nem sok magas szintű szakember van, aki a „bélbe” ért. Valóban, ha a választott technológia régi, nehéz valakit találni, leszámítva az idős, unott és az életből kifáradt embereket. A többi résztvevő azonban azt állítja, hogy ez a munkaerő-képzési kérdés.
Ha a választás kérdését tesszük fel: egy kis vállalatot indítani a Public Cloudban az Amazon RDS-ben lévő adatbázisokkal, vagy „on premise” adatbázisokkal Kubernetes alatt, akkor néhány hátrány ellenére a résztvevők választása az Amazon RDS lett.
Mivel a meetup hallgatóinak többsége nem a „vérengző” vállalati szektorból származik, a decentralizált megoldások azok, amelyekre törekedni érdemes. Az adatmegőrző rendszereknek decentralizáltnak, megbízhatónak és millisekundumokban mérhető latency-t kell produkálniuk, legfeljebb tucatnyi., - foglalta össze Andrej.
A Kubernetes használatának értékelése
Anton Zhbánkov hallgató kérdést tett fel a Kubernetes apologetáknak: hogyan választották ki és végezték el a techno-gazdasági indoklást? Miért Kubernetes, miért nem például virtuális gépek?
Fotó:
Erre Dmitrij és Ivan válaszoltak. Mindkét esetben próbálkozások és hibák módszerével készítettek megoldási sorozatot, amelynek eredményeként mindkét résztvevő a Kubernetesre jutott. Most a vállalatok elkezdenek saját szoftvert fejleszteni, amelynek értelme van a Kubernetesbe való áttelepítésnek. A klasszikus harmadik fél rendszerek, mint például az 1C, nem témák. A Kubernetes segít, amikor a fejlesztőknek gyorsan kell kiadniuk a verziókat a folyamatos fejlődés fenntartása mellett.
Andrej csapata megpróbálta létrehozni a skálázható klasztert virtuális gépek alapjain. A csomópontok, mint a dominók, estek, ami néha a klaszter bukásához vezetett. „Elméletileg lehetne kézzel befejezni és fenntartani, de ez nem könnyű. Ha a piacon létezik olyan megoldás, amely dobozból kifelé működik, akkor szívesen megyünk hozzá. És ennek eredményeként áttértünk.”, - meséli Andrej.
Vannak szabványok az ilyen típusú elemzéshez és számításhoz, de senki sem mondja meg, hogy mennyire pontosak ezek a valódi hardveren a gyakorlatban. A számításokhoz szintén fontos ismerni minden eszközt és ökoszisztémát, de ez lehetetlen.
Amit vár ránk
Fotó:
Ahogy a technológia fejlődik, egyre több különálló rész jelenik meg, majd bekövetkezik egy fázisátmenet, amelyben megjelenik egy beszállító, aki elég "pénzt" összegyűjtött ahhoz, hogy mindezt egyetlen eszközbe egyesítse.
Nem tűnik fel Önnek, hogy eljön az a pillanat, amikor megjelenik egy eszköz, ami olyan lesz, mint az Ubuntu a Linux világában? Lehetséges, hogy egyetlen konténerizáló és orchestration eszköz magában foglalja a Kubert is. Ezzel egyszerűbb lesz helyben felhőket építeni.
Ivan válaszolt: "A Google jelenleg az Anthos-t építi - ez az ő csomagajánlatuk, amely felhőt telepít és magában foglalja a Kuber-t, a Service Mesh-t, a megfigyelést — mindent, amire szükség van a mikroszolgáltatásokhoz a 'helyben' működéshez. Szinte a jövőben vagyunk."
Denis is megemlítette a Nutanix-et és a VMWare-t a vRealize Suite termékükkel, amelyek képesek hasonló feladatokat ellátni konténerizálás nélkül.
Dmitry véleménye szerint a 'fájdalom' csökkentése és az adócsökkentés két irány, ahol várhatóan javulásra lehet számítani.
A vita összegzéseként kiemeljük a modern infrastruktúra következő problémáit
- Hárman is jelezték a problémát a stateful-lal kapcsolatban.
- Különböző típusú biztonsági támogatási problémák, beleértve annak valószínűségét, hogy végül több Python verzió, alkalmazás-szerverek és komponentek kerüljenek a Dockerbe.
A túlmenet, amiről érdemes lenne egy külön meetupról beszélni.
A tanulás problémája, hiszen az orchestration egy bonyolult ökoszisztéma.
Az iparág általános problémája — az eszközök nem rendeltetésük szerint történő használata.A többi következtetést Önre bízom. Egyelőre az a benyomásom, hogy a Docker+Kubernetes párosnak nem egyszerű központi részévé válni a rendszernek. Például az operációs rendszerek először települnek a hardverre, amit nem mondhatunk el a konténerekről és az orchestration-ről. Lehetséges, hogy a jövőben az operációs rendszerek és a konténerek összeolvadnak a felhőmenedzsment szoftverrel.
Fotó:Használva az alkalmat, szeretném üdvözölni anyát, emlékeztetve, hogy van egy Facebook-csoportunk , csatorna érdekes publikációkkal a különböző technológiai blogokból. És az én csatornám , ahol a termékcégek fejlesztési menedzsmentjéről beszélek.
Forrás: habr.com
