Vuosien varrella Pinterestin 300 miljoonaa käyttäjää ovat luoneet yli 200 miljardia nastaa yli 4 miljardille taululle. Tämän käyttäjien armeijan ja laajan sisältöpohjan palvelemiseksi portaali on kehittänyt tuhansia palveluita, jotka vaihtelevat muutaman prosessorin käsittelemistä mikropalveluista jättimäisiin monoliitteihin, jotka toimivat kokonaisessa virtuaalikoneiden laivastossa. Ja sitten koitti se hetki, kun yrityksen katse osui k8:aan. Miksi "kuutio" näytti hyvältä Pinterestissä? Opit tästä käännöksestämme äskettäin julkaistusta artikkelista .
Siis satoja miljoonia käyttäjiä ja satoja miljardeja nastaja. Palvellaksemme tätä käyttäjien armeijaa ja laajaa sisältökantaa olemme kehittäneet tuhansia palveluita, jotka vaihtelevat muutamalla prosessorilla käsiteltävistä mikropalveluista jättimäisiin monoliitteihin, jotka toimivat kokonaisissa virtuaalikoneissa. Lisäksi meillä on useita kehyksiä, jotka saattavat myös vaatia CPU-, muisti- tai I/O-käyttöä.
Tämän työkalujen eläintarhan ylläpidossa kehitystiimi kohtaa useita haasteita:
- Insinööreillä ei ole yhtenäistä tapaa johtaa tuotantoympäristöä. Stateless-palvelut, Stateful-palvelut ja aktiivisesti kehitettävät projektit perustuvat täysin erilaisiin teknologiapinoihin. Tämä johti kokonaisen koulutuskurssin luomiseen insinööreille ja vaikeuttaa vakavasti myös infrastruktuuritiimimme työtä.
- Kehittäjät, joilla on oma virtuaalikoneen, aiheuttavat valtavan taakan sisäisille järjestelmänvalvojille. Tämän seurauksena sellaiset yksinkertaiset toiminnot kuin käyttöjärjestelmän tai AMI:n päivittäminen vievät viikkoja ja kuukausia. Tämä johtaa lisääntyneeseen työmäärään näennäisesti aivan jokapäiväisissä tilanteissa.
- Vaikeuksia luoda globaaleja infrastruktuurin hallintatyökaluja olemassa olevien ratkaisujen päälle. Tilannetta vaikeuttaa entisestään se, että virtuaalikoneiden omistajien löytäminen ei ole helppoa. Toisin sanoen emme tiedä, voidaanko tämä kapasiteetti ottaa turvallisesti käyttöön infrastruktuurimme muissa osissa.
Säilön orkestrointijärjestelmät ovat tapa yhtenäistää työkuorman hallintaa. Ne avaavat oven nopeutuneelle kehitysnopeudelle ja yksinkertaistavat infrastruktuurin hallintaa, sillä kaikkia projektin resursseja hallitaan yhdessä keskitetyssä järjestelmässä.
Kuva 1: Infrastruktuurin painopisteet (luotettavuus, kehittäjän tuottavuus ja tehokkuus).
Pinterestin Cloud Management Platform -tiimi löysi K8:t vuonna 2017. Vuoden 2017 ensimmäiseen puoliskoon mennessä olimme dokumentoineet suurimman osan tuotantoominaisuuksistamme, mukaan lukien API ja kaikki verkkopalvelimemme. Tämän jälkeen teimme perusteellisen arvioinnin erilaisista konttiratkaisujen organisointiin, klustereiden rakentamiseen ja niiden kanssa työskentelyyn liittyvistä järjestelmistä. Vuoden 2017 lopulla päätimme käyttää Kubernetesiä. Se oli melko joustava ja laajasti tuettu kehittäjäyhteisössä.
Tähän mennessä olemme rakentaneet omat Kopsiin perustuvat klusterin käynnistystyökalumme ja siirtäneet olemassa olevat infrastruktuurikomponentit, kuten verkottumisen, tietoturvan, mittaustulokset, kirjaamisen, identiteetinhallinnan ja liikenteen Kubernetesiin. Otimme myös resurssillemme käyttöön työkuorman mallinnusjärjestelmän, jonka monimutkaisuus on piilotettu kehittäjiltä. Nyt keskitymme klusterin vakauden varmistamiseen, skaalaamiseen ja uusien asiakkaiden yhdistämiseen.
Kubernetes: Pinterest Way
Kubernetesin aloittaminen Pinterestin tasolla alustana, josta insinöörimme haluaisivat, sisälsi monia haasteita.
Suurena yrityksenä olemme investoineet voimakkaasti infrastruktuurityökaluihin. Esimerkkejä ovat suojaustyökalut, jotka käsittelevät varmenteiden käsittelyä ja avainten jakelua, liikenteenohjauskomponentit, palvelunhakujärjestelmät, näkyvyyskomponentit sekä loki- ja mittauskomponentit. Kaikki tämä kerättiin syystä: kävimme läpi normaalin yrityksen ja erehdyksen polun, ja siksi halusimme integroida kaikki nämä laitteet Kubernetesin uuteen infrastruktuuriin sen sijaan, että keksisimme vanhan pyörän uudelleen uudelle alustalle. Tämä lähestymistapa yksinkertaisti yleisesti siirtoa, koska kaikki sovellustuki on jo olemassa, eikä sitä tarvitse luoda tyhjästä.
Toisaalta itse Kubernetesin kuormitusennustemallit (kuten käyttöönotot, työt ja Daemon-sarjat) eivät riitä projektiimme. Nämä käytettävyysongelmat ovat suuria esteitä Kubernetesiin siirtymiselle. Olemme esimerkiksi kuulleet palvelukehittäjien valittavan puuttuvista tai virheellisistä kirjautumisasetuksista. Kohtasimme myös mallimoottorien virheellistä käyttöä, kun satoja kopioita luotiin samoilla eritelmillä ja tehtävällä, mikä johti painajaisiin virheenkorjausongelmiin.
Oli myös erittäin vaikeaa ylläpitää eri versioita samassa klusterissa. Kuvittele asiakastuen monimutkaisuus, jos sinun on työskenneltävä samanaikaisesti useissa saman ajonaikaisen ympäristön versioissa kaikkine ongelmineen, vikoineen ja päivityksineen.
Pinterestin käyttäjäominaisuudet ja ohjaimet
Olemme kehittäneet omat mukautetut resurssimäärittelymme (CRD:t), jotta suunnittelijoidemme olisi helpompi ottaa Kubernetes käyttöön ja yksinkertaistaa ja nopeuttaa infrastruktuuriamme.
CRD:t tarjoavat seuraavat toiminnot:
- Yhdistämällä eri alkuperäisiä Kubernetes-resursseja niin, että ne toimivat yhtenä työmääränä. Esimerkiksi PinterestService-resurssi sisältää käyttöönoton, kirjautumispalvelun ja määrityskartan. Tämän ansiosta kehittäjät eivät tarvitse huolehtia DNS:n asettamisesta.
- Ota käyttöön tarvittava sovellustuki. Käyttäjän tulee keskittyä vain konttimäärittelyyn liiketoimintalogiikkansa mukaisesti, kun taas CRD-ohjain toteuttaa kaikki tarvittavat init-säilöt, ympäristömuuttujat ja pod-määritykset. Tämä tarjoaa kehittäjille täysin erilaisen mukavuuden tason.
- CRD-ohjaimet hallitsevat myös alkuperäisten resurssien elinkaarta ja parantavat virheenkorjauksen saatavuutta. Tämä sisältää haluttujen ja todellisten eritelmien yhteensovittamisen, CRD-tilan päivittämisen ja tapahtumalokien ylläpidon ja paljon muuta. Ilman CRD:tä kehittäjät joutuisivat hallitsemaan useita resursseja, mikä vain lisäisi virheiden todennäköisyyttä.
Tässä on esimerkki PinterestServicesta ja sisäisestä resurssista, jota valvojamme hallinnoi:
Kuten yllä näet, mukautetun säilön tukemiseksi meidän on integroitava aloitussäilö ja useita lisäosia turvallisuuden, näkyvyyden ja verkkoliikenteen tarjoamiseksi. Lisäksi loimme konfigurointikarttamalleja ja otimme käyttöön tuen PVC-malleille erätöitä varten sekä useiden ympäristömuuttujien seurannan identiteetin, resurssien kulutuksen ja roskien keräämisen seuraamiseksi.
On vaikea kuvitella, että kehittäjät haluaisivat kirjoittaa nämä määritystiedostot käsin ilman CRD-tukea, saati kokoonpanojen lisäylläpidosta ja virheenkorjauksesta.
Sovelluksen käyttöönoton työnkulku
Yllä oleva kuva näyttää, kuinka mukautettu Pinterest-resurssi otetaan käyttöön Kubernetes-klusteriin:
- Kehittäjät ovat vuorovaikutuksessa Kubernetes-klusterimme kanssa CLI:n ja käyttöliittymän kautta.
- CLI/UI-työkalut hakevat työnkulun kokoonpanon YAML-tiedostot ja muut koontiominaisuudet (sama versiotunnus) Artifactorystä ja lähettävät ne sitten työnhakupalveluun. Tämä vaihe varmistaa, että vain tuotantoversiot toimitetaan klusteriin.
- JSS on yhdyskäytävä useille alustoille, mukaan lukien Kubernetes. Täällä käyttäjä todennetaan, kiintiöt myönnetään ja CRD:n kokoonpano tarkistetaan osittain.
- Kun CRD on tarkistettu JSS-puolella, tiedot lähetetään k8s-alustan API:lle.
- CRD-ohjain valvoo tapahtumia kaikissa käyttäjäresursseissa. Se muuntaa CR:t alkuperäisiksi k8s-resurssiksi, lisää tarvittavat moduulit, asettaa sopivat ympäristömuuttujat ja suorittaa muita tukitoimia varmistaakseen, että konttikäyttöisillä käyttäjäsovelluksilla on riittävä infrastruktuurituki.
- CRD-ohjain välittää sitten vastaanotetut tiedot Kubernetes API:lle, jotta ajoittaja voi käsitellä ne ja ottaa ne tuotantoon.
Huomata: Tämä käyttöönottoa edeltävä työnkulku luotiin uuden k8s-alustan ensimmäisille käyttäjille. Jalostamme parhaillaan tätä prosessia integroidaksemme täysin uuden CI/CD:n kanssa. Tämä tarkoittaa, että emme voi kertoa sinulle kaikkea Kubernetesiin liittyvää. Odotamme innolla, että voimme jakaa kokemuksiamme ja tiimin edistystä tähän suuntaan seuraavassa blogikirjoituksessamme "CI/CD-alustan rakentaminen Pinterestille".
Erikoisresurssien tyypit
Pinterestin erityistarpeiden perusteella olemme kehittäneet seuraavat CRD:t, jotka sopivat erilaisiin työnkulkuihin:
- PinterestService ovat valtiottomia palveluita, jotka ovat olleet käynnissä pitkään. Monet ydinjärjestelmistämme perustuvat joukkoon tällaisia palveluita.
- PinterestJobSet mallintaa täyden syklin erätöitä. Pinterestissä yleinen skenaario on, että useat työt suorittavat samoja säilöjä rinnakkain muista vastaavista prosesseista riippumatta.
- PinterestCronJobia käytetään laajalti pienten jaksollisten kuormien yhteydessä. Tämä on kääre alkuperäiseen cron-työhön Pinterest-tukimekanismien kanssa, jotka vastaavat turvallisuudesta, liikenteestä, lokeista ja mittareista.
- PinterestDaemon sisältää infrastruktuuridaemonit. Tämä perhe kasvaa edelleen, kun lisäämme tukea klustereillemme.
- PinterestTrainingJob ulottuu Tensorflow- ja Pytorch-prosesseihin ja tarjoaa saman tason ajonaikaisen tuen kuin kaikki muut CRD:t. Koska Pinterest käyttää aktiivisesti Tensorflow- ja muita koneoppimisjärjestelmiä, meillä oli syy rakentaa erillinen CRD niiden ympärille.
Työskentelemme myös PinterestStatefulSetin parissa, joka mukautetaan pian tietovarastoihin ja muihin tilatietojärjestelmiin.
Ajonaikainen tuki
Kun sovelluskotelo suoritetaan Kubernetesissa, se vastaanottaa automaattisesti varmenteen tunnistaakseen itsensä. Tätä varmennetta käytetään pääsyyn salaiseen tallennustilaan tai viestimiseen muiden palvelujen kanssa mTLS:n kautta. Sillä välin Container Init Configurator ja Daemon lataavat kaikki tarvittavat riippuvuudet ennen konttisovelluksen suorittamista. Kun kaikki on valmis, liikenteen sivuvaunu ja Daemon rekisteröivät moduulin IP-osoitteen Zookeeperillemme, jotta asiakkaat voivat löytää sen. Kaikki tämä toimii, koska verkkomoduuli on määritetty ennen sovelluksen käynnistämistä.
Yllä olevat ovat tyypillisiä esimerkkejä työkuormien ajonaikaisesta tuesta. Muuntyyppiset työkuormat saattavat vaatia hieman erilaista tukea, mutta ne kaikki tulevat pod-tason sivuvaunujen, solmutason tai virtuaalikoneen tason demonien muodossa. Varmistamme, että kaikki tämä otetaan käyttöön hallintainfrastruktuurissa ja että se on johdonmukaista kaikissa sovelluksissa, mikä lopulta vähentää merkittävästi teknisen työn ja asiakastuen taakkaa.
Testaus ja laadunvarmistus
Rakensimme päästä päähän -testiputkiston olemassa olevan Kubernetes-testiinfrastruktuurin päälle. Nämä testit koskevat kaikkia klustereitamme. Valmistuksemme kävi läpi monia muutoksia, ennen kuin siitä tuli osa tuoteklusteria.
Testausjärjestelmien lisäksi meillä on valvonta- ja hälytysjärjestelmät, jotka seuraavat jatkuvasti järjestelmän komponenttien tilaa, resurssien kulutusta ja muita tärkeitä indikaattoreita ja ilmoittavat meille vain, kun ihmisen puuttuminen on tarpeen.
vaihtoehtoja
Tarkastelimme joitain vaihtoehtoja mukautetuille resursseille, kuten mutaatiopääsyohjaimet ja mallijärjestelmät. Niissä kaikissa on kuitenkin merkittäviä toiminnallisia haasteita, joten valitsimme CRD-reitin.
Mutaatiopääsyohjainta käytettiin sivuvaunujen, ympäristömuuttujien ja muun ajonaikaisen tuen käyttöönottamiseksi. Se kohtasi kuitenkin erilaisia ongelmia, kuten resurssien sitomisen ja elinkaarihallinnan, joita ei CRD:ssä esiinny.
Huom: Mallijärjestelmiä, kuten Helm-kaavioita, käytetään myös laajalti sovellusten suorittamiseen samanlaisilla kokoonpanoilla. Työsovelluksemme ovat kuitenkin liian monipuolisia hallittavaksi mallipohjien avulla. Myös jatkuvan käyttöönoton aikana tulee liian paljon virheitä käytettäessä malleja.
Tuleva työ
Käsittelemme tällä hetkellä sekakuormitusta kaikissa klustereissamme. Tukeaksemme tällaisia erityyppisiä ja -kokoisia prosesseja työskentelemme seuraavilla alueilla:
- Ryhmä klustereita jakaa suuret sovellukset eri klustereille skaalautuvuuden ja vakauden takaamiseksi.
- Klusterin vakauden, skaalautuvuuden ja näkyvyyden varmistaminen sovellusten liitettävyyden ja SLA-sopimusten luomiseksi.
- Hallitsemme resursseja ja kiintiöitä niin, että sovellukset eivät ole ristiriidassa keskenään ja klusterin laajuutta kontrolloidaan omalta osaltamme.
- Uusi CI/CD-alusta sovellusten tukemiseen ja käyttöönottoon Kubernetesissa.
Lähde: will.com