Если Red Hat доверяет OpenShift управление плоскостью управления своего крупнейшего оркестратора инфраструктуры, тот же подход применим и к самому небольшому.
Исторически запуск оркестрации рабочих нагрузок на периферии ставил организации перед неудобным выбором: либо распространить Kubernetes на устройства, для которых он никогда не проектировался, либо поддерживать совершенно отдельную инфраструктуру для управления периферийным парком. Ни один из вариантов не выглядит привлекательно — первый перегружает тяжёлой плоскостью управления ресурсно-ограниченное железо, второй дробит операционные практики и умножает экспертизу, необходимую для поддержки приложений и сервисов.
Тем не менее в августе 2024 года Red Hat объявила об общей доступности нового выпуска Red Hat OpenStack, названного «следующим поколением» платформы, — и он предлагает иной взгляд на эту проблему. В рамках Red Hat OpenStack Services on OpenShift (RHOSO) компания отказалась от прежней модели развёртывания — Undercloud и Director — в пользу запуска плоскости управления OpenStack в виде контейнеров, управляемых операторами (Operator) на OpenShift, при этом плоскость данных остаётся на внешних вычислительных узлах Red Hat Enterprise Linux (RHEL). Идея проста: Kubernetes превосходно управляет многосервисными приложениями с требованиями высокой доступности, тогда как плоскость данных лучше размещать на инфраструктуре, специально созданной под её характеристики нагрузки.
Логично применить ту же логику к противоположному концу шкалы. Там, где RHOSO решает задачи крупномасштабной оркестрации — корпоративный bare metal, сотни ядер на узел, совместно расположенная датацентровая инфраструктура, — HashiCorp Nomad закрывает задачи малого масштаба: лёгкие периферийные устройства, разнородные платформы, нестабильное подключение и рабочие нагрузки, не вписывающиеся в контейнерную модель.
В этой статье мы рассмотрим архитектуру запуска серверов HashiCorp Nomad на Red Hat OpenShift для управления распределёнными периферийными парками. Речь идёт не о конкурирующих оркестраторах, решающих одну и ту же задачу, — а об использовании сильных сторон каждой платформы и их экосистем. Red Hat OpenShift обеспечивает корпоративный жизненный цикл управления плоскостью управления Nomad, тогда как Nomad расширяет возможности планирования туда, куда OpenShift не может или не должен заходить.
Обзор архитектуры
В данной архитектуре серверные узлы Nomad размещаются на кластере OpenShift, а клиентские узлы Nomad работают на своей собственной инфраструктурной платформе — периферийных устройствах, одноплатных компьютерах, датацентровых серверах с GPU и аналогичном оборудовании.
Внутри OpenShift серверы Nomad развёртываются как StatefulSet и предоставляются внешним клиентам через сервис балансировщика нагрузки Kubernetes. Этим сервисом может быть MetalLB при on-premise развёртывании или облачный балансировщик нагрузки в облачных и управляемых средах OpenShift, таких как Red Hat OpenShift on AWS или Azure Red Hat OpenShift.
Клиенты Nomad могут работать на любой инфраструктуре, подходящей для конкретных рабочих нагрузок. Периферийные шлюзы на RHEL, одноплатные компьютеры на ARM, промышленные ПК с Windows или традиционные датацентровые серверы — все они могут регистрироваться в одном серверном кластере и получать от него задания (allocations). Бинарный файл Nomad достаточно мал для работы на ресурсно-ограниченных устройствах и достаточно устойчив, чтобы справляться с перебоями связи, не нарушая работу запущенных нагрузок.
С точки зрения сети, использование паттерна сервиса-балансировщика нагрузки гарантирует, что не-HTTPS/SNI трафик, на который Nomad полагается при взаимодействии между сервером и клиентом, без проблем пересекает границу кластера OpenShift. Клиенты Nomad устанавливают исходящие RPC-соединения с серверами и поддерживают их для сердцебиений (heartbeats), выделения заданий и потоковой передачи журналов. Это означает, что ваши периферийные устройства не обязаны быть напрямую адресуемы из плоскости управления — что может существенно упростить правила межсетевого экрана и обход NAT в распределённых развёртываниях.
Данный архитектурный паттерн также меняет взгляд на топологию кластера. Nomad без проблем масштабируется до тысяч узлов без специальной настройки, и стандартная рекомендация — использовать пулы узлов (node pools) и пространства имён (namespaces) для изоляции арендаторов внутри одного кластера Nomad. Однако когда развёртывание плоскости управления Nomad становится Kubernetes-native операцией, а не инфраструктурным проектом, появляется дополнительная гибкость. Если требования к соответствию нормативам, операционные или организационные задачи выигрывают от изоляции на уровне платформы, можно развернуть отдельные кластеры серверов Nomad для каждой команды, среды или региона — каждый в своём пространстве имён Kubernetes с управлением доступом на основе ролей (RBAC), контролирующим права на управление. Если один из кластеров управления испытывает проблемы, радиус поражения остаётся ограниченным; другие кластеры продолжают работать независимо. Возможности федерации Nomad по-прежнему доступны, если нужна межкластерная видимость, но изоляция становится нормой по умолчанию, а не исключением.
Наконец, стоит отметить, что предложенная модель развёртывания плоскости управления Nomad на OpenShift снижает порог входа. Традиционные развёртывания Nomad — виртуальные машины, балансировщики нагрузки, провайдеры хранилищ, инфраструктура мониторинга — несут достаточные накладные расходы, чтобы разумно откладывать их до момента, когда периферийный парк оправдает эти инвестиции. Но когда плоскость управления — это стандартное Kubernetes-развёртывание на существующем кластере OpenShift, централизованную оркестрацию можно внедрять с первого дня. Такой сдвиг перспективы позволяет даже небольшим паркам воспользоваться корпоративными возможностями оркестрации рабочих нагрузок Nomad без инфраструктурных накладных расходов стандартного развёртывания.
Что Nomad привносит на периферию?
Nomad особенно хорошо проявляет себя при оркестрации рабочих нагрузок на ресурсно-ограниченной и разнородной инфраструктуре, сосредотачиваясь на характеристиках, которым Kubernetes не уделяет приоритета — а в ряде случаев намеренно ими жертвует. Такие возможности, как абстракция среды выполнения контейнеров, интеграция сервисной сетки на основе sidecar-контейнеров и модель строгой согласованности etcd, вполне обоснованы для хорошо связанных датацентровых развёртываний, но добавляют накладные расходы, которые труднее оправдать с учётом ресурсных ограничений и сетевых реалий типичных периферийных парков.
Размер занимаемых ресурсов
Разница в занимаемых ресурсах весьма значительна. Бинарный файл Nomad занимает чуть больше 150 МБ и обладает минимальными накладными расходами времени выполнения, оставляя большую часть ресурсов устройства для сред выполнения рабочих нагрузок. На одноплатном компьютере или промышленном шлюзе этот запас ресурсов действительно важен.
Гибкость
Nomad планирует не только контейнеры: драйвер exec запускает бинарные файлы непосредственно на хосте, драйвер Java выполняет JAR-файлы без накладных расходов контейнеризации, и существует целая экосистема драйверов задач, доступная вне зависимости от архитектуры или операционной системы хоста. Если периферийная рабочая нагрузка не вписывается в контейнер или контейнеризация создаёт больше проблем, чем решает, Nomad не навязывает этот подход принудительно. Это особенно актуально для унаследованных приложений или программного обеспечения от производителей оборудования, которое никогда не проектировалось с учётом контейнеров, но должно развёртываться и управляться единообразно на всём парке.
Эта гибкость проявляется и в поддержке разнородных платформ. Одноплатные компьютеры ARM64, промышленные ПК на x86 и серверы Windows могут регистрироваться в одном кластере Nomad, а авторы заданий направляют нагрузки на нужные узлы через ограничения (constraints) и пулы узлов. Не нужно поддерживать отдельные кластеры для каждой платформы или архитектуры — плоскость управления справляется с разнообразием, а спецификация задания фиксирует ограничения.
Подключаемость
Стоит особо выделить модель подключения. Блок disconnect в Nomad позволяет настроить поведение плоскости управления при сетевых разделениях (network partitions). Выделения (allocations) продолжают выполняться на отключённых клиентах и могут корректно переподключаться при восстановлении связи, вместо того чтобы немедленно помечаться как утраченные и заменяться. Для периферийных площадок с нестабильным подключением это превращает корректную обработку сетевых разделений в вопрос конфигурации, а не архитектурное ограничение. Чтобы детально изучить это на ряде реальных примеров, рекомендуем прочитать статью «Managing Applications at the Edge with HashiCorp Nomad».
Интеграция
Если вы уже используете продукты HashiCorp, Nomad распространяет эти инвестиции на периферию. Нативная интеграция с Vault для управления секретами, с Consul для комплексного обнаружения сервисов и с Sentinel для применения политик означает, что удостоверения рабочих нагрузок и задачи управления доступом решаются без дополнительной сложности и интеграционных работ.
Что OpenShift привносит в плоскость управления Nomad?
Как и с любой Kubernetes-native нагрузкой, практическая ценность запуска серверов Nomad на OpenShift заключается в том, что вам не нужно строить самостоятельно.
Абстракция StatefulSet органично соответствует требованиям Nomad: каждый сервер Nomad получает стабильный сетевой идентификатор и постоянное хранилище, переживающее перепланирование пода. Правила анти-аффинити подов обеспечивают распределение серверов по доменам отказа, а при сбое узла Kubernetes автоматически выполняет перепланирование. В сочетании с консенсусом Raft в Nomad это обеспечивает отказоустойчивость плоскости управления без необходимости в специальной автоматизации или развёрнутой документации по типовым сценариям сбоев.
Средства управления безопасностью наследуются от платформы, а не являются специфической конфигурацией. Security Context Constraints OpenShift ограничивают возможности подов серверов Nomad, RBAC управляет правами на управление развёртыванием, сетевые политики ограничивают трафик, а журналирование платформы фиксирует как операционные, так и аудиторские журналы. Это не инвестиции, специфичные для Nomad, — это возможности, которые ваша команда платформы уже использует для всех остальных нагрузок кластера и последовательно применяет ещё к одной.
То же самое касается наблюдаемости (observability). Prometheus собирает метрики с эндпоинта Nomad наравне с любой другой нагрузкой, оповещения проходят через Alertmanager, а журналы попадают в существующий стек журналирования кластера. Для плоскости управления Nomad не нужна отдельная инфраструктура мониторинга — с операционной точки зрения это просто ещё одно приложение.
Экосистема операторов также расширяет возможности Nomad без дополнительных интеграционных работ. Vault Secrets Operator (VSO) умеет синхронизировать PKI-сертификаты и другие операционно-чувствительные данные из HashiCorp Vault в секреты Kubernetes, которые StatefulSet затем монтирует и потребляет. Ротация сертификатов становится операцией Vault, а не упражнением по управлению конфигурацией: Vault динамически обновляет сертификат, а VSO распространяет это изменение. OpenShift GitOps может также декларативно управлять развёртыванием Kubernetes-ресурсов Nomad, поддерживая паритет управления с другими нагрузками кластера OpenShift.
В итоге вы компонуете существующие продукты, предоставляемые как самой платформой, так и экосистемами Red Hat и HashiCorp, вместо того чтобы создавать специальные интеграции для каждой возможности, необходимой Nomad в производственном развёртывании.
Влияние на HashiCorp Validated Design
HashiCorp Validated Design (HVD) для Nomad Enterprise предоставляет исчерпывающие рекомендации по производственным развёртываниям, охватывая всё — от размера серверов до распределения по зонам доступности и стратегий резервного копирования. Большая часть этих рекомендаций исходит из модели развёртывания на виртуальных машинах, где восстановление инфраструктуры измеряется минутами, а не секундами. Когда серверы Nomad работают на Kubernetes, часть этих рекомендаций теряет актуальность, поскольку платформа уже решает соответствующую проблему.
Наиболее наглядный пример — конфигурация зон резервирования (redundancy zones). HVD рекомендует шесть серверов, организованных как пары voter/non-voter (голосующий/неголосующий) в трёх зонах доступности. При отказе voter Autopilot повышает non-voter в той же зоне, обеспечивая «горячий резерв», способный взять управление без ожидания восстановления инфраструктуры. Этот паттерн существует потому, что замена упавшей виртуальной машины занимает время — подготовка, начальная загрузка, повторное вступление в кластер — и работать с ухудшенным кворумом в этот период нежелательно.
Kubernetes меняет эту операционную модель. Перепланирование пода обычно завершается за секунды. StatefulSet сохраняет идентичность, поэтому nomad-0
повторно вступает в кластер как nomad-0 со своим существующим постоянным томом. Raft справляется с временным нарушением кворума в процессе перепланирования. StatefulSet из трёх реплик с ограничениями распределения по топологии (topology spread constraints) обеспечивает эквивалентную доступность без операционных накладных расходов на управление топологией voter/non-voter. Не нужно встраивать избыточность на уровне приложения, потому что уровень платформы её уже обеспечивает.
Распределение по зонам также упрощается. Даже без пар voter/non-voter серверы нужно распределять по доменам отказа. HVD описывает размещение серверов и настройку параметра redundancy_zone, но в Kubernetes этим декларативно управляют ограничения распределения по топологии. Вы задаёте желаемое распределение, и планировщик его соблюдает. При отказе узла замещающий под автоматически попадает в подходящую зону.
Это не критика HVD. Предоставляемые им рекомендации абсолютно справедливы для развёртываний на виртуальных машинах, где описанные проблемы действительно требуют решения. Однако понимание того, какие рекомендации становятся задачей платформы, а не приложения, — важная часть эффективного развёртывания серверов Nomad на Kubernetes. Вы наследуете решения, предоставляемые платформой, вместо того чтобы реализовывать их заново.
Соображения по применимости
Эта архитектура имеет смысл в определённых обстоятельствах, но стоит явно обозначить, когда она неуместна. Первое соображение — наличие у вас OpenShift или хотя бы Kubernetes. Аргумент о предельных затратах, согласно которому серверы Nomad — это просто ещё один StatefulSet, справедлив лишь при условии, что платформа уже существует. Разворачивать кластер OpenShift специально для размещения серверов Nomad было бы сложно обосновать; в таком случае лучше подойдёт модель развёртывания на виртуальных машинах, которую HVD подробно описывает.
Аналогично, ценность здесь — для инфраструктуры, до которой выбранный вами дистрибутив Kubernetes объективно не дотягивается. Корпоративные организации ценят стандартизацию: они работают на OpenShift, или на EKS, или на AKS — и эта стандартизация намеренна. Если ваша «периферия» состоит из стоечных серверов в торговых точках или региональных датацентрах, которые вполне могут запустить стандартный дистрибутив, расширение этого дистрибутива вполне может оказаться более простым ответом. Случай для Nomad наиболее убедителен, когда у вас есть устройства, на которых стандартный дистрибутив Kubernetes просто невозможен: одноплатные компьютеры, унаследованные системы и сервисы, оборудование с ограниченными ресурсами, проблемные сетевые топологии, влияющие на управление узлами и планирование нагрузок в Kubernetes, или среды и нагрузки, для которых среды выполнения контейнеров попросту нежизнеспособны. Если это не ваш случай, вы рискуете добавить операционную сложность без весомого повода её оправдывающего.
Важна и компетентность команды. Запуск Nomad вместе с OpenShift означает, что команда платформы должна разбираться в обеих системах — не только в развёртывании, но и в операциях второго дня, обновлениях и диагностике. Если у никого в команде нет опыта с Nomad, нужно учитывать кривую обучения. Операционная модель намного проще, чем запуск Nomad на виртуальных машинах, но и нулевой она не является.
Наконец, хотя Kubernetes решает многие проблемы высокой доступности, которые рассматривает HVD, доступность и производительность хранилища остаются реальными факторами. Серверы Nomad чувствительны к задержкам хранилища, особенно под нагрузкой планирования. Если бэкенд хранилища OpenShift не может обеспечить стабильные IOPS, вы столкнётесь с нестабильностью при выборе лидера или медленным планированием заданий. Эта проблема решаема — OpenShift Data Foundation с правильно настроенными классами хранилища справляется с ней хорошо, — но лучше проверить это заранее, чем обнаружить в продуктивной среде.
Хранилище для клиентов Nomad представляет отдельный вызов. В разнородных и распределённых средах нельзя рассчитывать на централизованные бэкенды хранилища или плагины Container Storage Interface (CSI), предполагающие надёжное подключение к провайдеру. Для большинства периферийных развёртываний локальное хранилище непосредственно на устройстве — прагматичный ответ: конфигурация host volume в Nomad предоставляет выделениям локальные пути без внешних зависимостей. Это не ограничение описанной здесь архитектуры — это неотъемлемая характеристика распределённой периферийной инфраструктуры, с которой вам придётся работать вне зависимости от способа развёртывания плоскости управления.
Осознание этих сложностей заранее поможет выработать подход, наилучшим образом соответствующий вашим нагрузкам и инфраструктурной области, в которой их нужно запускать.
Следующие шаги
Для организаций, уже работающих с OpenShift и сталкивающихся с задачами оркестрации на инфраструктуре, до которой Kubernetes не дотягивается, этот паттерн открывает возможность включить такие устройства в управляемый парк без традиционных инвестиций в плоскость управления. Периферийные нагрузки, которые иначе потребовали бы ручного развёртывания или специализированного инструментария, могут участвовать в той же операционной модели, что и всё остальное: декларативные определения заданий, централизованная видимость и единообразное управление жизненным циклом.
Референсный Helm-чарт, реализующий описанную здесь архитектуру, доступен в этом репозитории GitHub. Он охватывает StatefulSet, конфигурацию сервисов, интеграцию наблюдаемости и агент создания снимков (snapshot agent) — рассматривайте его как отправную точку для адаптации, а не как поддерживаемый артефакт. Кроме того, на сайте HashiCorp Developer есть практическое руководство по управлению периферийными нагрузками, уроки которого применимы вне зависимости от выбранной модели развёртывания.
Данный подход задействует ряд возможностей Nomad Enterprise: журналирование аудита для видимости в области безопасности и соответствия нормативам, агент создания снимков для автоматического резервного копирования в поддерживаемый провайдер хранилища и Autopilot для управления работоспособностью кластера во время скользящих обновлений и перепланирования подов. Если хотите попробовать всё это самостоятельно — запросите пробную версию Nomad Enterprise уже сегодня!
