Pinterest on aastate jooksul saavutanud 300 miljonit kasutajat, kes on loonud üle 200 miljardi pinnakujunduse enam kui 4 miljardi tahvlile. Selle kasutajate armee ja laia sisu alusmassi teenindamiseks on portaal arendanud tuhandeid teenuseid, alustades mikroteenustest, millega suudab toime tulla paar CPU-d, ja lõpetades tohututega, mis töötavad terve hulga virtuaalmasinate peal. Nüüd on käes aeg, mil ettevõtte pilk langes k8s-ile. Miks siis .
Nii et sadade miljonite kasutajate ja sadade miljardite pinnade puhul oleme välja töötanud tuhandeid teenuseid, alustades mikroteenustest, millega suudab toime tulla paar CPU-d, ja lõpetades tohututega, mis töötavad terve hulga virtuaalmasinate peal. Lisaks on meil mitmekesised raamistikud, mis võivad samuti nõuda CPU, mälu või sisend-väljund protsesside ressursse.
Selle tööriistade zoolooge toetamise protsessi käigus seisavad arendustiimid silmitsi mitmete probleemidega:
- Inseneridel puudub ühtne viis töötava keskkonna käivitamiseks. Stateless-teenused, Stateful-teenused ja aktiivselt arendatavad projektid põhinevad täiesti erinevatel tehnoloogia stekkidel. See on viinud inseneridele mõeldud koolituskursuste loomise ja oluliselt keerukama töö meie infrastruktuuri meeskonnale.
- Arendajad, kes omavad oma virtuaalmasinate parki, loovad tohutut koormust sisemistele administreerijatele. Lõpptulemusena venivad näiliselt lihtsad operatsioonid, nagu OS või AMI uuendamine, nädalateks ja kuudeks. See toob kaasa koormuse kasvu, isegi mõnes igapäevases olukorras.
- Globaalsete infrastruktuuri haldustööriistade loomise raskused olemasolevate lahenduste peal. Olukorda raskendab veelgi see, et virtuaalmasinate omanike leidmine pole lihtne. See tähendab, et me ei tea, kas neid ressursse on ohutu tõmmata, et need töötaksid meie infrastruktuuri teistes osades.
Konteinerite orkestreerimissüsteemid on viis ühtlustada töökoormuse haldamist. Need avavad teile tee arenduse kiirendamiseks ja lihtsustavad infrastruktuuri haldamist, kuna kõik projekti kaasatud ressursid hallatakse ühe keskse süsteemi kaudu.
Joonis 1: Infrastruktuuri prioriteedid (usaldusväärsus, arendajate tulemuslikkus ja efektiivsus).
Pinterest'i Cloud Management Platform meeskond tutvus K8s-iga 2017. aastal. 2017. aasta esimese pooleks dokumenteerisime suure osa meie tootmisvõimsusest, sealhulgas API ja kõik meie veebiserverid.Pärast seda viisime läbi põhjaliku hindamise erinevate konteinerite orkestratsioonisüsteemide, klastrite loomise ja nende haldamise osas. 2017. aasta lõpuks otsustasime Kubernetes'e kasuks. See oli piisavalt paindlik ja laialdaselt toetatud arendajate kogukonnas.
Käesolevaks hetkeks oleme loonud oma alglaadimisriistade komplekti Kopsi põhjal ja viinud meie olemasolevad infrastruktuuri komponendid - nagu võrk, turvalisus, mõõdikud, logimine, identiteedihalduse ja liikluse - Kubernetes'esse. Samuti oleme rakendanud töökoormuste modelleerimise süsteemi meie ressursile, mille keerukus on arendajatelt varjatud. Praegu keskendume klastri stabiilsuse tagamisele, selle skaleerimisele ja uute klientide ühendamisele.
Kubernetes: Pinterest'i tee
Kubernetes'ega alustamine Pinterestis platvormina, millest meie insenerid armastavad, tõi kaasa palju raskusi.
Suurena investeerisime infrastruktuuri tööriistadesse märkimisväärseid summasid. Näiteks võib tuua turvalisuse tööriistad, mis käsitlevad sertifikaate ja jagavad võtmeid, liikluse kontrolli komponente, teenuste avastamise süsteeme, nähtavuse ja logide ning mõõdikute saatmise komponente. Kõik see ei olnud lihtsalt kokku pandud: läbisime normaalse katsetamise ja eksimise tee ning soovisime integreerida kogu selle halduse uude infrastruktuuri Kubernetes'el, selle asemel et leiutada vana jalgratast uuel platvormil. Selline lähenemine lihtsustas sisuliselt migratsiooni, kuna kogu rakendustoetust oli juba olemas, seda ei pidanud nullist looma.
Teisest küljest ei piisa meie projektile Kubernetes'i ennustamis- ja koormuse haldamise mudelitest (nt rakenduste, ülesannete ja Daemon'i kogumite kohta). Need kasutatavuse probleemid on tohutud takistused Kubernetes'ile ülemiseks. Näiteks oleme kuulnud, kuidas teenuse arendajad on kurtnud ligipääsu puudumise või vale seadistamise üle. Samuti on meil olnud probleeme mallide vale kasutamisega, kui loodi sadu koopiaid sama spetsifikatsiooni ja ülesandega, mis tekitas kohutavaid tõrkeid.
Samuti oli väga keeruline toetada erinevaid versioone samas klastris. Kujutage ette, kui keeruline on kliendituge pakkuda, kui pead tegelema mitme versiooniga samas töökeskkonnas kõikide nende probleemide, vigade ja uuendustega.
Pinterest'i kohandatud ressursid ja kontrollerid
Kuna meie inseneride Kubernetes'i rakendamise protsessi lihtsustamiseks ning infrastruktuuri hõlbustamiseks ja kiirendamiseks arendasime välja oma kohandatud ressursside määratlemised (CRD).
CRD pakuvad järgmisi funktsionaalsusi:
- Erinevate natiivsete Kubernetes'i ressursside ühendamine, et need töötaksid kui üks koormus. Näiteks sisaldab PinterestService ressurss rakendust, ligipääsu teenust ja konfigureerimiskaarti. See võimaldab arendajatel mitte muretseda DNS-i seadistamise pärast.
- Rakenduste vajaliku toe pakkumine. Kasutaja peab keskenduma ainult konteineri spetsifikatsioonile vastavalt oma äriloogikale, samas kui CRD kontroller rakendab kõik vajalikud init-konteinerid, keskkonnamuutujad ja pod'i spetsifikatsioonid. See tagab arendajatele täiesti uue mugavuse taseme.
- CRD kontrollerid haldavad ka oma ressursside elutsüklit ja suurendavad tõrkeotsingu kättesaadavust. See hõlmab soovitud ja reaalse spetsifikatsiooni kooskõlastamist, CRD staatuse uuendamist ning sündmuste logimist ja palju muud. Ilma CRD-deta oleks arendajad sunnitud haldama rohkearvulisi ressursside komplekte, mis suurendaks ainult vea tõenäosust.
Siin on näide PinterestService'ist ja sisemisest ressursist, mida haldab meie kontroller:
Nagu ülal näha, on kasutajate konteineri toetamiseks vajalik integreerida sellesse initsialiseerimise konteiner ja mitmed lisandmoodulid, et tagada turvalisus, nähtavus ja võrgu liiklusega töötamine. Lisaks on loodud konfiguratsioonikaartide mallid ja rakendatud PVC-mallide toetus partiiülesannete jaoks, samuti jälgitakse keskkonnaparameetreid identifitseerimise, ressursikasutuse ja "prügi" kogumise jälgimiseks.
Raske on ette kujutada, et arendajad sooviksid neid konfiguratsioonifaile käsitsi kirjutada ilma CRD toeta, rääkimata edasisest korraldamisest ja konfiguratsioonide tõrkeotsingust.
Rakenduste juurutamise töövoog
Ülaloleval joonisel on näidatud, kuidas juurutada kasutajate ressurssi Pinterest Kubernetes klasteris:
- Arendajad suhtlevad meie Kubernetes klastriga CLI ja kasutajaliidese kaudu.
- CLI / UI tööriistad väljastavad töövoo YAML-konfiguratsioonifailid ja muud kokkupaneku omadused (sama versiooni number) Artifactory'st, mille järel saadetakse need Töö Esitamise Teenusele. See samm tagab, et klastri installitakse ainult stabiilsed versioonid.
- JSS on värav erinevatele platvormidele, sealhulgas Kubernetes. Siin toimub kasutaja autentimine, kvootide jagamine ja meie CRD konfiguratsiooni osaline kontroll.
- Pärast CRD kontrollimist JSS poolel saadetakse teave k8s API-le.
- Meie CRD-kontroller jälgib sündmusi kõigis kasutajate ressurssides. Ta muudab CR-i Kubernetes'i natiivseteks ressurssideks, lisab vajalikud moodulid, seadistab vastavad keskkonnaparameetrid ja täidab muid abiprotseduure, tagades, et konteineripõhised kasutaja rakendused saavad piisavat infrastruktuuri toetust.
- Seejärel edastab CRD kontroller saadud andmed Kubernetes API-le, et need saaksid ajakava koostajal töötlemiseks ja käivitamiseks.
Märkus: see eegi eelduslik töövoog kodutekstide reklaamimisel on loodud uus K8s platvorm. Praegu oleme protsessi täiendamise faasis, et täielikult integreerida see meie uue CI/CD-ga. See tähendab, et me ei saa kõike Kubernetese teemal jagada. Ootame põnevusega võimalust jagada meie kogemusi ja rääkida meeskonna edusammudest selles osas meie järgmises blogipostituses "CI/CD platvormi loomine Pinterestile".
Eri ressursi tüübid
Võttes arvesse Pinterest'i konkreetseid vajadusi, oleme välja töötanud järgmised CRD-d, mis sobivad erinevate tööprotsesside jaoks:
- PinterestService on juba pikka aega töötanud stateless-teenusena. Paljud meie põhikeskused põhinevad selliste teenuste kogumitel.
- PinterestJobSet modelleerib täieliku tsükli partiiülesandeid. Pinterestis on levinud stsenaarium, kus mitmed ülesanded käivitavad sama konteinerit paralleelselt, sõltumata teistest sarnastest protsessidest.
- PinterestCronJob on laialdaselt rakendatav väikeste perioodiliste koormuste korral. See on kesta jaoks loodud natüüri cron, mis töötab Pinterest'i toetamiseks, tagades turvalisuse, liikluse, logid ja mõõdikud.
- PinterestDaemon hõlmab infrastruktuuri Daemoneid. See perede kasvab, kuna lisame rohkem tuge meie klastritele.
- PinterestTrainingJob katab Tensorflow ja Pytorch protsessid, pakkudes sama tasemega tuge nagu kõik teised CRD-d. Kuna Pinterest kasutab aktiivselt Tensorflow't ja muid masinõppe süsteeme, oli meil põhjust luua nende ümber eraldi CRD.
Samuti töötame PinterestStatefulSet'i kallal, mis kohandatakse peagi andmesalvestuse ja teiste stateful süsteemide jaoks.
Käivitamisringkonna tugi
Kui rakenduse moodul käivitub Kuberneteses, saab see automaatselt sertifikaadi enda tuvastamiseks. Seda sertifikaati kasutatakse salajasse hoidlast pääsemiseks või teiste teenustega suhtlemiseks mTLS kaudu. Sel ajal laadivad konteinerite initsialiseerijal ja Daemon kõik vajalikud sõltuvused enne konteinerirakenduse käivitamist. Kui kõik on valmis, registreerivad sidecar ja Daemon mooduli IP-aadressi meie Zookeeperis, et kliendid saaksid selle avastada. Kõik see toimib, kuna võrgu moodul oli seadistatud juba enne rakenduse käivitamist.
Ülaltoodud on tüüpilised näited töökoormuste toetamisest käitamise ajal. Teiste tüüpi töökoormuste jaoks võib vajada veidi teistsugust tuge, kuid need on esitatud podi taseme sidecar'ide, sõlme või virtuaalmasina taseme Daemon'ide kujul. Me hoolitseme selle eest, et kõik see oleks juurutatud haldussüsteemi raames ja rakenduste vahel kooskõlastatud, mis vähendab oluliselt tehniliste tööde ja klienditoe koormust.
Testimine ja QA
Oleme kogunud end-to-end testimise konveieri juba olemasoleva Kubernetes testimisstruktuuri kohale. Need testid laienevad kõigile meie klastritele. Meie torujuhe on läbi teinud palju ümberkorraldusi, enne kui sai tootlikku klastrisse osa.
Lisaks testimissüsteemidele on meil olemas jälgimis- ja teavitussüsteemid, mis jälgivad pidevalt süsteemi komponentide seisundit, ressursikasutust ja muid olulisi näitajaid, teavitades meid ainult siis, kui on vajalik inimeste sekkumine.
Alternatiivid
Oleme kaalunud mõningaid alternatiive kohandatud ressursside jaoks, nagu mutatsioonikontrollerid ja mallisüsteemid. Kuid kõik need on seotud tõsiste tööprobleemidega, seega otsustasime CRD tee valida.
Mutatsioonikontrollerit kasutati sidecaride, keskkonnamuutujate ja muu toe sisenemiseks käitusaja jooksul. Kuid see kohtas erinevaid probleeme, näiteks ressursside sidumise ja nende elutsükli haldamise osas, samas kui CRD-de puhul neid probleeme ei esine.
Märkus: Mudel süsteemid, nagu Helm diagrammid, on samuti laialdaselt kasutusel sarnaste konfiguratsioonidega rakenduste käivitamiseks. Kuid meie töötavad rakendused on liiga mitmekesised, et neid hallata mallide abil. Samuti tekib mallide kasutamisel pideva juurutamise ajal liiga palju tõrkeid.
Eelseisev töö
Praegu tegeleme kõigis meie klastrites segatud koormusega. Selliste erinevat tüüpi ja suurusega protsesside toetamiseks töötame järgmistes suundades:
- Klastrite kogum jagab suured rakendused erinevatele klastritele, et tagada skaleeritavus ja stabiilsus.
- Klastri stabiilsuse, skaleeritavuse ja nähtavuse tagamine rakenduse ja selle SLA vahelise seose loomiseks.
- Ressursside ja kvotade haldamine, et rakendused ei konkureeriks omavahel ja klastrite suurust saaks meie poolt kontrollida.
- Uus CI/CD platvorm rakenduste toetamiseks ja juurutamiseks Kuberneteses.
Allikas: habr.com
