🥇Po krijojmë platformën kubernetes në Pinterest

Gjatë viteve të saj të ekzistencës, Pinterest ka pasur 300 milion përdorues që kanë krijuar më shumë se 200 miliard pin-e në më shumë se 4 miliard tabela. Për të mbështetur këtë ushtri përdoruesish dhe këtë bazë të gjerë përmbajtjeje, portali ka zhvilluar mijëra shërbime, që nga mikroshërbimet, të cilat menaxhohen nga disa CPU, deri te monolitë gjigantë që funksionojnë në një tërë park virtualësh. Dhe erdhi momenti kur kompania e përqendroi vëmendjen në k8s. Çfarë e tërhiqte "kubin" te "Pinterest"? Këtë do ta mësoni nga përkthimi ynë i një artikulli të ri nga blogu i inxhinierisë Pinterest.

Pra, qindra milion përdorues dhe qindra miliard pin-e. Për të mbështetur këtë ushtri përdoruesish dhe këtë bazë të gjerë përmbajtjeje, ne kemi zhvilluar mijëra shërbime, që nga mikroshërbimet, të cilat menaxhohen nga disa CPU, deri te monolitë gjigantë që funksionojnë në një tërë park virtualësh. Përveç kësaj, kemi gjithashtu një larmi kornizash që gjithashtu mund të kërkojnë burime CPU, kujtime ose qasje në operacionet e hyjshëm-dalës.

Gjatë mbështetjes së këtij zoo të veglave, ekipi i zhvillimit përballet me disa sfida:

Inxhinierët nuk kanë një mënyrë të unifikuar për të nisur mjedisin e punës. Shërbimet pa gjendje, shërbimet me gjendje dhe projektet në zhvillim aktiv bazohen në steka teknologjikë krejtësisht të ndryshëm. Kjo ka sjellë krijimin e një kursi të tërë trajnimi për inxhinierët dhe gjithashtu e komplikon ndjeshëm punën e ekipit tonë të infrastrukturës.
Zhvilluesit, që kanë të disponueshëm parqet e tyre të virtualëve, krijojnë një ngarkesë të madhe për administratorët tanë të brëndshëm. Në fund, operacione të tilla të thjeshta si përditësimi i OS ose AMI shtrihen në javë dhe muaj. Kjo çon në rritjen e ngarkesës në situata që duket se janë krejtësisht të zakonshme.
Vështirësitë në krijimin e mjeteve globale të menaxhimit të infrastrukturës mbi zgjidhjet që tashmë ekzistojnë. Situata komplikohet akoma më shumë nga fakti se është e vështirë të gjejmë pronarët e virtualëve. Pra, ne nuk e dimë nëse mund të nxjerrim sigurtë këto burime për t'i përdorur në pjesë të tjera të infrastrukturës sonë.

Sistemet e orkestrimit të kontejnerëve janë një mënyrë për të unifikuar menaxhimin e ngarkesës së punës. Ato ju hapin rrugën për të rritur shpejtësinë e zhvillimit dhe lehtësojnë menaxhimin e infrastrukturës, pasi të gjitha burimet e angazhura në projekt administrohen nga një sistem i centralizuar.

Figura 1: Prioritetet e infrastrukturës (besueshmëria, performanca e zhvilluesve dhe efikasiteti).

Ekipi i Platformës së Menaxhimit të Releve në Pinterest u njoftua me K8s në vitin 2017. Në gjysmën e parë të vitit 2017, ne dokumentuam pjesën më të madhe të kapaciteteve tona prodhuese, përfshirë API-të dhe të gjithë shërbimet tona web. Më pas, ne bëmë një vlerësim të kujdesshëm të sistemeve të ndryshme të orkestrimit të kontejnerëve, ndërtimit të klasterëve dhe punës me to. Në fund të vitit 2017, ne vendosëm të shfrytëzojmë Kubernetes. Ai ishte mjaft fleksibël dhe mbështetej gjerësisht në komunitetin e zhvilluesve.

