Создание Платформы Kubernetes На Pinterest

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

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

Разработчики с собственным парком виртуальных машин создают огромную нагрузку на внутренних администраторов.

В результате такие простые операции, как обновление ОС или AMI, занимают недели и месяцы.

Это приводит к увеличению нагрузки в, казалось бы, абсолютно повседневных ситуациях.

Сложности создания инструментов управления глобальной инфраструктурой поверх существующих решений.

Ситуация осложняется еще и тем, что найти владельцев виртуальных машин непросто.

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

Системы оркестрации контейнеров — это способ унифицировать управление рабочей нагрузкой.

Они открывают путь к увеличению скорости разработки и упрощают управление инфраструктурой, поскольку все ресурсы, задействованные в проекте, управляются одной централизованной системой.

Рисунок 1. Приоритеты инфраструктуры (надежность, продуктивность разработчиков и эффективность).

Команда облачной платформы управления Pinterest обнаружила K8 в 2017 году.

К первой половине 2017 года мы задокументировали большую часть наших производственных возможностей, включая API и все наши веб-серверы.

После этого мы провели тщательную оценку различных систем оркестрации контейнерных решений, построения кластеров и работы с ними.

Ближе к концу 2017 года мы решили использовать Kubernetes. Он был достаточно гибким и широко поддерживался сообществом разработчиков.

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

Сейчас мы сосредоточены на обеспечении стабильности кластера, его масштабировании и подключении новых клиентов.

Будучи крупной компанией, мы вложили значительные средства в инфраструктурные инструменты.

Примеры включают инструменты безопасности, которые обрабатывают сертификаты и распределение ключей, компоненты управления трафиком, системы обнаружения служб, компоненты видимости, а также компоненты диспетчеризации журналов и метрик.

Все это было собрано не просто так: мы прошли обычный путь проб и ошибок, и поэтому нам хотелось интегрировать все это оборудование в новую инфраструктуру на Kubernetes, а не изобретать старое колесо на новой платформе.

Такой подход в целом упростил миграцию, поскольку вся поддержка приложений уже существует и ее не нужно создавать с нуля.

С другой стороны, моделей прогнозирования нагрузки в самом Kubernetes (таких как развертывания, задания и наборы демонов) недостаточно для нашего проекта.

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

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

Также было очень сложно поддерживать разные версии в одном кластере.

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

Инструменты CLI/UI извлекают YAML-файлы конфигурации рабочего процесса и другие свойства сборки (тот же идентификатор версии) из Artifactory, а затем отправляют их в службу отправки заданий.

Этот шаг гарантирует, что в кластер доставляются только производственные версии.

JSS — это шлюз для различных платформ, включая Kubernetes. Здесь проходит аутентификация пользователя, выдаются квоты и частично проверяется конфигурация нашего CRD. После проверки CRD на стороне JSS информация отправляется в API платформы k8s. Наш CRD-контроллер отслеживает события на всех пользовательских ресурсах.

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

Затем контроллер CRD передает полученные данные в Kubernetes API, чтобы они могли быть обработаны планировщиком и запущены в производство.

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

Многие из наших основных систем основаны на наборе таких сервисов.

PinterestJobSet моделирует пакетные задания полного цикла.

Распространенный сценарий в Pinterest заключается в том, что несколько заданий параллельно запускают одни и те же контейнеры, независимо от других подобных процессов.

PinterestCronJob широко используется в сочетании с небольшими периодическими нагрузками.

Это оболочка для нативной работы cron с механизмами поддержки Pinterest, которые отвечают за безопасность, трафик, журналы и метрики.

PinterestDaemon включает инфраструктурные демоны.

Это семейство продолжает расти по мере того, как мы расширяем поддержку наших кластеров.

PinterestTrainingJob распространяется на процессы Tensorflow и Pytorch, обеспечивая тот же уровень поддержки во время выполнения, что и все другие CRD. Поскольку Pinterest активно использует Tensorflow и другие системы машинного обучения, у нас появилась причина построить вокруг них отдельный CRD. Мы также работаем над PinterestStatefulSet, который вскоре будет адаптирован для хранилищ данных и других систем с отслеживанием состояния.

Этот сертификат используется для доступа к секретному хранилищу или для связи с другими службами через mTLS. Тем временем конфигуратор и демон Container Init загрузят все необходимые зависимости перед запуском контейнерного приложения.

Когда все будет готово, сайдкар трафика и демон зарегистрируют IP-адрес модуля в нашем Zookeeper, чтобы клиенты могли его обнаружить.

Все это будет работать, поскольку сетевой модуль был настроен до запуска приложения.

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

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

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

Наш конвейер претерпел множество изменений, прежде чем стал частью продуктового кластера.

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

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

Однако он столкнулся с различными проблемами, такими как привязка ресурсов и управление жизненным циклом, где такие проблемы не возникают в CRD. Примечание: Системы шаблонов, такие как диаграммы Helm, также широко используются для запуска приложений со схожими конфигурациями.

Однако наши рабочие приложения слишком разнообразны, чтобы ими можно было управлять с помощью шаблонов.

Также при непрерывном развертывании будет слишком много ошибок при использовании шаблонов.