Krajem svibnja održao online sastanak na tu temu . Razgovarali smo o kontejnerima, Kubernetesu i načelnoj orkestraciji, kriterijima za odabir infrastrukture i još puno toga. Sudionici su podijelili slučajeve iz vlastite prakse.
Sudionici:
- Evgeniy Potapov, izvršni direktor ITSumme. Više od polovice njegovih kupaca se već seli ili želi prijeći na Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Ima 10+ godina iskustva u radu s kontejnerskim sustavima.
- Denis Remchukov (aka Eric Oldmann), COO argotech.io, bivši RAO UES. Obećao je govoriti o slučajevima u “krvavom” pothvatu.
- Andrey Fedorovsky, tehnički direktor “News360.com”Nakon što je tvrtku kupio drugi igrač, odgovoran je za brojne ML i AI projekte i infrastrukturu.
- Ivan Kruglov, sistem inženjer, ex-Booking.com.Ista osoba koja je napravila puno s Kubernetesom vlastitim rukama.
Teme:
- Uvidi sudionika o spremnicima i orkestraciji (Docker, Kubernetes, itd.); ono što je isprobano u praksi ili analizirano.
- Slučaj: Tvrtka godinama gradi plan razvoja infrastrukture. Kako se donosi odluka hoće li se graditi (ili migrirati trenutna) infrastruktura na kontejnere i Kuber ili ne?
- Problemi u svijetu oblaka, što nedostaje, zamislimo što će biti sutra.
Razvila se zanimljiva rasprava, mišljenja sudionika su bila toliko različita i izazvala toliko komentara da ih želim podijeliti s vama. Jesti , a u nastavku donosimo sažetak rasprave.
Je li Kubernetes već standard ili odličan marketing?
“Došli smo do njega (Kubernetes. - Urednik) kada još nitko nije znao za to. Dolazili smo kod njega i kad ga nije bilo. Htjeli smo to prije" - Dmitrij Stoljarov
Fotografija s Reddit.com
Prije 5-10 godina postojao je ogroman broj alata, a nije bilo jedinstvenog standarda. Svakih šest mjeseci pojavio se novi proizvod, ili čak više od jednog. Prvo Vagrant, zatim Salt, Chef, Puppet,... “i obnavljate svoju infrastrukturu svakih šest mjeseci. Imate pet administratora koji su stalno zauzeti prepisivanjem konfiguracija,” prisjeća se Andrey Fedorovsky. On vjeruje da su Docker i Kubernetes "istisnuli" ostale. Docker je postao standard u zadnjih pet godina, Kubernetes u zadnje dvije godine. I to je dobro za industriju.
Dmitrij Stoljarov i njegov tim vole Kubera. Željeli su takav alat prije nego što se pojavio, a došli su do njega kada nitko nije znao za njega. Trenutno, zbog pogodnosti, ne preuzimaju klijenta ako razumiju da s njim neće implementirati Kubernetes. U isto vrijeme, prema Dmitryju, tvrtka ima "mnoge divovske uspješne priče o prepravljanju užasne ostavštine."
Kubernetes nije samo orkestracija spremnika, to je sustav upravljanja konfiguracijom s razvijenim API-jem, mrežnom komponentom, L3 balansiranjem i Ingress kontrolerima, što čini relativno lakim upravljanje resursima, skaliranje i apstrahiranje od nižih slojeva infrastrukture.
Nažalost, u našem životu sve moramo platiti. A taj je porez velik, pogotovo ako govorimo o prelasku na Kubernetes tvrtke s razvijenom infrastrukturom, smatra Ivan Kruglov. Mogao je slobodno raditi i u tvrtki s tradicionalnom infrastrukturom i s Kuberom. Glavna stvar je razumjeti karakteristike tvrtke i tržišta. Ali, na primjer, za Evgenija Potapova, koji bi generalizirao Kubernetes na bilo koji alat za orkestraciju spremnika, takvo se pitanje ne postavlja.
Evgeniy je povukao analogiju sa situacijom iz 1990-ih, kada se objektno orijentirano programiranje pojavilo kao način programiranja složenih aplikacija. U to vrijeme rasprava se nastavila i pojavili su se novi alati za podršku OOP-u. Zatim su se pojavile mikrousluge kao način odmaka od monolitnog koncepta. To je pak dovelo do pojave spremnika i alata za upravljanje spremnicima. “Mislim da ćemo uskoro doći u vrijeme kada više neće biti pitanja isplati li se pisati mala mikroservisna aplikacija, ona će biti napisana kao mikroservis po defaultu”, smatra. Isto tako, Docker i Kubernetes će s vremenom postati standardno rješenje bez potrebe za izborom.
Problem baza podataka bez državljanstva
Foto
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. Je li moguće da će se u budućnosti baze podataka promijeniti toliko da će se isporučivati u kutiji, gdje će jedan dio biti orkestriran kroz Docker i Kubernetes, au drugom dijelu infrastrukture, kroz poseban softver, osiguravati dio za pohranu podataka ? Hoće li se baze promijeniti kao proizvod?
Ovaj opis sličan je upravljanju redovima čekanja, ali su zahtjevi za pouzdanošću i sinkronizacijom informacija u tradicionalnim bazama podataka mnogo veći, smatra Andrey. Omjer pogodaka predmemorije u normalnim bazama podataka ostaje na 99%. Ako radnik padne, pokreće se novi, a predmemorija se "zagrijava" od nule. Dok se predmemorija ne zagrije, worker radi sporo, što znači da se ne može učitati korisničkim opterećenjem. Dok nema korisničkog opterećenja, predmemorija se ne zagrijava. To je začarani krug.
Dmitrij se u osnovi ne slaže - kvorumi i dijeljenje rješavaju problem. Ali Andrey inzistira na tome da rješenje nije prikladno za sve. U nekim je situacijama kvorum prikladan, ali dodatno opterećuje mrežu. NoSQL baza podataka nije prikladna u svim slučajevima.
Sudionici 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 ekosustavu. Nemoguće je održati integritet i dosljednost proizvodnih podataka u Kubernetesu. Ovo je temeljna značajka. 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 postojane pohrane podataka izvan Kubernetesa.
Evgeniy prigovara: "Baze u Kuberi gotovo su ruske ili gotovo poslovne ozljede, što je povezano s činjenicom da u Rusiji ne postoji Cloud Adoption." Male ili srednje tvrtke na Zapadu su Cloud. Amazonove RDS baze podataka lakše je koristiti nego sami petljati s Kubernetesom. U Rusiji koriste Kuber “on-premise” i prenose baze na njega kada se pokušavaju riješiti zoološkog vrta.
Dmitrij se također nije složio s izjavom da se u Kubernetesu ne mogu čuvati baze podataka: „Baza se razlikuje od baze. A ako gurate ogromnu relacijsku bazu podataka, onda ni pod kojim uvjetima. Ako gurneš nešto malo i oblačno urođeno, što je mentalno pripremljeno za polu-efemerni život, sve će biti u redu.” Dmitry je također spomenuo da alati za upravljanje bazom podataka nisu spremni ni za Docker ni za Kuber, pa nastaju velike poteškoće.
Ivan je pak siguran da čak i ako apstrahiramo od koncepata stateful i stateless, ekosustav enterprise rješenja u Kubernetesu još nije spreman. S Kuberom je teško održati zakonske i regulatorne zahtjeve. Na primjer, nemoguće je napraviti rješenje za pružanje identiteta gdje su potrebna stroga jamstva identifikacije poslužitelja, sve do hardvera koji je umetnut u poslužitelje. Ovo područje se razvija, ali rješenja još nema.
Sudionici se nisu mogli složiti pa se u ovom dijelu neće donositi zaključci. Navedimo nekoliko praktičnih primjera.
Slučaj 1. Kibernetička sigurnost “megaregulatora” s bazama izvan Kubere
U slučaju razvijenog sustava kibernetičke sigurnosti, upotreba spremnika i orkestracije omogućuje borbu protiv napada i upada. Primjerice, u jednom megaregulatoru Denis i njegov tim implementirali su kombinaciju orkestratora s obučenom SIEM uslugom koja u stvarnom vremenu analizira zapise i utvrđuje proces napada, hakiranja ili kvara. U slučaju napada, pokušaja plasiranja nečega ili u slučaju invazije ransomware virusa, on preko orkestratora preuzima spremnike s aplikacijama brže nego što se one zaraze, odnosno brže nego što ih napadač napadne.
Slučaj 2. Djelomična migracija Booking.com baza podataka u Kubernetes
U Booking.com-u glavna baza podataka je MySQL s asinkronom replikacijom – postoji master i cijela hijerarhija robova. U trenutku kada je Ivan napustio tvrtku, pokrenut je projekt transfera robova koji bi se mogli “upucati” uz određena oštećenja.
Uz glavnu bazu, tu je i instalacija Cassandra s vlastitom orkestracijom, koja je nastala i prije nego što je Kuber ušao u mainstream. U tom smislu nema problema, ali postojan je na lokalnim SSD-ovima. Udaljena pohrana, čak ni unutar istog podatkovnog centra, ne koristi se 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 pohrane, koju je teško "podići" i "zagrijati".
Zbog toga tražilica nije prebačena u Kubernetes, a Ivan ne misli da će u skorije vrijeme biti novih pokušaja. MySQL baza podataka prebačena je napola: samo Robovi, koji se ne boje biti “upucani”. Cassandra se savršeno smjestila.
Izbor infrastrukture kao zadatak bez generalnog rješenja
Foto
Recimo, imamo novu tvrtku, ili tvrtku u kojoj je dio infrastrukture izgrađen na stari način. Godinama gradi plan razvoja infrastrukture. Kako se donosi odluka hoće li se graditi infrastruktura na kontejnerima i Kuberu ili ne?
Iz rasprave su isključene tvrtke koje se bore za nanosekunde. Zdravi konzervativizam se isplati u smislu pouzdanosti, ali još uvijek postoje tvrtke koje bi trebale razmotriti nove pristupe.
Ivan: “Svakako bih sada osnovao tvrtku na oblaku, jednostavno zato što je brže,” iako ne nužno i jeftinije. S razvojem rizičnog kapitalizma startupi nemaju velikih problema s novcem, a glavni zadatak je osvajanje tržišta.
Ivan je mišljenja da razvoj postojeće infrastrukture je kriterij odabira. Ako je u prošlosti bila ozbiljna investicija i ona funkcionira, nema smisla to ponavljati. Ako infrastruktura nije razvijena, a postoje problemi s alatima, sigurnošću i nadzorom, onda ima smisla gledati na 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 samim tim što se vozim u vlaku koji drugi voze, putovat ću puno dalje nego da sjednem u neki drugi vlak u koji sam moram natočiti gorivo.“, kaže Ivan. Kad je tvrtka nova, a zahtjevi za latencijom su deseci milisekundi, onda bi Ivan gledao 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 tvrtku s nekoliko servera Kubera nema smisla,” kaže Andrey. Ali ako planira narasti na stotine poslužitelja ili više, tada su mu potrebni automatizacija i sustav upravljanja resursima. 90% slučajeva isplati se. Štoviše, bez obzira na razinu opterećenja i resursa. Ima smisla da se svi, od startupa do velikih tvrtki s milijunskom publikom, postupno okrenu prema proizvodima za orkestraciju spremnika. "Da, ovo je stvarno budućnost", siguran je Andrej.
Denis je istaknuo dva glavna kriterija - skalabilnost i stabilnost rada. On će odabrati alate koji su najprikladniji za zadatak. “To bi mogao biti noname sastavljen na koljenima, a na sebi ima Nutanix Community Edition. Ovo bi mogao biti drugi redak u obliku aplikacije na Kuberu s bazom podataka na pozadini, koja se replicira i ima specificirane RTO i RPO parametre" (vrijeme oporavka/točka ciljevi - oko).
Evgeniy je identificirao mogući problem s osobljem. Trenutačno na tržištu nema mnogo visokokvalificiranih stručnjaka koji razumiju "utrobu". Dapače, ako je odabrana tehnologija stara, onda je teško zaposliti bilo koga osim sredovječnih ljudi kojima je život dosadan i umoran. Iako drugi sudionici smatraju da je riječ o školovanju kadrova.
Ako postavimo pitanje izbora: pokrenuti malu tvrtku u javnom oblaku s bazama podataka u Amazon RDS-u ili “on premise” s bazama podataka u Kubernetesu, tada je unatoč nekim nedostacima, Amazon RDS postao izbor sudionika.
Budući da većina slušatelja meetupa nije iz “krvavog” poduzeća, dakle distribuirana rješenja su ono čemu trebamo težiti. Sustavi za pohranu podataka moraju biti distribuirani, pouzdani i stvarati latenciju koja se mjeri u jedinicama milisekundi, najviše desetcima“, rezimirao je Andrej.
Procjena korištenja Kubernetesa
Slušatelj Anton Zhbankov postavio je pitanje zamke apologetima Kubernetesa: kako ste odabrali i proveli studiju izvodljivosti? Zašto Kubernetes, zašto ne virtualni strojevi, na primjer?
Foto
Odgovorili su Dmitrij i Ivan. U oba slučaja metodom pokušaja i pogrešaka donesen je slijed odluka, uslijed kojih su oba sudionika stigla u Kubernetes. Sada tvrtke počinju samostalno razvijati softver koji ima smisla prenijeti na Kuber. Ne govorimo o klasičnim sustavima trećih strana, poput 1C. Kubernetes pomaže kada programeri trebaju brzo izraditi izdanja, uz kontinuirano poboljšanje bez prestanka.
Andreyev tim pokušao je stvoriti skalabilni klaster temeljen na virtualnim strojevima. Čvorovi su padali poput domina, što je ponekad dovodilo do kolapsa klastera. “Teoretski, možete ga završiti i poduprijeti rukama, ali je zamorno. A ako na tržištu postoji rješenje koje vam omogućuje da radite izvan okvira, mi ćemo ga rado prihvatiti. I kao rezultat toga smo se zamijenili”, kaže Andrey.
Postoje standardi za takvu analizu i izračun, ali nitko ne može reći koliko su točni na stvarnom hardveru u radu. Za izračune je također važno razumjeti svaki alat i ekosustav, ali to nije moguće.
Što nas čeka
Foto
Kako se tehnologija razvija, pojavljuje se sve više različitih dijelova, a zatim dolazi do faznog prijelaza, pojavljuje se prodavač koji je ubio dovoljno novca da se sve spoji u jednom alatu.
Mislite li da će doći vrijeme kada će postojati alat poput Ubuntua za svijet Linuxa? Možda će jedan alat za kontejnerizaciju i orkestraciju uključivati Kuber. To će olakšati izgradnju lokalnih oblaka.
Odgovor je dao Ivan: “Google sada gradi Anthos - ovo je njihova paketna ponuda koja implementira oblak i uključuje Kuber, Service Mesh, monitoring - sav hardver koji je potreban za on-premise mikroservise.” Skoro smo u budućnosti."
Denis je također spomenuo Nutanix i VMWare s vRealize Suite proizvodom koji se može nositi sa sličnim zadatkom bez kontejnerizacije.
Dmitry je podijelio svoje mišljenje da su smanjenje "boli" i smanjenje poreza dva područja u kojima možemo očekivati poboljšanja.
Ukratko, ističemo sljedeće probleme moderne infrastrukture:
- Troje sudionika odmah je identificiralo problem sa statusom.
- Razni problemi sa sigurnosnom podrškom, uključujući mogućnost da Docker završi s više verzija Pythona, aplikacijskih poslužitelja i komponenti.
Prekomjerna potrošnja, o čemu je bolje razgovarati na zasebnom sastanku.
Izazov učenja jer je orkestracija složen ekosustav.
Čest problem u industriji je zlouporaba alata.Ostali zaključci su na vama. Još uvijek postoji osjećaj da kombinaciji Docker+Kubernetes nije lako postati “centralni” dio sustava. Na primjer, operativni sustavi se prvo instaliraju na hardver, što se ne može reći za kontejnere i orkestraciju. Možda će se u budućnosti operativni sustavi i spremnici spojiti sa softverom za upravljanje oblakom.
FotoIskoristio bih priliku da pozdravim svoju mamu i podsjetim te da imamo Facebook grupu , kanal sa zanimljivim publikacijama s raznih tehnoloških blogova. I moj kanal , gdje govorim o upravljanju razvojem u proizvodnim tvrtkama.
Izvor: www.habr.com