Derisa kemi krijuar mjete të tona për ngarkesën fillestare të klasterit të bazuar në Kops dhe kemi kaluar në Kubernetes komponentët ekzistues të infrastrukturës — siç janë rrjeti, siguria, metrikat, regjistrimi, menaxhimi i identitetit dhe trafiku. Po ashtu kemi implemetuar një sistem modelimi të ngarkesave të punës për burimin tonë, komplekset e të cilit janë të fshehura nga zhvilluesit. Tani jemi përqëndruar në sigurinë e stabilitetit të klasterit, zgjerimin e tij dhe lidhjen e klientëve të rinj.

Kubernetes: rruga e Pinterest

Fillimi i punës me Kubernetes në masë në Pinterest si një platformë që do të përqafohet nga inxhinierët tanë, rezultoi në shumë vështirësi.

Si një kompani e madhe, ne kemi investuar ndjeshëm në mjetet infrastrukturore. Siç janë mjetet e sigurisë që trajtojnë certifikatat dhe shpërndajnë çelësat, komponentët e kontrollit të trafikut, sistemet e zbulimit të shërbimeve, komponentët e dukshmërisë dhe dërgimit të regjistrimeve dhe metrikave. Të gjitha këto u ndërtuan jo pa arsye: ne përjetuam një rrugë normale provash dhe gabimesh, dhe prandaj do të doja të integrojmë të gjithë këtë në infrastrukturën e re mbi Kubernetes në vend të rishkimit të së kaluarës në një platformë të re. Ky qasje e thjeshtoi në përgjithësi migrimin, pasi të gjitha mbështetje aplikative ekzistojnë tashmë, nuk ka nevojë të krijohen nga fillimi.

С другой стороны, моделей прогнозирования нагрузок в самом Kubernetes (например, развертывания, заданий и наборов Daemon) недостаточно для нашего проекта. Эти проблемы юзабилити являются огромными препятствиями на пути к переходу на Kubernetes. Например, мы слышали, как разработчики сервисов жалуются на отсутствие или некорректную настройку входа. Также мы сталкивались с неправильным использованием шаблонизаторов, когда создавались сотни копий с одинаковой спецификацией и заданием, что выливалось в кошмарные проблемы с отладкой.

Еще было очень сложно поддерживать разные версии в одном и том же кластере. Представьте себе сложность клиентской поддержки, если вам нужно работать сразу во множестве версий одной и той же среды исполнения, со всеми их проблемами, багами и апдейтами.

Пользовательские ресурсы и контроллеры Pinterest

Чтобы облегчить для наших инженеров процесс внедрения Kubernetes, а также упростить инфраструктуру и ускорить ее работу, мы разработали наши собственные определения пользовательских ресурсов (CRD).

CRD предоставляют следующие функциональные возможности:

Объединение различных нативных ресурсов Kubernetes, чтобы они работали в качестве единой нагрузки. Например, ресурс PinterestService включает в себя развертывание, службу входа и конфигурационную карту. Это позволяет разработчикам не беспокоиться о настройке DNS.
Внедрение необходимой поддержки приложений. Пользователь должен сосредоточиться только на спецификации контейнера согласно своей бизнес-логике, в то время как контроллер CRD внедряет все необходимые init-контейнеры, переменные среды и спецификации pod. Это обеспечивает принципиально иной уровень комфорта для разработчиков.
Контроллеры CRD также управляют жизненным циклом собственных ресурсов и повышают доступность отладки. Это включает согласование желаемой и реальной спецификаций, обновление статуса CRD и ведение логов событий и не только. Без CRD разработчики были бы вынуждены управлять многочисленным набором ресурсов, что только повышало бы вероятность ошибки.

Вот пример PinterestService и внутреннего ресурса, который управляется нашим контроллером:

