Moderna infrastruktura: problemi i perspektive

Moderna infrastruktura: problemi i perspektive

Na kraju maja mi smo održao online sastanak na tu temu “Moderna infrastruktura i kontejneri: problemi i izgledi”. Razgovarali smo o kontejnerima, Kubernetesu i orkestraciji u principu, kriterijima za odabir infrastrukture i još mnogo toga. Učesnici su podijelili slučajeve iz vlastite prakse.

Učesnici:

  • Evgenij Potapov, izvršni direktor kompanije ITSumma. Više od polovine njegovih kupaca ili se već seli ili želi da pređe na Kubernetes.
  • Dmitrij Stoljarov, tehnički direktor "Flant". Ima 10+ godina iskustva u radu sa kontejnerskim sistemima.
  • Denis Remchukov (aka Eric Oldmann), COO argotech.io, bivši RAO UES. Obećao je da će govoriti o slučajevima u "krvavom" preduzeću.
  • Andrey Fedorovsky, CTO “News360.com”Nakon što je kompaniju kupio drugi igrač, odgovoran je za brojne ML i AI projekte i infrastrukturu.
  • Ivan Kruglov, sistemski inženjer, ex-Booking.com.Ista osoba koja je mnogo uradila sa Kubernetesom svojim rukama.

Teme:

  • Uvid učesnika o kontejnerima i orkestraciji (Docker, Kubernetes, itd.); šta je isprobano u praksi ili analizirano.
  • Slučaj: Kompanija godinama gradi plan razvoja infrastrukture. Kako se donosi odluka da li da se izgradi (ili migrira trenutna) infrastruktura na kontejnere i Kuber ili ne?
  • Problemi u cloud-native svijetu, šta nedostaje, zamislimo šta će se dogoditi sutra.

Uslijedila je zanimljiva diskusija, mišljenja učesnika su bila toliko različita i izazvala toliko komentara da ih želim podijeliti sa vama. Jedi trosatni video, a ispod je sažetak diskusije.

Da li je Kubernetes već standardan ili odličan marketing?

“Došli smo do toga (Kubernetes. - Red.) kada još niko nije znao za to. Dolazili smo kod njega i kada ga nije bilo. Htjeli smo to prije" - Dmitry Stolyarov

Moderna infrastruktura: problemi i perspektive
Fotografija sa Reddit.com

Prije 5-10 godina postojao je ogroman broj alata, a nije postojao jedinstveni standard. Svakih šest mjeseci pojavio se novi proizvod, ili čak više od jednog. Prvo Vagrant, pa Salt, Chef, Puppet,... “i obnavljate svoju infrastrukturu svakih šest mjeseci. Imate pet administratora koji su stalno zauzeti prepisivanjem konfiguracija”, prisjeća se Andrej Fedorovski. On vjeruje da su Docker i Kubernetes "istisnuli" ostale. Docker je postao standard u posljednjih pet godina, Kubernetes u posljednje dvije godine. I to je dobro za industriju..

Dmitrij Stoljarov i njegov tim vole Kuber. Željeli su takav alat prije nego što se pojavio, a došli su do njega kada niko nije znao za njega. Trenutno, iz praktičnih razloga, ne preuzimaju klijenta ako shvate da neće implementirati Kubernetes s njim. Istovremeno, prema Dmitriju, kompanija ima „mnoge gigantske uspješne priče o ponovnoj izradi užasnog naslijeđa“.

Kubernetes nije samo orkestracija kontejnera, to je sistem za upravljanje konfiguracijom sa razvijenim API-jem, mrežnom komponentom, L3 balansiranjem i Ingress kontrolerima, što čini relativno lakim upravljanje resursima, razmerom i apstrahovanjem od nižih slojeva infrastrukture.

Nažalost, u našem životu moramo platiti za sve. A ovaj porez je velik, pogotovo ako govorimo o prelasku na Kubernetes kompanije sa razvijenom infrastrukturom, kako smatra Ivan Kruglov. Mogao je slobodno da radi i u kompaniji sa tradicionalnom infrastrukturom i sa Kuberom. Glavna stvar je razumjeti karakteristike kompanije i tržišta. Ali, na primjer, za Evgenija Potapova, koji bi generalizirao Kubernetes na bilo koji alat za orkestraciju kontejnera, takvo pitanje se ne postavlja.

Evgenij je povukao analogiju sa situacijom iz 1990-ih, kada se objektno orijentisano programiranje pojavilo kao način programiranja složenih aplikacija. U to vrijeme, debata se nastavila i pojavili su se novi alati koji podržavaju OOP. Tada su se pojavile mikroservise kao način da se odmakne od monolitnog koncepta. To je zauzvrat dovelo do pojave kontejnera i alata za upravljanje kontejnerima. “Mislim da ćemo uskoro doći u vrijeme kada se više neće postavljati pitanje isplati li se pisati mala mikroservisna aplikacija, već će ona po defaultu biti napisana kao mikroservis”, smatra on. Isto tako, Docker i Kubernetes će na kraju postati standardno rješenje bez potrebe za izborom.

