In l'anni, i 300 milioni d'utilizatori di Pinterest anu creatu più di 200 miliardi di pin in più di 4 miliardi di schede. Per serve stu esercitu di l'utilizatori è una vasta basa di cuntenutu, u portale hà sviluppatu millaie di servizii, chì varienu da i microservizii chì ponu esse trattati da uni pochi CPU, à i monoliti giganti chì funzionanu nantu à una flotta intera di macchine virtuali. E dopu u mumentu hè vinutu quandu l'ochji di a cumpagnia cascò nantu à k8s. Perchè u "cubu" pareva bè in Pinterest? Sapete nantu à questu da a nostra traduzzione di un articulu recente da .
Cusì, centinaie di milioni d'utilizatori è centinaie di miliardi di pin. Per serve stu esercitu di l'utilizatori è una vasta basa di cuntenutu, avemu sviluppatu millaie di servizii, chì varienu da i microservizi chì ponu esse trattati da uni pochi CPU, à monoliti giganti chì funzionanu in flotte intere di macchine virtuali. Inoltre, avemu una varietà di quadri chì ponu ancu esse bisognu di CPU, memoria o accessu I / O.
In u mantenimentu di stu zoo di strumenti, a squadra di sviluppu face una quantità di sfide:
- Ùn ci hè micca manera uniforme per l'ingegneri di gestisce un ambiente di produzzione. I servizii senza stati, i servizii Stateful è i prughjetti in u sviluppu attivu sò basati nantu à stacks tecnologichi completamente differenti. Questu hà purtatu à a creazione di un cursu sanu di furmazione per l'ingegneri, è ancu cumplicà seriamente u travagliu di a nostra squadra di infrastruttura.
- I sviluppatori cù a so propria flotta di macchine virtuali creanu un pesu enormu per l'amministratori interni. In u risultatu, l'operazioni simplici cum'è l'aghjurnamentu di u SO o AMI piglianu settimane è mesi. Questu porta à una carica di travagliu aumentata in situazioni apparentemente assulutamente quotidiane.
- Difficultà à creà strumenti di gestione di l'infrastruttura globale nantu à e soluzioni esistenti. A situazione hè più complicata da u fattu chì truvà i pruprietarii di macchine virtuali ùn hè micca faciule. Questu hè, ùn sapemu micca se sta capacità pò esse estratta in modu sicuru per operare in altre parti di a nostra infrastruttura.
I sistemi di orchestrazione di u containeru sò un modu per unificà a gestione di a carica di travagliu. Apertura a porta à una crescita di velocità di sviluppu è simplificà a gestione di l'infrastruttura, postu chì tutte e risorse implicate in u prugettu sò gestite da un sistema centralizatu.
Figura 1: Priorità di l'infrastruttura (affidabilità, produtividade di sviluppatore è efficienza).
U squadra di Cloud Management Platform in Pinterest hà scupertu K8s in 2017. Da a prima mità di 2017, avemu avutu documentatu a maiò parte di e nostre capacità di produzzione, cumprese l'API è tutti i nostri servitori web. Dopu, avemu realizatu una valutazione approfondita di diversi sistemi per l'orchestrazione di soluzioni di cuntenituri, custruendu clusters è travaglià cun elli. Versu a fine di 2017, avemu decisu di utilizà Kubernetes. Era abbastanza flessibile è largamente supportatu in a cumunità di sviluppatori.
Finu a data, avemu custruitu i nostri strumenti di boot di cluster basati nantu à Kops è migratu cumpunenti di l'infrastruttura esistenti cum'è rete, sicurezza, metrica, logging, gestione di l'identità è trafficu à Kubernetes. Avemu ancu implementatu un sistema di mudellu di carichi di travagliu per a nostra risorsa, a cumplessità di quale hè oculata da i sviluppatori. Avà simu focu annantu à assicurà a stabilità di u cluster, scaling it and connecting new clients.
Kubernetes: U modu di Pinterest
L'iniziu cù Kubernetes à a scala di Pinterest cum'è una piattaforma chì i nostri ingegneri amarianu ghjuntu cù parechje sfide.
Cum'è una grande cumpagnia, avemu investitu assai in strumenti di infrastruttura. L'esempii includenu strumenti di sicurezza chì gestiscenu certificati è distribuzione chjave, cumpunenti di cuntrollu di trafficu, sistemi di scuperta di serviziu, cumpunenti di visibilità, è cumpunenti di spedizione di log è metrica. Tuttu chistu hè statu cullatu per una ragione: avemu passatu per u percorsu normale di prucessu è errore, è per quessa vulemu integrà tuttu questu equipamentu in a nova infrastruttura in Kubernetes invece di reinventà a vechja rota nantu à una nova piattaforma. Stu approcciu in generale simplificatu a migrazione, postu chì tuttu u supportu di l'applicazioni esiste digià è ùn deve micca esse creatu da zero.
Per d 'altra banda, i mudelli di previsione di carica in Kubernetes stessu (cum'è implementazioni, impieghi è setti Daemon) ùn sò micca abbastanza per u nostru prughjettu. Questi prublemi di usabilità sò enormi ostaculi per passà à Kubernetes. Per esempiu, avemu intesu chì i sviluppatori di serviziu si lamentanu di paràmetri di login mancanti o sbagliati. Avemu ancu scontru à l'usu incorrectu di i mutori di mudelli, quandu centinaie di copie sò stati creati cù a listessa specificazione è u travagliu, chì hà risultatu in prublemi di debugging di incubo.
Era ancu assai difficiule di mantene diverse versioni in u stessu cluster. Immaginate a cumplessità di l'assistenza à i clienti se avete bisognu di travaglià simultaneamente in parechje versioni di u stessu ambiente di runtime, cù tutti i so prublemi, bug è aghjurnamenti.
Pruprietà di l'utilizatori di Pinterest è Controllers
Per fà più faciule per i nostri ingegneri à implementà Kubernetes, è simplificà è accelerà a nostra infrastruttura, avemu sviluppatu e nostre definizioni di risorse persunalizate (CRD).
I CRD furniscenu e seguenti funziunalità:
- Cumminendu diverse risorse native Kubernetes in modu chì travaglianu cum'è una sola carica di travagliu. Per esempiu, a risorsa PinterestService include una implementazione, un serviziu di login è una mappa di cunfigurazione. Questu permette à i sviluppatori di ùn preoccupari micca di stallà DNS.
- Implementà u supportu di l'applicazione necessariu. L'utilizatore hà bisognu di fucalizza solu nantu à a specificazione di u containeru secondu a so logica cummerciale, mentre chì u controller CRD implementa tutti i cuntenituri init necessarii, variabili ambientali è specificazioni pod. Questu furnisce un livellu fundamentale di cunfortu per i sviluppatori.
- I controller CRD gestiscenu ancu u ciclu di vita di e risorse native è migliurà a dispunibilità di debug. Questu include a cunciliazione di e specificazioni desiderate è attuali, l'aghjurnamentu di u statutu CRD è u mantenimentu di i registri di l'avvenimenti, è più. Senza CRD, i sviluppatori seranu furzati à gestisce parechje risorse, chì solu aumentà a probabilità di errore.
Eccu un esempiu di un PinterestService è una risorsa interna chì hè amministrata da u nostru controller:
Comu pudete vede sopra, per sustene un containeru persunalizatu avemu bisognu di integrà un containeru init è parechji add-ons per furnisce sicurezza, visibilità è trafficu di rete. Inoltre, avemu creatu mudelli di mappa di cunfigurazione è implementatu supportu per i mudelli PVC per i travaglii in batch, è ancu u seguimentu di parechje variabili di l'ambiente per seguità l'identità, u cunsumu di risorse è a raccolta di basura.
Hè difficiuli d'imaginà chì i sviluppatori vulianu scrive questi schedarii di cunfigurazione à manu senza supportu CRD, è ancu più mantene è debug e cunfigurazioni.
Flussu di travagliu di implementazione di l'applicazioni
L'imaghjini sopra mostra cumu implementà una risorsa persunalizata di Pinterest à un cluster Kubernetes:
- I sviluppatori interagiscenu cù u nostru cluster Kubernetes attraversu a CLI è l'interfaccia d'utilizatore.
- L'arnesi CLI / UI ripiglià i schedarii YAML di cunfigurazione di u flussu di travagliu è altre proprietà di custruzzione (stessa versione ID) da Artifactory è poi sottumettenu à u Serviziu di Submission Job. Stu passu assicura chì solu versioni di produzzione sò furnite à u cluster.
- JSS hè un gateway per diverse piattaforme, cumprese Kubernetes. Quì l'utilizatore hè autentificatu, i quote sò emessi è a cunfigurazione di u nostru CRD hè parzialmente verificatu.
- Dopu avè verificatu u CRD in u latu JSS, l'infurmazione hè mandata à l'API di a piattaforma k8s.
- U nostru controller CRD monitoreghja l'avvenimenti nantu à tutte e risorse di l'utilizatori. Cunverte i CR in risorse native k8s, aghjunghjenu i moduli necessarii, stabilisce e variabili di l'ambiente appropritatu, è eseguisce altre travagliu di supportu per assicurà chì l'applicazioni d'utilizatori containerizzate anu un supportu di infrastruttura sufficiente.
- U controller CRD poi passa i dati ricevuti à l'API Kubernetes in modu chì pò esse trattatu da u pianificatore è mette in produzzione.
Vita: Stu flussu di travagliu pre-release di a implementazione hè stata creata per i primi utilizatori di a nova plataforma k8s. Semu attualmente in u prucessu di raffinà stu prucessu per integrà cumplettamente cù u nostru novu CI / CD. Questu significa chì ùn pudemu micca dì tuttu ciò chì riguarda Kubernetes. Aspittemu di sparte a nostra sperienza è u prugressu di a squadra in questa direzzione in u nostru prossimu post di blog, "Custruisce una piattaforma CI/CD per Pinterest".
Tipi di risorse speciali
Basatu nantu à i bisogni specifichi di Pinterest, avemu sviluppatu i seguenti CRD per adattà à diversi flussi di travagliu:
- PinterestService sò servizii senza statu chì sò stati in esecuzione per un bellu pezzu. Parechji di i nostri sistemi core sò basati nantu à un inseme di tali servizii.
- PinterestJobSet modella i travaglii in batch di ciclu cumpletu. Un scenariu cumuni nantu à Pinterest hè chì parechji travaglii currianu i stessi cuntenituri in parallelu, indipendentemente da altri prucessi simili.
- PinterestCronJob hè largamente utilizatu in cunghjunzione cù picculi carichi periodichi. Questu hè un wrapper per u travagliu cron nativu cù i meccanismi di supportu di Pinterest chì sò rispunsevuli di sicurezza, trafficu, logs è metrica.
- PinterestDaemon include Daemons d'infrastruttura. Sta famiglia cuntinueghja à cresce cum'è aghjustemu più supportu à i nostri clusters.
- PinterestTrainingJob si estende à i prucessi Tensorflow è Pytorch, chì furnisce u listessu livellu di supportu di runtime cum'è tutti l'altri CRD. Siccomu Pinterest usa attivamente Tensorflow è altri sistemi di apprendimentu di macchina, avemu avutu una ragione per custruisce un CRD separatu intornu à elli.
Avemu ancu travagliatu nantu à PinterestStatefulSet, chì sarà prestu adattatu per i magazzini di dati è altri sistemi stateful.
Supportu di runtime
Quandu un pod di applicazione corre in Kubernetes, riceve automaticamente un certificatu per identificà. Stu certificatu hè utilizatu per accede à u almacenamentu secretu o per cumunicà cù altri servizii via mTLS. Intantu, u Container Init Configurator è Daemon scaricanu tutte e dipendenze necessarie prima di eseguisce l'applicazione containerizzata. Quandu tuttu hè prontu, u trafficu sidecar è Daemon registrà l'indirizzu IP di u modulu cù u nostru Zookeeper per chì i clienti ponu scopre. Tuttu chistu hà da travaglià perchè u modulu di a rete hè stata cunfigurata prima chì l'applicazione hè stata lanciata.
I sopra sò esempi tipici di supportu di runtime per carichi di travagliu. Altri tipi di carichi di travagliu ponu esse bisognu di supportu ligeramente sfarente, ma tutti venenu in forma di sidecars à livellu di pod, Demoni à livellu di nodu o di macchina virtuale. Assicurendu chì tuttu questu hè implementatu in l'infrastruttura di gestione è hè coerente in tutte l'applicazioni, chì infine riduce significativamente u pesu in termini di travagliu tecnicu è supportu di i clienti.
Test è QA
Avemu custruitu un pipeline di teste end-to-end in cima à l'infrastruttura di teste Kubernetes esistente. Queste teste si applicanu à tutti i nostri clusters. U nostru pipeline hà attraversatu parechje revisioni prima di diventà parti di u cluster di produttu.
In più di i sistemi di teste, avemu un sistema di monitoraghju è d'alerta chì monitoranu constantemente u statutu di i cumpunenti di u sistema, u cunsumu di risorse è altri indicatori impurtanti, avvisendu solu quandu l'intervenzione umana hè necessaria.
Alternattivi
Avemu guardatu alcune alternative à risorse persunalizate, cum'è i cuntrolli d'accessu di mutazione è i sistemi di mudelli. Tuttavia, tutti venenu cun sfidi operativi significativi, cusì avemu sceltu a strada CRD.
Un controller d'admission mutational hè statu utilizatu per intruduce sidecars, variabili di l'ambienti è altre supportu di runtime. In ogni casu, hà affruntatu diversi prublemi, cum'è l'associazione di risorse è a gestione di u ciclu di vita, induve tali prublemi ùn sò micca in CRD.
Nutate bè: Sistemi di mudelli cum'è i charts Helm sò ancu largamente utilizati per eseguisce applicazioni cù cunfigurazioni simili. Tuttavia, e nostre applicazioni di travagliu sò troppu diverse per esse gestite cù mudelli. Inoltre durante a implementazione cuntinuu ci saranu troppu errori quandu si usanu mudelli.
U travagliu à vene
Attualmente avemu trattatu cù una carica mista in tutti i nostri clusters. Per sustene tali prucessi di diversi tipi è dimensioni, travagliemu in i seguenti spazii:
- Una cullizzioni di clusters distribuisce grandi applicazioni in diversi clusters per scalabilità è stabilità.
- Assicurendu a stabilità di u cluster, a scalabilità è a visibilità per creà una connettività di l'applicazioni è SLA.
- Gestisce risorse è quotes per chì l'applicazioni ùn sò micca cunflittu cù l'altri, è a scala di u cluster hè cuntrullata da a nostra parte.
- Una nova piattaforma CI/CD per supportà è implementà applicazioni in Kubernetes.
Source: www.habr.com