Paglikha ng kubernetes platform sa Pinterest

Sa paglipas ng mga taon, ang 300 milyong user ng Pinterest ay nakagawa ng higit sa 200 bilyong pin sa higit sa 4 na bilyong board. Upang pagsilbihan ang hukbong ito ng mga user at malawak na base ng nilalaman, ang portal ay bumuo ng libu-libong serbisyo, mula sa mga microservice na maaaring pangasiwaan ng ilang mga CPU, hanggang sa mga higanteng monolith na tumatakbo sa isang buong fleet ng mga virtual machine. At pagkatapos ay dumating ang sandali na ang mga mata ng kumpanya ay nahulog sa mga k8. Bakit maganda ang hitsura ng “cube” sa Pinterest? Malalaman mo ang tungkol dito mula sa aming pagsasalin ng isang kamakailang artikulo mula sa blog Pinterest engineering.

Kaya, daan-daang milyong mga gumagamit at daan-daang bilyong mga pin. Para pagsilbihan ang hukbong ito ng mga user at malawak na content base, nakabuo kami ng libu-libong serbisyo, mula sa mga microservice na maaaring pangasiwaan ng ilang CPU, hanggang sa mga higanteng monolith na tumatakbo sa buong fleet ng mga virtual machine. Bilang karagdagan, mayroon kaming iba't ibang mga framework na maaaring mangailangan din ng CPU, memory, o I/O access.

Sa pagpapanatili ng zoo ng mga tool na ito, nahaharap ang development team ng ilang hamon:

• Walang pare-parehong paraan para sa mga inhinyero na magpatakbo ng isang kapaligiran sa produksyon. Ang mga walang estado na serbisyo, Stateful na serbisyo at proyekto sa ilalim ng aktibong pag-unlad ay batay sa ganap na magkakaibang mga stack ng teknolohiya. Ito ay humantong sa paglikha ng isang buong kurso sa pagsasanay para sa mga inhinyero, at seryoso ring nagpapalubha sa gawain ng aming koponan sa imprastraktura.
• Ang mga developer na may sariling fleet ng mga virtual machine ay lumikha ng isang malaking pasanin sa mga panloob na administrator. Bilang resulta, ang mga simpleng operasyon gaya ng pag-update ng OS o AMI ay tumatagal ng mga linggo at buwan. Ito ay humahantong sa pagtaas ng workload sa tila ganap na pang-araw-araw na mga sitwasyon.
• Mga kahirapan sa paglikha ng mga pandaigdigang tool sa pamamahala ng imprastraktura bukod pa sa mga kasalukuyang solusyon. Ang sitwasyon ay mas kumplikado sa pamamagitan ng katotohanan na ang paghahanap ng mga may-ari ng mga virtual machine ay hindi madali. Ibig sabihin, hindi natin alam kung ang kapasidad na ito ay ligtas na makukuha para gumana sa ibang bahagi ng ating imprastraktura.

Ang mga container orchestration system ay isang paraan upang pag-isahin ang pamamahala ng workload. Binubuksan nila ang pinto sa pagtaas ng bilis ng pag-unlad at pinapasimple ang pamamahala sa imprastraktura, dahil ang lahat ng mga mapagkukunang kasangkot sa proyekto ay pinamamahalaan ng isang sentralisadong sistema.

Figure 1: Mga priyoridad sa imprastraktura (pagkakatiwalaan, produktibidad ng developer, at kahusayan).

Natuklasan ng Cloud Management Platform team sa Pinterest ang mga K8 noong 2017. Sa unang kalahati ng 2017, naidokumento na namin ang karamihan sa aming mga kakayahan sa produksyon, kabilang ang API at lahat ng aming web server. Pagkatapos, nagsagawa kami ng masusing pagtatasa ng iba't ibang mga sistema para sa pagsasaayos ng mga solusyon sa lalagyan, pagbuo ng mga kumpol at pakikipagtulungan sa kanila. Sa pagtatapos ng 2017, nagpasya kaming gamitin ang Kubernetes. Ito ay medyo nababaluktot at malawak na suportado sa komunidad ng developer.

Sa ngayon, nakagawa kami ng sarili naming mga cluster boot tool batay sa Kops at inilipat ang mga kasalukuyang bahagi ng imprastraktura gaya ng networking, seguridad, sukatan, pag-log, pamamahala ng pagkakakilanlan, at trapiko sa Kubernetes. Nagpatupad din kami ng workload modeling system para sa aming resource, ang pagiging kumplikado nito ay nakatago sa mga developer. Ngayon ay nakatuon kami sa pagtiyak ng katatagan ng cluster, pag-scale nito at pagkonekta ng mga bagong kliyente.

