La kompanio URUS provis Kubernetes en malsamaj formoj: sendependa deplojo sur nuda metalo, en Google Cloud, kaj poste transdonis sian platformon al la nubo Mail.ru Cloud Solutions (MCS). Igor Ŝiŝkin rakontas kiel ili elektis novan nuban provizanton kaj kiel ili sukcesis migri al ĝi en rekordo de du horoj (), altranga sistemadministranto ĉe URUS.
Kion faras URUS?
Estas multaj manieroj plibonigi la kvaliton de la urba medio, kaj unu el ili estas fari ĝin ekologie amika. Ĝuste pri tio laboras la kompanio URUS - Smart Digital Services. Ĉi tie ili efektivigas solvojn, kiuj helpas entreprenojn monitori gravajn mediajn indikilojn kaj redukti sian negativan efikon al la medio. Sensiloj kolektas datumojn pri aerkonsisto, brunivelo kaj aliaj parametroj, kaj poste sendas ilin al la unuigita URUS-Ekomon-platformo por analizi kaj fari rekomendojn.
Kiel funkcias URUS de interne
Tipa kliento de URUS estas firmao situanta en aŭ proksime de loĝkvartalo. Ĉi tio povus esti fabriko, haveno, fervoja deponejo aŭ iu ajn alia instalaĵo. Se nia kliento jam ricevis averton, estis monpunita pro media poluado, aŭ volas fari malpli da bruo, redukti la kvanton de malutilaj ellasoj, li venas al ni, kaj ni jam proponas al li pretan solvon por media monitorado.
La monitora grafikaĵo de koncentriĝo de H2S montras regulajn noktajn emisiojn de proksima planto
La aparatoj, kiujn ni uzas ĉe URUS, enhavas plurajn sensilojn, kiuj kolektas informojn pri la enhavo de iuj gasoj, bruniveloj kaj aliaj datumoj por taksi la median situacion. La preciza nombro da sensiloj ĉiam estas determinita de la specifa tasko.
Depende de la specifaĵoj de la mezuradoj, aparatoj kun sensiloj povas esti lokitaj sur la muroj de konstruaĵoj, poloj kaj aliaj arbitraj lokoj. Ĉiu tia aparato kolektas informojn, agregas ĝin kaj sendas ĝin al la datumoj ricevantaj enirejon. Tie ni konservas la datumojn por longdaŭra konservado kaj antaŭtraktas ĝin por posta analizo. La plej simpla ekzemplo de tio, kion ni ricevas kiel rezulto de analizo, estas la aerkvalita indekso, ankaŭ konata kiel AQI.
Paralele, multaj aliaj servoj funkcias en nia platformo, sed ili estas ĉefe de servo-naturo. Ekzemple, la sciiga servo sendas sciigojn al klientoj se iu el la monitoritaj parametroj (ekzemple, CO2 enhavo) superas la permeseblan valoron.
Kiel ni konservas datumojn. La rakonto de Kubernetes sur nuda metalo
La projekto pri media monitorado de URUS havas plurajn datumstokejojn. En unu ni konservas "krudajn" datumojn - kion ni ricevis rekte de la aparatoj mem. Ĉi tiu stokado estas "magneta" bendo, kiel sur malnovaj kasedoj, kun historio de ĉiuj indikiloj. La dua speco de stokado estas uzata por antaŭprocesitaj datumoj - datumoj de aparatoj, riĉigitaj per metadatenoj pri konektoj inter sensiloj kaj la legaĵoj de la aparatoj mem, aliĝo al organizoj, lokoj, ktp. Ĉi tiu informo permesas dinamike taksi kiel aparta indikilo havas. ŝanĝiĝis dum certa tempodaŭro. Ni uzas la "krudan" datumstokadon, interalie, kiel sekurkopion kaj por restarigi antaŭprilaboritajn datumojn, se tia bezono ŝprucas.
Kiam ni serĉis solvi nian stokan problemon antaŭ pluraj jaroj, ni havis du platformelektojn: Kubernetes kaj OpenStack. Sed ĉar ĉi-lasta aspektas sufiĉe monstra (nur rigardu ĝian arkitekturon por konvinkiĝi pri tio), ni decidis por Kubernetes. Alia argumento en ĝia favoro estis la relative simpla softvarkontrolo, la kapablo pli flekseble tranĉi eĉ aparatarnodojn laŭ rimedoj.
Paralele al regado de Kubernetes mem, ni ankaŭ studis manierojn konservi datumojn, dum ni konservis nian tutan stokadon en Kubernetes per nia propra aparataro, ni ricevis bonegan kompetentecon. Ĉio, kion ni tiam vivis sur Kubernetes: statoplena stokado, monitora sistemo, CI/KD. Kubernetes fariĝis tute-en-unu platformo por ni.
Sed ni volis labori kun Kubernetes kiel servo, kaj ne okupiĝi pri ĝia subteno kaj evoluo. Krome, ni ne ŝatis kiom kostis al ni konservi ĝin sur nuda metalo, kaj ni bezonis disvolviĝon konstante! Ekzemple, unu el la unuaj taskoj estis integri Kubernetes Ingress-regilojn en la retan infrastrukturon de nia organizo. Ĉi tio estas maloportuna tasko, precipe konsiderante, ke tiutempe nenio estis preta por programa administrado de rimedoj kiel DNS-rekordoj aŭ la asigno de IP-adresoj. Poste ni komencis eksperimenti kun ekstera datumstokado. Ni neniam atingis efektivigi la PVC-regilon, sed eĉ tiam evidentiĝis, ke tio estas granda laborkampo, kiu postulas dediĉitajn specialistojn.
Ŝanĝi al Google Cloud Platform estas provizora solvo
Ni rimarkis, ke ĉi tio ne povas daŭri, kaj movis niajn datumojn de nuda metalo al Google Cloud Platform. Fakte, tiutempe ne estis multaj interesaj opcioj por rusa kompanio: krom Google Cloud Platform, nur Amazon ofertis similan servon, sed ni ankoraŭ decidis por la solvo de Guglo. Tiam ĝi ŝajnis al ni pli ekonomie profita, pli proksime al Upstream, sen mencii la fakton, ke Google mem estas speco de PoC Kubernetes en Produktado.
La unua grava problemo aperis ĉe la horizonto dum nia klientbazo kreskis. Kiam ni devis konservi personajn datumojn, ni alfrontis elekton: aŭ ni laboras kun Guglo kaj malobservas rusajn leĝojn, aŭ ni serĉas alternativon en la Rusa Federacio. La elekto, entute, estis antaŭvidebla. 🙂
Kiel ni vidis la idealan nuban servon
Je la komenco de la serĉo, ni jam sciis, kion ni volas ricevi de la estonta nuba provizanto. Kiun servon ni serĉis:
- Rapida kaj fleksebla. Tia, ke ni povas rapide aldoni novan nodon aŭ disfaldi ion iam ajn.
- Nekosta. Ni tre zorgis pri la financa afero, ĉar ni estis limigitaj en rimedoj. Ni jam sciis, ke ni volas labori kun Kubernetes, kaj nun la tasko estis minimumigi ĝian koston por pliigi aŭ almenaŭ konservi la efikecon uzi ĉi tiun solvon.
- Aŭtomatigita. Ni planis labori kun la servo per la API, sen administrantoj kaj telefonvokoj aŭ situacioj, kie ni bezonas mane levi plurajn dekduojn da nodoj en kriz-reĝimo. Ĉar la plej multaj el niaj procezoj estas aŭtomatigitaj, ni atendis la samon de la nuba servo.
- Kun serviloj en la Rusa Federacio. Kompreneble, ni planis plenumi la rusan leĝaron kaj tiun saman 152-FZ.
Tiutempe, estis malmultaj Kubernetes aaS-provizantoj en Rusio, kaj elektante provizanton, estis grave por ni ne kompromiti niajn prioritatojn. La teamo de Mail.ru Cloud Solutions, kun kiu ni komencis labori kaj daŭre kunlaboras, provizis al ni plene aŭtomatigitan servon, kun API-subteno kaj oportuna kontrolpanelo kiu inkluzivas Horizon - per ĝi ni povus rapide levi arbitran nombron da nodoj.
Kiel ni sukcesis migri al MCS en du horoj
En tiaj movoj, multaj kompanioj alfrontas malfacilaĵojn kaj malsukcesojn, sed en nia kazo ne estis. Ni estis bonŝancaj: ĉar ni jam laboris pri Kubernetes antaŭ ol la migrado komenciĝis, ni simple korektis tri dosierojn kaj lanĉis niajn servojn sur la nova nuba platformo, MCS. Mi memorigu vin, ke tiam ni finfine forlasis nudan metalon kaj vivis sur la Google Cloud Platform. Sekve, la movo mem prenis ne pli ol du horojn, krom iom pli da tempo (ĉirkaŭ unu horo) estis elspezita kopiante datumojn de niaj aparatoj. Tiam ni jam uzis Spinnaker (plurnuba KD-servo por provizi Continuous Delivery). Ni ankaŭ rapide aldonis ĝin al la nova areto kaj daŭre funkciis kiel kutime.
Danke al la aŭtomatigo de evoluaj procezoj kaj CI/KD, Kubernetes ĉe URUS estas pritraktata de unu specialisto (kaj tio estas mi). Iam alia sistemadministranto laboris kun mi, sed tiam montriĝis, ke ni jam aŭtomatigis la tutan ĉefan rutinon kaj estis pli kaj pli da taskoj flanke de nia ĉefa produkto kaj estis senco direkti rimedojn al ĉi tio.
Ni ricevis tion, kion ni atendis de la nuba provizanto, ĉar ni komencis kunlaboron sen iluzioj. Se estis iuj okazaĵoj, ili estis plejparte teknikaj kaj tiuj, kiuj povus facile esti klarigitaj per la relativa freŝeco de la servo. La ĉefa afero estas, ke la MCS-teamo rapide forigas mankojn kaj rapide respondas demandojn en mesaĝistoj.
Se mi komparas mian sperton kun Google Cloud Platform, en ilia kazo mi eĉ ne sciis, kie estas la sugesta butono, ĉar simple ne necesis ĝin. Kaj se iuj problemoj okazis, Guglo mem sendis sciigojn unuflanke. Sed en la kazo de MCS, mi pensas, ke la granda avantaĝo estas, ke ili estas kiel eble plej proksimaj al rusaj klientoj - kaj geografie kaj mense.
Kiel ni vidas labori kun nuboj estonte
Nun nia laboro estas proksime ligita al Kubernetes, kaj ĝi tute konvenas al ni el la vidpunkto de infrastrukturaj taskoj. Tial ni ne planas migri de ĝi ie ajn, kvankam ni konstante enkondukas novajn praktikojn kaj servojn por simpligi rutinajn taskojn kaj aŭtomatigi novajn, pliigi la stabilecon kaj fidindecon de servoj... Ni nun lanĉas la servon Chaos Monkey (specife). , ni uzas chaoskube, sed ĉi tio ne ŝanĝas la koncepton: ), kiu estis origine kreita de Netflix. Chaos Monkey faras unu simplan aferon: ĝi forigas hazardan Kubernetes-podon en hazarda tempo. Ĉi tio estas necesa por ke nia servo vivu normale kun la nombro da okazoj n–1, do ni trejnas nin por esti pretaj por ajnaj problemoj.
Nun mi vidas la uzon de triaj solvoj - la samaj nubaj platformoj - kiel la sola ĝusta afero por junaj kompanioj. Kutime, komence de sia vojaĝo, ili estas limigitaj en rimedoj, kaj homaj kaj financaj, kaj konstrui kaj konservi sian propran nubon aŭ datumcentron estas tro multekostaj kaj laborintensaj. Nubaj provizantoj permesas vin minimumigi ĉi tiujn kostojn; vi povas rapide akiri de ili la rimedojn necesajn por la funkciado de servoj ĉi tie kaj nun, kaj pagi por ĉi tiuj rimedoj post la fakto. Koncerne la firmaon URUS, ni restos fidelaj al Kubernetes en la nubo nuntempe. Sed kiu scias, ni eble devos vastigi geografie, aŭ efektivigi solvojn bazitajn sur iuj specifaj ekipaĵoj. Aŭ eble la kvanto de konsumitaj rimedoj pravigos propran Kubernetes sur nuda metalo, kiel en la bonaj tempoj. 🙂
Kion ni lernis laborante kun nubaj servoj
Ni komencis uzi Kubernetes sur nuda metalo, kaj eĉ tie ĝi estis bona laŭ sia maniero. Sed ĝiaj fortoj estis malkaŝitaj ĝuste kiel aaS-komponento en la nubo. Se vi fiksas celon kaj aŭtomatigas ĉion kiel eble plej multe, vi povos eviti vendiston-enŝlosadon kaj moviĝi inter nubaj provizantoj daŭros kelkajn horojn, kaj la nervaj ĉeloj restos ĉe ni. Ni povas konsili aliajn kompaniojn: se vi volas lanĉi vian propran (nuban) servon, havante limigitajn rimedojn kaj maksimuman rapidecon por disvolviĝo, komencu tuj luante nubajn rimedojn, kaj konstruu vian datumcentron post kiam Forbes skribas pri vi.
fonto: www.habr.com