Как можно увидеть выше, для поддержки пользовательского контейнера нам необходимо интегрировать в него контейнер инициализации и несколько дополнений, чтобы обеспечить безопасность, видимость и работу с сетевым трафиком. Кроме того, мы создали шаблоны карт конфигурации и реализовали поддержку шаблонов PVC для пакетных заданий, а также трекинг множества переменных среды для отслеживания идентификации, потребления ресурсов и сбора «мусора».

Трудно представить, что разработчики захотят написать эти файлы конфигурации вручную без поддержки CRD, не говоря уже о дальнейшей поддержке и отладке конфигураций.

Воркфлоу деплоя приложений

На рисунке выше показано, как развернуть пользовательский ресурс Pinterest в кластере Kubernetes:

Разработчики взаимодействуют с нашим кластером Kubernetes через CLI и пользовательский интерфейс.
Инструменты CLI / UI извлекают YAML-файлы конфигурации рабочего процесса и другие свойства сборки (тот же идентификатор версии) из Artifactory, после чего отправляют их в Job Submission Service. Этот шаг гарантирует, что в кластер будут поставлены только рабочие версии.
JSS является шлюзом для различных платформ, включая Kubernetes. Тут происходит аутентификация пользователя, выдача квот и частичная проверка конфигурации нашего CRD.
После проверки CRD на стороне JSS информация отправляется на API платформы k8s.
Наш CRD-контроллер отслеживает события на всех пользовательских ресурсах. Он преобразует CR в нативные ресурсы k8s, добавляет необходимые модули, устанавливает соответствующие переменные среды и выполняет другие вспомогательные работы, чем гарантирует контейнерным пользовательским приложениям достаточную инфраструктурную поддержку.
Затем контроллер CRD передает полученные данные в API Kubernetes для того, чтобы они были обработаны планировщиком и запущены в работу.

Shënim: это предрелизное воркфлоу деплоя было создано для первых пользователей новой k8s-платформы. Сейчас мы находимся в процессе доработки этого процесса для того, чтобы полностью интегрироваться с нашей новой CI/CD. Это значит, что мы не можем рассказать всего связанного с Kubernetes. Мы с нетерпением ждем возможности поделиться нашим опытом и рассказать о прогрессе команды в данном направлении в нашей следующей блогозаписи «Building a CI/CD platform for Pinterest».

Виды специальных ресурсов

Duke nga nevojat specifike të Pinterest, ne kemi zhvilluar këto CRD që janë të përshtatshëm për procese të ndryshme pune:

PinterestService është një shërbim stateless që funksionon prej kohësh. Shumica e sistemeve tona kryesore mbështeten në një grup të tillë shërbimesh.
PinterestJobSet modelon detyra paketash me cikël të plotë. Në Pinterest ekziston një skenar i zakonshëm ku disa detyra nisin të njëjtat kontejnerë paralelisht, pavarësisht nga proceset e tjera të ngjashme.
PinterestCronJob përdoret gjerësisht në lidhje me ngarkesa të vogla periodike. Kjo është një mbështetje për punën native të cron me mekanizmat mbështetës të Pinterest që merren me sigurinë, trafikun, logjet dhe metrikat.
PinterestDaemon përfshin Daemon-at e infrastrukturës. Ky familje vazhdon të rritet ndërsa ne shtojmë gjithnjë e më shumë mbështetje për klasterët tanë.
PinterestTrainingJob shtrihet mbi proceset Tensorflow dhe Pytorch, duke ofruar të njëjtën nivel mbështetje gjatë punës si të gjitha CRD-të e tjera. Duke qenë se në Pinterest përdoret gjerësisht Tensorflow dhe sistemet e tjera të mësimit të makinerive, ne kishim arsyen ta ndërtojmë rreth tij një CRD të veçantë.

Ne gjithashtu po punojmë mbi PinterestStatefulSet, i cili do të adaptohet së shpejti për depozita të dhënash dhe sisteme të tjera stateful.

Mbështetje e mjedisit të ekzekutimit

