Konec maja organiziral spletno srečanje na to temo . Pogovarjali smo se o kontejnerjih, Kubernetesu in principu orkestracije, kriterijih za izbiro infrastrukture in še marsičem. Udeleženci so delili primere iz lastne prakse.
Udeleženci:
- Evgeniy Potapov, izvršni direktor ITSumma. Več kot polovica strank se že seli ali želi preiti na Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Ima 10+ let izkušenj pri delu s kontejnerskimi sistemi.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, bivši RAO UES. Obljubil je, da bo govoril o primerih v "krvavem" podjetju.
- Andrej Fedorovski, tehnični direktor »News360.com«Potem ko je podjetje kupil drug igralec, je odgovoren za številne projekte in infrastrukturo ML in AI.
- Ivan Kruglov, sistemski inženir, ex-Booking.com.Ista oseba, ki je naredila veliko s Kubernetesom z lastnimi rokami.
Teme:
- Spoznanja udeležencev o vsebnikih in orkestraciji (Docker, Kubernetes itd.); kaj je bilo preizkušeno v praksi ali analizirano.
- Primer: Podjetje že leta gradi načrt razvoja infrastrukture. Kako se sprejme odločitev, ali zgraditi (ali preseliti sedanjo) infrastrukturo na kontejnerje in Kuber ali ne?
- Težave v svetu oblakov, kaj manjka, predstavljajmo si, kaj se bo zgodilo jutri.
Razvila se je zanimiva razprava, mnenja udeležencev so bila tako različna in sprožila toliko komentarjev, da jih želim deliti z vami. Jejte , spodaj pa je povzetek razprave.
Je Kubernetes že standard ali odličen marketing?
»Do tega (Kubernetes. - Ed.) smo prišli, ko še nihče ni vedel zanj. K njemu smo prihajali tudi, ko ga ni bilo. Želeli smo si ga prej" - Dmitrij Stoljarov
Fotografija iz Reddit.com
Pred 5-10 leti je bilo ogromno orodij in ni bilo enotnega standarda. Vsakih šest mesecev se je pojavil nov izdelek ali celo več. Najprej Vagrant, nato Salt, Chef, Puppet,... »in vsakih šest mesecev obnovite svojo infrastrukturo. Imate pet skrbnikov, ki so nenehno zaposleni s prepisovanjem konfiguracij,« se spominja Andrey Fedorovsky. Verjame, da sta Docker in Kubernetes "izrinila" ostale. Docker je postal standard v zadnjih petih letih, Kubernetes v zadnjih dveh letih. In to je dobro za industrijo..
Dmitrij Stoljarov in njegova ekipa obožujejo Kuberja. Želeli so si takšno orodje, preden se je pojavilo, in do njega prišli, ko nihče ni vedel zanj. Trenutno zaradi priročnosti ne sprejmejo stranke, če razumejo, da z njo ne bodo implementirali Kubernetesa. Hkrati ima po Dmitryjevih besedah podjetje "veliko velikanskih zgodb o uspehu o predelavi strašne zapuščine."
Kubernetes ni le orkestracija vsebnikov, je sistem za upravljanje konfiguracije z razvitim API-jem, omrežno komponento, uravnoteženjem L3 in krmilniki Ingress, kar omogoča razmeroma enostavno upravljanje virov, skaliranje in abstrahiranje od nižjih plasti infrastrukture.
Na žalost moramo v življenju vse plačati. In ta davek je velik, še posebej, če govorimo o prehodu na Kubernetes podjetja z razvito infrastrukturo, kot meni Ivan Kruglov. Lahko bi prosto delal tako v podjetju s tradicionalno infrastrukturo kot pri Kuberju. Glavna stvar je razumeti značilnosti podjetja in trga. Toda na primer za Evgenija Potapova, ki bi posplošil Kubernetes na katero koli orodje za orkestracijo vsebnikov, se takšno vprašanje ne pojavi.
Evgeniy je potegnil analogijo s situacijo v devetdesetih letih, ko se je pojavilo objektno orientirano programiranje kot način programiranja kompleksnih aplikacij. Takrat se je razprava nadaljevala in pojavila so se nova orodja za podporo OOP. Nato so se mikrostoritve pojavile kot način za odmik od monolitnega koncepta. To pa je privedlo do nastanka kontejnerjev in orodij za upravljanje kontejnerjev. »Mislim, da bomo kmalu prišli v čas, ko ne bo več vprašanj, ali se splača pisati majhno mikrostoritveno aplikacijo, privzeto bo napisana kot mikrostoritev,« je prepričan. Podobno bosta Docker in Kubernetes sčasoma postala standardna rešitev brez potrebe po izbiri.
Problem baz podatkov v brezdržavnosti
Foto:
Dandanes obstaja veliko receptov za izvajanje baz podatkov v Kubernetesu. Tudi kako ločiti del, ki dela z I/O diskom, od pogojno aplikativnega dela baze. Ali je možno, da se bodo baze podatkov v prihodnosti toliko spremenile, da bodo dostavljene v škatli, kjer bo en del orkestriran preko Dockerja in Kubernetesa, v drugem delu infrastrukture pa bo prek ločene programske opreme zagotovljen shranjevalni del ? Ali se bodo baze spremenile kot produkt?
Ta opis je podoben upravljanju čakalnih vrst, vendar so zahteve po zanesljivosti in sinhronizaciji informacij v tradicionalnih bazah podatkov veliko višje, meni Andrey. Razmerje zadetkov predpomnilnika v običajnih zbirkah podatkov ostaja 99 %. Če delavec preneha delovati, se zažene nov in predpomnilnik se »ogreje« iz nič. Dokler se predpomnilnik ne segreje, delavec deluje počasi, kar pomeni, da ga ni mogoče naložiti z uporabniško obremenitvijo. Medtem ko ni obremenitve uporabnika, se predpomnilnik ne segreje. To je začaran krog.
Dmitry se v bistvu ne strinja - kvorumi in razrezi rešujejo težavo. A Andrej vztraja, da rešitev ni primerna za vse. V nekaterih situacijah je kvorum primeren, vendar dodatno obremeni omrežje. Baza podatkov NoSQL ni primerna v vseh primerih.
Udeleženci srečanja so bili razdeljeni v dva tabora.
Denis in Andrey trdita, da je vse, kar je zapisano na disk - baze podatkov in tako naprej - nemogoče narediti v trenutnem ekosistemu Kuber. V Kubernetesu je nemogoče vzdrževati celovitost in doslednost proizvodnih podatkov. To je temeljna lastnost. Rešitev: hibridna infrastruktura.
Celo sodobne baze podatkov v oblaku, kot sta MongoDB in Cassandra, ali čakalne vrste sporočil, kot sta Kafka ali RabbitMQ, zahtevajo obstojne shrambe podatkov zunaj Kubernetesa.
Evgeniy nasprotuje: "Baze v Kuberi so skoraj ruska ali skoraj podjetniška poškodba, ki je povezana z dejstvom, da v Rusiji ni sprejemanja oblakov." Mala ali srednje velika podjetja na Zahodu so Cloud. Podatkovne baze Amazon RDS je lažje uporabljati, kot če bi se sami ukvarjali s Kubernetesom. V Rusiji uporabljajo Kuber »on-premise« in vanj prenašajo baze, ko se poskušajo znebiti živalskega vrta.
Dmitry se prav tako ni strinjal z izjavo, da v Kubernetesu ni mogoče hraniti baz podatkov: »Osnova se razlikuje od baze. In če potisnete velikansko relacijsko bazo podatkov, potem pod nobenim pogojem. Če potisneš nekaj majhnega in oblačnega, ki je psihično pripravljeno na pol minljivo življenje, bo vse v redu.” Dmitry je tudi omenil, da orodja za upravljanje baz podatkov niso pripravljena ne za Docker ne za Kuber, zato se pojavljajo velike težave.
Ivan pa je prepričan, da tudi če se abstrahiramo od konceptov stateful in stateless, ekosistem podjetniških rešitev v Kubernetesu še ni pripravljen. S Kuberjem je težko vzdrževati zakonodajne in regulativne zahteve. Na primer, nemogoče je narediti rešitev za zagotavljanje identitete, kjer so potrebna stroga jamstva za identifikacijo strežnika, vse do strojne opreme, ki je vstavljena v strežnike. To področje se razvija, a rešitve še ni.
Udeleženci se niso mogli dogovoriti, zato v tem delu ne bomo sklepali. Naj navedemo nekaj praktičnih primerov.
Primer 1. Kibernetska varnost »megaregulatorja« z bazami zunaj Kubere
V primeru razvitega sistema kibernetske varnosti uporaba vsebnikov in orkestracije omogoča boj proti napadom in vdorom. Na primer, v enem megaregulatorju sta Denis in njegova ekipa implementirala kombinacijo orkestratorja z usposobljeno storitvijo SIEM, ki analizira dnevnike v realnem času in določa postopek napada, vdora ali okvare. V primeru napada, poskusa nameščanja ali vdora izsiljevalskega virusa ta preko orkestratorja pobere vsebnike z aplikacijami hitreje, kot se te okužijo oziroma hitreje, kot jih napade napadalec.
Primer 2. Delna selitev baz podatkov Booking.com v Kubernetes
Pri Booking.com je glavna baza podatkov MySQL z asinhrono replikacijo – obstaja master in cela hierarhija podrejenih. V času, ko je Ivan zapustil podjetje, se je začel projekt prenosa sužnjev, ki bi jih lahko "strelili" z določeno škodo.
Poleg glavne baze je tu še instalacija Cassandra z lastnoročno orkestracijo, ki je nastala še preden je Kuber vstopil v mainstream. V zvezi s tem ni težav, je pa obstojen na lokalnih SSD-jih. Oddaljeno shranjevanje, tudi znotraj istega podatkovnega centra, se ne uporablja zaradi težave z visoko zakasnitvijo.
Tretji razred baz podatkov je iskalna storitev Booking.com, kjer je vsako servisno vozlišče baza podatkov. Poskusi prenosa iskalne storitve na Kuber niso uspeli, saj je vsako vozlišče 60-80 GB lokalnega pomnilnika, ki ga je težko "dvigniti" in "ogreti".
Iskalnik zaradi tega ni bil prenesen na Kubernetes in Ivan ne misli, da bo v bližnji prihodnosti novih poskusov. Podatkovna baza MySQL je bila prenesena na polovico: samo Sužnji, ki se ne bojijo, da bi jih »strelili«. Cassandra se je odlično vživela.
Izbira infrastrukture kot naloga brez splošne rešitve
Foto:
Recimo, da imamo novo podjetje ali podjetje, kjer je del infrastrukture zgrajen na star način. Leta gradi načrt razvoja infrastrukture. Kako poteka odločitev, ali graditi infrastrukturo na kontejnerjih in Kuberju ali ne?
Iz razprave so izključena podjetja, ki se borijo za nanosekunde. Zdrav konzervativizem se obrestuje z vidika zanesljivosti, vendar še vedno obstajajo podjetja, ki bi morala razmisliti o novih pristopih.
Ivan: »Zagotovo bi zdaj ustanovil podjetje v oblaku, preprosto zato, ker je hitreje,« čeprav ne nujno ceneje. Z razvojem tveganega kapitala startupi nimajo velikih težav z denarjem, glavna naloga pa je osvajanje trga.
Ivan je mnenja, da merilo izbire je razvoj obstoječe infrastrukture. Če je bila v preteklosti resna naložba in deluje, potem je nima smisla ponavljati. Če infrastruktura ni razvita in obstajajo težave z orodji, varnostjo in spremljanjem, potem je smiselno pogledati porazdeljeno infrastrukturo.
Davek bo v vsakem primeru treba plačati, Ivan pa bi plačal tistega, ki mu je v prihodnje omogočal manj. "Ker preprosto zaradi dejstva, da se vozim na vlaku, ki ga drugi premikajo, bom potoval veliko dlje, kot če bi sedel na drugem vlaku, v katerega moram sam natočiti gorivo.« pravi Ivan. Ko je podjetje novo in so zahteve po zakasnitvi desetine milisekund, bi se Ivan ozrl proti “operaterjem”, v katere so danes “zavite” klasične baze podatkov. Dvignejo replikacijsko verigo, ki se sama preklopi v primeru preklopa itd.
Za majhno podjetje z nekaj strežniki Kubera nima smisla,« pravi Andrey. Če pa namerava zrasti na stotine strežnikov ali več, potem potrebuje avtomatizacijo in sistem za upravljanje virov. 90 % primerov je vrednih stroškov. Poleg tega ne glede na stopnjo obremenitve in sredstev. Smiselno je, da se vsi, od startupov do velikih podjetij z milijonskim občinstvom, postopoma osredotočajo na izdelke za orkestracijo vsebnikov. "Da, to je res prihodnost," je prepričan Andrey.
Denis je izpostavil dva glavna kriterija – razširljivost in stabilnost delovanja. Izbral bo orodja, ki so najbolj primerna za nalogo. »Lahko bi bil noname, sestavljen na kolenih, na njem pa je Nutanix Community Edition. To bi lahko bila druga vrstica v obliki aplikacije na Kuberju z bazo podatkov na zaledju, ki je podvojena in ima določene parametre RTO in RPO" (cilji časa/točke obnovitve - pribl.).
Evgeniy je ugotovil možno težavo z osebjem. Trenutno na trgu ni veliko visokokvalificiranih strokovnjakov, ki bi razumeli "drobo". Če je izbrana tehnologija namreč stara, potem je težko zaposliti koga drugega kot ljudi srednjih let, ki so zdolgočaseni in utrujeni od življenja. Čeprav drugi udeleženci menijo, da gre za izobraževanje kadrov.
Če postavimo vprašanje izbire: ustanoviti majhno podjetje v javnem oblaku z bazami podatkov v Amazon RDS ali »on premise« z bazami podatkov v Kubernetesu, potem je bila izbira udeležencev kljub nekaterim pomanjkljivostim Amazon RDS.
Ker večina poslušalcev srečanja ni iz "krvavega" podjetja, torej porazdeljene rešitve so tisto, za kar bi si morali prizadevati. Sistemi za shranjevanje podatkov morajo biti porazdeljeni, zanesljivi in ustvarjati zakasnitev, merjeno v enotah milisekund, največ desetin.«, je povzel Andrej.
Ocenjevanje uporabe Kubernetesa
Poslušalec Anton Zhbankov je apologetom Kubernetesa postavil trap vprašanje: kako ste izbrali in izvedli študijo izvedljivosti? Zakaj Kubernetes, zakaj ne na primer virtualni stroji?
Foto:
Dmitrij in Ivan sta odgovorila. V obeh primerih je s poskusi in napakami prišlo do zaporedja odločitev, zaradi katerih sta oba udeleženca prispela v Kubernetes. Zdaj podjetja začenjajo samostojno razvijati programsko opremo, ki jo je smiselno prenesti v Kuber. Ne govorimo o klasičnih sistemih tretjih oseb, kot je 1C. Kubernetes pomaga, ko morajo razvijalci hitro izdati izdaje, z nenehnim nenehnim izboljševanjem.
Andreyeva ekipa je poskušala ustvariti razširljivo gručo, ki temelji na virtualnih strojih. Vozlišča so padala kot domine, kar je včasih vodilo v propad grozda. »Teoretično ga lahko dokončaš in podpreš z rokami, a je dolgočasno. In če je na trgu rešitev, ki vam omogoča, da delate takoj, potem jo z veseljem sprejmemo. In kot rezultat smo zamenjali,« pravi Andrey.
Obstajajo standardi za takšno analizo in izračune, vendar nihče ne more reči, kako natančni so na dejanski delujoči strojni opremi. Za izračune je pomembno tudi razumevanje vsakega orodja in ekosistema, vendar to ni mogoče.
Kaj nas čaka
Foto:
Ko se tehnologija razvija, se pojavlja vedno več različnih kosov, nato pa pride do faznega prehoda, pojavi se prodajalec, ki je pobil dovolj testa, da se je vse združilo v enem orodju.
Ali menite, da bo prišel čas, ko bo za svet Linuxa na voljo orodje, kot je Ubuntu? Morda bo eno samo orodje za kontejnerizacijo in orkestracijo vključevalo Kuber. Poenostavil bo gradnjo lokalnih oblakov.
Odgovor je podal Ivan: "Google zdaj gradi Anthos - to je njihova paketna ponudba, ki uvaja oblak in vključuje Kuber, Service Mesh, nadzor - vso strojno opremo, ki je potrebna za lokalne mikrostoritve." Smo skoraj v prihodnosti."
Denis je omenil tudi Nutanix in VMWare z izdelkom vRealize Suite, ki je kos podobni nalogi brez kontejnerizacije.
Dmitry je delil svoje mnenje, da sta zmanjšanje "bolečine" in znižanje davkov dve področji, kjer lahko pričakujemo izboljšave.
Če povzamemo razpravo, izpostavljamo naslednje probleme sodobne infrastrukture:
- Trije udeleženci so takoj ugotovili težavo s stanjem.
- Različne težave z varnostno podporo, vključno z možnostjo, da bo Docker imel več različic Pythona, aplikacijskih strežnikov in komponent.
Prekomerna poraba, o kateri je bolje razpravljati na ločenem sestanku.
Učni izziv, saj je orkestracija kompleksen ekosistem.
Pogosta težava v industriji je napačna uporaba orodij.Ostale zaključke pa prepuščate vam. Še vedno obstaja občutek, da kombinaciji Docker+Kubernetes ni lahko postati »osrednji« del sistema. Na primer, operacijski sistemi so najprej nameščeni na strojno opremo, česar pa ne moremo reči za vsebnike in orkestracijo. Morda se bodo v prihodnosti operacijski sistemi in vsebniki združili s programsko opremo za upravljanje v oblaku.
Foto:Rad bi izkoristil to priložnost, da pozdravim svojo mamo in vas spomnim, da imamo skupino na Facebooku , kanal z zanimivimi objavami iz različnih tehnoloških blogov. In moj kanal , kjer govorim o vodenju razvoja v produktnih podjetjih.
Vir: www.habr.com