Problem baza podataka u apatridima

Moderna infrastruktura: problemi i perspektive
Photo by Twitter: @jankolario na Unsplash-u

Danas postoji mnogo recepata za pokretanje baza podataka u Kubernetesu. Čak i kako odvojiti dio koji radi s I/O diskom od, uvjetno, aplikacijskog dijela baze podataka. Da li je moguće da će se u budućnosti baze podataka toliko promeniti da će se isporučivati ​​u kutiji, gde će jedan deo biti orkestriran kroz Docker i Kubernetes, au drugom delu infrastrukture, kroz poseban softver, biti obezbeđen deo za skladištenje ? Hoće li se baze mijenjati kao proizvod?

Ovaj opis je sličan upravljanju redovima, ali su zahtjevi za pouzdanošću i sinhronizacijom informacija u tradicionalnim bazama podataka mnogo veći, smatra Andrey. Omjer pogodaka keša u normalnim bazama podataka ostaje 99%. Ako radnik padne, pokreće se novi i keš se „zagreva“ od nule. Dok se keš ne zagrije, worker radi sporo, što znači da se ne može učitati sa opterećenjem korisnika. Dok nema učitavanja korisnika, keš se ne zagrijava. To je začarani krug.

Dmitrij se u osnovi ne slaže - kvorum i dijeljenje rješavaju problem. Ali Andrey insistira na tome da rješenje nije prikladno za sve. U nekim situacijama kvorum je prikladan, ali dodatno opterećuje mrežu. NoSQL baza podataka nije prikladna u svim slučajevima.

Učesnici susreta bili su podijeljeni u dva tabora.

Denis i Andrey tvrde da je sve što je zapisano na disk - baze podataka i tako dalje - nemoguće učiniti u trenutnom Kuber ekosistemu. Nemoguće je održati integritet i konzistentnost proizvodnih podataka u Kubernetesu. Ovo je fundamentalna karakteristika. Rješenje: hibridna infrastruktura.

Čak i moderne izvorne baze podataka u oblaku kao što su MongoDB i Cassandra, ili redovi poruka kao što su Kafka ili RabbitMQ, zahtijevaju trajna skladišta podataka izvan Kubernetesa.

Evgeniy prigovara: „Baze u Kuberi su skoro ruska, ili blizu preduzeća povreda, koja je povezana sa činjenicom da u Rusiji nema usvajanja oblaka.“ Male ili srednje kompanije na Zapadu su Cloud. Amazon RDS baze podataka lakše je koristiti nego sami petljati s Kubernetesom. U Rusiji koriste Kuber "on-premise" i prenose baze na njega kada pokušavaju da se otarase zoološkog vrta.

Dmitrij se takođe nije složio sa izjavom da se u Kubernetesu ne mogu čuvati baze podataka: „Baza se razlikuje od baze. A ako gurnete ogromnu relacionu bazu podataka, ni pod kojim okolnostima. Ako gurnete nešto malo i domorodno u oblaku, što je mentalno pripremljeno za polu-efemeran život, sve će biti u redu.” Dmitrij je takođe napomenuo da alati za upravljanje bazom podataka nisu spremni ni za Docker ni za Kuber, pa se javljaju velike poteškoće.

Ivan je zauzvrat siguran da čak i ako apstrahujemo od koncepta stanja i bez državljanstva, ekosistem poslovnih rješenja u Kubernetesu još nije spreman. Sa Kuberom je teško održati zakonske i regulatorne zahtjeve. Na primjer, nemoguće je napraviti rješenje za obezbjeđivanje identiteta gdje su potrebne stroge garancije identifikacije servera, sve do hardvera koji je umetnut u servere. Ovo područje se razvija, ali još uvijek nema rješenja.
Učesnici se nisu mogli složiti, pa se u ovom dijelu neće donositi zaključci. Navedimo nekoliko praktičnih primjera.

Slučaj 1. Sajber sigurnost „mega regulatora“ sa bazama izvan Kubere

U slučaju razvijenog sistema sajber-sigurnosti, upotreba kontejnera i orkestracije omogućavaju borbu protiv napada i upada. Na primjer, u jednom megaregulatoru, Denis i njegov tim implementirali su kombinaciju orkestratora sa obučenim SIEM servisom koji analizira logove u realnom vremenu i određuje proces napada, hakovanja ili neuspjeha. U slučaju napada, pokušaja postavljanja nečega ili u slučaju invazije ransomware virusa, on preko orkestratora preuzima kontejnere s aplikacijama brže nego što se zaraze, odnosno brže nego što ih napadač napadne.

