Május végén online találkozót tartott a témában . Beszéltünk konténerekről, Kubernetesről és elvi hangszerelésről, az infrastruktúra kiválasztásának kritériumairól és még sok másról. A résztvevők eseteket osztottak meg saját gyakorlatukból.
Résztvevők:
- Jevgenyij Potapov, az ITSumma vezérigazgatója. Ügyfeleinek több mint fele vagy már költözik, vagy szeretne áttérni a Kubernetesre.
- Dmitrij Stolyarov, "Flant" műszaki igazgató. Több mint 10 éves tapasztalattal rendelkezik konténerrendszerek terén.
- Denis Remchukov (más néven Eric Oldmann), az argotech.io ügyvezető igazgatója, ex-RAO UES. Megígérte, hogy beszélni fog a „véres” vállalkozás eseteiről.
- Andrej Fedorovszkij, a News360.com műszaki igazgatójaMiután egy másik játékos megvásárolta a céget, számos ML és AI projektért és infrastruktúráért felel.
- Ivan Kruglov, rendszermérnök, ex-Booking.com.Ugyanaz, aki Kubernetessel sokat tett saját kezűleg.
Témák:
- A résztvevők meglátásai a konténerekről és a hangszerelésről (Docker, Kubernetes stb.); amit a gyakorlatban kipróbáltak vagy elemeztek.
- Eset: A cég évek óta infrastruktúra-fejlesztési tervet készít. Hogyan születik a döntés, hogy kiépítjük-e (vagy migrálja a jelenlegi) infrastruktúrát konténerekre és Kuberre vagy sem?
- Problémák a felhőben natív világban, mi hiányzik, képzeljük el, mi lesz holnap.
Érdekes vita alakult ki, a résztvevők véleménye annyira eltérő volt, és annyi észrevételt váltott ki, hogy szeretném megosztani veletek. Eszik , alább pedig a vita összefoglalója.
A Kubernetes már szabványos vagy nagyszerű marketing?
„Amikor jöttünk rá (Kubernetes. - A szerk.), amikor még senki nem tudott róla. Akkor is eljöttünk hozzá, amikor nem volt ott. Korábban akartuk" - Dmitrij Sztoljarov
Fotó a Reddit.com-ról
5-10 évvel ezelőtt nagyon sok szerszám volt, és nem volt egységes szabvány. Félévente megjelent egy új termék, vagy akár több is. Először Vagrant, majd Salt, Chef, Puppet,... „és félévente újjáépíted az infrastruktúrát. Öt rendszergazdája van, akik folyamatosan a konfigurációk átírásával vannak elfoglalva” – emlékszik vissza Andrey Fedorovsky. Úgy véli, hogy Docker és Kubernetes „kiszorította” a többit. A Docker az elmúlt öt évben, a Kubernetes az elmúlt két évben standard lett. És ez jó az iparnak..
Dmitrij Stolyarov és csapata szereti a Kubert. Szerettek volna egy ilyen eszközt, mielőtt megjelent, és akkor jöttek rá, amikor senki sem tudott róla. Jelenleg kényelmi okokból nem vállalnak ügyfelet, ha megértik, hogy nem valósítják meg vele a Kuberneteset. Ugyanakkor Dmitrij szerint a cégnek „sok gigantikus sikertörténete van a szörnyű örökség újraalkotásáról”.
A Kubernetes nem csupán konténer-hangszerelés, hanem egy konfigurációkezelő rendszer, fejlett API-val, hálózati komponenssel, L3 kiegyensúlyozó és bemeneti vezérlőkkel, amely viszonylag egyszerűvé teszi az erőforrások kezelését, méretezését és az infrastruktúra alsóbb rétegeitől való elvonatkoztatást.
Sajnos az életünkben mindenért fizetnünk kell. Ez az adó pedig nagy, különösen, ha egy fejlett infrastruktúrával rendelkező cég Kubernetesre való átállásáról beszélünk, ahogy Ivan Kruglov véli. Szabadon dolgozhatott hagyományos infrastruktúrájú cégnél és a Kubernél is. A legfontosabb dolog az, hogy megértsük a vállalat és a piac jellemzőit. De például Jevgenyij Potapov számára, aki a Kubernetes-et bármilyen konténer hangszerelési eszközre általánosítaná, ilyen kérdés nem merül fel.
Jevgenyij az 1990-es évek helyzetével analógiát vont le, amikor az objektum-orientált programozás az összetett alkalmazások programozásának egyik módjaként jelent meg. Ekkor a vita folytatódott, és új eszközök jelentek meg az OOP támogatására. Aztán megjelentek a mikroszolgáltatások a monolitikus koncepciótól való eltávolodás módjaként. Ez pedig a konténerek és konténerkezelő eszközök megjelenéséhez vezetett. „Úgy gondolom, hamarosan elérkezünk ahhoz az időhöz, amikor nem lesz kérdés, hogy megéri-e kis mikroszolgáltatási alkalmazást írni, az alapból mikroszolgáltatásként fog írni” – vélekedik. Hasonlóképpen, a Docker és a Kubernetes végül a standard megoldás lesz, választási igény nélkül.
Az adatbázisok problémája hontalan állapotban
Fotó
Manapság számos recept létezik adatbázisok futtatására a Kubernetesben. Még azt is, hogyan lehet elválasztani az I/O lemezzel működő részt az adatbázis alkalmazási részétől feltételesen. Lehetséges, hogy a jövőben annyira megváltoznak az adatbázisok, hogy dobozban szállítják, ahol az egyik részt a Dockeren és a Kubernetesen keresztül hangszereljük, az infrastruktúra másik részében pedig külön szoftveren keresztül a tároló részt biztosítják ? Változnak az alapok termékként?
Ez a leírás hasonló a sorkezeléshez, de a megbízhatóság és az információk szinkronizálása a hagyományos adatbázisokban sokkal magasabb, vélekedik Andrey. A gyorsítótár találati aránya normál adatbázisokban továbbra is 99%. Ha egy dolgozó leáll, egy újat indítanak el, és a gyorsítótár a semmiből „bemelegszik”. Amíg a gyorsítótár fel nem melegszik, a dolgozó lassan dolgozik, ami azt jelenti, hogy nem tölthető be felhasználói betöltéssel. Amíg nincs felhasználói terhelés, a gyorsítótár nem melegszik fel. Ez egy ördögi kör.
Dmitrij alapvetően nem ért egyet - a határozatképesség és a felosztás megoldja a problémát. De Andrey ragaszkodik ahhoz, hogy a megoldás nem mindenki számára megfelelő. Bizonyos helyzetekben a határozatképesség megfelelő, de ez további terhelést jelent a hálózatra. A NoSQL adatbázis nem minden esetben megfelelő.
A találkozó résztvevőit két táborra osztották.
Denis és Andrey azzal érvelnek, hogy minden, ami lemezre van írva – adatbázisok és így tovább – lehetetlen a jelenlegi Kuber-ökoszisztémában. A Kubernetesben lehetetlen fenntartani a termelési adatok integritását és konzisztenciáját. Ez alapvető jellemző. Megoldás: hibrid infrastruktúra.
Még a modern felhőalapú natív adatbázisok, például a MongoDB és a Cassandra, vagy az üzenetsorok, mint a Kafka vagy a RabbitMQ is állandó adattárakat igényelnek a Kubernetesen kívül.
Jevgenyij tiltakozik: "A kuberai bázisok közel orosz vagy vállalatközeli károk, ami azzal a ténnyel jár, hogy Oroszországban nincs felhőbefogadás." Nyugaton a kis- vagy középvállalatok a Cloud. Az Amazon RDS-adatbázisait könnyebben lehet használni, mint a Kubernetes-szel saját maga trükközni. Oroszországban a Kuber „on-premise”-t használják, és bázisokat adnak át neki, amikor megpróbálnak megszabadulni az állatkerttől.
Dmitrij nem értett egyet azzal az állítással, hogy a Kubernetesben nem lehet adatbázist tartani: „Az alap különbözik az alaptól. És ha egy óriási relációs adatbázist nyomsz, akkor semmi esetre sem. Ha valami apró és felhős bennszülöttet nyomsz, ami mentálisan fel van készülve a félig múlandó életre, minden rendben lesz.” Dmitrij azt is megemlítette, hogy az adatbázis-kezelő eszközök sem a Docker, sem a Kuber számára nem állnak készen, így nagy nehézségek merülnek fel.
Iván viszont biztos abban, hogy még ha elvonatkoztatunk is az állapotos és hontalan fogalmaktól, a vállalati megoldások ökoszisztémája Kubernetesben még nincs készen. A Kuberrel nehéz fenntartani a törvényi és szabályozási követelményeket. Lehetetlen például olyan identitásbiztosítási megoldást készíteni, ahol szigorú szerverazonosítási garanciák kellenek, egészen a szerverekbe behelyezett hardverig. Ez a terület fejlődik, de még nincs megoldás.
A résztvevők nem tudtak megegyezni, ezért ebben a részben nem vonunk le következtetéseket. Mondjunk néhány gyakorlati példát.
1. eset. Egy „mega-szabályozó” kiberbiztonsága Kuberán kívüli bázisokkal
Egy fejlett kiberbiztonsági rendszer esetén a konténerek és a hangszerelés lehetővé teszi a támadások és behatolások leküzdését. Például az egyik mega-szabályozóban Denis és csapata egy hangszerelőt és egy képzett SIEM-szolgáltatás kombinációját valósította meg, amely valós időben elemzi a naplókat, és meghatározza a támadás, feltörés vagy hiba folyamatát. Támadás, elhelyezési kísérlet, vagy ransomware vírus invázió esetén a hangszerelőn keresztül gyorsabban veszi fel az alkalmazásokat tartalmazó konténereket, mint ahogy azok megfertőződnek, vagy gyorsabban, mint ahogy a támadó megtámadja őket.
2. eset: Booking.com adatbázisok részleges áttelepítése Kubernetesre
A Booking.com webhelyen a fő adatbázis a MySQL aszinkron replikációval - van egy mester és egy teljes hierarchia a szolgáknak. Mire Ivan elhagyta a céget, egy projekt indult olyan rabszolgák szállítására, amelyeket bizonyos sérülésekkel „le lehet lőni”.
A főalap mellett van egy Cassandra installáció saját kezűleg hangszereléssel, ami még azelőtt készült, hogy Kuber belépett volna a mainstreambe. Ebben a tekintetben nincs probléma, de a helyi SSD-ken tartós. A távoli tárhelyet még ugyanazon az adatközponton belül sem használják a magas késleltetési idő miatt.
Az adatbázisok harmadik osztálya a Booking.com keresőszolgáltatása, ahol minden szolgáltatási csomópont egy adatbázis. A keresési szolgáltatás Kuberre való átvitelére tett kísérletek kudarcot vallottak, mert minden csomópont 60-80 GB helyi tárhellyel rendelkezik, amelyet nehéz „emelni” és „bemelegíteni”.
Ennek eredményeként a keresőmotor nem került át a Kubernetesre, és Ivan nem gondolja, hogy a közeljövőben újabb próbálkozások lesznek. A MySQL adatbázis fele-fele arányban került átadásra: csak a Slave-ok, akik nem félnek a „lövéstől”. Cassandra tökéletesen beilleszkedett.
Az infrastruktúra kiválasztása, mint általános megoldás nélküli feladat
Fotó
Tegyük fel, hogy van egy új cégünk, vagy olyan cégünk, ahol az infrastruktúra egy része a régi módon van kiépítve. Évekre épít infrastruktúra-fejlesztési tervet. Hogyan születik a döntés, hogy konténerekre és Kuberre építsünk-e infrastruktúrát vagy sem?
A nanoszekundumért küzdő cégeket kizárják a vitából. Az egészséges konzervativizmus megtérül a megbízhatóság szempontjából, de még mindig vannak olyan cégek, amelyeknek új megközelítéseket kellene fontolóra venniük.
Ivan: „Most biztosan alapítanék egy céget a felhőn, egyszerűen azért, mert gyorsabb”, bár nem feltétlenül olcsóbb. A kockázati tőkés fejlődésével a startupoknak nincs nagy gondja a pénzzel, a piac meghódítása a fő feladat.
Iván azon a véleményen van kiválasztási szempont a jelenlegi infrastruktúra fejlesztése. Ha volt egy komoly beruházás a múltban, és az működik, akkor nincs értelme újratenni. Ha az infrastruktúra nem fejlett, és problémák vannak az eszközökkel, a biztonsággal és a felügyelettel, akkor érdemes elosztott infrastruktúrát nézni.
Az adót mindenképpen fizetni kell, és Iván azt fizetné, amelyik miatt a jövőben kevesebbet fizethet. "Mert pusztán attól a ténytől fogva, hogy olyan vonaton ülök, amelyen mások is közlekednek, sokkal messzebbre utazom, mintha egy másik vonatra ülnék, amibe magamnak kell üzemanyagot töltenem.– mondja Iván. Amikor a cég új, és a késleltetési követelmények tízezredmásodpercek, akkor Ivan azokra az „üzemeltetőkre” tekintene, amelyekbe ma a klasszikus adatbázisokat „csomagolják”. Felállítanak egy replikációs láncot, ami feladatátvétel esetén magától vált, stb...
Egy pár szerverrel rendelkező kis cégnél a Kuberának semmi értelme” – mondja Andrey. De ha azt tervezi, hogy több száz szerverre vagy még többre nő, akkor automatizálásra és erőforrás-kezelő rendszerre van szüksége. Az esetek 90%-a megéri az árát. Sőt, függetlenül a terhelés és az erőforrások szintjétől. Az induló vállalkozásoktól a milliós közönséggel rendelkező nagyvállalatokig mindenki számára logikus, hogy fokozatosan a konténerhangszerelési termékek felé forduljon. „Igen, ez valóban a jövő” – biztos benne Andrey.
Denis két fő kritériumot vázolt fel: a skálázhatóság és a működés stabilitása. Ő választja ki a feladathoz legmegfelelőbb eszközöket. „Lehet, hogy egy noname a térdére rakva, és rajta van a Nutanix Community Edition. Ez lehet egy második sor egy alkalmazás formájában a Kuberen egy adatbázissal a háttérben, amely replikálva van, és RTO és RPO paraméterekkel rendelkezik" (helyreállítási idő/pont célok - kb).
Jevgenyij egy lehetséges problémát azonosított a személyzettel. Jelenleg nem sok olyan magasan képzett szakember van a piacon, aki megértené a „beleket”. Valóban, ha a választott technológia régi, akkor nehéz mást felvenni, mint középkorúakat, akik megunták és belefáradtak az életbe. Bár más résztvevők úgy vélik, hogy ez a személyzet képzésének kérdése.
Ha feltesszük a kérdést: egy kis céget indítunk a Public Cloudban Amazon RDS adatbázisokkal vagy „on premise” Kubernetes adatbázisokkal, akkor némi hiányosság ellenére a résztvevők az Amazon RDS-t választották.
Mivel a meetup hallgatóinak többsége nem a „véres” vállalkozásból származik, ezért az elosztott megoldásokra kell törekednünk. Az adattároló rendszereknek elosztottnak, megbízhatónak kell lenniük, és ezredmásodperces egységekben, legfeljebb tízekben mérhető késleltetést kell létrehozniuk.– foglalta össze Andrey.
A Kubernetes használatának felmérése
Anton Zsbankov hallgató csapdakérdést tett fel a Kubernetes bocsánatkérőinek: hogyan választották ki és készítették el a megvalósíthatósági tanulmányt? Miért a Kubernetes, miért nem a virtuális gépek például?
Fotó
Dmitrij és Ivan válaszolt. Mindkét esetben próbálgatással, döntések sorozata született, melynek eredményeként mindkét résztvevő megérkezett a Kuberneteshez. Most a vállalkozások elkezdenek önállóan fejleszteni olyan szoftvereket, amelyeknek van értelme átadni a Kubernek. Nem beszélünk klasszikus harmadik féltől származó rendszerekről, például az 1C-ről. A Kubernetes segít, ha a fejlesztőknek gyorsan kell kiadásokat készíteniük, a folyamatos folyamatos fejlesztéssel.
Andrey csapata megpróbált létrehozni egy skálázható klasztert virtuális gépeken. A csomópontok dominóként estek le, ami néha a klaszter összeomlásához vezetett. „Elméletileg be lehet fejezni és kézzel alátámasztani, de fárasztó. És ha van olyan megoldás a piacon, amely lehetővé teszi, hogy a dobozból dolgozzon, akkor szívesen vállaljuk. És ennek eredményeként váltottunk” – mondja Andrey.
Vannak szabványok az ilyen elemzésekre és számításokra, de senki sem tudja megmondani, mennyire pontosak a működő hardvereken. A számításokhoz az is fontos, hogy megértsük az egyes eszközöket és ökoszisztémákat, de ez nem lehetséges.
Mi vár ránk
Fotó
A technológia fejlődésével egyre több, egymástól eltérő darab jelenik meg, majd fázisátalakulás következik be, megjelenik egy eladó, aki elég tésztát ölt ahhoz, hogy minden egyetlen eszközben összeálljon.
Gondolod, hogy eljön az idő, amikor lesz egy olyan eszköz, mint az Ubuntu a Linux világ számára? Talán egyetlen konténerezési és hangszerelési eszköz lesz a Kuber. Ez megkönnyíti a helyszíni felhők építését.
A választ Ivan adta meg: „A Google most építi az Anthost – ez az ő csomagolt ajánlatuk, amely telepíti a felhőt, és magában foglalja a Kubert, a Service Mesh-t, a felügyeletet – minden olyan hardvert, amely a helyszíni mikroszolgáltatásokhoz szükséges.” Szinte a jövőben vagyunk."
Denis a Nutanixet és a VMWare-t is megemlítette a vRealize Suite termékkel, amelyek konténerezés nélkül is megbirkóznak egy hasonló feladattal.
Dmitrij osztotta azt a véleményét, hogy a „fájdalom” csökkentése és az adócsökkentés két olyan terület, ahol javulásra számíthatunk.
A vita összefoglalásaként a modern infrastruktúra alábbi problémáit emeljük ki:
- Három résztvevő azonnal problémát azonosított az állapotjelzővel.
- Különféle biztonsági támogatási problémák, beleértve annak lehetőségét, hogy a Docker a Python, az alkalmazáskiszolgálók és -összetevők több verziójával is foglalkozik.
Túlköltekezés, amit jobb külön megbeszélésen megbeszélni.
Tanulási kihívás, mint a hangszerelés, összetett ökoszisztéma.
Az iparban gyakori probléma az eszközökkel való visszaélés.A többi következtetés csak rajtad múlik. Továbbra is az az érzés, hogy nem könnyű a Docker+Kubernetes kombinációnak a rendszer „központi” részévé válni. Például az operációs rendszereket először hardverre telepítik, ami nem mondható el a konténerekről és a hangszerelésről. Talán a jövőben az operációs rendszerek és a konténerek egyesülni fognak a felhőkezelő szoftverekkel.
FotóSzeretném megragadni az alkalmat, hogy köszöntsem édesanyámat, és emlékeztessem önöket, hogy van egy Facebook csoportunk , csatorna érdekes publikációkkal a különböző technológiai blogokról. És a csatornám , ahol a termékgyártó cégek fejlesztésének irányításáról beszélek.
Forrás: will.com