Fine de majo okazigis retan kunvenon pri la temo . Ni parolis pri ujoj, Kubernetes kaj orkestrado principe, kriterioj por elekti infrastrukturon kaj multe pli. Partoprenantoj dividis kazojn de sia propra praktiko.
Partoprenantoj:
- Evgeniy Potapov, Ĉefoficisto de ITSumma. Pli ol duono de ĝiaj klientoj aŭ jam moviĝas aŭ volas ŝanĝi al Kubernetes.
- Dmitry Stolyarov, CTO "Flant". Havas 10+ jarojn da sperto laboranta kun ujsistemoj.
- Denis Remchukov (alinome Eric Oldmann), COO argotech.io, eks-RAO UES. Li promesis paroli pri kazoj en la "sanga" entrepreno.
- Andrey Fedorovsky, CTO "News360.com"Post aĉetado de la kompanio de alia ludanto, li respondecas pri kelkaj ML kaj AI-projektoj kaj infrastrukturoj.
- Ivan Kruglov, sisteminĝeniero, eks-Booking.com.La sama persono, kiu faris multon kun Kubernetes per siaj propraj manoj.
Temoj:
- Enrigardoj de partoprenantoj pri ujoj kaj instrumentado (Docker, Kubernetes, ktp.); kio estis provita en praktiko aŭ analizita.
- Kazo: La firmao konstruas infrastrukturan disvolvan planon dum jaroj. Kiel estas la decido ĉu konstrui (aŭ migri la nunan) infrastrukturon al ujoj kaj Kuber aŭ ne?
- Problemoj en la nubo-denaska mondo, kio mankas, ni imagu, kio okazos morgaŭ.
Sekvis interesa diskuto, la opinioj de la partoprenantoj estis tiel malsamaj kaj kaŭzis tiom da komentoj, ke mi volas kunhavigi ilin kun vi. Manĝu , kaj sube estas resumo de la diskuto.
Ĉu Kubernetes jam estas norma aŭ bonega merkatado?
“Ni venis al ĝi (Kubernetes. - Red.) kiam neniu ankoraŭ sciis pri ĝi. Ni venis al li eĉ kiam li ne estis tie. Ni deziris ĝin antaŭe" - Dmitrij Stolyarov
Foto de Reddit.com
Antaŭ 5-10 jaroj ekzistis grandega nombro da iloj, kaj ne ekzistis ununura normo. Ĉiujn ses monatojn aperis nova produkto, aŭ eĉ pli ol unu. Unue Vaganto, poste Salo, Kuiristo, Marioneto,... “kaj vi rekonstruas vian infrastrukturon ĉiujn ses monatojn. Vi havas kvin administrantojn, kiuj konstante okupiĝas pri reverkado de agordoj,” rememoras Andrej Fedorovsky. Li kredas, ke Docker kaj Kubernetes "forpuŝis" la reston. Docker fariĝis normo en la lastaj kvin jaroj, Kubernetes en la lastaj du jaroj. Kaj tio estas bona por la industrio..
Dmitry Stolyarov kaj lia teamo amas Kuber. Ili deziris tian ilon antaŭ ol ĝi aperis, kaj venis al ĝi kiam neniu sciis pri ĝi. Nuntempe, pro konvenaj kialoj, ili ne prenas klienton se ili komprenas, ke ili ne efektivigos Kubernetes kun li. Samtempe, laŭ Dmitry, la kompanio havas "multajn gigantajn sukceshistoriojn pri refari la teruran heredaĵon."
Kubernetes ne estas nur kontenera orkestrado, ĝi estas agorda administra sistemo kun evoluinta API, interkonekta komponanto, L3-balancado kaj Ingress-regiloj, kio faras relative facile administri rimedojn, skalon kaj abstraktadon de la malsuperaj tavoloj de la infrastrukturo.
Bedaŭrinde, en nia vivo ni devas pagi por ĉio. Kaj ĉi tiu imposto estas granda, precipe se ni parolas pri la transiro al Kubernetes de kompanio kun evoluinta infrastrukturo, kiel kredas Ivan Kruglov. Li povis libere labori kaj en firmao kun tradicia infrastrukturo kaj kun Kuber. La ĉefa afero estas kompreni la karakterizaĵojn de la kompanio kaj la merkato. Sed, ekzemple, por Evgeny Potapov, kiu ĝeneraligus Kubernetes al iu ajn uja orkestra ilo, tia demando ne ŝprucas.
Evgeniy desegnis analogecon kun la situacio en la 1990-aj jaroj, kiam objekt-orientita programado aperis kiel maniero de programado de kompleksaj aplikoj. En tiu tempo, la debato daŭris kaj novaj iloj aperis por subteni OOP. Tiam mikroservoj aperis kiel maniero malproksimiĝi de la monolita koncepto. Ĉi tio siavice kaŭzis la aperon de ujoj kaj iloj pri kontenera administrado. "Mi pensas, ke ni baldaŭ venos al tempo, kiam ne estos demando pri ĉu indas skribi malgrandan mikroservan aplikaĵon, ĝi estos skribita kiel mikroservo defaŭlte," li kredas. Same, Docker kaj Kubernetes eventuale fariĝos la norma solvo sen bezono de elekto.
La problemo de datumbazoj en sennacia
Foto de
Nuntempe ekzistas multaj receptoj por funkcii datumbazojn en Kubernetes. Eĉ kiel apartigi la parton kiu funkcias kun la I/O-disko de, kondiĉe, la aplika parto de la datumbazo. Ĉu eblas, ke estonte la datumbazoj tiom ŝanĝiĝos, ke ili estos liveritaj en skatolo, kie unu parto estos orkestrata per Docker kaj Kubernetes, kaj en alia parto de la infrastrukturo, per aparta programaro, la konserva parto estos provizita. ? Ĉu la bazoj ŝanĝiĝos kiel produkto?
Ĉi tiu priskribo similas al atendovicadministrado, sed la postuloj por fidindeco kaj sinkronigado de informoj en tradiciaj datumbazoj estas multe pli altaj, opinias Andrey. Cache-trafproporcio en normalaj datumbazoj restas ĉe 99%. Se laboristo falas, nova estas lanĉita, kaj la kaŝmemoro "varmiĝas" de nulo. Ĝis la kaŝmemoro estas varmigita, la laboristo funkcias malrapide, kio signifas, ke ĝi ne povas esti ŝarĝita kun uzantŝarĝo. Dum ne estas uzantŝarĝo, la kaŝmemoro ne varmiĝas. Ĝi estas malvirta cirklo.
Dmitry esence malkonsentas - kvorumoj kaj sharding solvas la problemon. Sed Andrey insistas, ke la solvo ne taŭgas por ĉiuj. En iuj situacioj, kvorumo taŭgas, sed ĝi metas plian ŝarĝon sur la reto. NoSQL-datumbazo ne taŭgas en ĉiuj kazoj.
La renkontiĝpartoprenantoj estis dividitaj en du tendarojn.
Denis kaj Andrey argumentas, ke ĉio, kio estas skribita al disko - datumbazoj kaj tiel plu - estas neeble fari en la nuna Kuber-ekosistemo. Estas neeble konservi la integrecon kaj konsistencon de produktadaj datumoj en Kubernetes. Ĉi tio estas fundamenta trajto. Solvo: hibrida infrastrukturo.
Eĉ modernaj nubaj denaskaj datumbazoj kiel MongoDB kaj Cassandra, aŭ mesaĝaj atendovicoj kiel Kafka aŭ RabbitMQ, postulas konstantajn datumbutikojn ekster Kubernetes.
Evgeniy kontraŭas: "La bazoj en Kubera estas preskaŭ rusa, aŭ preskaŭ-entreprena vundo, kiu rilatas al la fakto, ke ne ekzistas Nuba Adopcio en Rusio." Malgrandaj aŭ mezgrandaj kompanioj en la Okcidento estas Nubo. Amazon RDS-datumbazoj estas pli facile uzeblaj ol mem tuŝi Kubernetes. En Rusio ili uzas Kuber "surloke" kaj transdonas bazojn al ĝi kiam ili provas forigi la zoon.
Dmitry ankaŭ malkonsentis kun la deklaro, ke neniuj datumbazoj povas esti konservitaj en Kubernetes: "Bazo diferencas de bazo. Kaj se vi puŝas gigantan rilatan datumbazon, tiam sub neniuj cirkonstancoj. Se vi puŝas ion malgrandan kaj nuban indiĝenan, kiu estas mense preparita por duonefemera vivo, ĉio estos en ordo.” Dmitry ankaŭ menciis, ke iloj pri administrado de datumbazoj ne estas pretaj nek por Docker nek Kuber, do ekestas grandaj malfacilaĵoj.
Ivan, siavice, certas, ke eĉ se ni abstraktas de la konceptoj de ŝtata kaj sennacia, la ekosistemo de entreprenaj solvoj en Kubernetes ankoraŭ ne estas preta. Kun Kuber, estas malfacile konservi leĝdonajn kaj reguligajn postulojn. Ekzemple, estas neeble fari identecprovizo-solvon kie striktaj servilaj identiggarantioj estas postulataj, ĝuste ĝis la aparataro kiu estas enigita en la servilojn. Ĉi tiu areo disvolviĝas, sed ankoraŭ ne ekzistas solvo.
La partoprenantoj ne povis konsenti, do neniuj konkludoj estos eltiritaj en ĉi tiu parto. Ni donu kelkajn praktikajn ekzemplojn.
Kazo 1. Cibersekureco de "mega-reguligilo" kun bazoj ekster Kubera
En la kazo de evoluinta cibersekureca sistemo, la uzo de ujoj kaj orkestrado ebligas batali kontraŭ atakoj kaj entrudiĝoj. Ekzemple, en unu mega-reguligisto, Denis kaj lia teamo efektivigis kombinaĵon de orkestranto kun trejnita SIEM-servo, kiu analizas protokolojn en reala tempo kaj determinas la procezon de atako, piratado aŭ fiasko. Okaze de atako, provo meti ion, aŭ okaze de invado de ransomware viruso, ĝi, per la orkestranto, prenas ujojn kun aplikoj pli rapide ol ili infektiĝas, aŭ pli rapide ol la atakanto atakas ilin.
Kazo 2. Parta migrado de Booking.com datumbazoj al Kubernetes
En Booking.com, la ĉefa datumbazo estas MySQL kun nesinkrona reproduktado - ekzistas mastro kaj tuta hierarkio de sklavoj. Antaŭ la tempo Ivan forlasis la firmaon, projekto estis lanĉita por translokigi sklavojn kiuj povus esti "pafitaj" kun certa difekto.
Aldone al la ĉefa bazo, ekzistas Kasandra instalaĵo kun memskribita instrumentado, kiu estis skribita eĉ antaŭ ol Kuber eniris la ĉeftendencon. Ne estas problemoj ĉi-rilate, sed ĝi persistas sur lokaj SSD-oj. Fora stokado, eĉ ene de la sama datumcentro, ne estas uzata pro la problemo de alta latenteco.
La tria klaso de datumbazoj estas la serĉservo Booking.com, kie ĉiu serva nodo estas datumbazo. Provoj transdoni la serĉservon al Kuber malsukcesis, ĉar ĉiu nodo estas 60-80 GB de loka stokado, kiu estas malfacile "levi" kaj "varmiĝi".
Kiel rezulto, la serĉilo ne estis translokigita al Kubernetes, kaj Ivan ne pensas, ke estos novaj provoj en la proksima estonteco. La datumbazo MySQL estis translokigita duone: nur Sklavoj, kiuj ne timas esti "pafitaj". Kasandra ekloĝis perfekte.
Elekto de infrastrukturo kiel tasko sen ĝenerala solvo
Foto de
Ni diru, ke ni havas novan kompanion, aŭ kompanion, kie parto de la infrastrukturo estas konstruita laŭ la malnova maniero. Ĝi konstruas infrastrukturan disvolvan planon dum jaroj. Kiel estas la decido ĉu konstrui infrastrukturon sur ujoj kaj Kuber aŭ ne?
Firmaoj kiuj batalas por nanosekundoj estas ekskluditaj de la diskuto. Sana konservativismo pagas laŭ fidindeco, sed ankoraŭ ekzistas kompanioj, kiuj devus konsideri novajn alirojn.
Ivan: "Mi certe ekus kompanion en nubo nun, simple ĉar ĝi estas pli rapida", kvankam ne nepre pli malmultekosta. Kun la disvolviĝo de riskkapitalismo, noventreprenoj ne havas grandajn problemojn kun mono, kaj la ĉefa tasko estas konkeri la merkaton.
Ivano opinias ke la evoluo de la nuna infrastrukturo estas elekta kriterio. Se estis serioza investo en la pasinteco, kaj ĝi funkcias, tiam ne utilas refari ĝin. Se la infrastrukturo ne estas evoluigita, kaj estas problemoj kun iloj, sekureco kaj monitorado, tiam havas sencon rigardi distribuitan infrastrukturon.
La imposto devos ĉiukaze pagi, kaj Ivano pagus tiun, kiu permesis al li pagi malpli en la estonteco. "Ĉar simple pro tio, ke mi veturas en trajno, kiun aliaj movas, mi vojaĝos multe pli ol se mi sidos en alia trajno, en kiun mi devas mem enmeti fuelon.“diras Ivano. Kiam la kompanio estas nova, kaj la latenciaj postuloj estas dekoj da milisekundoj, tiam Ivan rigardus al la "funkciigistoj" en kiuj klasikaj datumbazoj estas "envolvitaj" hodiaŭ. Ili levas reproduktadĉenon, kiu ŝanĝas sin en kazo de malsukceso, ktp...
Por malgranda kompanio kun kelkaj serviloj, Kubera ne havas sencon,” diras Andrey. Sed se ĝi planas kreski al centoj da serviloj aŭ pli, tiam ĝi bezonas aŭtomatigon kaj sistemon pri administrado de rimedoj. 90% de kazoj valoras la koston. Krome, sendepende de la nivelo de ŝarĝo kaj rimedoj. Ĝi havas sencon por ĉiuj, de noventreprenoj ĝis grandaj kompanioj kun milionoj da publiko, iom post iom rigardi al ujinstrumentaj produktoj. "Jes, ĉi tio vere estas la estonteco," Andrey estas certa.
Denis skizis du ĉefajn kriteriojn - skaleblo kaj stabileco de operacio. Li elektos la ilojn plej taŭgajn por la tasko. “Ĝi povus esti nenomo kunvenita sur viaj genuoj, kaj ĝi havas Nutanix Community Edition sur ĝi. Ĉi tio povus esti dua linio en formo de aplikaĵo ĉe Kuber kun datumbazo sur la malantaŭo, kiu estas reproduktita kaj specifita RTO kaj RPO-parametroj" (reakiro tempo/punktaj celoj - ĉ.).
Evgeniy identigis eblan problemon kun dungitaro. Nuntempe, ne estas multaj tre kvalifikitaj specialistoj sur la merkato, kiuj komprenas la "kuraĝon". Efektive, se la elektita teknologio estas malnova, tiam estas malfacile dungi iun ajn krom mezaĝaj homoj, kiuj estas enuigitaj kaj lacaj de vivo. Kvankam aliaj partoprenantoj opinias, ke tio estas demando pri trejnado de dungitoj.
Se ni metas la demandon pri elekto: lanĉi malgrandan kompanion en la Publika Nubo kun datumbazoj en Amazon RDS aŭ "surloke" kun datumbazoj en Kubernetes, tiam malgraŭ iuj mankoj, Amazon RDS fariĝis la elekto de la partoprenantoj.
Ĉar la plimulto de la renkontiĝo-aŭskultantoj ne estas de la "sanga" entrepreno, do distribuitaj solvoj estas kion ni devus strebi. Datenstokaj sistemoj devas esti distribuitaj, fidindaj kaj krei latentecon mezurita en unuoj de milisekundoj, dekoj maksimume“, resumis Andreo.
Takso de Kubernetes-Uzado
Aŭskultanto Anton Ĵbankov faris kaptilan demandon al la apologiistoj de Kubernetes: kiel vi elektis kaj faris realigeblan studon? Kial Kubernetes, kial ne virtualaj maŝinoj, ekzemple?
Foto de
Dmitrij kaj Ivano respondis al ĝi. En ambaŭ kazoj, per provo kaj eraro, vico da decidoj estis farita, kiel rezulto de kiuj ambaŭ partoprenantoj alvenis al Kubernetes. Nun entreprenoj komencas sendepende evoluigi programaron, kiu havas sencon translokiĝi al Kuber. Ni ne parolas pri klasikaj triaj sistemoj, kiel 1C. Kubernetes helpas kiam programistoj bezonas rapide fari eldonojn, kun senhalta Daŭra Pliboniĝo.
La teamo de Andrey provis krei skaleblan areton bazitan sur virtualaj maŝinoj. Nodoj falis kiel domeno, kio foje kaŭzis disfalon de la areto. “Teorie, vi povas fini ĝin kaj subteni ĝin per viaj manoj, sed ĝi estas teda. Kaj se ekzistas solvo sur la merkato, kiu permesas vin labori ekstere de la skatolo, tiam ni feliĉas iri por ĝi. Kaj ni ŝanĝis kiel rezulto,” diras Andrey.
Estas normoj por tia analizo kaj kalkulo, sed neniu povas diri kiom precizaj ili estas sur reala aparataro funkcianta. Por kalkuloj, ankaŭ gravas kompreni ĉiun ilon kaj ekosistemon, sed tio ne eblas.
Kio atendas nin
Foto de
Dum teknologio evoluas, aperas pli kaj pli malsimilaj pecoj, kaj tiam okazas faza transiro, aperas vendisto, kiu mortigis sufiĉe da pasto por ke ĉio kuniĝu en ununura ilo.
Ĉu vi pensas, ke venos tempo, kiam estos ilo kiel Ubuntu por la Linukso-mondo? Eble unuopa kontenerigo kaj orkestra ilo inkluzivos Kuber. Ĝi faciligos konstrui surlokaj nuboj.
La respondo estis donita de Ivan: "Google nun konstruas Anthos - ĉi tio estas ilia pakita oferto, kiu disvastigas la nubon kaj inkluzivas Kuber, Service Mesh, monitoradon - la tutan aparataron necesan por surlokaj mikroservoj." Ni estas preskaŭ en la estonteco."
Denis ankaŭ menciis Nutanix kaj VMWare kun la produkto vRealize Suite, kiu povas trakti similan taskon sen kontenerigo.
Dmitry dividis sian opinion, ke redukti la "doloron" kaj redukti impostojn estas du areoj, kie ni povas atendi plibonigojn.
Por resumi la diskuton, ni emfazas la sekvajn problemojn de moderna infrastrukturo:
- Tri partoprenantoj tuj identigis problemon kun stateful.
- Diversaj sekurecaj subtenaj problemoj, inkluzive de la ebleco, ke Docker finiĝos kun pluraj versioj de Python, aplikaĵoserviloj kaj komponantoj.
Trospezado, pri kio estas pli bone diskutita en aparta kunveno.
Lerna defio kiel instrumentado estas kompleksa ekosistemo.
Ofta problemo en la industrio estas la misuzo de iloj.La ceteraj konkludoj dependas de vi. Ankoraŭ estas sento, ke ne estas facile por la kombinaĵo Docker+Kubernetes fariĝi "centra" parto de la sistemo. Ekzemple, operaciumoj unue estas instalitaj sur aparataro, kio ne povas esti dirita pri ujoj kaj instrumentado. Eble estonte, operaciumoj kaj ujoj kunfandiĝos kun programaro pri nuba administrado.
Foto deMi ŝatus profiti ĉi tiun okazon por saluti mian patrinon kaj memorigi vin, ke ni havas Fejsbukan grupon , kanalo kun interesaj publikaĵoj de diversaj teknikaj blogoj. Kaj mia kanalo , kie mi parolas pri administrado de evoluo en produktaj kompanioj.
fonto: www.habr.com