За гады існавання Pinterest 300 мільёнаў карыстачоў сэрвісу стварылі больш за 200 мільярдаў пінаў на больш за 4 мільярды дошак. Каб абслугоўваць гэтае войска карыстачоў і шырокую кантэнт-базу, партал распрацаваў тысячы сэрвісаў, пачынальна ад мікрасэрвісаў, з якімі можа зладзіцца некалькі CPU, і сканчаючы гіганцкімі маналітамі, якія круцяцца на цэлым парку віртуальных машын. І вось наступіў момант, калі погляд кампаніі зваліўся на k8s. Чым жа «кубік» зірнуўся «Пінтэрасту»? Пра гэта вы даведаецеся з нашага перакладу свежага артыкула з .
Такім чынам, сотні мільёнаў карыстальнікаў і сотні мільярдаў пінаў. Каб абслугоўваць гэтае войска карыстачоў і шырокую кантэнт-базу, мы распрацавалі тысячы сэрвісаў, пачынальна ад мікрасэрвісаў, з якімі можа зладзіцца некалькі CPU, і сканчаючы гіганцкімі маналітамі, якія круцяцца на цэлым парку віртуальных машын. Акрамя таго, у нас ёсць разнастайныя фрэймворкі, якія таксама могуць патрабаваць рэсурсаў CPU, памяці або доступу да аперацый уводу-высновы.
У ходзе падтрымкі гэтага заапарка інструментаў каманда распрацоўкі сутыкаецца з шэрагам праблем:
- У інжынераў няма ўніфікаванага спосабу запуску працоўнага асяроддзя. Stateless-сэрвісы, Stateful-сэрвісы і змешчаныя ў стадыі актыўнай распрацоўкі праекты грунтуюцца на абсалютна розных тэхналагічных стэках. Гэта прывяло да стварэння цэлага навучальнага курса для інжынераў, а таксама сур'ёзна ўскладняе працу нашай інфраструктурнай каманды.
- Распрацоўнікі, якія маюць у распараджэнні ўласны парк віртуальных машын, ствараюць велізарную нагрузку на ўнутраных адміністратараў. У выніку, такія простыя аперацыі, як абнаўленне АС ці AMI, расцягваюцца на тыдні і месяцы. Гэта прыводзіць да росту нагрузкі ў, здавалася б, абсалютна будзённых сітуацыях.
- Складанасці са стварэннем глабальных інструментаў кіравання інфраструктурай па-над ужо існуючымі рашэннямі. Сітуацыя ўскладняецца яшчэ і тым, што знайсці ўладальнікаў віртуальных машын няпроста. Гэта значыць, мы не ведаем, ці можна бяспечна атрымаць гэтыя магутнасці для працы на іншых участках нашай інфраструктуры.
Кантэйнерныя сістэмы аркестрацыі - гэта спосаб уніфікаваць кіраванне працоўнай нагрузкай. Яны адчыняюць вам шлях да падвышэння хуткасці распрацоўкі і спрашчаюць кіраванне інфраструктурай, бо ўсе задзейнічаныя ў праекце рэсурсы кіруюцца адной цэнтралізаванай сістэмай.
Малюнак 1: Прыярытэты інфраструктуры (надзейнасць, прадукцыйнасць распрацоўшчыкаў і эфектыўнасць).
Каманда Cloud Management Platform у Pinterest пазнаёмілася з K8s у 2017 годзе. Да першай паловы 2017 года мы дакументавалі большую частку нашых вытворчых магутнасцяў, у тым ліку, API і ўсе нашы вэб-серверы. Пасля мы правялі ўважлівую адзнаку розных сістэм аркестрацыі кантэйнерных рашэнняў, пабудовы кластараў і працы з імі. Да канца 2017 года мы вырашылі скарыстацца Kubernetes. Ён быў дастаткова гнуткі і шырока падтрымліваўся ў супольнасці распрацоўшчыкаў.
Да цяперашняга моманту мы стварылі ўласныя інструменты першаснай загрузкі кластара на аснове Kops і перавялі на Kubernetes існуючыя кампаненты інфраструктуры - такія, як сетка, бяспека, метрыкі, вядзенне часопісаў, кіраванне ідэнтыфікацыяй і трафік. Таксама мы рэалізавалі сістэму мадэлявання працоўных нагрузак для нашага рэсурсу, складанасць якой утоена ад распрацоўнікаў. Цяпер мы сканцэнтраваны на забеспячэнні стабільнасці кластара, яго маштабаванні і падключэнні новых кліентаў.
Kubernetes: шлях Pinterest
Пачатак працы з Kubernetes у маштабах Pinterest як з платформай, якая будзе кахана нашымі інжынерамі, вылілася ў мноства цяжкасцяў.
Як буйная кампанія мы ўклалі значныя сродкі ў інфраструктурныя інструменты. У прыклад можна прывесці прылады бяспекі, якія апрацоўваюць сертыфікаты і размяркоўваюць ключы, кампаненты кантролю трафіку, сістэмы выяўлення сэрвісаў, кампаненты бачнасці і адпраўкі часопісаў і метрык. Усё гэта было сабрана не проста так: мы прайшлі нармальны шлях спроб і памылак, і таму хацелася інтэграваць усю гэтую гаспадарку ў новую інфраструктуру на Kubernetes замест таго, каб зноўку вынаходзіць стары ровар на новай платформе. Такі падыход у цэлым спрасціў міграцыю, бо ўся падтрымка прыкладанняў ужо існуе, яе не трэба ствараць з нуля.
З іншага боку, мадэляў прагназавання нагрузак у самім 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 для таго, каб яны былі апрацаваны планавальнікам і запушчаны ў працу.
Заўвага: гэта предрелизное воркфлоў дэплою было створана для першых карыстальнікаў новай k8s-платформы. Цяпер мы знаходзімся ў працэсе дапрацоўкі гэтага працэсу для таго, каб поўнасцю інтэгравацца з нашай новай CI/CD. Гэта значыць, што мы не можам расказаць за ўсё звязанага з Kubernetes. Мы з нецярпеннем чакаем магчымасці падзяліцца нашым вопытам і расказаць аб прагрэсе каманды ў гэтым напрамку ў нашым наступным блогапісе "Building a CI/CD platform for Pinterest".
Віды спецыяльных рэсурсаў
Зыходзячы з канкрэтных патрэбаў Pinterest, мы распрацавалі наступныя CRD, якія падыходзяць для розных працоўных працэсаў:
- PinterestService - гэта ўжо даўно працуюць stateless-сэрвісы. Многія нашы асноўныя сістэмы грунтуюцца на наборы такіх сервісаў.
- PinterestJobSet мадэлюе пакетныя заданні поўнага цыклу. У Pinterest ёсць распаўсюджаны сцэнар, паводле якога некалькі заданняў запускаюць адны і тыя ж кантэйнеры раўналежна, прычым па-за залежнасцю ад іншых падобных працэсаў.
- PinterestCronJob шырока прымяняецца ў звязку з невялікімі перыядычнымі нагрузкамі. Гэта абалонка для натыўнай працы cron з механізмамі падтрымкі Pinterest, якія адказваюць за бяспеку, трафік, логі і метрыкі.
- PinterestDaemon ўключае ў сябе Daemon-ы інфраструктуры. Гэта сямейства працягвае расці, паколькі мы дадаем усё больш падтрымкі для нашых кластараў.
- PinterestTrainingJob распаўсюджваецца на працэсы Tensorflow і Pytorch, забяспечваючы той жа ўзровень падтрымкі падчас працы, што і ўсе іншыя CRD. Паколькі ў Pinterest актыўна выкарыстоўваецца Tensorflow і іншыя сістэмы машыннага навучання, у нас быў рацыя пабудаваць вакол іх асобную CRD.
Таксама мы працуем над PinterestStatefulSet, які неўзабаве будзе адаптаваны для сховішчаў даных і іншых stateful-сістэм.
Падтрымка асяроддзя выканання
Калі модуль прыкладанняў запускаецца ў Kubernetes, ён аўтаматычна атрымлівае сертыфікат для ідэнтыфікацыі самога сябе. Гэты сертыфікат выкарыстоўваецца для доступу да сакрэтнага сховішча або для зносін з іншымі службамі праз mTLS. Між тым, канфігуратар ініцыялізацыі кантэйнераў і Daemon загрузяць усе неабходныя залежнасці да запуску кантэйнернага дадатку. Калі ўсё будзе гатова, sidecar трафіку і Daemon зарэгіструюць IP-адрас модуля ў нашым Zookeeper, каб кліенты маглі яго выявіць. Усё гэта будзе працаваць, бо сеткавы модуль быў наладжаны яшчэ да запуску прыкладання.
Вышэй прыведзены тыповыя прыклады падтрымкі працоўных нагрузак падчас выканання. Для іншых тыпаў працоўных нагрузак можа спатрэбіцца крыху іншы саппорт, але ўсе яны прадстаўлены ў выглядзе sidecar ўзроўню pod, вузлавымі або Daemon-амі ўзроўню віртуальных машын. Мы сочым за тым, каб усё гэта было разгорнута ў рамках кіруючай інфраструктуры і ўзгоднена паміж праграмамі, што ў выніку значна зніжае нагрузку ў плане тэхнічных работ і падтрымкі кліентаў.
Тэставанне і QA
Мы сабралі end-to-end тэставы канвеер па-над ужо наяўнай тэставай інфраструктурай Kubernetes. Гэтыя тэсты распаўсюджваюцца на ўсе нашы кластары. Наш пайплайн перажыў мноства пераробак, перш чым стаў часткай прадуктовага кластара.
Апроч сістэм тэставання ў нас ёсць сістэмы маніторынгу і абвесткі, якія стала сочаць за станам кампанентаў сістэмы, спажываннем рэсурсаў і іншымі важнымі паказчыкамі, апавяшчаючы нас толькі пры неабходнасці чалавечага ўмяшання.
альтэрнатывы
Мы разглядалі некаторыя альтэрнатывы кастамных рэсурсаў, такія як мутацыйныя кантролеры доступу і сістэмы шаблонаў. Аднак усе яны спалучаны з сур'ёзнымі цяжкасцямі ў працы, так што мы выбралі шлях CRD.
Мутацыйны кантролер допуску выкарыстоўваўся для ўводу сайдкараў, зменнага асяроддзя і іншай падтрымкі падчас выканання. Тым не менш, ён сутыкаўся з рознымі праблемамі, напрыклад, са звязваннем рэсурсаў і кіраваннем іх жыццёвым цыклам, калі як у CRD такіх праблем не ўзнікае.
Заўвага: Сістэмы шаблонаў, такія як дыяграмы Хелма, таксама шырока выкарыстоўваюцца для запуску прыкладанняў са падобнымі канфігурацыямі. Аднак нашы працоўныя прыкладанні занадта разнастайныя, каб кіраваць імі з дапамогай шаблонаў. Таксама падчас бесперапыннага разгортвання пры выкарыстанні шаблонаў будзе ўзнікаць занадта шмат памылак.
Будучая праца
Цяпер мы маем справу са змяшанай нагрузкай на ўсіх нашых кластарах. Каб падтрымліваць падобныя працэсы рознага тыпу і памеру, мы працуем у наступных кірунках:
- Сукупнасць кластараў размяркоўвае вялікія прыкладанні па розных кластарах для забеспячэння маштабаванасці і стабільнасці.
- Забеспячэнне стабільнасці, маштабаванасці і бачнасці кластара для стварэння сувязі дадатку і яго SLA.
- Кіравання рэсурсамі і квотамі, каб прыкладанні не канфліктавалі паміж сабой, а маштаб кластара кантраляваўся з нашага боку.
- Новая платформа CI/CD для падтрымкі і разгортванні прыкладанняў у Kubernetes.
Крыніца: habr.com