Создавање платформа kubernetes на Pinterest

Со текот на годините, 300 милиони корисници на Pinterest создадоа повеќе од 200 милијарди пинови на повеќе од 4 милијарди табли. За да и служи на оваа армија на корисници и огромна база на содржини, порталот разви илјадници услуги, кои се движат од микросервиси со кои може да се ракуваат неколку процесори, до огромни монолити кои работат на цела флота на виртуелни машини. И тогаш дојде моментот кога очите на компанијата паднаа на k8s. Зошто „коцката“ изгледаше добро на Pinterest? Ќе дознаете за ова од нашиот превод на неодамнешна статија од блог Pinterest инженеринг.

Значи, стотици милиони корисници и стотици милијарди пинови. За да и служиме на оваа армија на корисници и огромна база на содржини, развивме илјадници услуги, кои се движат од микросервиси со кои може да се ракуваат неколку процесори, до џиновски монолити кои работат на цели флоти на виртуелни машини. Дополнително, имаме различни рамки за кои исто така може да биде потребен процесор, меморија или пристап до I/O.

Во одржувањето на оваа зоолошка градина со алатки, тимот за развој се соочува со голем број предизвици:

• Не постои единствен начин инженерите да водат производствена средина. Услугите без државјанство, државните услуги и проектите кои се во активен развој се засноваат на сосема различни технолошки купови. Ова доведе до создавање на цел курс за обука за инженери, а исто така сериозно ја отежнува работата на нашиот инфраструктурен тим.
• Програмерите со сопствена флота на виртуелни машини создаваат огромен товар за внатрешните администратори. Како резултат на тоа, таквите едноставни операции како ажурирање на оперативниот систем или AMI траат со недели и месеци. Ова води до зголемен обем на работа во навидум апсолутно секојдневни ситуации.
• Тешкотии во креирањето на глобалните алатки за управување со инфраструктурата над постоечките решенија. Ситуацијата дополнително се усложнува поради фактот што не е лесно да се најдат сопственици на виртуелни машини. Односно, не знаеме дали овој капацитет може безбедно да се извлече за да работи во други делови од нашата инфраструктура.

Системите за оркестрација на контејнери се начин да се обедини управувањето со обемот на работа. Тие ја отвораат вратата за зголемена брзина на развој и го поедноставуваат управувањето со инфраструктурата, бидејќи сите ресурси вклучени во проектот се управувани од еден централизиран систем.

Слика 1: Приоритети на инфраструктурата (доверливост, продуктивност на развивачите и ефикасност).

Тимот на платформата за управување со облак во Pinterest ги откри K8s во 2017 година. До првата половина на 2017 година, ги документиравме повеќето од нашите производствени способности, вклучувајќи го и API и сите наши веб-сервери. Потоа направивме темелна проценка на различни системи за оркестрирање контејнерски решенија, градење кластери и работа со нив. Кон крајот на 2017 година, решивме да го користиме Кубернетес. Беше доста флексибилен и широко поддржан во заедницата на програмери.

Досега, изградивме свои алатки за подигање на кластери базирани на Kops и мигриравме постојни инфраструктурни компоненти како што се вмрежување, безбедност, метрика, евиденција, управување со идентитетот и сообраќај до Kubernetes. Исто така, имплементиравме систем за моделирање на обемот на работа за нашиот ресурс, чија сложеност е скриена од програмерите. Сега сме фокусирани на обезбедување на стабилност на кластерот, негово скалирање и поврзување на нови клиенти.

Kubernetes: Начинот на Pinterest

Започнувањето со Kubernetes на скалата на Pinterest како платформа која нашите инженери би ја сакале доаѓа со многу предизвици.

Како голема компанија, инвестиравме многу во инфраструктурни алатки. Примерите вклучуваат безбедносни алатки кои ракуваат со сертификати и дистрибуција на клучеви, компоненти за контрола на сообраќајот, системи за откривање услуги, компоненти за видливост и компоненти за испраќање на дневници и метрика. Сето ова беше собрано со причина: поминавме низ нормалниот пат на обиди и грешки, и затоа сакавме да ја интегрираме сета оваа опрема во новата инфраструктура на Kubernetes наместо повторно да го измислиме старото тркало на нова платформа. Овој пристап генерално ја поедностави миграцијата, бидејќи целата поддршка за апликации веќе постои и не треба да се креира од нула.