Kubernetes: Ang Pinterest Way

Ang pagsisimula sa Kubernetes sa sukat ng Pinterest bilang isang platform na magugustuhan ng aming mga inhinyero ay may kasamang maraming hamon.

Bilang isang malaking kumpanya, namuhunan kami nang malaki sa mga tool sa imprastraktura. Kasama sa mga halimbawa ang mga tool sa seguridad na humahawak sa pagpoproseso ng certificate at pamamahagi ng susi, mga bahagi ng kontrol sa trapiko, mga sistema ng pagtuklas ng serbisyo, mga bahagi ng visibility, at mga bahagi ng pagpapadala ng log at sukatan. Ang lahat ng ito ay nakolekta para sa isang kadahilanan: dumaan kami sa normal na landas ng pagsubok at pagkakamali, at samakatuwid gusto naming isama ang lahat ng kagamitang ito sa bagong imprastraktura sa Kubernetes sa halip na muling likhain ang lumang gulong sa isang bagong platform. Sa pangkalahatan, pinasimple ng diskarteng ito ang paglipat, dahil umiiral na ang lahat ng suporta sa application at hindi na kailangang gawin mula sa simula.

Sa kabilang banda, ang mga modelo ng pagtataya ng pag-load sa Kubernetes mismo (tulad ng mga deployment, trabaho, at set ng Daemon) ay hindi sapat para sa aming proyekto. Ang mga isyung ito sa usability ay malaking hadlang sa paglipat sa Kubernetes. Halimbawa, narinig namin ang mga developer ng serbisyo na nagreklamo tungkol sa nawawala o maling mga setting sa pag-log in. Nakatagpo din kami ng maling paggamit ng mga template engine, noong daan-daang kopya ang ginawa na may parehong detalye at gawain, na nagresulta sa mga problema sa pag-debug ng bangungot.

Napakahirap ding mapanatili ang iba't ibang bersyon sa parehong kumpol. Isipin ang pagiging kumplikado ng suporta sa customer kung kailangan mong magtrabaho nang sabay-sabay sa maraming bersyon ng parehong runtime environment, kasama ang lahat ng kanilang mga problema, bug at update.

Mga Property at Controller ng Gumagamit ng Pinterest

Upang gawing mas madali para sa aming mga inhinyero na ipatupad ang Kubernetes, at pasimplehin at pabilisin ang aming imprastraktura, bumuo kami ng sarili naming mga custom na resource definition (CRD).

Ang mga CRD ay nagbibigay ng sumusunod na pagpapaandar:

1. Pinagsasama-sama ang iba't ibang katutubong mapagkukunan ng Kubernetes upang gumana ang mga ito bilang iisang workload. Halimbawa, ang mapagkukunan ng PinterestService ay may kasamang deployment, isang serbisyo sa pag-login, at isang configuration map. Nagbibigay-daan ito sa mga developer na huwag mag-alala tungkol sa pag-set up ng DNS.
2. Ipatupad ang kinakailangang suporta sa aplikasyon. Kailangang tumuon lang ang user sa detalye ng container ayon sa kanilang lohika sa negosyo, habang ipinapatupad ng CRD controller ang lahat ng kinakailangang init container, mga variable ng kapaligiran at mga detalye ng pod. Nagbibigay ito ng kakaibang antas ng kaginhawaan para sa mga developer.
3. Pinamamahalaan din ng mga controller ng CRD ang lifecycle ng mga katutubong mapagkukunan at pinapahusay ang availability ng pag-debug. Kabilang dito ang pag-reconcile ng ninanais at aktwal na mga detalye, pag-update ng status ng CRD at pagpapanatili ng mga log ng kaganapan, at higit pa. Kung walang CRD, mapipilitan ang mga developer na pamahalaan ang maraming mapagkukunan, na magpapataas lamang ng posibilidad na magkamali.

Narito ang isang halimbawa ng isang PinterestService at isang panloob na mapagkukunan na pinamamahalaan ng aming controller:

