Yn 'e rin fan' e jierren hawwe de 300 miljoen brûkers fan Pinterest mear dan 200 miljard pinnen makke op mear dan 4 miljard boards. Om dit leger fan brûkers en grutte ynhâldbasis te tsjinjen, hat it portaal tûzenen tsjinsten ûntwikkele, fariearjend fan mikrotsjinsten dy't kinne wurde behannele troch in pear CPU's, oant gigantyske monoliten dy't rinne op in heule float fan firtuele masines. En doe kaam it momint dat de eagen fan it bedriuw op k8's foelen. Wêrom seach de "kubus" goed op Pinterest? Jo sille leare oer dit út ús oersetting fan in resint artikel fan .
Dat, hûnderten miljoenen brûkers en hûnderten miljarden pinnen. Om dit leger fan brûkers en in grutte ynhâldbasis te tsjinjen, hawwe wy tûzenen tsjinsten ûntwikkele, fariearjend fan mikrotsjinsten dy't kinne wurde behannele troch in pear CPU's, oant gigantyske monoliten dy't rinne op heule floaten fan firtuele masines. Derneist hawwe wy in ferskaat oan kaders dy't ek CPU-, ûnthâld- of I / O-tagong fereaskje kinne.
By it behâld fan dizze bistetún fan ark stiet it ûntwikkelteam foar in oantal útdagings:
- D'r is gjin unifoarme manier foar yngenieurs om in produksjeomjouwing út te fieren. Steateleaze tsjinsten, Stateful tsjinsten en projekten ûnder aktive ûntwikkeling binne basearre op folslein ferskillende technology stacks. Dit late ta de oprjochting fan in folsleine oplieding foar yngenieurs, en ek serieus komplisearret it wurk fan ús ynfrastruktuerteam.
- Untwikkelders mei har eigen float fan firtuele masines meitsje in enoarme lêst foar ynterne behearders. As resultaat nimme sokke ienfâldige operaasjes as it bywurkjen fan it OS of AMI wiken en moannen. Dit liedt ta ferhege wurkdruk yn skynber absolút deistige situaasjes.
- Swierrichheden by it meitsjen fan globale ark foar ynfrastruktuerbehear boppe op besteande oplossingen. De situaasje wurdt fierder komplisearre troch it feit dat it net maklik is om de eigners fan firtuele masines te finen. Dat is, wy witte net oft dizze kapasiteit feilich helle wurde kin om te operearjen yn oare dielen fan ús ynfrastruktuer.
Containerorkestraasjesystemen binne in manier om wurkdrukbehear te ferienigjen. Se iepenje de doar nei ferhege ûntwikkelingssnelheid en ferienfâldigje ynfrastruktuerbehear, om't alle boarnen belutsen by it projekt wurde beheard troch ien sintralisearre systeem.
Ofbylding 1: Prioriteiten foar ynfrastruktuer (betrouberens, produktiviteit fan ûntwikkelders en effisjinsje).
It Cloud Management Platform-team by Pinterest ûntduts K8's yn 2017. Tsjin de earste helte fan 2017 hienen wy de measte fan ús produksjemooglikheden dokumintearre, ynklusyf de API en al ús webservers. Nei ôfrin hawwe wy in yngeande beoardieling dien fan ferskate systemen foar it orkestrearjen fan konteneroplossingen, it bouwen fan klusters en dêrmei wurkje. Tsjin it ein fan 2017 hawwe wy besletten om Kubernetes te brûken. It wie frij fleksibel en breed stipe yn 'e ûntwikkeldersmienskip.
Oant no ta hawwe wy ús eigen klusterboot-ark boud op basis fan Kops en migrearre besteande ynfrastruktuerkomponinten lykas netwurking, feiligens, metriken, logging, identiteitsbehear, en ferkear nei Kubernetes. Wy hawwe ek in wurkdrukmodelleringssysteem ymplementearre foar ús boarne, wêrfan de kompleksiteit ferburgen is foar ûntwikkelders. No binne wy rjochte op it garandearjen fan de stabiliteit fan it kluster, it skaalfergrutting en it ferbinen fan nije kliïnten.
Kubernetes: The Pinterest Way
Begjin mei Kubernetes op 'e skaal fan Pinterest as in platfoarm dat ús yngenieurs leuk fine, kaam mei in protte útdagings.
As in grut bedriuw hawwe wy swier ynvestearre yn ynfrastruktuerark. Foarbylden omfetsje befeiligingsark dy't sertifikaatferwurking en kaaiferdieling behannelje, komponinten foar ferkearskontrôle, systemen foar ûntdekking fan tsjinsten, sichtberenskomponinten, en komponinten foar ferstjoeren fan logs en metriken. Dit alles waard sammele foar in reden: wy gongen troch it normale paad fan probearjen en flater, en dêrom woene wy al dizze apparatuer yntegrearje yn 'e nije ynfrastruktuer op Kubernetes ynstee fan it âlde tsjil op in nij platfoarm opnij útfine. Dizze oanpak ferienfâldige algemien de migraasje, om't alle applikaasjestipe al bestiet en net fanôf it begjin oanmakke wurde hoecht.
Oan 'e oare kant binne de modellen foar prognose foar lading yn Kubernetes sels (lykas ynset, banen en Daemon-sets) net genôch foar ús projekt. Dizze brûkberensproblemen binne enoarme barriêres foar it ferpleatsen nei Kubernetes. Wy hawwe bygelyks tsjinstûntwikkelders heard oer ûntbrekkende of ferkearde oanmeldingsynstellingen. Wy hawwe ek tsjinkaam ferkeard gebrûk fan sjabloan motoren, doe't hûnderten kopyen waarden makke mei deselde spesifikaasje en taak, wat resultearre yn nachtmerje debuggen problemen.
It wie ek heul lestich om ferskate ferzjes yn itselde kluster te behâlden. Stel jo de kompleksiteit fan klantstipe foar as jo tagelyk moatte wurkje yn meardere ferzjes fan deselde runtime-omjouwing, mei al har problemen, bugs en updates.
Pinterest brûkerseigenskippen en kontrôlers
Om it makliker te meitsjen foar ús yngenieurs om Kubernetes te ymplementearjen, en om ús ynfrastruktuer te ferienfâldigjen en te fersnellen, hawwe wy ús eigen oanpaste boarne-definysjes (CRD's) ûntwikkele.
CRD's leverje de folgjende funksjonaliteit:
- It kombinearjen fan ferskate native Kubernetes-boarnen sadat se wurkje as ien wurkdruk. Bygelyks, de boarne fan PinterestService omfettet in ynset, in oanmeldtsjinst en in konfiguraasjekaart. Hjirmei kinne ûntwikkelders gjin soargen meitsje oer it ynstellen fan DNS.
- Implementearje needsaaklike applikaasjestipe. De brûker moat allinich rjochtsje op 'e kontenerspesifikaasje neffens har bedriuwslogika, wylst de CRD-controller alle nedige init-konteners, omjouwingsfariabelen en podspesifikaasjes ymplementearret. Dit soarget foar ûntwikkelders in fûneminteel oar nivo fan komfort.
- CRD-controllers beheare ek de libbenssyklus fan lânseigen boarnen en ferbetterje debugbeskikberens. Dit omfettet it fermoedsoenjen fan winske en werklike spesifikaasjes, it bywurkjen fan CRD-status en it behâld fan barrenslogs, en mear. Sûnder CRD soene ûntwikkelders twongen wurde om meardere boarnen te behearjen, wat allinich de kâns op flater soe ferheegje.
Hjir is in foarbyld fan in PinterestService en in ynterne boarne dy't wurdt beheard troch ús controller:
Lykas jo hjirboppe kinne sjen, moatte wy om in oanpaste kontener te stypjen in init-kontener en ferskate tafoegings yntegrearje om feiligens, sichtberens en netwurkferkear te leverjen. Derneist hawwe wy konfiguraasjekaartsjabloanen makke en stipe ymplementearre foar PVC-sjabloanen foar batchbanen, lykas ek it folgjen fan meardere omjouwingsfariabelen om identiteit, boarneferbrûk en jiskefet te folgjen.
It is dreech foar te stellen dat ûntwikkelders dizze konfiguraasjebestannen mei de hân wolle skriuwe sûnder CRD-stipe, lit stean de konfiguraasjes fierder ûnderhâlde en debuggen.
Applikaasje ynset workflow
De ôfbylding hjirboppe lit sjen hoe't jo in oanpaste boarne fan Pinterest kinne ynsette nei in Kubernetes-kluster:
- Untwikkelders ynteraksje mei ús Kubernetes-kluster fia de CLI en brûkersynterface.
- De CLI / UI ark helje de workflow konfiguraasje YAML triemmen en oare build eigenskippen (deselde ferzje ID) út Artifactory en dan yntsjinje se nei de Job Submission Service. Dizze stap soarget derfoar dat allinich produksjeferzjes wurde levere oan it kluster.
- JSS is in poarte foar ferskate platfoarms, ynklusyf Kubernetes. Hjir wurdt de brûker authentisearre, quota's wurde útjûn en de konfiguraasje fan ús CRD wurdt foar in part kontrolearre.
- Nei it kontrolearjen fan de CRD oan 'e JSS-kant, wurdt de ynformaasje stjoerd nei it k8s-platfoarm API.
- Us CRD-controller kontrolearret eveneminten op alle brûkersboarnen. It konvertearret CR's yn lânseigen k8s-boarnen, foeget de nedige modules ta, stelt de passende omjouwingsfariabelen yn en fiert oar stipewurk út om te soargjen dat kontenerisearre brûkersapplikaasjes genôch ynfrastruktuerstipe hawwe.
- De CRD-controller jout dan de ûntfongen gegevens troch oan de Kubernetes API, sadat it kin wurde ferwurke troch de planner en yn produksje set.
remark: Dizze pre-release wurkstream fan 'e ynset is makke foar de earste brûkers fan it nije k8s-platfoarm. Wy binne op it stuit yn it proses om dit proses te ferfine om folslein te yntegrearjen mei ús nije CI/CD. Dit betsjut dat wy jo net alles kinne fertelle oer Kubernetes. Wy sjogge út nei it dielen fan ús ûnderfining en de foarútgong fan it team yn dizze rjochting yn ús folgjende blogpost, "It bouwen fan in CI / CD-platfoarm foar Pinterest."
Soarten spesjale middels
Op grûn fan de spesifike behoeften fan Pinterest hawwe wy de folgjende CRD's ûntwikkele om te passen by ferskate workflows:
- PinterestService binne steatleaze tsjinsten dy't al in lange tiid rinne. In protte fan ús kearnsystemen binne basearre op in set fan sokke tsjinsten.
- PinterestJobSet modellen folsleine syklus batch banen. In mienskiplik senario op Pinterest is dat meardere banen deselde konteners parallel rinne, nettsjinsteande oare ferlykbere prosessen.
- PinterestCronJob wurdt in protte brûkt yn gearhing mei lytse periodike loads. Dit is in wrapper foar native cron-wurk mei Pinterest-stipemeganismen dy't ferantwurdlik binne foar feiligens, ferkear, logs en metriken.
- PinterestDaemon omfettet ynfrastruktuer Daemons. Dizze famylje bliuwt groeie as wy mear stipe tafoegje oan ús klusters.
- PinterestTrainingJob wreidet út nei Tensorflow- en Pytorch-prosessen, en leveret itselde nivo fan runtime-stipe as alle oare CRD's. Sûnt Pinterest aktyf brûkt Tensorflow en oare masine-learsystemen, hiene wy in reden om in aparte CRD om har hinne te bouwen.
Wy wurkje ek oan PinterestStatefulSet, dy't ynkoarten sil wurde oanpast foar gegevenspakhuzen en oare steatlike systemen.
Runtime stipe
As in applikaasjepod op Kubernetes rint, krijt it automatysk in sertifikaat om himsels te identifisearjen. Dit sertifikaat wurdt brûkt om tagong te krijen ta geheime opslach of om te kommunisearjen mei oare tsjinsten fia mTLS. Underwilens sille de Container Init Configurator en Daemon alle nedige ôfhinklikens downloade foardat de containerisearre applikaasje útfiert. As alles klear is, sille de ferkearssidecar en Daemon it IP-adres fan de module registrearje by ús Zookeeper, sadat kliïnten it kinne ûntdekke. Dit alles sil wurkje om't de netwurkmodule is konfigureare foardat de applikaasje waard lansearre.
It boppesteande binne typyske foarbylden fan runtime-stipe foar workloads. Oare soarten workloads kinne in bytsje oare stipe fereaskje, mar se komme allegear yn 'e foarm fan pod-nivo sidecars, node-nivo of firtuele masine-nivo Daemons. Wy soargje derfoar dat dit alles wurdt ynset binnen de behear ynfrastruktuer en is konsekwint oer applikaasjes, dy't úteinlik signifikant ferminderet de lêst yn termen fan technysk wurk en klant stipe.
Testen en QA
Wy bouden in end-to-end testpipeline boppe op 'e besteande Kubernetes-testynfrastruktuer. Dizze tests jilde foar al ús klusters. Us pipeline gie troch in protte ferzjes foardat it diel waard fan it produktkluster.
Neist testsystemen hawwe wy kontrôle- en warskôgingssystemen dy't konstant de status fan systeemkomponinten, boarneferbrûk en oare wichtige yndikatoaren kontrolearje, en ús allinich ynformearje as minsklike yntervinsje nedich is.
Alternativen
Wy hawwe sjoen nei guon alternativen foar oanpaste boarnen, lykas mutaasje tagong controllers en sjabloan systemen. Se komme lykwols allegear mei wichtige operasjonele útdagings, dus wy hawwe de CRD-rûte keazen.
In mutational admission controller waard brûkt om sidecars, omjouwingsfariabelen en oare runtime-stipe yn te fieren. It hat lykwols ferskate problemen konfrontearre, lykas resource binding en lifecycle management, wêr't sokke problemen net foarkomme yn CRD.
Tink derom: Sjabloansystemen lykas Helm-kaarten wurde ek in soad brûkt om applikaasjes út te fieren mei ferlykbere konfiguraasjes. Us wurkapplikaasjes binne lykwols te ferskaat om te wurde beheard mei sjabloanen. Ek by trochgeande ynset sille d'r tefolle flaters wêze by it brûken fan sjabloanen.
Oankommende wurk
Wy hawwe op it stuit te krijen mei in mingde lading oer al ús klusters. Om sokke prosessen fan ferskate soarten en grutte te stypjen, wurkje wy yn 'e folgjende gebieten:
- In samling klusters ferspriedt grutte applikaasjes oer ferskate klusters om skaalberens en stabiliteit te garandearjen.
- It garandearjen fan klusterstabiliteit, skalberens en sichtberens om applikaasjeferbining en SLA's te meitsjen.
- Behear fan boarnen en kwota's sadat applikaasjes net yn konflikt binne mei elkoar, en de skaal fan it kluster wurdt kontrolearre fan ús kant.
- In nij CI/CD-platfoarm foar it stypjen en ynsetten fan applikaasjes op Kubernetes.
Boarne: www.habr.com