Од друга страна, моделите за прогнозирање на оптоварувањето во самиот Kubernetes (како што се распоредувања, работни места и Daemon сетови) не се доволни за нашиот проект. Овие проблеми со употребливоста се огромни бариери за преселување во Кубернетес. На пример, слушнавме дека развивачите на услуги се жалат за исчезнати или неточни поставки за најавување. Наидовме и на неправилна употреба на мотори на шаблони, кога беа создадени стотици копии со иста спецификација и задача, што резултираше со кошмарни проблеми со дебагирање.

Исто така, беше многу тешко да се одржуваат различни верзии во истиот кластер. Замислете ја сложеноста на корисничката поддршка ако треба да работите истовремено во повеќе верзии на иста околина за извршување, со сите нивни проблеми, грешки и ажурирања.

Својства и контролори на корисниците на Pinterest

За да им олесниме на нашите инженери да го имплементираат Kubernetes и да ја поедноставиме и забрзаме нашата инфраструктура, развивме сопствени сопствени дефиниции за ресурси (CRD).

CRD ја обезбедуваат следната функционалност:

1. Комбинирање на различни природни ресурси на Kubernetes, така што тие работат како единствен обем на работа. На пример, ресурсот PinterestService вклучува распоредување, услуга за најавување и конфигурациска карта. Ова им овозможува на програмерите да не се грижат за поставување на DNS.
2. Спроведување на потребната поддршка за апликации. Корисникот треба да се фокусира само на спецификацијата на контејнерот според неговата деловна логика, додека CRD контролерот ги имплементира сите потребни инитни контејнери, променливи на животната средина и спецификации на pod. Ова обезбедува фундаментално различно ниво на удобност за програмерите.
3. Контролерите на CRD, исто така, управуваат со животниот циклус на природните ресурси и ја подобруваат достапноста за отстранување грешки. Ова вклучува усогласување на саканите и вистинските спецификации, ажурирање на статусот на CRD и одржување на дневници на настани и многу повеќе. Без CRD, програмерите би биле принудени да управуваат со повеќе ресурси, што само би ја зголемило веројатноста за грешка.

Еве пример за PinterestService и внатрешен ресурс со кој управува нашиот контролер:

Како што можете да видите погоре, за поддршка на прилагоден контејнер, треба да интегрираме иницијален контејнер и неколку додатоци за да обезбедиме безбедност, видливост и мрежниот сообраќај. Дополнително, создадовме шаблони за конфигурациска карта и имплементиравме поддршка за ПВЦ шаблони за сериски задачи, како и следење на повеќе променливи на околината за следење на идентитетот, потрошувачката на ресурси и собирањето ѓубре.

Тешко е да се замисли дека програмерите би сакале да ги напишат овие конфигурациски датотеки рачно без поддршка за CRD, а камоли дополнително да ги одржуваат и дебагираат конфигурациите.

Работен тек за распоредување на апликации

Сликата погоре покажува како да се распореди прилагоден ресурс на Pinterest во кластерот Kubernetes:

1. Програмерите комуницираат со нашиот кластер Kubernetes преку CLI и корисничкиот интерфејс.
2. Алатките CLI/UI ги преземаат YAML-датотеките за конфигурација на работниот тек и другите својства за изградба (идентификатор на истата верзија) од Artifactory и потоа ги доставуваат до услугата за поднесување работни места. Овој чекор осигурува дека само производствените верзии се доставуваат до кластерот.
3. JSS е портал за различни платформи, вклучувајќи го и Kubernetes. Овде корисникот се автентицира, се издаваат квоти и делумно се проверува конфигурацијата на нашиот CRD.
4. По проверка на CRD на страната JSS, информациите се испраќаат до API на платформата k8s.
5. Нашиот CRD контролер ги следи настаните на сите кориснички ресурси. Ги конвертира CR-ите во природни ресурси на k8s, ги додава потребните модули, ги поставува соодветните променливи на животната средина и врши други работи за поддршка за да се осигури дека контејнеризираните кориснички апликации имаат доволна инфраструктурна поддршка.
6. Контролерот CRD потоа ги пренесува добиените податоци на Kubernetes API за да може да се обработи од распоредувачот и да се стави во производство.

Имајте на ум: Овој работен тек на распоредот пред објавување беше создаден за првите корисници на новата платформа k8s. Во моментов сме во процес на рафинирање на овој процес за целосно да се интегрираме со нашиот нов CI/CD. Ова значи дека не можеме да ви кажеме сè што е поврзано со Кубернетес. Со нетрпение очекуваме да го споделиме нашето искуство и напредокот на тимот во оваа насока во нашиот следен блог пост, „Градење на CI/CD платформа за Pinterest“.