Slučaj 2. Djelomična migracija Booking.com baza podataka na Kubernetes

U Booking.com-u, glavna baza podataka je MySQL sa asinhronom replikacijom - postoji master i čitava hijerarhija slave. U trenutku kada je Ivan napustio kompaniju, pokrenut je projekt prijenosa robova koji su mogli biti „pucani” uz određenu štetu.

Pored glavne baze, tu je i Cassandra instalacija sa samostalno pisanom orkestracijom, koja je napisana i prije nego što je Kuber ušao u mainstream. Nema problema u tom pogledu, ali je uporan na lokalnim SSD-ovima. Daljinsko skladištenje, čak i unutar istog data centra, se ne koristi zbog problema velike latencije.

Treća klasa baza podataka je usluga pretraživanja Booking.com, gdje je svaki servisni čvor baza podataka. Pokušaji prijenosa usluge pretraživanja na Kuber nisu uspjeli, jer svaki čvor ima 60-80 GB lokalne memorije, koju je teško "podići" i "zagrijati".

Kao rezultat toga, pretraživač nije prebačen u Kubernetes, a Ivan ne misli da će biti novih pokušaja u bliskoj budućnosti. MySQL baza podataka je prebačena na pola: samo Slave, koji se ne plaše da budu "ustreljeni". Kasandra se savršeno uklopila.

Odabir infrastrukture kao zadatak bez generalnog rješenja

Moderna infrastruktura: problemi i perspektive
Photo by Manuel Geissinger iz Pexelsa

Recimo da imamo novo preduzeće, ili firmu u kojoj je dio infrastrukture izgrađen na stari način. Godinama gradi plan razvoja infrastrukture. Kako se donosi odluka da li da se gradi infrastruktura na kontejnerima i Kuberu ili ne?

Kompanije koje se bore za nanosekunde isključene su iz rasprave. Zdravi konzervativizam se isplati u smislu pouzdanosti, ali još uvijek postoje kompanije koje bi trebale razmotriti nove pristupe.

Ivan: „Sada bih definitivno osnovao kompaniju u oblaku, jednostavno zato što je brže“, iako ne nužno jeftinije. S razvojem rizičnog kapitalizma, startapovi nemaju velikih problema s novcem, a glavni zadatak je osvajanje tržišta.

Ivan je mišljenja da razvoj postojeće infrastrukture je kriterijum izbora. Ako je u prošlosti bilo ozbiljnog ulaganja, a radi, onda to nema smisla ponavljati. Ako infrastruktura nije razvijena, a postoje problemi sa alatima, sigurnošću i nadzorom, onda ima smisla pogledati distribuiranu infrastrukturu.

Porez će se u svakom slučaju morati platiti, a Ivan bi platio onaj koji mu je omogućio da ubuduće plaća manje. "Jer jednostavno zbog činjenice da se vozim u vozu kojim se drugi kreću, putovaću mnogo dalje nego da sednem u drugi voz, u koji moram sam da dolivam gorivo.“, kaže Ivan. Kada je kompanija nova, a zahtjevi za kašnjenje su desetine milisekundi, onda bi Ivan pogledao prema “operatorima” u koje su danas “umotane” klasične baze podataka. Oni podižu lanac replikacije, koji se sam prebacuje u slučaju greške, itd...

Za malu kompaniju sa nekoliko servera, Kubera nema smisla“, kaže Andrey. Ali ako planira da naraste na stotine servera ili više, onda mu je potrebna automatizacija i sistem upravljanja resursima. 90% slučajeva je vrijedno troškova. Štaviše, bez obzira na nivo opterećenja i resursa. Ima smisla da svi, od startupa do velikih kompanija sa milionskom publikom, postupno gledaju prema proizvodima orkestracije kontejnera. „Da, ovo je zaista budućnost“, siguran je Andrej.

Denis je naveo dva glavna kriterijuma - skalabilnost i stabilnost rada. On će odabrati alate koji su najprikladniji za zadatak. “To bi mogao biti noname sastavljen na vašim koljenima, a na sebi ima Nutanix Community Edition. Ovo bi mogao biti drugi red u obliku aplikacije na Kuberu sa bazom podataka na pozadini, koja je replicirana i ima specificirane RTO i RPO parametre" (ciljevi vremena/točke oporavka - cca.).

Evgeniy je identifikovao mogući problem sa osobljem. Trenutno na tržištu nema mnogo visoko kvalifikovanih stručnjaka koji razumiju "uštinu". Zaista, ako je odabrana tehnologija stara, onda je teško zaposliti bilo koga osim ljudi srednjih godina koji su dosadni i umorni od života. Iako drugi učesnici smatraju da je to stvar obuke kadrova.
Ako postavimo pitanje izbora: pokrenuti malu kompaniju u javnom oblaku sa bazama podataka u Amazon RDS ili “on premise” sa bazama podataka u Kubernetesu, onda je, uprkos nekim nedostacima, Amazon RDS postao izbor učesnika.

