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

През годините 300 милиона потребители на Pinterest са създали повече от 200 милиарда пина на повече от 4 милиарда дъски. За да обслужва тази армия от потребители и огромна база от съдържание, порталът е разработил хиляди услуги, вариращи от микроуслуги, които могат да се управляват от няколко процесора, до гигантски монолити, които работят на цял флот от виртуални машини. И тогава дойде моментът, когато погледът на компанията падна върху k8s. Защо „кубът“ изглеждаше добре в Pinterest? Ще научите за това от нашия превод на скорошна статия от блог Pinterest инженерство.

И така, стотици милиони потребители и стотици милиарди пинове. За да обслужваме тази армия от потребители и огромна база от съдържание, ние разработихме хиляди услуги, вариращи от микроуслуги, които могат да се управляват от няколко процесора, до гигантски монолити, които работят на цели групи от виртуални машини. Освен това имаме различни рамки, които може също да изискват достъп до процесор, памет или I/O.

При поддържането на тази зоологическа градина от инструменти екипът за разработка е изправен пред редица предизвикателства:

Няма единен начин за инженерите да управляват производствена среда. Услугите без състояние, услугите с пълно състояние и проектите в процес на активно развитие са базирани на напълно различни технологични стекове. Това доведе до създаването на цял курс за обучение на инженери, а също така сериозно усложнява работата на нашия инфраструктурен екип.
Разработчиците със собствен парк от виртуални машини създават огромна тежест за вътрешните администратори. В резултат на това такива прости операции като актуализиране на операционната система или 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 и вътрешен ресурс, който се управлява от нашия контролер:

Както можете да видите по-горе, за да поддържаме персонализиран контейнер, трябва да интегрираме init контейнер и няколко добавки, за да осигурим сигурност, видимост и мрежов трафик. Освен това създадохме шаблони за конфигурационна карта и внедрихме поддръжка за PVC шаблони за пакетни задания, както и проследяване на множество променливи на средата за проследяване на идентичност, потребление на ресурси и събиране на боклук.

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

Работен процес за внедряване на приложение

Изображението по-горе показва как да внедрите персонализиран ресурс на Pinterest в клъстер на Kubernetes:

Разработчиците взаимодействат с нашия Kubernetes клъстер чрез CLI и потребителски интерфейс.
Инструментите CLI/UI извличат YAML файловете за конфигурация на работния поток и други свойства на компилация (същия ID на версията) от Artifactory и след това ги изпращат на услугата за подаване на задания. Тази стъпка гарантира, че в клъстера се доставят само производствени версии.
JSS е шлюз за различни платформи, включително Kubernetes. Тук потребителят се удостоверява, издават се квоти и частично се проверява конфигурацията на нашия CRD.
След проверка на CRD от страна на JSS, информацията се изпраща до API на платформата k8s.
Нашият CRD контролер следи събитията на всички потребителски ресурси. Той преобразува CR в собствени k8s ресурси, добавя необходимите модули, задава подходящите променливи на средата и извършва друга поддръжка, за да гарантира, че контейнеризираните потребителски приложения имат достатъчна инфраструктурна поддръжка.
След това CRD контролерът предава получените данни към Kubernetes API, така че да могат да бъдат обработени от планировчика и пуснати в производство.

Внимание: Този работен процес преди пускане на внедряването е създаден за първите потребители на новата платформа k8s. В момента сме в процес на усъвършенстване на този процес, за да се интегрира напълно с нашия нов CI/CD. Това означава, че не можем да ви кажем всичко, свързано с Kubernetes. Очакваме с нетърпение да споделим нашия опит и напредъка на екипа в тази посока в следващата ни публикация в блога „Изграждане на 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, така че клиентите да могат да го открият. Всичко това ще работи, защото мрежовият модул е конфигуриран преди стартирането на приложението.

Горните са типични примери за поддръжка по време на изпълнение за работни натоварвания. Други типове натоварвания може да изискват малко по-различна поддръжка, но всички те идват под формата на странични колички на ниво pod, ниво на възел или демони на ниво виртуална машина. Ние гарантираме, че всичко това е внедрено в рамките на инфраструктурата за управление и е последователно в приложенията, което в крайна сметка значително намалява тежестта по отношение на техническата работа и поддръжката на клиентите.

Тестване и QA

Изградихме тестова линия от край до край върху съществуващата тестова инфраструктура на Kubernetes. Тези тестове се прилагат за всички наши клъстери. Нашият тръбопровод премина през много ревизии, преди да стане част от продуктовия клъстер.

В допълнение към системите за тестване, разполагаме със системи за наблюдение и предупреждение, които постоянно следят състоянието на системните компоненти, потреблението на ресурси и други важни показатели, като ни уведомяват само когато е необходима човешка намеса.

алтернативи

Разгледахме някои алтернативи на персонализирани ресурси, като контролери за достъп до мутация и шаблонни системи. Всички те обаче идват със значителни оперативни предизвикателства, така че избрахме маршрута на CRD.

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

Забележка: Системи с шаблони като диаграми на Helm също се използват широко за стартиране на приложения с подобни конфигурации. Нашите работни приложения обаче са твърде разнообразни, за да бъдат управлявани с помощта на шаблони. Освен това по време на непрекъснато внедряване ще има твърде много грешки при използване на шаблони.

Предстояща работа

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

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

Източник: www.habr.com

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