Gaya ng nakikita mo sa itaas, upang suportahan ang isang custom na lalagyan kailangan naming isama ang isang lalagyan ng init at ilang mga add-on upang magbigay ng seguridad, visibility, at trapiko sa network. Bilang karagdagan, gumawa kami ng mga template ng configuration map at nagpatupad ng suporta para sa mga template ng PVC para sa mga batch na trabaho, pati na rin ang pagsubaybay sa maraming variable ng kapaligiran upang masubaybayan ang pagkakakilanlan, pagkonsumo ng mapagkukunan, at koleksyon ng basura.

Mahirap isipin na gugustuhin ng mga developer na isulat ang mga configuration file na ito sa pamamagitan ng kamay nang walang suporta sa CRD, lalo pa't higit pang mapanatili at i-debug ang mga configuration.

Daloy ng trabaho sa pag-deploy ng application

Ipinapakita ng larawan sa itaas kung paano mag-deploy ng custom na mapagkukunan ng Pinterest sa isang cluster ng Kubernetes:

1. Nakikipag-ugnayan ang mga developer sa aming Kubernetes cluster sa pamamagitan ng CLI at user interface.
2. Kinukuha ng mga tool ng CLI/UI ang configuration ng workflow na mga YAML file at iba pang build property (parehong bersyon ID) mula sa Artifactory at pagkatapos ay isumite ang mga ito sa Job Submission Service. Tinitiyak ng hakbang na ito na ang mga bersyon ng produksyon lang ang ihahatid sa cluster.
3. Ang JSS ay isang gateway para sa iba't ibang platform, kabilang ang Kubernetes. Dito na-authenticate ang user, ibinibigay ang mga quota at bahagyang nasuri ang configuration ng aming CRD.
4. Pagkatapos suriin ang CRD sa gilid ng JSS, ipapadala ang impormasyon sa k8s platform API.
5. Sinusubaybayan ng aming CRD controller ang mga kaganapan sa lahat ng mapagkukunan ng user. Kino-convert nito ang mga CR sa mga katutubong k8s na mapagkukunan, nagdaragdag ng mga kinakailangang module, nagtatakda ng naaangkop na mga variable ng kapaligiran, at nagsasagawa ng iba pang gawaing suporta upang matiyak na ang mga containerized na application ng user ay may sapat na suporta sa imprastraktura.
6. Pagkatapos, ipinapasa ng CRD controller ang natanggap na data sa Kubernetes API para maproseso ito ng scheduler at mailagay sa produksyon.

Nota: Ang pre-release na daloy ng trabaho ng deployment ay ginawa para sa mga unang user ng bagong k8s platform. Kasalukuyan kaming nasa proseso ng pagpino sa prosesong ito upang ganap na maisama sa aming bagong CI/CD. Nangangahulugan ito na hindi namin masasabi sa iyo ang lahat ng nauugnay sa Kubernetes. Inaasahan naming ibahagi ang aming karanasan at ang pag-unlad ng koponan sa direksyong ito sa aming susunod na post sa blog, "Pagbuo ng CI/CD platform para sa Pinterest."

Mga uri ng mga espesyal na mapagkukunan

Batay sa mga partikular na pangangailangan ng Pinterest, binuo namin ang mga sumusunod na CRD upang umangkop sa iba't ibang daloy ng trabaho:

• Ang PinterestService ay mga stateless na serbisyo na tumatakbo sa mahabang panahon. Marami sa aming mga pangunahing system ay batay sa isang hanay ng mga naturang serbisyo.
• Pinomodelo ng PinterestJobSet ang mga full cycle batch job. Ang isang karaniwang senaryo sa Pinterest ay ang maraming trabaho ay nagpapatakbo ng parehong mga lalagyan nang magkatulad, anuman ang iba pang katulad na proseso.
• Ang PinterestCronJob ay malawakang ginagamit kasabay ng maliliit na pana-panahong pagkarga. Ito ay isang wrapper para sa native cron work na may mga mekanismo ng suporta sa Pinterest na responsable para sa seguridad, trapiko, mga log at sukatan.
• PinterestDaemon ay kinabibilangan ng mga Daemon sa imprastraktura. Ang pamilyang ito ay patuloy na lumalaki habang nagdaragdag kami ng higit na suporta sa aming mga kumpol.
• Ang PinterestTrainingJob ay umaabot sa mga proseso ng Tensorflow at Pytorch, na nagbibigay ng parehong antas ng suporta sa runtime gaya ng lahat ng iba pang CRD. Dahil aktibong gumagamit ang Pinterest ng Tensorflow at iba pang machine learning system, nagkaroon kami ng dahilan upang bumuo ng hiwalay na CRD sa paligid nila.

