За роки існування 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-контейнери, змінні середовища та специфікації під. Це забезпечує принципово інший рівень комфорту для розробників.
- Контролери 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