Kur moduli i aplikacioneve nishet në Kubernetes, ai automatikisht merr një certifikatë për identifikimin e vet. Kjo certifikatë përdoret për qasje në ruajtjen sekrete ose për komunikim me shërbime të tjera përmes mTLS. Ndërkohë, konfiguruesi i inicializimit të kontejnerëve dhe Daemon do të shkarkojnë të gjitha varësitë e nevojshme përpara se të nisë aplikacioni i kontejnerit. Kur gjithçka të jetë gati, traffic sidecar dhe Daemon do të regjistrojnë adresën IP të modulit në Zookeeper-in tonë, në mënyrë që klientët ta zbulojnë. Të gjitha këto do të funksionojnë, pasi moduli i rrjetit është konfiguruar para nisjes së aplikacionit.

Më sipër janë shembuj tipikë të mbështetjes së ngarkesave gjatë ekzekutimit. Për lloje të tjera ngarkesash mund të nevojitet pak ndihmë tjetër, por të gjitha ato paraqiten si sidecar në nivel pod, nodale ose Daemon në nivel makinerie virtuale. Ne sigurojmë që gjithçka të disatohet brenda infrastrukturës menaxhuese dhe të harmonizohet midis aplikacioneve, e cila në fund të fundit zvogëlon ndjeshëm ngarkesën lidhur me punët teknike dhe mbështetje për klientët.

Testimi dhe QA

Ne kemi ndërtuar një pipeline testimi end-to-end mbi infrastrukturën ekzistuese të testimit të Kubernetes. Këto teste përfshijnë të gjithë klasterët tanë. Pipeline-i ynë ka përjetuar shumë ristrukturime përpara se të bëhej pjesë e klasterit të produktit.

Përveç sistemeve të testimit, kemi sisteme monitorimi dhe njoftimi që ndjekin vazhdimisht gjendjen e komponentëve, konsumimin e burimeve dhe tregues të tjerë të rëndësishëm, duke na njoftuar vetëm kur është e nevojshme ndërhyrja njerëzore.

Alternativat

Ne shqyrtuam disa alternativa për burimet e zakonshme, si kontrolluesit e mutacioneve dhe sistemet e shablloneve. Megjithatë, të gjitha ato janë të lidhura me vështirësi të konsiderueshme në punë, kështu që zgjodhëm rrugën e CRD.

Kontrolleri i muarimit u përdor për të futur sidecard, variablën e ambientit dhe mbështetje të tjera gjatë ekzekutimit. Megjithatë, ai përballej me probleme të ndryshme, si lidhja e burimeve dhe menaxhimi i ciklit të jetës së tyre, ndërsa në CRD nuk ka këto probleme.

Shënim: Sistemet e shablloneve, si diagramet Helm, përdoren gjithashtu gjerësisht për të nisur aplikacione me konfiguracione të ngjashme. Megjithatë, aplikacionet tona të punës janë shumë të ndryshme për t'u menaxhuar përmes shablloneve. Gjithashtu, gjatë shpërndarjes së vazhdueshme duke përdorur shabllone do të lindin shumë gabime.

Puna e ardhshme

Aktualisht, ne po merremi me ngarkesa të përziera në të gjitha klasterët tanë. Për të mbështetur procese të tilla të llojeve dhe madhësive të ndryshme, ne po punojmë në treguesit e mëposhtme:

Kombinimi i klasterëve shpërndan aplikacione të mëdha në klasterë të ndryshëm për të siguruar shkallëzim dhe stabilitet.
Sigurimi i stabilitetit, shkallëzimit dhe dukshmërisë së klasterit për të krijuar lidhjen midis aplikacionit dhe SLA-së së tij.
Menaxhimi i burimeve dhe kuotave, në mënyrë që aplikacionet të mos përplasen mes tyre, dhe shkalla e klasterit të kontrollohet nga ana jonë.
Platforma e re CI/CD për mbështetje dhe shpërndarje aplikacionesh në Kubernetes.

Burimi: habr.com