Видови специјални ресурси

Врз основа на специфичните потреби на Pinterest, ги развивме следниве CRD за да одговараат на различни работни текови:

• PinterestService се услуги без државјанство кои работат долго време. Многу од нашите основни системи се засноваат на збир на такви услуги.
• Моделите на PinterestJobSet сериски задачи со целосен циклус. Вообичаено сценарио на Pinterest е дека повеќе работни места паралелно ги извршуваат истите контејнери, без оглед на други слични процеси.
• PinterestCronJob е широко користен во врска со мали периодични оптоварувања. Ова е обвивка за домашна работа на cron со механизми за поддршка на Pinterest кои се одговорни за безбедноста, сообраќајот, дневниците и метриката.
• PinterestDaemon вклучува инфраструктурни демони. Ова семејство продолжува да расте додека додаваме поголема поддршка на нашите кластери.
• PinterestTrainingJob се проширува на процесите Tensorflow и Pytorch, обезбедувајќи исто ниво на поддршка за време на траење како и сите други CRD. Бидејќи Pinterest активно користи Tensorflow и други системи за машинско учење, имавме причина да изградиме посебна CRD околу нив.

Работиме и на PinterestStatefulSet, кој наскоро ќе биде приспособен за складишта на податоци и други државни системи.

Поддршка за траење

Кога подлогата за апликација работи на Kubernetes, тој автоматски добива сертификат за да се идентификува. Овој сертификат се користи за пристап до тајно складирање или за комуникација со други услуги преку mTLS. Во меѓувреме, Container Init Configurator и Daemon ќе ги преземат сите потребни зависности пред да ја стартуваат контејнеризираната апликација. Кога сè е подготвено, сообраќајната патна кола и Daemon ќе ја регистрираат IP адресата на модулот кај нашиот Zookeeper за клиентите да можат да ја откријат. Сето ова ќе работи бидејќи мрежниот модул беше конфигуриран пред да се стартува апликацијата.

Горенаведеното се типични примери за поддршка за време на траење за оптоварувања. Други типови на оптоварувања може да бараат малку поинаква поддршка, но сите тие доаѓаат во форма на странични картички на ниво на под, на ниво на јазол или на ниво на виртуелна машина демони. Ние осигуруваме дека сето ова е распоредено во инфраструктурата за управување и е конзистентно низ апликациите, што на крајот значително го намалува товарот во однос на техничката работа и поддршката на корисниците.

Тестирање и ОК

Изградивме тест-цевковод од крај до крај врз постоечката тест инфраструктура на Кубернетес. Овие тестови се однесуваат на сите наши кластери. Нашиот гасовод помина низ многу ревизии пред да стане дел од кластерот на производи.

Покрај системите за тестирање, имаме системи за следење и предупредување кои постојано го следат статусот на компонентите на системот, потрошувачката на ресурси и други важни индикатори, известувајќи не само кога е неопходна човечка интервенција.

Алтернативи

Разгледавме некои алтернативи на сопствените ресурси, како што се контролорите за пристап до мутации и системите за шаблони. Сепак, сите тие доаѓаат со значителни оперативни предизвици, па затоа ја избравме рутата CRD.

За да се воведат странични караши, променливи на животната средина и друга поддршка за време на траење, се користеше контролер за прием на мутации. Сепак, таа се соочи со различни проблеми, како што се врзување на ресурси и управување со животниот циклус, каде што таквите проблеми не се појавуваат во CRD.

Забелешка: Системите за шаблони, како што се Helm charts, исто така широко се користат за извршување на апликации со слични конфигурации. Сепак, нашите работни апликации се премногу разновидни за да се управуваат со помош на шаблони. Исто така при континуирано распоредување ќе има премногу грешки при користење на шаблони.

Претстојна работа

Во моментов се справуваме со мешано оптоварување во сите наши кластери. За поддршка на вакви процеси од различни видови и големини, работиме во следниве области:

• Збирката кластери дистрибуира големи апликации низ различни кластери за приспособливост и стабилност.
• Обезбедување стабилност на кластерот, приспособливост и видливост за да се создаде поврзување со апликации и SLA.
• Управување со ресурси и квоти, така што апликациите не се во конфликт една со друга, а обемот на кластерот е контролиран од наша страна.
• Нова CI/CD платформа за поддршка и распоредување на апликации на Kubernetes.

Извор: www.habr.com