De-a lungul anilor, cei 300 de milioane de utilizatori Pinterest au creat peste 200 de miliarde de pini pe peste 4 miliarde de panouri. Pentru a servi această armată de utilizatori și o bază vastă de conținut, portalul a dezvoltat mii de servicii, de la microservicii care pot fi gestionate de câteva procesoare, până la monoliți giganți care rulează pe o întreagă flotă de mașini virtuale. Și apoi a venit momentul în care ochii companiei au căzut pe k8-uri. De ce „cubul” arăta bine pe Pinterest? Veți afla despre acest lucru din traducerea noastră a unui articol recent din .
Deci, sute de milioane de utilizatori și sute de miliarde de pini. Pentru a servi această armată de utilizatori și o bază vastă de conținut, am dezvoltat mii de servicii, de la microservicii care pot fi gestionate de câteva procesoare, până la monoliți giganți care rulează pe flote întregi de mașini virtuale. În plus, avem o varietate de cadre care pot necesita, de asemenea, acces CPU, memorie sau I/O.
În menținerea acestei grădini zoologice de instrumente, echipa de dezvoltare se confruntă cu o serie de provocări:
- Nu există o modalitate uniformă pentru ingineri de a rula un mediu de producție. Serviciile fără stat, serviciile cu stat și proiectele aflate în dezvoltare activă se bazează pe stive de tehnologie complet diferite. Acest lucru a condus la crearea unui întreg curs de formare pentru ingineri și, de asemenea, complică serios munca echipei noastre de infrastructură.
- Dezvoltatorii cu propria lor flotă de mașini virtuale creează o povară uriașă pentru administratorii interni. Ca rezultat, operațiuni atât de simple precum actualizarea sistemului de operare sau AMI durează săptămâni și luni. Acest lucru duce la creșterea volumului de muncă în situații aparent absolut cotidiene.
- Dificultăți în crearea instrumentelor globale de management al infrastructurii pe lângă soluțiile existente. Situația se complică și mai mult de faptul că găsirea proprietarilor mașinilor virtuale nu este ușoară. Adică, nu știm dacă această capacitate poate fi extrasă în siguranță pentru a opera în alte părți ale infrastructurii noastre.
Sistemele de orchestrare a containerelor sunt o modalitate de a unifica gestionarea sarcinii de lucru. Acestea deschid ușa către o viteză crescută de dezvoltare și simplifică gestionarea infrastructurii, deoarece toate resursele implicate în proiect sunt gestionate de un singur sistem centralizat.
Figura 1: Prioritățile de infrastructură (fiabilitatea, productivitatea dezvoltatorului și eficiența).
Echipa Cloud Management Platform de la Pinterest a descoperit K8-urile în 2017. Până în prima jumătate a anului 2017, am documentat majoritatea capacităților noastre de producție, inclusiv API-ul și toate serverele noastre web. Ulterior, am efectuat o evaluare amănunțită a diferitelor sisteme pentru orchestrarea soluțiilor de containere, construirea clusterelor și lucrul cu acestea. Spre sfârșitul anului 2017, am decis să folosim Kubernetes. A fost destul de flexibil și a fost susținut pe scară largă în comunitatea de dezvoltatori.
Până în prezent, ne-am construit propriile instrumente de pornire a clusterului bazate pe Kops și am migrat componentele existente ale infrastructurii, cum ar fi rețelele, securitatea, valorile, jurnalizarea, gestionarea identității și traficul către Kubernetes. De asemenea, am implementat un sistem de modelare a sarcinii de lucru pentru resursa noastră, a cărui complexitate este ascunsă dezvoltatorilor. Acum ne concentrăm pe asigurarea stabilității cluster-ului, scalarea acestuia și conectarea de noi clienți.
Kubernetes: Calea Pinterest
Începerea cu Kubernetes la scara Pinterest ca platformă pe care inginerii noștri ar adora a venit cu o mulțime de provocări.
Ca o companie mare, am investit masiv în instrumente de infrastructură. Exemplele includ instrumente de securitate care se ocupă de procesarea certificatelor și distribuirea cheilor, componente de control al traficului, sisteme de descoperire a serviciilor, componente de vizibilitate și componente de expediere a jurnalelor și a valorilor. Toate acestea au fost colectate dintr-un motiv: am trecut pe calea normală a încercărilor și erorilor și, prin urmare, am vrut să integrăm toate aceste echipamente în noua infrastructură de pe Kubernetes în loc să reinventăm vechea roată pe o nouă platformă. Această abordare a simplificat în general migrarea, deoarece tot suportul pentru aplicații există deja și nu trebuie creat de la zero.
Pe de altă parte, modelele de prognoză a încărcării din Kubernetes însuși (cum ar fi implementările, joburile și seturile Daemon) nu sunt suficiente pentru proiectul nostru. Aceste probleme de utilizare sunt bariere uriașe în calea trecerii la Kubernetes. De exemplu, am auzit dezvoltatorii de servicii plângându-se de setările de conectare lipsă sau incorecte. De asemenea, am întâlnit utilizarea incorectă a motoarelor de șabloane, când au fost create sute de copii cu aceeași specificație și sarcină, ceea ce a dus la probleme de depanare de coșmar.
De asemenea, a fost foarte dificil să menținem versiuni diferite în același cluster. Imaginează-ți complexitatea asistenței pentru clienți dacă trebuie să lucrezi simultan în mai multe versiuni ale aceluiași mediu de rulare, cu toate problemele, erorile și actualizările acestora.
Proprietăți și controlere ale utilizatorului Pinterest
Pentru a facilita implementarea Kubernetes de către inginerii noștri și pentru a simplifica și accelera infrastructura noastră, am dezvoltat propriile definiții personalizate de resurse (CRD).
CRD-urile oferă următoarele funcționalități:
- Combinând diferite resurse Kubernetes native, astfel încât acestea să funcționeze ca un singur volum de lucru. De exemplu, resursa PinterestService include o implementare, un serviciu de conectare și o hartă de configurare. Acest lucru permite dezvoltatorilor să nu-și facă griji cu privire la configurarea DNS.
- Implementați suportul necesar pentru aplicații. Utilizatorul trebuie să se concentreze doar pe specificația containerului în funcție de logica lor de afaceri, în timp ce controlerul CRD implementează toate containerele init necesare, variabilele de mediu și specificațiile podului. Acest lucru oferă un nivel fundamental diferit de confort pentru dezvoltatori.
- Controlerele CRD gestionează, de asemenea, ciclul de viață al resurselor native și îmbunătățesc disponibilitatea de depanare. Aceasta include reconcilierea specificațiilor dorite cu cele reale, actualizarea stării CRD și menținerea jurnalelor de evenimente și multe altele. Fără CRD, dezvoltatorii ar fi forțați să gestioneze mai multe resurse, ceea ce ar crește doar probabilitatea de eroare.
Iată un exemplu de PinterestService și o resursă internă care este gestionată de controlerul nostru:
După cum puteți vedea mai sus, pentru a susține un container personalizat, trebuie să integrăm un container init și mai multe suplimente pentru a oferi securitate, vizibilitate și trafic de rețea. În plus, am creat șabloane de hărți de configurare și am implementat suport pentru șabloane PVC pentru joburi în loturi, precum și urmărirea mai multor variabile de mediu pentru a urmări identitatea, consumul de resurse și colectarea gunoiului.
Este greu de imaginat că dezvoltatorii ar dori să scrie manual aceste fișiere de configurare fără suport CRD, darămite să întrețină și să depaneze în continuare configurațiile.
Flux de lucru pentru implementarea aplicației
Imaginea de mai sus arată cum să implementați o resursă personalizată Pinterest într-un cluster Kubernetes:
- Dezvoltatorii interacționează cu clusterul nostru Kubernetes prin interfața CLI și cu utilizatorul.
- Instrumentele CLI/UI preiau fișierele YAML de configurare a fluxului de lucru și alte proprietăți de compilare (același ID de versiune) de la Artifactory și apoi le trimit Serviciului de trimitere a joburilor. Acest pas asigură că numai versiunile de producție sunt livrate către cluster.
- JSS este o poartă de acces pentru diverse platforme, inclusiv Kubernetes. Aici utilizatorul este autentificat, se emit cote și se verifică parțial configurația CRD-ului nostru.
- După verificarea CRD-ului pe partea JSS, informațiile sunt trimise către API-ul platformei k8s.
- Controlerul nostru CRD monitorizează evenimentele pe toate resursele utilizatorilor. Convertește CR-urile în resurse native k8s, adaugă modulele necesare, stabilește variabilele de mediu adecvate și efectuează alte lucrări de asistență pentru a se asigura că aplicațiile utilizatorilor containerizate au suport suficient pentru infrastructură.
- Controlerul CRD transmite apoi datele primite către API-ul Kubernetes, astfel încât acestea să poată fi procesate de planificator și puse în producție.
Nota: Acest flux de lucru pre-lansare al implementării a fost creat pentru primii utilizatori ai noii platforme k8s. În prezent, suntem în proces de perfecționare a acestui proces pentru a ne integra pe deplin cu noul nostru CI/CD. Aceasta înseamnă că nu vă putem spune tot ce este legat de Kubernetes. Așteptăm cu nerăbdare să împărtășim experiența noastră și progresul echipei în această direcție în următoarea noastră postare pe blog, „Crearea unei platforme CI/CD pentru Pinterest”.
Tipuri de resurse speciale
Pe baza nevoilor specifice ale Pinterest, am dezvoltat următoarele CRD-uri pentru a se potrivi diferitelor fluxuri de lucru:
- PinterestService sunt servicii apatride care rulează de mult timp. Multe dintre sistemele noastre de bază se bazează pe un set de astfel de servicii.
- PinterestJobSet modelează joburi de lot cu ciclu complet. Un scenariu comun pe Pinterest este că mai multe joburi rulează aceleași containere în paralel, indiferent de alte procese similare.
- PinterestCronJob este utilizat pe scară largă împreună cu sarcini periodice mici. Acesta este un înveliș pentru lucrul cron nativ cu mecanisme de asistență Pinterest care sunt responsabile pentru securitate, trafic, jurnale și valori.
- PinterestDaemon include Daemonii de infrastructură. Această familie continuă să crească pe măsură ce adăugăm mai mult sprijin clusterelor noastre.
- PinterestTrainingJob se extinde la procesele Tensorflow și Pytorch, oferind același nivel de suport pentru runtime ca toate celelalte CRD-uri. Deoarece Pinterest folosește în mod activ Tensorflow și alte sisteme de învățare automată, am avut un motiv să construim un CRD separat în jurul lor.
De asemenea, lucrăm la PinterestStatefulSet, care va fi adaptat în curând pentru depozitele de date și alte sisteme cu stare.
Suport de rulare
Când un pod de aplicație rulează pe Kubernetes, primește automat un certificat pentru a se identifica. Acest certificat este folosit pentru a accesa stocarea secretă sau pentru a comunica cu alte servicii prin mTLS. Între timp, Container Init Configurator și Daemon vor descărca toate dependențele necesare înainte de a rula aplicația containerizată. Când totul este gata, sidecar-ul de trafic și Daemon vor înregistra adresa IP a modulului la Zookeeper, astfel încât clienții să o poată descoperi. Toate acestea vor funcționa deoarece modulul de rețea a fost configurat înainte de lansarea aplicației.
Cele de mai sus sunt exemple tipice de suport de rulare pentru încărcături de lucru. Alte tipuri de sarcini de lucru pot necesita suport ușor diferit, dar toate vin sub formă de sidecar-uri la nivel de pod, demoni la nivel de nod sau la nivel de mașină virtuală. Ne asigurăm că toate acestea sunt implementate în cadrul infrastructurii de management și sunt consecvente între aplicații, ceea ce în cele din urmă reduce semnificativ sarcina în ceea ce privește munca tehnică și asistența clienților.
Testare și QA
Am construit o conductă de testare end-to-end pe deasupra infrastructurii de testare Kubernetes existente. Aceste teste se aplică tuturor clusterelor noastre. Conducta noastră a trecut prin multe revizuiri înainte de a deveni parte a clusterului de produse.
Pe lângă sistemele de testare, avem sisteme de monitorizare și alertă care monitorizează constant starea componentelor sistemului, consumul de resurse și alți indicatori importanți, anunțându-ne doar atunci când este necesară intervenția umană.
alternative
Am analizat câteva alternative la resursele personalizate, cum ar fi controlere de acces pentru mutații și sisteme șablon. Cu toate acestea, toate vin cu provocări operaționale semnificative, așa că am ales ruta CRD.
Un controler de admitere mutațional a fost folosit pentru a introduce sidecar-uri, variabile de mediu și alte suporturi de rulare. Cu toate acestea, sa confruntat cu diverse probleme, cum ar fi legarea resurselor și managementul ciclului de viață, în cazul în care astfel de probleme nu apar în CRD.
Nota: Sistemele de șabloane, cum ar fi diagramele Helm, sunt, de asemenea, utilizate pe scară largă pentru a rula aplicații cu configurații similare. Cu toate acestea, aplicațiile noastre de lucru sunt prea diverse pentru a fi gestionate folosind șabloane. De asemenea, în timpul implementării continue, vor apărea prea multe erori la utilizarea șabloanelor.
Lucrare viitoare
În prezent avem de-a face cu o sarcină mixtă în toate clusterele noastre. Pentru a susține astfel de procese de diferite tipuri și dimensiuni, lucrăm în următoarele domenii:
- O colecție de clustere distribuie aplicații mari în diferite clustere pentru scalabilitate și stabilitate.
- Asigurarea stabilității, scalabilității și vizibilității clusterului pentru a crea conectivitate pentru aplicații și SLA.
- Gestionarea resurselor și a cotelor astfel încât aplicațiile să nu intre în conflict între ele, iar scara clusterului este controlată din partea noastră.
- O nouă platformă CI/CD pentru susținerea și implementarea aplicațiilor pe Kubernetes.
Sursa: www.habr.com