Per daugelį metų 300 milijonų Pinterest vartotojų sukūrė daugiau nei 200 milijardų kaiščių daugiau nei 4 milijarduose lentų. Siekdamas aptarnauti šią vartotojų armiją ir didžiulę turinio bazę, portalas sukūrė tūkstančius paslaugų – nuo mikropaslaugų, kurias gali valdyti keli procesoriai, iki milžiniškų monolitų, veikiančių visame virtualių mašinų parke. Ir tada atėjo momentas, kai įmonės akys užkliuvo ant k8s. Kodėl „kubas“ gerai atrodė „Pinterest“? Sužinosite apie tai iš mūsų naujausio straipsnio vertimo iš .
Taigi, šimtai milijonų vartotojų ir šimtai milijardų smeigtukų. Siekdami aptarnauti šią vartotojų armiją ir didžiulę turinio bazę, sukūrėme tūkstančius paslaugų – nuo mikropaslaugų, kurias gali valdyti keli procesoriai, iki milžiniškų monolitų, veikiančių ištisuose virtualių mašinų parkuose. Be to, turime įvairių sistemų, kurioms taip pat gali prireikti procesoriaus, atminties arba I/O prieigos.
Prižiūrėdama šį įrankių zoologijos sodą, kūrimo komanda susiduria su daugybe iššūkių:
- Nėra vienodo būdo, kaip inžinieriai galėtų valdyti gamybos aplinką. Be pilietybės teikiamos paslaugos, „Stateful“ paslaugos ir aktyviai vystomi projektai yra pagrįsti visiškai skirtingomis technologijomis. Tai paskatino sukurti visą inžinierių mokymo kursą, be to, labai apsunkina mūsų infrastruktūros komandos darbą.
- Kūrėjai, turintys savo virtualių mašinų parką, sukuria didžiulę naštą vidiniams administratoriams. Dėl to tokios paprastos operacijos kaip OS ar AMI atnaujinimas trunka savaites ir mėnesius. Tai padidina darbo krūvį iš pažiūros visiškai kasdienėse situacijose.
- Sunkumai kuriant pasaulinius infrastruktūros valdymo įrankius kartu su esamais sprendimais. Situaciją dar labiau apsunkina tai, kad rasti virtualių mašinų savininkus nėra lengva. Tai yra, mes nežinome, ar šiuos pajėgumus galima saugiai išgauti, kad galėtume veikti kitose mūsų infrastruktūros dalyse.
Konteinerių orkestravimo sistemos yra būdas suvienodinti darbo krūvio valdymą. Jie atveria duris didesniam plėtros greičiui ir supaprastina infrastruktūros valdymą, nes visi projekte dalyvaujantys ištekliai valdomi vienoje centralizuotoje sistemoje.
1 pav. Infrastruktūros prioritetai (patikimumas, kūrėjo produktyvumas ir efektyvumas).
„Pinterest“ debesų valdymo platformos komanda atrado K8 2017 m. Iki pirmojo 2017 m. pusmečio dokumentavome daugumą savo gamybos galimybių, įskaitant API ir visus žiniatinklio serverius. Po to atlikome išsamų įvairių konteinerių sprendimų derinimo, grupių kūrimo ir darbo su jais sistemų vertinimą. 2017 m. pabaigoje nusprendėme naudoti Kubernetes. Jis buvo gana lankstus ir plačiai palaikomas kūrėjų bendruomenėje.
Iki šiol sukūrėme savo klasterio įkrovos įrankius, pagrįstus Kops, ir perkėlėme esamus infrastruktūros komponentus, tokius kaip tinklai, sauga, metrika, registravimas, tapatybės valdymas ir srautas į Kubernetes. Taip pat savo ištekliui įdiegėme darbo krūvio modeliavimo sistemą, kurios sudėtingumas slepiamas nuo kūrėjų. Dabar orientuojamės į klasterio stabilumo užtikrinimą, jo mastelį ir naujų klientų prijungimą.
Kubernetes: Pinterest būdas
Pradedant naudotis „Kubernetes“ „Pinterest“ platforma, kuri mūsų inžinieriams patiktų, kilo daug iššūkių.
Kaip didelė įmonė, daug investavome į infrastruktūros įrankius. Pavyzdžiai: saugos įrankiai, kurie tvarko sertifikatus ir raktų paskirstymą, srauto valdymo komponentus, paslaugų aptikimo sistemas, matomumo komponentus ir žurnalų bei metrikų siuntimo komponentus. Visa tai buvo surinkta ne veltui: praėjome įprastą bandymų ir klaidų kelią, todėl norėjome integruoti visą šią įrangą į naują Kubernetes infrastruktūrą, o ne išradinėti seną ratą naujoje platformoje. Šis metodas apskritai supaprastino perkėlimą, nes visas programų palaikymas jau yra ir jo nereikia kurti nuo nulio.
Kita vertus, apkrovos prognozavimo modelių pačiame „Kubernetes“ (tokių kaip diegimas, užduotys ir „Daemon“ rinkiniai) mūsų projektui nepakanka. Šios naudojimo problemos yra didžiulės kliūtys pereiti prie „Kubernetes“. Pavyzdžiui, girdėjome, kad paslaugų kūrėjai skundžiasi dėl trūkstamų arba neteisingų prisijungimo nustatymų. Taip pat susidūrėme su netinkamu šablonų variklių naudojimu, kai buvo sukurta šimtai kopijų su ta pačia specifikacija ir užduotimi, o tai sukėlė košmariškų derinimo problemų.
Taip pat buvo labai sunku išlaikyti skirtingas versijas tame pačiame klasteryje. Įsivaizduokite klientų aptarnavimo sudėtingumą, jei jums reikia vienu metu dirbti keliose tos pačios vykdymo aplinkos versijose su visomis jų problemomis, klaidomis ir naujinimais.
Pinterest vartotojo ypatybės ir valdikliai
Kad mūsų inžinieriams būtų lengviau įdiegti „Kubernetes“ ir supaprastinti bei pagreitinti infrastruktūrą, sukūrėme savo pasirinktinius išteklių apibrėžimus (CRD).
CRD suteikia šias funkcijas:
- Skirtingų vietinių „Kubernetes“ išteklių derinimas, kad jie veiktų kaip vienas darbo krūvis. Pavyzdžiui, PinterestService išteklius apima diegimą, prisijungimo paslaugą ir konfigūracijos žemėlapį. Tai leidžia kūrėjams nesijaudinti dėl DNS nustatymo.
- Įdiekite reikiamą programų palaikymą. Vartotojas turi sutelkti dėmesį tik į konteinerio specifikaciją pagal savo verslo logiką, o CRD valdiklis įgyvendina visus reikiamus init konteinerius, aplinkos kintamuosius ir pod specifikacijas. Tai kūrėjams suteikia iš esmės kitokį komforto lygį.
- CRD valdikliai taip pat valdo vietinių išteklių gyvavimo ciklą ir pagerina derinimo prieinamumą. Tai apima norimų ir esamų specifikacijų suderinimą, CRD būsenos atnaujinimą ir įvykių žurnalų tvarkymą ir kt. Be CRD kūrėjai būtų priversti valdyti kelis išteklius, o tai tik padidintų klaidų tikimybę.
Štai „PinterestService“ ir vidinio šaltinio, kurį valdo mūsų valdytojas, pavyzdys:
Kaip matote aukščiau, norėdami palaikyti pasirinktinį konteinerį, turime integruoti pradinį konteinerį ir kelis priedus, kad užtikrintume saugumą, matomumą ir tinklo srautą. Be to, sukūrėme konfigūracijos žemėlapio šablonus ir įdiegėme PVC šablonų palaikymą paketinėms užduotims, taip pat kelių aplinkos kintamųjų stebėjimą, kad būtų galima stebėti tapatybę, išteklių suvartojimą ir šiukšlių surinkimą.
Sunku įsivaizduoti, kad kūrėjai norėtų šiuos konfigūracijos failus rašyti ranka be CRD palaikymo, jau nekalbant apie tolesnę konfigūracijų priežiūrą ir derinimą.
Programos diegimo darbo eiga
Aukščiau pateiktame paveikslėlyje parodyta, kaip pritaikyti Pinterest išteklius Kubernetes klasteryje:
- Kūrėjai sąveikauja su mūsų „Kubernetes“ grupe per CLI ir vartotojo sąsają.
- CLI/UI įrankiai nuskaito darbo eigos konfigūracijos YAML failus ir kitas kūrimo ypatybes (tą patį versijos ID) iš „Artifactory“ ir pateikia juos darbų pateikimo tarnybai. Šis veiksmas užtikrina, kad į klasterį būtų pristatomos tik gamybinės versijos.
- JSS yra įvairių platformų, įskaitant Kubernetes, vartai. Čia autentifikuojamas vartotojas, išduodamos kvotos ir iš dalies patikrinama mūsų CRD konfigūracija.
- Patikrinus CRD JSS pusėje, informacija siunčiama į k8s platformos API.
- Mūsų CRD valdiklis stebi visų vartotojų išteklių įvykius. Jis konvertuoja CR į vietinius k8s išteklius, prideda reikalingus modulius, nustato atitinkamus aplinkos kintamuosius ir atlieka kitus palaikymo darbus, kad užtikrintų, jog konteinerinės vartotojų programos turėtų pakankamą infrastruktūros palaikymą.
- Tada CRD valdiklis perduoda gautus duomenis į Kubernetes API, kad planuotojas galėtų juos apdoroti ir pradėti gaminti.
Atkreipti dėmesį: Šis išankstinis diegimo darbo srautas buvo sukurtas pirmiesiems naujosios k8s platformos vartotojams. Šiuo metu tobuliname šį procesą, kad galėtume visiškai integruotis su mūsų naujuoju CI/CD. Tai reiškia, kad negalime jums pasakyti visko, kas susiję su „Kubernetes“. Tikimės pasidalinti savo patirtimi ir komandos pažanga šia kryptimi kitame tinklaraščio įraše „CI/CD platformos kūrimas Pinterest“.
Specialiųjų išteklių rūšys
Atsižvelgdami į specifinius „Pinterest“ poreikius, sukūrėme šiuos CRD, kad atitiktų skirtingas darbo eigas:
- „PinterestService“ yra paslaugos be pilietybės, veikiančios ilgą laiką. Daugelis mūsų pagrindinių sistemų yra pagrįstos tokių paslaugų rinkiniu.
- PinterestJobSet modeliuoja viso ciklo paketinius darbus. Dažnas Pinterest scenarijus yra toks, kad kelios užduotys vykdo tuos pačius konteinerius lygiagrečiai, neatsižvelgiant į kitus panašius procesus.
- PinterestCronJob plačiai naudojamas kartu su nedidelėmis periodinėmis apkrovomis. Tai įvynioklis, skirtas vietiniam cron darbui su Pinterest palaikymo mechanizmais, kurie yra atsakingi už saugumą, srautą, žurnalus ir metriką.
- „PinterestDaemon“ apima infrastruktūros demonus. Ši šeima toliau auga, nes mes pridedame daugiau paramos savo klasteriams.
- „PinterestTrainingJob“ apima „Tensorflow“ ir „Pytorch“ procesus, užtikrinant tokio paties lygio vykdymo palaikymą kaip ir visi kiti CRD. Kadangi Pinterest aktyviai naudoja Tensorflow ir kitas mašininio mokymosi sistemas, turėjome priežastį aplink jas sukurti atskirą CRD.
Taip pat dirbame su PinterestStatefulSet, kuris netrukus bus pritaikytas duomenų saugykloms ir kitoms būseną nustatančioms sistemoms.
Vykdymo trukmės palaikymas
Kai „Kubernetes“ veikia programų rinkinys, jis automatiškai gauna sertifikatą, leidžiantį identifikuoti save. Šis sertifikatas naudojamas norint pasiekti slaptą saugyklą arba susisiekti su kitomis paslaugomis per mTLS. Tuo tarpu „Container Init Configurator“ ir „Daemon“ atsisiųs visas būtinas priklausomybes prieš paleisdami konteinerinę programą. Kai viskas bus paruošta, eismo šoninė priekaba ir demonas užregistruos modulio IP adresą mūsų Zookeeper, kad klientai galėtų jį atrasti. Visa tai veiks, nes tinklo modulis buvo sukonfigūruotas prieš paleidžiant programą.
Pirmiau pateikti tipiški darbo krūvių vykdymo laiko palaikymo pavyzdžiai. Kitų tipų darbo krūviams gali prireikti šiek tiek kitokio palaikymo, tačiau jie visi pateikiami kaip pod lygio šoninės priekabos, mazgo lygio arba virtualios mašinos lygio demonai. Užtikriname, kad visa tai būtų įdiegta valdymo infrastruktūroje ir būtų nuosekli visose programose, o tai galiausiai žymiai sumažina techninio darbo ir klientų aptarnavimo naštą.
Testavimas ir kokybės užtikrinimas
Ant esamos „Kubernetes“ bandymų infrastruktūros pastatėme nuo galo iki galo bandymų vamzdyną. Šie testai taikomi visoms mūsų grupėms. Mūsų vamzdynas buvo daug peržiūrėtas, kol jis tapo produktų grupės dalimi.
Be testavimo sistemų, turime stebėjimo ir perspėjimo sistemas, kurios nuolat stebi sistemos komponentų būseną, resursų suvartojimą ir kitus svarbius rodiklius, pranešdamos tik tada, kai būtinas žmogaus įsikišimas.
Alternatyvos
Išnagrinėjome kai kurias pasirinktinių išteklių alternatyvas, pvz., mutacijų prieigos valdiklius ir šablonų sistemas. Tačiau jie visi susiduria su dideliais veiklos iššūkiais, todėl pasirinkome CRD kelią.
Mutacinis įėjimo valdiklis buvo naudojamas šoninėms priekaboms, aplinkos kintamiesiems ir kitam vykdymo laikui pristatyti. Tačiau ji susidūrė su įvairiomis problemomis, tokiomis kaip išteklių susiejimas ir gyvavimo ciklo valdymas, kai tokių problemų CRD nekyla.
Pastaba: Šablonų sistemos, tokios kaip Helm diagramos, taip pat plačiai naudojamos panašių konfigūracijų programoms paleisti. Tačiau mūsų darbo programos yra per daug įvairios, kad jas būtų galima valdyti naudojant šablonus. Taip pat nuolatinio diegimo metu naudojant šablonus bus per daug klaidų.
Būsimas darbas
Šiuo metu susiduriame su mišria apkrova visose mūsų grupėse. Siekdami palaikyti tokius įvairių tipų ir dydžių procesus, dirbame šiose srityse:
- Klasterių rinkinys paskirsto dideles programas įvairiose grupėse, kad būtų galima keisti mastelį ir stabilumą.
- Klasterio stabilumo, mastelio ir matomumo užtikrinimas, siekiant sukurti programų ryšį ir SLA.
- Išteklių ir kvotų valdymas taip, kad programos neprieštarautų viena kitai, o klasterio mastą valdome iš mūsų pusės.
- Nauja CI / CD platforma, skirta programoms Kubernetes palaikyti ir diegti.
Šaltinis: www.habr.com