Gumagawa din kami sa PinterestStatefulSet, na malapit nang iakma para sa mga data warehouse at iba pang stateful system.

Suporta sa runtime

Kapag ang isang application pod ay tumatakbo sa Kubernetes, awtomatiko itong nakakatanggap ng isang sertipiko upang makilala ang sarili nito. Ginagamit ang certificate na ito para ma-access ang lihim na storage o para makipag-ugnayan sa ibang mga serbisyo sa pamamagitan ng mTLS. Samantala, ida-download ng Container Init Configurator at Daemon ang lahat ng kinakailangang dependencies bago patakbuhin ang containerized na application. Kapag handa na ang lahat, irerehistro ng traffic sidecar at Daemon ang IP address ng module sa aming Zookeeper para matuklasan ito ng mga kliyente. Ang lahat ng ito ay gagana dahil ang network module ay na-configure bago ang application ay inilunsad.

Ang nasa itaas ay karaniwang mga halimbawa ng suporta sa runtime para sa mga workload. Ang iba pang mga uri ng workload ay maaaring mangailangan ng bahagyang naiibang suporta, ngunit lahat ng ito ay nasa anyo ng pod-level sidecars, node-level o virtual machine-level na mga Daemon. Tinitiyak namin na ang lahat ng ito ay na-deploy sa loob ng imprastraktura ng pamamahala at pare-pareho sa mga application, na sa huli ay makabuluhang binabawasan ang pasanin sa mga tuntunin ng teknikal na trabaho at suporta sa customer.

Pagsubok at QA

Bumuo kami ng end-to-end test pipeline sa itaas ng kasalukuyang imprastraktura ng pagsubok ng Kubernetes. Nalalapat ang mga pagsubok na ito sa lahat ng aming cluster. Ang aming pipeline ay dumaan sa maraming rebisyon bago ito naging bahagi ng cluster ng produkto.

Bilang karagdagan sa mga sistema ng pagsubok, mayroon kaming mga sistema ng pagsubaybay at alerto na patuloy na sinusubaybayan ang katayuan ng mga bahagi ng system, pagkonsumo ng mapagkukunan at iba pang mahahalagang tagapagpahiwatig, na nag-aabiso lamang sa amin kapag kinakailangan ang interbensyon ng tao.

Mga alternatibo

Tumingin kami sa ilang alternatibo sa mga custom na mapagkukunan, tulad ng mga mutation access controller at template system. Gayunpaman, lahat sila ay may kasamang makabuluhang mga hamon sa pagpapatakbo, kaya pinili namin ang ruta ng CRD.

Ginamit ang mutational admission controller para ipakilala ang mga sidecar, environment variable, at iba pang suporta sa runtime. Gayunpaman, nahaharap ito sa iba't ibang problema, tulad ng resource binding at lifecycle management, kung saan ang mga ganitong problema ay hindi lumalabas sa CRD.

Tandaan: Ang mga sistema ng template tulad ng mga Helm chart ay malawakang ginagamit upang magpatakbo ng mga application na may katulad na mga configuration. Gayunpaman, ang aming mga application sa trabaho ay masyadong magkakaibang upang pamahalaan gamit ang mga template. Gayundin sa patuloy na pag-deploy magkakaroon ng masyadong maraming mga error kapag gumagamit ng mga template.

Paparating na trabaho

Kasalukuyan kaming nakikitungo sa magkahalong pagkarga sa lahat ng aming mga kumpol. Upang suportahan ang mga ganitong proseso ng iba't ibang uri at laki, nagtatrabaho kami sa mga sumusunod na lugar:

• Ang isang koleksyon ng mga cluster ay namamahagi ng malalaking application sa iba't ibang mga cluster para sa scalability at katatagan.
• Tinitiyak ang katatagan ng cluster, scalability at visibility upang lumikha ng pagkakakonekta ng application at mga SLA.
• Pamamahala ng mga mapagkukunan at quota upang ang mga aplikasyon ay hindi magkasalungat sa isa't isa, at ang sukat ng cluster ay kinokontrol sa aming bahagi.
• Isang bagong platform ng CI/CD para sa pagsuporta at pag-deploy ng mga application sa Kubernetes.

Pinagmulan: www.habr.com