Pošto većina slušalaca susreta nije iz "krvavog" preduzeća, onda distribuirana rješenja su ono čemu trebamo težiti. Sistemi za skladištenje podataka moraju biti distribuirani, pouzdani i stvarati kašnjenje mjereno u jedinicama milisekundi, najviše desetinama“, rezimirao je Andrej.

Procjena upotrebe Kubernetesa

Slušalac Anton Zhbankov postavio je pitanje zamke Kubernetes apologetima: kako ste odabrali i sproveli studiju izvodljivosti? Zašto Kubernetes, zašto ne virtuelne mašine, na primer?

Moderna infrastruktura: problemi i perspektive
Photo by Tatjana Eremina na Unsplash-u

Dmitrij i Ivan su odgovorili. U oba slučaja, metodom pokušaja i grešaka, donešen je niz odluka, usled čega su oba učesnika stigla u Kubernetes. Sada kompanije počinju samostalno razvijati softver koji ima smisla prenijeti na Kuber. Ne govorimo o klasičnim sistemima treće strane, kao što je 1C. Kubernetes pomaže kada programeri moraju brzo da naprave izdanja, uz kontinuirano kontinuirano poboljšanje.

Andreyev tim je pokušao da napravi skalabilni klaster baziran na virtuelnim mašinama. Čvorovi su padali poput domina, što je ponekad dovodilo do kolapsa klastera. “Teoretski, možete ga završiti i poduprijeti rukama, ali to je zamorno. A ako na tržištu postoji rješenje koje vam omogućava da radite iz kutije, onda ćemo ga rado prihvatiti. I zbog toga smo se zamenili”, kaže Andrey.

Postoje standardi za takve analize i proračune, ali niko ne može reći koliko su tačni na stvarnom hardveru u radu. Za proračune je također važno razumjeti svaki alat i ekosistem, ali to nije moguće.

Šta nas čeka

Moderna infrastruktura: problemi i perspektive
Photo by Drew Beamer na Unsplash-u

Kako tehnologija evoluira, pojavljuje se sve više i više različitih komada, a zatim dolazi do fazne tranzicije, pojavljuje se prodavac koji je ubio dovoljno tijesta da se sve spoji u jedan alat.

Mislite li da će doći vrijeme kada će postojati alat poput Ubuntua za Linux svijet? Možda će jedan alat za kontejnerizaciju i orkestraciju uključiti Kuber. To će olakšati izgradnju lokalnih oblaka.

Odgovor je dao Ivan: “Google sada gradi Anthos – ovo je njihova pakirana ponuda koja postavlja oblak i uključuje Kuber, Service Mesh, nadzor – sav hardver koji je potreban za lokalne mikroservise.” Skoro smo u budućnosti."

Denis je spomenuo i Nutanix i VMWare s proizvodom vRealize Suite, koji se može nositi sa sličnim zadatkom bez kontejnerizacije.

Dmitrij je podijelio svoje mišljenje da su smanjenje „bola“ i smanjenje poreza dvije oblasti u kojima možemo očekivati ​​poboljšanja.

Da sumiramo diskusiju, ističemo sljedeće probleme moderne infrastrukture:

  • Tri učesnika su odmah identifikovala problem sa stanjem.
  • Različiti problemi sa sigurnosnom podrškom, uključujući mogućnost da Docker završi s više verzija Pythona, poslužitelja aplikacija i komponenti.
    Prekomjerna potrošnja, o čemu je bolje razgovarati na posebnom sastanku.
    Izazov učenja kao orkestracija je složen ekosistem.
    Čest problem u industriji je zloupotreba alata.

    Ostatak zaključaka je na vama. Još uvijek postoji osjećaj da kombinaciji Docker+Kubernetes nije lako postati „centralni“ dio sistema. Na primjer, operativni sistemi se prvo instaliraju na hardver, što se ne može reći za kontejnere i orkestraciju. Možda će se u budućnosti operativni sistemi i kontejneri spojiti sa softverom za upravljanje oblakom.

    Moderna infrastruktura: problemi i perspektive
    Photo by Gabriel Santos Fotografija iz Pexelsa

    Želio bih iskoristiti ovu priliku da pozdravim svoju majku i podsjetim vas da imamo Facebook grupu "Upravljanje i razvoj velikih IT projekata", kanal @feedmeto sa zanimljivim publikacijama sa raznih tehnoloških blogova. I moj kanal @rybakalexey, gdje govorim o upravljanju razvojem u proizvodnim kompanijama.

izvor: www.habr.com

Dodajte komentar