Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Сунил Говиндан, Вэйвэй Янг, Вангда Tан, Уилфред Шпигельбург
Предпосылки
Почему для Apache Spark выбирают K8s
Apache Spark унифицирует в рамках одной платформы пакетную обработку в режиме реального времени, потоковую аналитику, машинное обучение и интерактивные запросы. Хотя Apache Spark предоставляет множество возможностей для разнообразных сценариев применения, его использование сопряжено с дополнительной сложностью и высокими затратами на обслуживание и администрирование кластера. Давайте рассмотрим некоторые высокоуровневые требования к базовому оркестратору ресурсов, чтобы расширить возможности Spark как единой платформы:
● Контейнерные вычисления Spark для предоставления общих ресурсов разным заданиям машинного обучения и ETL.
● Поддержка нескольких версий Spark, версий Python с контролем версий, контейнеры на общих кластерах K8s для более быстрой итерации и стабильной работы в продуктиве.
● Единая унифицированная инфраструктура для большинства пакетных рабочих нагрузок и микросервисов.
● Контроль доступа к общим кластерам.
Kubernetes как фактический стандарт для развертывания сервисов предлагает более точный и детализированный контроль всех вышеупомянутых аспектов по сравнению с другими оркестраторами ресурсов. Kubernetes предлагает упрощенный способ управления инфраструктурой и приложениями с практическим подходом к изоляции рабочих нагрузок, ограничению использования ресурсов, развертыванию ресурсов по запросу и возможностям автоматического масштабирования по мере необходимости.
Проблемы планирования задач Apache Spark на K8s
В планировщике Kubernetes по умолчанию есть пробелы с точки зрения эффективного развертывания пакетных рабочих нагрузок на том же кластере, где также планируется длительная работа других сервисов. Для пакетных рабочих нагрузок из-за требуемого параллелизма вычислений в основном должно планироваться совместное и гораздо более частое выполнение. Давайте подробно рассмотрим некоторые из этих пробелов.
Отсутствие первоклассной концепции приложения
В зависимости от типа развертываемого контейнера пакетные задания часто необходимо планировать к выполнению последовательно. Например, поды драйверов Spark нужно планировать раньше, чем рабочие поды. Четкая концепция первоклассного приложения может помочь с упорядочиванием или постановкой в очередь при каждом развертывании контейнера. Кроме того, такая концепция помогает администратору визуализировать задания, запланированные для отладки.
Отсутствие эффективных возможностей управления емкостью/квотами
Для управления ресурсами при выполнении рабочих нагрузок Spark в случае использования ресурсов несколькими арендаторами могут применяться квоты Kubernetes на ресурсы пространства имен (неймспейсов). Однако здесь есть несколько проблем:
1. Задания Apache Spark в отношении использования ресурсов являются динамическими по своей природе. А квоты пространства имен фиксируются и проверяются на этапе допуска. Запрос пода отклоняется, если он не соответствует квоте пространства имен. Это требует, чтобы задание Apache Spark вместо того, чтобы ставить запрос на выполнение в очередь внутри самого Kubernetes, реализовывало механизм повтора запросов пода.
2. Квота ресурсов пространства имен “плоская”, она не поддерживает иерархии управления квотами ресурсов.
Также часто пользователь может сталкиваться с нехваткой ресурсов для выполнения пакетных рабочих нагрузок, поскольку квоты пространства имен Kubernetes нередко не соответствуют плану распределения ресурсов на основе организационной иерархии. Эластичное и иерархическое управление приоритетами заданий в K8s сегодня отсутствует.
Недостаточно справедливое распределение ресурсов между арендаторами
В производственной, рабочей среде часто обнаруживается, что планировщик Kubernetes по умолчанию не может эффективно управлять диверсифицированными рабочими нагрузками и обеспечивать справедливость распределения ресурсов для рабочих нагрузок арендаторов. Вот некоторые из основных причин:
● Управление рабочими нагрузками в производственной среде часто выполняется большим количеством пользователей.
● В плотной производственной среде, где выполняются разные типы рабочих нагрузок, весьма вероятно, что поды драйверов Spark могут занять все ресурсы в пространстве имен. Такие сценарии создают большую проблему для эффективного совместного использования ресурсов.
● Неправомерные или поврежденные задания могут легко захватить ресурсы и повлиять на производственные рабочие нагрузки.
Строгие требования SLA с задержкой планирования
На большинстве загруженных производственных кластеров, предназначенных для пакетных рабочих нагрузок, часто выполняются тысячи заданий с сотнями тысяч тасков ежедневно. Эти рабочие нагрузки требуют большего количества параллельно развертываемых контейнеров, и часто время жизни таких контейнеров весьма короткое (от нескольких секунд до часов). Обычно это влечет потребность в развертывании тысяч подов или контейнеров, ожидающих выполнения, и использование по умолчанию планировщика Kubernetes может привести к дополнительным задержкам, что, в свою очередь, приведет к невыполнению SLA.
Как может помочь Apache YuniKorn
Обзор Apache YuniKorn
YuniKorn - это улучшенный планировщик Kubernetes, как для сервисов, так и для пакетных рабочих нагрузок. В зависимости от сценариев использования и развертывания, YuniKorn может либо полностью заменить стандартный планировщик Kubernetes, либо работать с ним совместно.
YuniKorn является унифицированным кроссплатформенным планировщиком смешанных рабочих нагрузок, состоящих как из stateless пакетных рабочих нагрузок, так и stateful сервисов.
Сравнение YuniKorn и стандартного планировщика Kubernetes
Фича | Планировщик по умолчанию | YUNIKORN | Примечание |
Концепция приложения | x | √ | Приложения в YuniKorn приоритетны. YuniKorn планирует приложения с учетом, например, порядка их запуска, приоритета, использования ресурсов и т. д. |
Упорядочение заданий | x | √ | YuniKorn поддерживает правила упорядочения заданий FIFO/FAIR/Приоритеты (WIP) |
Детализированное управление ресурсами | x | √ | Управление ресурсами кластера с помощью иерархии очередей. Очереди предоставляют гарантированные ресурсы (минимум) и предельные квоты ресурсов (максимум). |
Справедливое распределение ресурсов | x | √ | Справедливое распределение ресурсов между приложениями и очередями для их идеального распределения для всех запущенных приложений. |
Нативная поддержка нагрузок Big Data | x | √ | Стандартный планировщик ориентирован на долговременные сервисы. YuniKorn разработан для рабочих нагрузок приложений Big Data и изначально поддерживает эффективное выполнение Spark / Flink / Tensorflow и т. д. на базе K8s. |
Масштабирование и производительность | x | √ | YuniKorn оптимизирован по производительности, он подходит для высокопроизводительных и крупномасштабных сред. |
Как YuniKorn помогает в работе Spark на K8s
YuniKorn имеет богатый набор функций, которые помогают более эффективно запускать Apache Spark на Kubernetes. Подробности можно найти здесь (инструкции по запуску Spark на K8s с YuniKorn).
Ознакомьтесь с более подробной информацией о том, как YuniKorn расширяет возможности Spark на K8s: Cloud-Native Spark Scheduling with YuniKorn Scheduler на Spark & AI саммите 2020.
Давайте рассмотрим некоторые варианты использования и то, как YuniKorn помогает улучшить планирование ресурсов Spark в этих сценариях.
Несколько пользователей одновременно запускают разные рабочие нагрузки (‘шумные соседи’)
По мере того, как все больше пользователей начинают одновременно запускать джобы, становится все сложнее изолировать их и справедливо предоставлять им необходимые ресурсы. Планировщик YuniKorn предоставляет оптимальное решение для управления квотами ресурсов путем использования очередей ресурсов.
В приведенном выше примере структуры очередей в YuniKorn и пространства имен, определенные в Kubernetes, сопоставляются с очередями неймспейсов родительской очереди с помощью политики размещения. Очереди сред тестирования и разработки имеют фиксированные ограничения по ресурсам. Все остальные очереди ограничены только размером кластера. Ресурсы распределяются между очередями с использованием справедливой политики, а задания в очереди в производственной среде планируются в порядке FIFO.
Вот некоторые из основных преимуществ:
● Одна очередь YuniKorn может автоматически сопоставляться с одним пространством имен в Kubernetes.
● Емкость очереди эластична по своей природе и может обеспечивать диапазон ресурсов от минимального до максимального заданного значения.
● Справедливость распределения ресурсов, которая поможет избежать возможной нехватки ресурсов.
YuniKorn предоставляет простой способ управления квотой ресурсов для кластера Kubernetes, он может работать как замена квоты ресурсов пространства имен. Управление квотами ресурсов в YuniKorn позволяет задействовать очереди запросов подов и совместное использование ограниченных ресурсов между заданиями на основе подключаемых политик планирования. Все это может быть выполнено без каких-либо дополнительных манипуляций, таких как повторная отправка запроса к поду Apache Spark.
Настройка кластера для модели распределения ресурсов на основе существующей в организации иерархии
В большой производственной среде несколько пользователей будут одновременно запускать рабочие нагрузки разных типов. Часто эти пользователи вынуждены потреблять ресурсы в зависимости от бюджетных ограничений в иерархии организации. Такая производственная настройка помогает эффективно использовать ресурсы кластера в пределах выделенной квоты ресурсов.
YuniKorn позволяет управлять ресурсами кластера с иерархией очередей. Детальное управление распределением ресурсов в многопользовательской среде становится возможным за счет использования очередей ресурсов с четкой иерархией (например, соответствующей иерархии организации). Очереди YuniKorn можно настраивать статически или динамически управлять ими, а с помощью функции динамического управления очередями пользователи могут настраивать правила для делегирования функций управления очередью.
Улучшенное SLA заданий Spark в мультиарендном кластере
Обычные рабочие нагрузки ETL, выполняемые в мультиарендном (мультитенантном) кластере, требуют более простых средств определения детализированных политик для выполнения заданий в желаемой для организации иерархии очередей. Часто такие политики помогают определять для выполнения заданий более строгие SLA.
YuniKorn дает администраторам возможность размещать задания в очередях на основе более простых политик, таких как FIFO, FAIR и т. д. Политика сортировки приложений StateAware упорядочивает задания в очереди в порядке FIFO и планирует их выполнение одно за другим согласно условиям. Это позволяет избежать обычного “состояния гонки” при отправке большого количества пакетных заданий, например Spark, в одно пространство имен (или кластер). Обеспечивая определенный порядок заданий, она также улучшает планирование заданий, делая его более предсказуемым.
Использование различных фич K8s для планирования заданий Apache Spark
YuniKorn полностью совместим с основными выпущенными версиями K8s. Пользователи могут прозрачным образом менять планировщик в существующем кластере K8s. YuniKorn полностью поддерживает всю родную семантику K8s, которая может использоваться во время планирования, такую как селектор меток, афинность/анти-афинность пода, толерантность, PV/PVC и т. д. YuniKorn также совместим с командами управления и утилитами, такими как узлы cordon, получение событий через kubectl и т. д.
Apache YuniKorn в CDP
Платформа CDP от Cloudera предлагает аналитическое приложение Cloudera Data Engineering на базе Apache YuniKorn (в инкубации).
Некоторые из основных вариантов использования YuniKorn в Cloudera включают в себя:
● Управление квотами ресурсов для виртуальных кластеров CDE.
● Расширенные возможности планирования заданий Spark.
● Ответственность за планирование как микросервисных, так и пакетных заданий.
● Работа в облаке с поддержкой автоматического масштабирования.
Планы на улучшение поддержки рабочих нагрузок Spark
Сообщество YuniKorn активно изучает определенные улучшения основных функций для поддержки выполнения рабочих нагрузок Spark. Например, для более эффективного выполнения важно выделить минимальное количество подов драйверов и рабочих подов. Параллельное планирование (gang scheduling) помогает обеспечить выделение для выполнения задания Spark необходимого количества подов. Такая функция будет очень полезна в “шумном” окружении при развертывании многопользовательского кластера. Для получения более подробной информации см. YUNIKORN-2 (Jira отслеживает прогресс функций).
Поддержка приоритетов заданий/задач
Упорядочение по приоритетам на уровне заданий помогает администраторам расставлять приоритеты и YuniKorn выделять необходимые ресурсы заданиям с высоким уровнем SLA. Это также дает большую гибкость для эффективного использования ресурсов кластера. Для получения более подробной информации см. YUNIKORN-1 (Jira отслеживает прогресс функции).
Распределенная трассировка
В YUNIKORN-387 для улучшения общего контроля планировщика используется открытая трассировка. С помощью этой функции можно собирать и сохранять критические трассировки в рамках основного цикла планирования для устранения неполадок, профилирования системы и мониторинга.
Резюме
YuniKorn помогает эффективно осуществлять детальное распределение ресурсов для различных рабочих нагрузок Spark в крупномасштабных многопользовательских средах, с одной стороны, и динамически создаваемых облачных средах - с другой.
Таким образом, благодаря YuniKorn платформа Apache Spark может стать для пользователей важной платформой корпоративного уровня, предлагающей надежную основу для различных приложений, от крупномасштабного преобразования данных до задач аналитики и машинного обучения.
