V letih obstoja Pinterest je 300 milijonov uporabnikov storitve ustvarilo več kot 200 milijard priponk na več kot 4 milijardah tabl. Da bi lahko oskrbeli to vojsko uporabnikov in obsežno bazo vsebin, je portal razvil tisoče storitev, od mikroservisov, s katerimi se lahko spopade nekaj CPU-jev, do velikih monolitov, ki tečejo na celotnih parkih virtualnih strojev. In prišel je trenutek, ko je pogled podjetja padel na k8s. Kaj je torej „kocka“ pritegnila „Pinterest“? O tem boste izvedeli iz našega prevoda svežega članka iz .
Torej, stotine milijonov uporabnikov in stotine milijard priponk. Da bi oskrbeli to vojsko uporabnikov in obsežno bazo vsebin, smo razvili tisoče storitev, od mikroservisov, s katerimi se lahko spopade nekaj CPU-jev, do velikih monolitov, ki tečejo na celotnih parkih virtualnih strojev. Poleg tega imamo različne okvire, ki prav tako lahko zahtevajo vire CPU, pomnilnika ali dostop do vhodno-izhodnih operacij.
Med podporo temu zoološkemu vrtu orodij se razvojna ekipa sooča s številnimi težavami:
- Inženirji nimajo enotnega načina zagona delovnega okolja. Stateless storitve, Stateful storitve in projekti v aktivnem razvoju temeljijo na povsem različnih tehnoloških kupih. To je privedlo do ustvarjanja celotnega izobraževalnega tečaja za inženirje in resno otežuje delo naši infrastrukturni ekipi.
- Razvijalci, ki imajo na voljo lastne parke virtualnih strojev, črpajo ogromno obremenitev na notranje skrbnike. Na koncu se tako preproste operacije, kot so posodobitve OS ali AMI, raztegujejo na tedne in mesece. To povzroča povečanje obremenitve v, zdi se, povsem vsakdanjih situacijah.
- Težave pri ustvarjanju globalnih orodij za upravljanje infrastrukture nad obstoječimi rešitvami. Situacijo še otežuje dejstvo, da je težko najti lastnike virtualnih strojev. To pomeni, da ne vemo, ali lahko varno izvlečemo te zmogljivosti za delo na drugih področjih naše infrastrukture.
Sistem orkestracije kontejnera je način unifikacije upravljanja radnim opterećenjem. Otvaraju vam put ka povećanju brzine razvoja i pojednostavljuju upravljanje infrastrukturom, jer svi resursi uključeni u projekat se upravljaju jednim centralizovanim sistemom.
Slika 1: Prioriteti infrastrukture (pouzdanost, produktivnost programera i efikasnost).
Tim Cloud Management Platform u Pinterestu se upoznao sa K8s 2017. godine. Do prve polovine 2017. dokumentovali smo većinu naših proizvodnih kapaciteta, uključujući API i sve naše web servere. Nakon toga, sproveli smo detaljnu evaluaciju različitih sistema orkestracije kontejnerskih rešenja, izgradnje klastera i rada s njima. Do kraja 2017. godine odlučili smo se za Kubernetes. Bio je dovoljno fleksibilan i široko podržavan u zajednici programera.
Do sada smo kreirali vlastite alate za primarnu konfiguraciju klastera na bazi Kops i prebacili postojeće komponente infrastrukture na Kubernetes — kao što su mreža, bezbednost, merenja, vođenje dnevnika, upravljanje identitetom i saobraćajem. Takođe smo implementirali sistem modelovanja radnih opterećenja za naš resurs, čija je složenost skrivena od programera. Sada se fokusiramo na obezbeđivanje stabilnosti klastera, njegovom skaliranju i povezivanju novih klijenata.
Kubernetes: Put Pinterest-a
Početak rada sa Kubernetesom u okviru Pinterest-a, kao platforme koja će biti omiljena našim inženjerima, ispostavio se kao izazovan.
Kao velika kompanija, uložili smo značajna sredstva u infrastrukturne alate. Na primer, tu su sigurnosni alati koji obrađuju sertifikate i distribuiraju ključeve, komponente za kontrolu saobraćaja, sisteme otkrivanja usluga, komponente za vidljivost i slanje dnevnika i merenja. Sve to nije skupljeno bez razloga: prošli smo normalan put proba i grešaka, i zbog toga smo želeli da integrišemo sve to u novu infrastrukturu na Kubernetes-u, umesto da ponovo izmišljamo stari bicikl na novoj platformi. Ovakav pristup u celini je pojednostavio migraciju, jer je sva podrška aplikacijama već postojala, nije je bilo potrebno kreirati ispočetka.
S druge strani, modeli napovedovanja obremenitev v samem Kubernetes (na primer, uvedbe, naloge in Daemon sets) niso dovolj za naš projekt. Te uporabniške težave so ogromne ovire na poti prehoda na Kubernetes. Na primer, slišali smo, kako se razvijalci storitev pritožujejo zaradi pomanjkanja ali nepravilne konfiguracije vhodnih točk. Prav tako smo se srečali z napačno uporabo predlog, ko so bile ustvarjene na stotine kopij z enako specifikacijo in nalogo, kar je vodilo do strašnih težav z odpravljanjem napak.
Poleg tega je bilo zelo težko vzdrževati različne različice v istem klastru. Predstavljajte si težave pri podpori strankam, če morate delati v več različicah istega izvajalnega okolja, z vsemi njihovimi težavami, napakami in posodobitvami.
Uporabniški viri in krmilniki Pinterest
Da bi našim inženirjem olajšali postopek uvedbe Kubernetes ter poenostavili infrastrukturo in pospešili njeno delovanje, smo razvili svoje lastne opredelitve uporabniških virov (CRD).
CRD zagotavljajo naslednje funkcionalnosti:
- Zajedinjene različne nativne vire Kubernetes, da delujejo kot enotna obremenitev. Na primer, vir PinterestService vključuje uvedbo, vhodno službo in konfiguracijsko karto. To razvijalcem omogoča, da se ne obremenjujejo s konfiguracijo DNS.
- Uvedba potrebne podpore aplikacijam. Uporabnik se mora osredotočiti le na specifikacijo kontejnerja v skladu s svojo poslovno logiko, medtem ko krmilnik CRD uvede vse potrebne init-kontejnerje, okoljske spremenljivke in specifikacije pod. To zagotavlja povsem drugačno raven udobnosti za razvijalce.
- Krmilniki CRD prav tako upravljajo življenjski cikel lastnih virov in povečujejo razpoložljivost odkrivanja napak. To vključuje usklajevanje želenih in dejanskih specifikacij, posodabljanje statusa CRD ter vodenje dnevnikov dogodkov in še več. Brez CRD bi bili razvijalci primorani upravljati z ogromnim naborom virov, kar bi le povečalo verjetnost napak.
Tukaj je primer PinterestService in notranjega vira, ki ga upravlja naš krmilnik:
Kot lahko vidite zgoraj, za podporo uporabniškemu vsebniku moramo integrirati vsebnik za inicializacijo in več razširitev, da zagotovimo varnost, vidnost in upravljanje s omrežnim prometom. Poleg tega smo ustvarili predloge za konfiguracijske karte in uvedli podporo za PVC predloge za paketna opravila, kot tudi sledenje številnim spremenljivkam okolja za spremljanje identifikacije, porabe virov in zbiranje 'smeti'.
Težko si je predstavljati, da bi razvijalci želeli ročno napisati te konfiguracijske datoteke brez podpore CRD, kaj šele nadaljnje vzdrževanje in odpravljanje napak v konfiguracijah.
Delovni tok za nameščanje aplikacij
Na zgornji sliki je prikazano, kako razporediti uporabniški vir Pinterest v grozdu Kubernetes:
- Razvijalci komunicirajo z našim grozdom Kubernetes preko CLI in uporabniškega vmesnika.
- Orodja CLI / UI pridobivajo YAML datoteke o konfiguraciji delovnega toka in druge lastnosti zbirke (isto različico različice) iz Artifactory, nato pa jih pošljejo v storitev za oddajo opravil. Ta korak zagotavlja, da bodo v grozd nameščene samo delujoče različice.
- JSS je prehod za različne platforme, vključno s Kubernetes. Tu poteka avtentikacija uporabnika, dodeljevanje kvot in delna preveritev konfiguracije našega CRD.
- Po preverjanju CRD na strani JSS se informacije pošljejo na API platforme k8s.
- Naš CRD kontroler sledi dogodkom na vseh uporabniških virih. Pretvarja CR v naravne vire k8s, dodaja potrebne module, nastavi ustrezne okoljske spremenljivke in opravi druga pomožna dela, s čimer zagotavlja ustrezno infrastrukturo za podporo uporabniškim aplikacijam v vsebnikih.
- Nato CRD kontroler prenese pridobljene podatke v API Kubernetes, da jih obdeluje razporejevalnik in uvede v delovanje.
Napomena: to je predizvodni proces implementacije ustvarjen za prve uporabnike nove k8s platforme. Trenutno smo v procesu izboljšanja tega postopka, da se popolnoma integriramo z našo novo CI/CD. To pomeni, da ne moremo deliti vsega, kar je povezano z Kubernetesom. Z nestrpnostjo čakamo, da bomo lahko delili svoje izkušnje in poročali o napredku ekipe na tem področju v našem naslednjem blogu 'Gradnja CI/CD platforme za Pinterest'.
Vrste posebnih virov
Na podlagi specifičnih potreb Pinterest smo razvili naslednje CRD, ki so primerne za različne delovne tokove:
- PinterestService so že dolgo delujoče stateless storitve. Številni naši osnovni sistemi temeljijo na nizu takšnih storitev.
- PinterestJobSet modelira pakete celovitih nalog. V Pinterestu obstaja splošni scenarij, v katerem več nalog hkrati zažene iste kontejnere, neodvisno od drugih podobnih procesov.
- PinterestCronJob se široko uporablja v povezavi z majhnimi periodičnimi obremenitvami. To je ovoj za nativno delovanje cron s sistemi podpore Pinterest, ki skrbijo za varnost, promet, dnevnike in metrike.
- PinterestDaemon vključuje infrastrukturne Daemone. To družino nenehno razvijamo, saj dodajamo vedno več podpore za naše grozde.
- PinterestTrainingJob pokriva procese Tensorflow in Pytorch, zagotavljajoč enako raven podpore med delovanjem kot vse druge CRD. Ker se v Pinterestu široko uporablja Tensorflow in druge sisteme strojnega učenja, smo imeli razlog, da okoli njih oblikujemo ločeno CRD.
Prav tako delamo na PinterestStatefulSet, ki bo kmalu prilagojen za shranjevanje podatkov in druge stateful sisteme.
Podpora za izvajalno okolje
Ko modül aplikacija se zažene v Kubernetesu, samodejno pridobi certifikat za svojo identifikacijo. Ta certifikat se uporablja za dostop do skrivnostnega skladišča ali za komunikacijo z drugimi storitvami prek mTLS. Medtem ko inicializator kontejnerjev in Daemon naložita vse potrebne odvisnosti pred zagon kontejnerske aplikacije, bo, ko bo vse pripravljeno, sidecar za promet in Daemon registriral IP naslov modula v našem Zookeeperju, da ga lahko stranke odkrijejo. Vse to bo delovalo, saj je bila omrežna modul nastavljena že pred zagonom aplikacije.
Zgoraj so predstavljeni tipični primeri podpore delovnim obremenitvam med izvajanjem. Drugim vrstam delovnih obremenitev morda zadostuje nekoliko drugačna podpora, vendar so vse predstavljene v obliki sidecar-jev na ravni poda, vozliščih ali Daemon-ih na ravni virtualnih strojev. Skrbimo, da se vse to izvaja v okviru upravljalske infrastrukture in je usklajeno med aplikacijami, kar na koncu znatno zmanjšuje obremenitev glede tehničnega dela in podpore strankam.
Testiranje in QA
Zbrali smo end-to-end testni pipeline na že obstoječi testni infrastrukturi Kubernetes. Ti testi pokrivajo vse naše klastre. Naš pipeline je preživel številne predelave, preden je postal del produktnega klasterja.
Poleg sistemov testiranja imamo tudi sisteme za nadzor in obveščanje, ki nenehno spremljajo stanje sistemskih komponent, porabo virov in druge pomembne kazalnike, nas obveščajo le, ko je potrebna človeška intervencija.
Alternatives
Razmislili smo o nekaterih alternativah za prilagojene vire, kot so mutacijski kontrolerji dostopa in sistemi predlog. Vendar so vsi ti povezani s resnimi težavami pri delu, zato smo izbrali pot CRD.
Mutacijski kontroler dostopa je bil uporabljen za vnos sidecarjev, spremenljivk okolja in druge podpore med izvajanjem. Kljub temu pa se je soočal z različnimi težavami, kot so povezovanje virov in upravljanje njihovega življenjskega cikla, medtem ko v CRD teh težav ni.
Opomba: Sistemi predložaka, poput Helm dijagrama, široko se koriste za pokretanje aplikacija sličnih konfiguracija. Međutim, naše radne aplikacije su previše različite da bi se njima moglo upravljati putem predložaka. Takođe, prilikom neprekidnog raspoređivanja uz korišćenje predložaka javiće se previše grešaka.
Nadolazeći rad
Trenutno se suočavamo s mešovitim opterećenjem na svim našim klastrima. Da bismo podržali takve procese različitih tipova i veličina, radimo u sledećim pravcima:
- Skup klastera raspoređuje velike aplikacije po različitim klasterima za obezbeđivanje skalabilnosti i stabilnosti.
- Održavanje stabilnosti, skalabilnosti i vidljivosti klastera kako bi se stvorila veza između aplikacije i njenog SLA.
- Upravljanje resursima i kvotama kako bi se aplikacije međusobno ne sukobljavale, a obim klastera kontrolisao sa naše strane.
- Nova CI/CD platforma za podršku i raspoređivanje aplikacija u Kubernetes.
Izvor: habr.com
