Развёртывание NVIDIA Run:ai на VMware Cloud Foundation - часть 1 Развёртывание NVIDIA Run:ai на VMware Cloud Foundation - часть 1 Автор: Александр Самойленко Дата: 04/08/2026 Поддержите VM Guru! USDT / TRC20, адрес: TCDP7d9hBM4dhU2mBt5oX2x5REPtq9QdU1 Статья:

Предприятиям, которые запускают AI в собственных дата-центрах, нужно частное облако, где под единой панелью управления живут и традиционные приложения, и нагрузки с GPU-ускорением. Таким частным облаком выступает VMware Cloud Foundation (VCF), а в связке с VMware vSphere Kubernetes Service (VKS) как штатной средой исполнения Kubernetes и с VMware Private AI Foundation with NVIDIA он превращается в готовую к работе с GPU платформу для AI. Поверх этого фундамента располагается NVIDIA Run:ai — слой оркестрации AI-нагрузок и графических ускорителей, который помогает платформенным командам поднять утилизацию разделяемых GPU и обслужить больше одновременных пользователей, AI-задач, агентных сценариев и сервисов инференса.

VCF и vSphere VKS

VCF — интегрированная платформа частного облака от Broadcom. Одно развёртывание объединяет VMware vSphere для вычислений, vSAN (либо поддерживаемый внешний массив) для хранения и VMware NSX для сетевой подсистемы, причём всё это управляется через VMware Cloud Foundation Operations (VCF Operations). Вычисления, хранилище, сеть и Kubernetes развёртываются, обновляются и патчатся как единая система, а не как четыре слабо связанных продукта.

VKS — среда исполнения Kubernetes, поставляемая вместе с VCF. Кластеры создаются прямо из vSphere через Supervisor — управляющий слой Kubernetes, работающий на уровне гипервизора ESX и выполняющий роль плоскости управления для всех рабочих кластеров VKS, пространств имён vSphere и сервисов Supervisor. Отдельный дистрибутив Kubernetes не требуется, внешнюю плоскость управления обслуживать не нужно, дополнительного лицензирования нет. Рабочие узлы — это виртуальные машины vSphere, поэтому GPU, подключённые через NVIDIA vGPU или через (Dynamic) DirectPath I/O, потребляются Kubernetes через тот же планировщик vSphere, с привычным поведением vMotion и DRS. Слой Kubernetes не становится новым изолированным «островом» — он часть того же кластера, которым платформенная команда управляет и без него.

VMware Private AI Foundation with NVIDIA

VMware Private AI Foundation with NVIDIA — совместная платформа Broadcom и NVIDIA для запуска AI на VCF. Она позволяет предприятиям дообучать LLM, разворачивать RAG-сценарии и выполнять инференс внутри собственных датацентров, снимая вопросы приватности, выбора, стоимости, производительности и соответствия требованиям. Платформа упрощает внедрение AI, предлагая хранилище Model Store, поддержку изолированных (air-gapped) сред, среду исполнения моделей, NVIDIA NIM, NVIDIA Blueprints и другие компоненты.

Построенная на ведущей платформе частного облака VCF, Private AI Foundation with NVIDIA включает сервисы VCF Private AI Services, NVIDIA AI Enterprise, микросервисы инференса NVIDIA NIM для актуальных моделей — в том числе моделей NVIDIA Nemotron и ведущих открытых моделей сообщества — а также NVIDIA Blueprints.

Платформа собирает воедино компоненты, необходимые GPU-кластеру VKS, валидирует их как единое целое и предоставляет арендаторам в виде самообслуживаемых элементов каталога через VMware Cloud Foundation Automation (VCF Automation). AI-блюпринты — это элементы каталога VCF Automation, включая шаблон автоматизации AI Kubernetes Cluster. Запрос AI Kubernetes Cluster заставляет Supervisor подготовить VKS-кластер с нужным классом ВМ, профилем GPU, библиотекой контента и дополнениями (включая NVIDIA GPU Operator и лицензирование), так что кластер поднимается с загруженными драйверами, device plugin уже объявляет GPU, а метрики Data Center GPU Manager (DCGM) поступают в систему мониторинга.

Чего Kubernetes не даёт сам по себе — так это планировщика нагрузок и GPU, понимающего пользователей, проекты, квоты, справедливое распределение, вытеснение и автомасштабирование инференса. Именно эту нишу занимает NVIDIA Run:ai.

NVIDIA Run:ai

NVIDIA Run:ai - это Kubernetes-нативная платформа оркестрации AI-нагрузок и GPU для разделяемой AI-инфраструктуры. Платформенным командам она даёт плоскость управления для организаций пользователей, департаментов, проектов, квот, политик и ёмкости GPU, а специалистам по AI — единообразный способ отправлять, запускать и отслеживать задачи на всех этапах жизненного цикла. NVIDIA Run:ai добавляет следующее:

• Планирование с учётом GPU: проекты, департаменты, квоты, работа сверх квоты и справедливое распределение, приоритеты, вытеснение, пулы узлов и разделение GPU на доли, чтобы несколько команд могли использовать одни и те же ускорители, не мешая друг другу.
• Абстракции нагрузок: полноценные объекты для интерактивных рабочих сред, задач обучения, распределённого обучения (PyTorch, TensorFlow, MPI, XGBoost) и сервисов инференса — доступные из UI, CLI runai, REST API или через сырые Custom Resources Kubernetes.
• Композиционные нагрузки: задачи собираются из переиспользуемых активов (источники данных, учётные данные, окружения, шаблоны вычислительных ресурсов, политики). Одни и те же активы подключаются сегодня к Workspace, а завтра — к задаче обучения или сервису инференса без переписывания спецификации.
• Пользовательские рабочие среды и окружения: администраторы публикуют подготовленные окружения (Jupyter, VS Code, RStudio, собственные образы CUDA, vLLM, Triton, NIM), а исследователи выбирают их из выпадающего списка.
• Обслуживание инференса: нагрузки инференса работают поверх Knative Serving и получают автомасштабирование по запросам, масштабирование до нуля, выкатку по ревизиям и стабильную конечную точку в стиле OpenAI — без ручного написания конфигураций Knative.
• Управление и наблюдаемость: SSO/OIDC, RBAC на уровне департаментов и проектов, политики, журналы аудита, метрики GPU и нагрузок как в интерфейсе NVIDIA Run:ai, так и в Prometheus.

NVIDIA Run:ai предлагается в двух моделях развёртывания: SaaS в облаке NVIDIA и self-hosted. Обе модели устанавливают на каждый подключённый Kubernetes-кластер лёгкий кластерный компонент, который запускает планировщик, admission-вебхуки и контроллеры нагрузок рядом с самими нагрузками. Далее рассматривается именно self-hosted вариант — типичный выбор заказчиков VCF и Private AI Foundation with NVIDIA, желающих держать плоскость управления внутри собственного частного облака.

Почему это важно для заказчиков NVIDIA AI Enterprise

NVIDIA Run:ai теперь входит в состав NVIDIA AI Enterprise. Любой заказчик с правами на NVIDIA AI Enterprise может развернуть NVIDIA Run:ai без отдельной лицензии. Для клиента VCF, уже использующего Private AI Foundation with NVIDIA, это упрощает и закупку, и развёртывание:

• Платформа с GPU уже на месте: VCF, VKS и элемент каталога AI Kubernetes Cluster из состава Private AI Foundation with NVIDIA с GPU Operator и лицензированным стеком драйверов «из коробки».
• Компоненты NVIDIA Run:ai уже покрыты правами: NVIDIA AI Enterprise вместе с Private AI Foundation with NVIDIA приносит хостовый драйвер vGPU, образы Deep Learning VM и поддерживаемые в NVIDIA AI Enterprise среды исполнения (CUDA, PyTorch, TensorFlow, NIM).
• Остаётся только развёртывание: установить плоскость управления NVIDIA Run:ai, подключить кластер VKS, настроить Knative Serving для инференса и проверить работоспособность стека.

Главный сюжет здесь — консолидация. NVIDIA перенесла Kubernetes-нативный слой планирования GPU и оркестрации нагрузок в те же права, которые уже действуют поверх инфраструктурного слоя VCF. Дерево решений схлопывается: вместо сравнения NVIDIA Run:ai с KAI Scheduler (открытым Kubernetes-нативным планировщиком GPU, ныне песочницей CNCF, который изначально был создан для платформы NVIDIA Run:ai и до сих пор лежит в её основе), с обычным kube-scheduler в связке с GPU Operator или со сторонними планировщиками, вариантом по умолчанию становится NVIDIA Run:ai.

Далее мы рассмотрим базовое развёртывание NVIDIA Run:ai на VCF с Private AI Foundation with NVIDIA, которое включает в себя следующие шаги:

1. Поднять self-hosted плоскость управления NVIDIA Run:ai на кластере VKS.
2. Зарегистрировать один или несколько VKS-кластеров с GPU в плоскости управления.
3. Установить Knative Serving для конечных точек инференса.
4. Проверить работу разделения GPU на доли.
5. Проверить планирование сверх квоты и справедливое распределение между департаментами.
6. Запустить сервис инференса на одном GPU.
7. Запустить интерактивную рабочую среду.
8. Запустить задачу обучения на одном GPU.
9. Настроить мониторинг через интерфейс NVIDIA Run:ai, CLI runai и VCF Operations.

За рамками рассмотрения остаются две темы:

1. Автомасштабирование Knative по запросам и масштабирование до нуля.
2. Распределённое обучение на нескольких узлах (PyTorch DDP, DeepSpeed, MPI).

Далее предполагается, что у читателя развёрнут VCF 9.0 с Private AI Foundation with NVIDIA, имеются права на NVIDIA AI Enterprise, подготовлен хотя бы один AI Kubernetes Cluster из каталога VCF Automation, и всё готово к добавлению NVIDIA Run:ai поверх этого.

Референсная архитектура

Референсная архитектура представляет собой трёхуровневый стек: внизу VCF с Private AI Foundation with NVIDIA (вычисления, хранилище, сеть, пространства имён vSphere, кластеры VKS), сверху NVIDIA Run:ai (плоскость управления, кластерные компоненты, Knative Serving, нагрузки). Составные части показаны на рисунке ниже.

Уровень инфраструктуры и сервисов: VCF

Нижний уровень архитектуры — развёртывание VCF с поддержкой GPU.

• vSphere виртуализует вычислительные ресурсы и предоставляет GPU верхним уровням в виде профилей vGPU или целых устройств через Dynamic DirectPath I/O / DirectPath I/O.
• NSX обеспечивает программно-определяемую сеть, распределённую маршрутизацию и балансировщики нагрузки, используемые кластерами VKS и конечными точками NVIDIA Run:ai.
• vSAN (или поддерживаемый внешний массив, подключённый через vSphere Container Storage Plugin) предоставляет постоянные тома для stateful-компонентов NVIDIA Run:ai, базы данных плоскости управления и любых постоянных данных нагрузок.

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

Уровень Kubernetes и GPU: VKS

VKS не вводит отдельный дистрибутив Kubernetes: он использует vSphere Supervisor, поставляемый вместе с VCF, и применяет VCF Automation для публикации самообслуживаемых элементов каталога, которые управляют Supervisor от имени арендатора.

Предполагается два пространства имён vSphere, в каждом — свой кластер VKS:

• Пространство имён управления: кластер VKS только с CPU, где размещается self-hosted плоскость управления NVIDIA Run:ai (UI, API, Postgres, Keycloak/OIDC, внутренние сервисы). Вынос плоскости управления с узлов с GPU исключает конкуренцию с задачами исследователей и позволяет платформенной команде обновлять её независимо.
• Пространство имён нагрузок: кластер VKS с GPU для задач data science и инференса, созданный из элемента каталога AI Kubernetes Cluster. Кластер поднимается с предустановленным GPU Operator, загруженными драйверами, device plugin, объявляющим ресурс nvidia.com/gpu, и работающей передачей метрик NVIDIA Data Center GPU Manager (DCGM).

Уровень оркестрации нагрузок: NVIDIA Run:ai

NVIDIA Run:ai разворачивается на двух кластерах VKS предыдущего уровня:

• Плоскость управления на кластере только с CPU, устанавливается self-hosted Helm-чартом NVIDIA Run:ai. Это система учёта проектов, департаментов, квот, пользователей, ролей и политик. Доступна через UI, CLI runai и REST API.
• Кластерный компонент на кластере с GPU, также через Helm. Содержит планировщик NVIDIA Run:ai, admission-вебхуки и контроллеры нагрузок. Подключается к плоскости управления по HTTPS и регистрируется как управляемый кластер.
• Knative Serving на кластере с GPU — среда исполнения, которую NVIDIA Run:ai использует для нагрузок инференса. Обеспечивает автомасштабирование по запросам, масштабирование до нуля, выкатку по ревизиям и стабильный URL для каждого сервиса. Объекты Knative Service генерируются NVIDIA Run:ai из спецификации более высокого уровня InferenceWorkload.
• Нагрузки исследователей (Workspaces, задачи обучения, распределённое обучение, сервисы инференса) отправляются в плоскость управления и планируются на кластер с GPU.

Протестированная конфигурация

В таблице ниже перечислены компоненты, задействованные в проверке. Для продуктивных внедрений источником истины следует считать опубликованные матрицы совместимости NVIDIA Run:ai, GPU Operator и VCF. Перечисленные компоненты были сверены с системными требованиями кластера NVIDIA Run:ai 2.24 и матрицей поддержки; Kubernetes, GPU Operator, Knative и Prometheus укладываются в поддерживаемые диапазоны версий.

Топология сети и DNS

На рисунке ниже показан сквозной путь трафика от внешних клиентов через NSX и HAProxy в плоскость управления NVIDIA Run:ai и к конечным точкам инференса.

Внутренний (внутрикластерный) ingress

Ingress представляет собой двухчастный стек:

• HAProxy как контроллер внутри кластера;
• NSX как внешний балансировщик уровня L4.

Контроллер haproxytech/kubernetes-ingress устанавливается через Helm на каждый кластер VKS и публикуется сервисом типа LoadBalancer. NSX создаёт виртуальный сервер, выделяет внешний IP из пула LB кластера (далее по тексту он обозначается как <haproxy-lb-ip>) и перенаправляет порты 80 и 443 на поды HAProxy. HAProxy маршрутизирует по хосту и пути внутрь кластера: на сервисы плоскости управления NVIDIA Run:ai в управляющем кластере и на шлюз Knative kourier в кластере нагрузок.

HAProxy выбран потому, что NVIDIA Run:ai 2.24 теперь рекомендует именно его. Апстримный контроллер NGINX Ingress (kubernetes/ingress-nginx) выведен из эксплуатации, и параметр global.ingress.ingressClass у NVIDIA Run:ai для новых установок по умолчанию имеет значение haproxy. Стандарт Kubernetes Ingress при этом не изменился, поэтому чарты NVIDIA Run:ai безразличны к тому, какой контроллер используется, — лишь бы совпадал IngressClass.

Внешняя сеть (NSX, DNS и исходящий доступ)

Документация NVIDIA Run:ai рекомендует MetalLB для обслуживания сервисов LoadBalancer в self-hosted развёртываниях на собственной площадке. На VCF MetalLB не нужен: NSX уже реализует тот же контракт, поэтому любой сервис LoadBalancer автоматически получает виртуальный сервер NSX и внешний IP из пула Supervisor. NSX является локальным эквивалентом MetalLB для этого сценария.

Требуются два внешне доступных URL:

• URL плоскости управления (runai.<corp-domain>): разрешается в IP HAProxy LB на кластере плоскости управления. Используется администраторами и исследователями для UI и API, а также кластерным компонентом для регистрации и передачи событий обратно.
• Wildcard-домен инференса (*.inference.<corp-domain>): разрешается в IP HAProxy LB на кластере с GPU. Knative использует его, чтобы каждая нагрузка InferenceWorkload получала стабильное имя хоста для своей ревизии — например, phi3-mini.<project-namespace>.inference.<corp-domain>; HAProxy передаёт такие запросы в Kourier.

Оба имени — это записи DNS типа A, указывающие на IP соответствующего виртуального сервера NSX. Требуется wildcard-сертификат TLS, покрывающий домен инференса, чтобы конечные точки были доступны по HTTPS без выпуска сертификата под каждый сервис. С обоих кластеров нужен исходящий доступ по HTTPS (или настроенное зеркало) к NVIDIA NGC (GPU Operator, NVIDIA AI Enterprise, образы NIM), а также к helm.ngc.nvidia.com и nvcr.io (чарты и образы NVIDIA Run:ai). Устаревшая конечная точка runai.jfrog.io нужна только тем, кто до сих пор использует признанный устаревшим источник артефактов JFrog.

Идентификация и RBAC

В рассматриваемом развёртывании пользователи аутентифицируются по встроенной локальной базе NVIDIA Run:ai. Администраторы создаются и управляются через UI/API NVIDIA Run:ai, входят по логину и паролю и сопоставляются с ролевой моделью NVIDIA Run:ai (системный администратор, администратор департамента, администратор проекта, исследователь, наблюдатель) без внешнего поставщика удостоверений (IdP). Локальные учётные записи делают лабораторный стенд самодостаточным и позволяют проверить установку от начала до конца ещё до подключения IdP.

Для продуктивных сред NVIDIA Run:ai поддерживает федерацию через OpenID Connect (OIDC). Self-hosted плоскость управления включает собственный Keycloak, который может выступать доверяющей стороной по отношению к вышестоящему OIDC- или SAML-провайдеру (AD FS, Entra ID, Okta, Ping). Группы из claim-ов сопоставляются с департаментами и проектами NVIDIA Run:ai, а одни и те же токены OIDC принимаются интерфейсом, CLI runai и REST API. Переход от локальных пользователей к OIDC меняет только конфигурацию плоскости управления; кластерный компонент и нагрузки остаются нетронутыми.

Внутри Kubernetes NVIDIA Run:ai опирается на стандартный RBAC. Кластерный компонент создаёт пространства имён, сервисные учётные записи, роли и привязки ролей, под которыми работают нагрузки, а admission-вебхуки следят за соблюдением квот и политик проекта. Исследователям не нужен прямой доступ к kubeconfig рабочего кластера: для повседневной работы достаточно интерфейса, CLI и REST API NVIDIA Run:ai.

Хранилище

Оба кластера VKS используют драйвер CSI в качестве StorageClass по умолчанию, опираясь на vSAN или тот массив, который заказчик предоставил через политики хранения Supervisor. Драйвер поставляется вместе с VKS, поэтому отдельная установка CSI не требуется. Здесь появляются три класса постоянных томов:

• Состояние плоскости управления на управляющем кластере: встроенный PostgreSQL, хранилище Thanos receive, потоки NATS, Keycloak.
• Состояние на стороне кластера с GPU: локальный Prometheus, собирающий метрики DCGM и нагрузок, плюс любые кэши NVIDIA Run:ai уровня кластера.
• PVC, запрошенные исследователями косвенно через источники данных NVIDIA Run:ai: подключение источника данных на базе PVC к Workspace или задаче обучения материализует PersistentVolumeClaim к StorageClass по умолчанию, который обслуживается драйвером vSphere CSI поверх vSAN.

Топология и гибкость

Одна self-hosted плоскость управления способна обслуживать один или несколько кластеров с GPU; кластер, на котором она работает, может как выполнять GPU-нагрузки, так и оставаться исключительно CPU-кластером; кластеры с GPU можно добавлять и убирать со временем без пересоздания плоскости управления.

Для двухкластерной схемы NVIDIA Run:ai на VCF с Private AI Foundation with NVIDIA (управляющий кластер только с CPU плюс рабочий кластер с GPU) — это удачная отправная точка. Такая схема даёт платформенным командам наибольшую свободу действий: работы второго дня над плоскостью управления (обновления, резервные копии, ротация сертификатов, перенастройка OIDC) не затрагивают кластер с GPU, а сама плоскость управления никогда не конкурирует с нагрузками за ёмкость GPU. Именно эта топология рекомендуется для промышленной эксплуатацAI, и на неё ориентированы описанные далее шаги развёртывания.

Практическое замечание о том, как эти кластеры создаются на VCF: элемент каталога AI Kubernetes Cluster в VCF Automation создаёт только кластеры VKS с GPU. Элемент каталога инициирует установку GPU Operator в процессе развёртывания, а DaemonSet драйвера оператора не находит GPU на узле без ускорителя, поэтому такой кластер никогда не переходит в исправное состояние. Следовательно, управляющий кластер только с CPU нужно создавать другим путём: через интерфейс Supervisor, рабочие процессы VCF Lifecycle and Configuration, CLI VCF или обычный манифест VKS, применённый к пространству имён vSphere. За элементом каталога AI Kubernetes Cluster остаётся только рабочий кластер с GPU.

В документации NVIDIA Run:ai 2.24 явно поддерживаются и эта двухкластерная схема, и более простой однокластерный вариант, когда плоскость управления и кластерный компонент сосуществуют на одном Kubernetes-кластере. В системных требованиях к кластеру отмечается: если первый кластер и плоскость управления размещены совместно, отдельный ingress-контроллер и FQDN не нужны; если они разнесены, и то и другое требуется на каждой стороне.

Лабораторный стенд намеренно демонстрирует эту гибкость: два кластера VKS с GPU (оба развёрнуты через элемент каталога AI Kubernetes Cluster в VCF Automation) зарегистрированы в одной плоскости управления NVIDIA Run:ai. Имена кластеров, модели GPU и доменные имена, встречающиеся далее, отражают конкретную среду, использованную для проверки.

На рисунке представлена следующая референсная архитектура:

• runai-vks размещает плоскость управления NVIDIA Run:ai (пространство имён runai-backend) и собственный кластерный компонент (пространство имён runai) на одном и том же Kubernetes-кластере, наряду с GPU-нагрузками на NVIDIA H100 в режиме vGPU. Одна и та же конечная точка NSX LB обслуживает и URL плоскости управления (runai.<corp-domain>), и локальный ingress кластера. Это однокластерная схема: плоскость управления находится на кластере с GPU и делит ресурсы с нагрузками, когда такой компромисс приемлем.
• runai-vks-rtx — второй AI Kubernetes Cluster в собственном пространстве имён vSphere, с другим оборудованием (профиль vGPU на базе NVIDIA RTX PRO 6000 Blackwell) и собственной точкой ingress (runai-rtx.<corp-domain>). На нём работает только кластерный компонент NVIDIA Run:ai, который регистрируется в плоскости управления на runai-vks. В интерфейсе он отображается как второй управляемый кластер со своими пулами узлов, проектами и квотами.

Вместе два кластера покрывают обе поддерживаемые топологии в рамках одной аренды. Обоими управляет одна и та же плоскость управления, поэтому проекты, департаменты, RBAC, политики, интеграции и дашборды настраиваются один раз. В этом и состоит эксплуатационная история для заказчиков VCF и Private AI Foundation with NVIDIA: начать с той конфигурацAI, которая подходит сегодня, добавлять кластеры VKS по мере установки нового оборудования или подключения новых арендаторов, смешивать поколения GPU между кластерами и управлять всем через единую плоскость управления NVIDIA Run:ai.

Мультиарендность и изоляция арендаторов на VCF

Внутри одного кластера VKS NVIDIA Run:ai разделяет арендаторов через департаменты, проекты и пространства имён Kubernetes. Каждая команда получает собственную квоту GPU, область действия RBAC и изоляцию нагрузок, но все арендаторы используют один и тот же API-сервер Kubernetes, etcd и controller manager. Многим организациям такой сегментации на уровне пространств имён достаточно, и она максимизирует утилизацию GPU: планировщик NVIDIA Run:ai видит каждый GPU на каждом узле и может плотно упаковывать задачи по всем ним.

Когда требуется более жёсткая изоляция — например, арендаторам нужно устанавливать собственные CRD, работать с несовместимыми версиями Kubernetes или иметь строгую границу безопасности на уровне плоскости управления — на VCF ответом становится создание отдельных кластеров VKS. Каждый кластер VKS — полностью независимая плоскость управления Kubernetes (собственные API-сервер, etcd, controller manager), работающая на своём наборе виртуальных машин рабочих узлов. Supervisor и VCF Automation делают это операционно простым: запрос дополнительного AI Kubernetes Cluster из каталога VCF Automation выполняется в режиме самообслуживания, а управление жизненным циклом (обновления, патчи, масштабирование) берёт на себя Supervisor, а не платформенная команда вручную. Добавление нового кластера в NVIDIA Run:ai сводится к одной Helm-установке кластерного компонента и последующей регистрации в интерфейсе плоскости управления.

Это VCF-нативный эквивалент паттерна виртуальных кластеров, применяемого в Kubernetes на «голом железе», где поверх общего физического кластера накладывается лёгкая виртуальная плоскость управления, дающая каждому арендатору собственную поверхность API. На VCF такая абстракция уже существует на инфраструктурном уровне: кластеры VKS являются границей арендатора, Supervisor — общей инфраструктурой, а NSX обеспечивает сетевую изоляцию между ними. Результат тот же — сильная изоляция арендаторов без потери централизованного планирования GPU через NVIDIA Run:ai, но достигается он средствами платформы, которой заказчик уже управляет, а не дополнительным слоем «Kubernetes внутри Kubernetes».

Предварительные требования

NVIDIA Run:ai публикует подробные системные требования как для self-hosted плоскости управления, так и для кластерного компонента. Их следует считать источником истины и изучить полностью до начала работ:

• Run:ai 2.24 Control Plane System Requirements
• Run:ai 2.24 Cluster System Requirements
• Run:ai 2.24 Support Matrix

Сверх этого выбран вариант self-hosted плоскости управления и предполагается, что уже выполнены следующие условия:

• VCF 9.0 с включённым Supervisor и настроенным Private AI Foundation with NVIDIA.
• Два кластера VKS, созданных через элемент каталога AI Kubernetes Cluster в VCF Automation, с развёрнутым GPU Operator и работающим nvidia-smi в тестовом поде.
• StorageClass на базе драйвера vSphere CSI (используется по умолчанию в AI Kubernetes Cluster).
• Две записи типа A: одна для URL плоскости управления (runai.<corp-domain>), другая для wildcard-домена инференса (*.inference.<corp-domain>), обе указывают на выданные NSX адреса LoadBalancer соответствующих кластеров.
• Wildcard-сертификат TLS, покрывающий домен инференса.
• Ключ NGC API для загрузки Helm-чартов NVIDIA Run:ai (helm.ngc.nvidia.com) и контейнерных образов (nvcr.io); этот же ключ покрывает образы NVIDIA AI Enterprise (GPU Operator, NIM). Начиная с версAI 2.24 NGC является рекомендуемым источником артефактов для всех новых и существующих установок; устаревший репозиторий JFrog (runai.jfrog.io) остаётся поддерживаемым в 2.24, но будет удалён в одном из будущих выпусков. Для изолированных кластеров реестры следует зеркалировать локально.

Шаги развёртывания

Далее установка описана от начала до конца, с реальными командами и значениями в рамках лабораторного стенда VMware. FQDN плоскости управления, wildcard инференса и IP-адреса приведены как заполнители (runai.<corp-domain>, *.inference.<corp-domain>, <haproxy-lb-ip>) — их следует заменить своими. Каждый шаг сопровождается ссылкой на соответствующую страницу документации NVIDIA Run:ai.

В лаборатории задействованы два AI Kubernetes Cluster из VCF Automation: runai-vks несёт плоскость управления NVIDIA Run:ai вместе с собственными GPU-нагрузками (однокластерная схема), а runai-vks-rtx — второй кластер только с GPU, зарегистрированный в той же плоскости управления (схема с раздельными кластерами). Приведённый ниже порядок написан для двухкластерного варианта (кластер плоскости управления плюс один или несколько рабочих кластеров с GPU); для однокластерной схемы, используемой на runai-vks, все команды выполняются с одним и тем же kubeconfig, один и тот же TLS-секрет обслуживает обе роли, а раздел о регистрации кластера и установке кластерного компонента следует непосредственно за разделом об установке self-hosted плоскости управления на том же кластере.

Подготовка кластеров VKS

Оба лабораторных кластера (runai-vks и runai-vks-rtx) создаются как элементы каталога AI Kubernetes Cluster в VCF Automation в соответствAI с описанной выше топологией. Если используется рекомендуемая двухкластерная схема, дополнительно нужно создать управляющий кластер только с CPU одним из путей VKS, не связанных с AI (интерфейс Supervisor, рабочие процессы VCF Lifecycle and Configuration, CLI VCF или обычный манифест VKS); остальные шаги применимы к нему без изменений.

При развертывании любого из кластеров с GPU в VCF Automation следует выбрать класс ВМ для пула узлов, чей профиль vGPU соответствует модели и объёму, которые нужно предоставить Kubernetes. Как только кластер перейдёт в состояние Ready, создайте контекст kube с помощью CLI VCF. Одна команда одновременно выполняет вход в Supervisor и ограничивает контекст рабочим кластером VKS:

vcf context create <ctx-name> \
  --endpoint https://<supervisor-vip> \
  --username <sso-user> \
  --workload-cluster-name <cluster-name> \
  --workload-cluster-namespace <vsphere-namespace> \
  --type k8s

vcf context use <ctx-name>

Дополнительные материалы: Deploy a GPU-Accelerated VKS Cluster by Using a Self-Service Catalog Item in VCF Automation (VCF 9.0) и Workflow for Provisioning VKS Clusters Using VCF CLI.

Проверка NVIDIA GPU Operator

Когда кластер создан через элемент каталога AI Kubernetes Cluster, GPU Operator разворачивается автоматически вместе с лицензированным по NVIDIA AI Enterprise гостевым драйвером vGPU, device plugin и DCGM Exporter. Его работоспособность подтверждают три проверки.

Во-первых, все поды оператора должны быть в состоянии Running:

kubectl -n gpu-operator get pods
# gpu-operator-*, nvidia-driver-daemonset-*, nvidia-device-plugin-*,
# nvidia-dcgm-exporter-*, nvidia-container-toolkit-* ... all Running

Во-вторых, нужно зайти в под DaemonSet драйвера на узле с GPU и выполнить nvidia-smi -q, чтобы убедиться, что драйвер загружен, привязан нужный профиль vGPU, а лицензия имеет статус Licensed относительно сервера NVIDIA License System (NLS):

DRIVER_POD=$(kubectl -n gpu-operator get pod \
  -l app.kubernetes.io/component=nvidia-driver \
  -o jsonpath='{.items[0].metadata.name}')

kubectl -n gpu-operator exec "$DRIVER_POD" -c nvidia-driver-ctr -- nvidia-smi -q | \
  grep -E "Driver Version|vGPU Software Licensed Product|License Status"
# Driver Version : 580.105.08
# vGPU Software Licensed Product
#     Product Name : NVIDIA AI Enterprise
#     License Status : Licensed (Expiry: ...)

Статус Licensed для ожидаемого продукта NVIDIA AI Enterprise служит сигналом, что виртуальная машина рабочего узла достучалась до NLS и что элемент каталога выдал ей правильный токен. Если отображается Unlicensed, чаще всего причина на Private AI Foundation with NVIDIA заключается в недоступности NLS с рабочей ВМ, а не в Kubernetes.

В-третьих, следует запустить одноразовый под с CUDA, чтобы убедиться, что device plugin объявляет GPU, а container toolkit корректно их пробрасывает. Кластеры VKS применяют политику Pod Security Admission (PSA) уровня restricted к пространству имён default, поэтому спецификация пода должна содержать соответствующий securityContext:

kubectl run cuda-smoke --image=nvcr.io/nvidia/cuda:12.4.1-base-ubuntu22.04 \
  --rm -it --restart=Never \
  --overrides='{
    "spec":{
      "containers":[{
        "name":"cuda-smoke",
        "image":"nvcr.io/nvidia/cuda:12.4.1-base-ubuntu22.04",
        "command":["nvidia-smi"],
        "resources":{"limits":{"nvidia.com/gpu":"1"}},
        "securityContext":{
          "runAsNonRoot":true,
          "runAsUser":1000,
          "allowPrivilegeEscalation":false,
          "capabilities":{"drop":["ALL"]},
          "seccompProfile":{"type":"RuntimeDefault"}
        }
      }]
    }
  }'

Дополнительный материал: NVIDIA GPU Operator with NVIDIA AI Enterprise.

Установка ingress-контроллера (HAProxy) и создание TLS-секретов

Эти действия выполняются на кластере плоскости управления и на каждом рабочем кластере. IngressClass (haproxy) везде одинаков.

Назначение StorageClass по умолчанию. NVIDIA Run:ai требует наличия StorageClass по умолчанию. В кластерах VKS, созданных через Private AI Foundation with NVIDIA, уже есть драйвер vSphere CSI и класс vsan-default-storage-policy:

kubectl get storageclass

kubectl patch storageclass vsan-default-storage-policy \
  -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Установка ingress-контроллера HAProxy. Образы чарта HAProxy размещены на Docker Hub, который теперь ограничивает частоту анонимных загрузок. Репозиторий образов следует переопределить на кэширующее зеркало Google (mirror.gcr.io):

helm repo add haproxytech https://haproxytech.github.io/helm-charts
helm repo update

helm install haproxy-kubernetes-ingress haproxytech/kubernetes-ingress \
  --create-namespace --namespace haproxy-controller \
  --set controller.service.type=LoadBalancer \
  --set controller.image.repository=mirror.gcr.io/haproxytech/kubernetes-ingress \
  --wait --timeout 5m

Внешний IP NSX назначает автоматически:

kubectl -n haproxy-controller get svc haproxy-kubernetes-ingress \
  -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Команда возвращает IP HAProxy LB данного кластера, далее обозначаемый как <haproxy-lb-ip>. Публичную запись A runai.<corp-domain> нужно перенаправить на <haproxy-lb-ip> кластера плоскости управления. На рабочем кластере с GPU wildcard-запись инференса *.inference.<corp-domain> направляется на <haproxy-lb-ip> этого кластера.

kubectl get ingressclass haproxy
# NAME      CONTROLLER                              PARAMETERS   AGE
# haproxy   haproxy.org/ingress-controller/haproxy  <none>       30s

Генерация TLS-материалов. Перед установками NVIDIA Run:ai нужны два комплекта TLS:

• Комплект плоскости управления (используется на кластере плоскости управления): серверный сертификат, покрывающий FQDN плоскости управления (runai.<corp-domain>), и его закрытый ключ. Если сертификат подписан частным центром сертифкации, дополнительно требуется пакет CA, чтобы кластерный компонент на рабочем кластере мог его проверить.
• Комплект инференса (используется на рабочем кластере с GPU средствами Knative): wildcard-сертификат сервера, покрывающий *.inference.<corp-domain>, и его закрытый ключ.

Каждый комплект должен превратиться в три PEM-файла в том рабочем каталоге, где хранятся установочные материалы:

1. fullchain.pem (сертификат сервера плюс промежуточные УЦ);
2. private.pem (соответствующий ключ);
3. ca-bundle.pem (цепочка выпускающего УЦ, нужна только для частных УЦ).

Способ их получения остаётся на усмотрение администратора: корпоративная PKI вроде Active Directory Certificate Services, публичный провайдер ACME с проверкой DNS-01 (Let's Encrypt, ZeroSSL) или самоподписанный локальный центр сертификации, созданный с помощью cfssl либо openssl для непродуктивных сборок. Дальнейшая процедура одинакова независимо от издателя; меняются только пути, передаваемые в kubectl create secret tls и kubectl create secret generic.

Замечания по Pod Security Admission. Кластеры VKS в лаборатории по умолчанию применяют PSA уровня restricted. Устанавливаемым компонентам (плоскость управления и кластер NVIDIA Run:ai, Knative, GPU Operator) требуется уровень privileged на их пространствах имён, и каждый подраздел явно помечает своё пространство имён; пропускать строки вида kubectl label namespace ... pod-security.kubernetes.io/enforce=privileged --overwrite нельзя. Чарт HAProxy уже соответствует уровню restricted.

Тестовые нагрузки, создаваемые вне привилегированных пространств имён, остаются под restricted и требуют явного securityContext:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: [ALL]
  seccompProfile:
    type: RuntimeDefault

Дополнительные материалы: Domain Name и Install Ingress.

Установка Prometheus на рабочем кластере

Телеметрия NVIDIA Run:ai на стороне кластера питается от kube-prometheus-stack. У NVIDIA Run:ai есть собственный интерфейс, поэтому Grafana отключается:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install prometheus prometheus-community/kube-prometheus-stack \
  -n monitoring --create-namespace \
  --set grafana.enabled=false

kubectl -n monitoring get pods
# kube-prometheus-stack components Running,
# prometheus-prometheus-kube-prometheus-prometheus-0 Ready 2/2

Конфигурация сбора метрик DCGM Exporter из GPU Operator подхватывается автоматически через ServiceMonitor nvidia-dcgm-exporter.

Дополнительный материал: Install Prometheus.

Установка self-hosted плоскости управления NVIDIA Run:ai

Нужно переключиться на кластер плоскости управления и создать пространство имён:

kubectl create namespace runai-backend
kubectl label namespace runai-backend \
  pod-security.kubernetes.io/enforce=privileged --overwrite

Затем создаются секрет TLS для FQDN плоскости управления, секрет с пакетом CA (обязателен при использованAI частного УЦ) и секрет для загрузки образов из NGC:

kubectl -n runai-backend create secret tls runai-backend-tls \
  --cert /path/to/fullchain.pem --key /path/to/private.pem

kubectl -n runai-backend create secret generic runai-ca-cert \
  --from-file=runai-ca.pem=/path/to/ca-bundle.pem

kubectl -n runai-backend create secret docker-registry runai-reg-creds \
  --docker-server=https://nvcr.io \
  --docker-username='$oauthtoken' \
  --docker-password='<ngc-api-key>' \
  --docker-email=<your-email>

Далее добавляется Helm-репозиторий NGC для чарта плоскости управления с аутентификацией по ключу NGC API:

helm repo add runai-backend https://helm.ngc.nvidia.com/nvidia/runai --force-update \
  --username='$oauthtoken' --password='<ngc-api-key>'
helm repo update

Установка плоскости управления. Для частного УЦ добавляется --set global.customCA.enabled=true; для любого ingress-контроллера, отличного от HAProxy, переопределяется --set global.ingress.ingressClass=:

helm upgrade -i runai-backend -n runai-backend \
  runai-backend/control-plane \
  --version <2.24.x> \
  --set global.domain=runai.<corp-domain> \
  --set global.customCA.enabled=true \
  --set global.ingress.ingressClass=haproxy \
  --set tenantsManager.config.adminUsername=admin@<corp-domain> \
  --set tenantsManager.config.adminPassword='<initial-admin-password>' \
  --wait --timeout 15m

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

Затем следует убедиться, что все поды в состоянии Running:

kubectl -n runai-backend get pods
# keycloak-0, runai-backend-{frontend,backend,bff-service,authorization,tenants-manager,
# postgresql-0,nats-0..2,traefik,thanos-receive-0,...} all Running

Далее нужно открыть https://runai.<corp-domain>/ (после завершения установки Helm интерфейс может становиться доступным до 15 минут) и войти под учётными данными администратора. Кластер должен отображаться в интерфейсе со статусом Connected.

При первой установке первый вход запускает мастер начальной настройки из четырёх шагов:

1. Установка кластера.
2. Настройка SSO.
3. Настройка почтового сервера.
4. Создание первой исследовательской команды.

Шаги со второго по четвёртый можно пропустить и настроить позже из интерфейса NVIDIA Run:ai. Первый шаг описан в следующем разделе.

Дополнительный материал: Install the Control Plane.

Регистрация кластера и установка кластерного компонента NVIDIA Run:ai

Мастер начальной настройки (шаг 1) проводит через регистрацию первого кластера: нужно ввести имя, например runai-vks, выбрать вариант Same as the control plane или Remote control plane, указать URL кластера (runai.<corp-domain> для однокластерной схемы либо собственный FQDN кластера для схемы с раздельными кластерами) и пройти дальше. Интерфейс выводит команду Helm, заранее заполненную значениями controlPlane.url, свежим controlPlane.clientSecret, cluster.uid и cluster.url — её нужно скопировать.

Чтобы добавить последующие кластеры после завершения работы мастера, следует перейти в Resources > Clusters > New Cluster и пройти тот же процесс.

Далее нужно переключиться на рабочий кластер и подготовить пространство имён и TLS-материалы:

kubectl create namespace runai
kubectl label namespace runai pod-security.kubernetes.io/enforce=privileged --overwrite
kubectl label namespace runai pod-security.kubernetes.io/warn=privileged --overwrite
kubectl label namespace runai pod-security.kubernetes.io/audit=privileged --overwrite

Установщик кластера NVIDIA Run:ai дополнительно создаёт на рабочем кластере два собственных пространства имён: runai-reservation (поды резервирования GPU, используемые нагрузками с дробными GPU) и runai-scale-adjust (поды масштабирования node-scale-adjuster). Поскольку VKS применяет стандарт Pod Security уровня restricted к любому пространству имён без явных меток PSA, оба пространства имён следует создать заранее с привилегированными метками, включая метаданные владения Helm, чтобы чарт runai-cluster принял их во время установки:

for ns in runai-reservation runai-scale-adjust; do
  kubectl create namespace $ns --dry-run=client -o yaml | kubectl apply -f -
  kubectl label namespace $ns \
    pod-security.kubernetes.io/enforce=privileged \
    pod-security.kubernetes.io/warn=privileged \
    pod-security.kubernetes.io/audit=privileged \
    app.kubernetes.io/managed-by=Helm --overwrite
  kubectl annotate namespace $ns \
    meta.helm.sh/release-name=runai-cluster \
    meta.helm.sh/release-namespace=runai --overwrite
done

kubectl -n runai create secret tls runai-cluster-domain-tls-secret \
  --cert /path/to/fullchain.pem --key /path/to/private.pem

kubectl -n runai create secret generic runai-ca-cert \
  --from-file=runai-ca.pem=/path/to/ca-bundle.pem

kubectl -n runai label secret runai-ca-cert \
  run.ai/cluster-wide=true run.ai/name=runai-ca-cert --overwrite

kubectl -n runai create secret docker-registry runai-reg-creds \
  --docker-server=https://nvcr.io \
  --docker-username='$oauthtoken' \
  --docker-password='<ngc-api-key>' \
  --docker-email=<your-email>

Затем добавляется Helm-репозиторий NGC для кластерного чарта. Это тот же репозиторий NGC, что и для плоскости управления, добавленный под другим псевдонимом:

helm repo add runai https://helm.ngc.nvidia.com/nvidia/runai --force-update \
  --username='$oauthtoken' --password='<ngc-api-key>'
helm repo update

Далее выполняется команда, выданная интерфейсом, плюс два дополнительных флага: global.customCA.enabled=true (частный УЦ) и clusterConfig.global.ingress.ingressClass=haproxy (IngressClass, который оператор кластера проставляет любому создаваемому им Ingress). На Helm 4 следует также добавить --server-side=false, чтобы избежать конфликтов серверного применения с оператором NVIDIA Run:ai:

helm upgrade -i runai-cluster runai/runai-cluster -n runai \
  --version <2.24.x> \
  --set controlPlane.url=runai.<corp-domain> \
  --set controlPlane.clientSecret='<from-UI>' \
  --set cluster.uid='<from-UI>' \
  --set cluster.url=runai.<corp-domain> \
  --set global.customCA.enabled=true \
  --set-string clusterConfig.global.ingress.ingressClass=haproxy \
  --server-side=false \
  --wait --timeout 15m

Затем проверяется, что поды на стороне кластера находятся в состоянии Running:

kubectl -n runai get pods
# runai-agent, cluster-sync, cluster-api, runai-operator, engine-operator,
# admission-controller, *-controllers, runai-node-exporter (DaemonSet),
# init-ca, prometheus-runai-0, status-updater, ... all Running

Как только агент достучится до плоскости управления, мастер в интерфейсе сменит сообщение Waiting for cluster to connect на Cluster connected. После этого кластер отображается в разделе Resources > Clusters со статусом Connected.

Дополнительный материал: Install the Cluster.

Установка Knative Serving для инференса

Knative Serving на кластере с GPU материализует нагрузки инференса NVIDIA Run:ai. Версия 2.24 поддерживает Knative от 1.11 до 1.18; в лаборатории используется 1.18.x с Kourier в качестве сетевого слоя и HAProxy перед ним.

Создание пространств имён:

kubectl create ns knative-operator
kubectl label ns knative-operator pod-security.kubernetes.io/enforce=privileged --overwrite

kubectl create ns knative-serving
kubectl label ns knative-serving pod-security.kubernetes.io/enforce=privileged --overwrite

Установка оператора Knative:

helm repo add knative-operator https://knative.github.io/operator
helm repo update

helm install knative-operator \
  --create-namespace --namespace knative-operator \
  --version 1.18.2 \
  knative-operator/knative-operator

kubectl -n knative-operator get deployment knative-operator

Создание wildcard-секрета TLS. NVIDIA Run:ai ожидает wildcard-сертификат под конкретным именем (runai-cluster-inference-tls-secret) в пространстве имён knative-serving:

kubectl -n knative-serving create secret tls runai-cluster-inference-tls-secret \
  --cert /path/to/wildcard-fullchain.pem --key /path/to/wildcard-private.pem

Применение пользовательского ресурса KnativeServing. Значение domain нужно заменить на реальный базовый домен инференса (без ведущего *.):

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  config:
    config-autoscaler:
      enable-scale-to-zero: "true"
    config-features:
      kubernetes.podspec-affinity: enabled
      kubernetes.podspec-init-containers: enabled
      kubernetes.podspec-persistent-volume-claim: enabled
      kubernetes.podspec-persistent-volume-write: enabled
      kubernetes.podspec-schedulername: enabled
      kubernetes.podspec-securitycontext: enabled
      kubernetes.podspec-tolerations: enabled
      kubernetes.podspec-volumes-emptydir: enabled
      kubernetes.podspec-fieldref: enabled
      kubernetes.containerspec-addcapabilities: enabled
      kubernetes.podspec-nodeselector: enabled
      multi-container: enabled
    domain:
      inference.<corp-domain>: ""
    network:
      domainTemplate: '{{.Name}}-{{.Namespace}}.{{.Domain}}'
      ingress-class: kourier.ingress.networking.knative.dev
      default-external-scheme: https
  high-availability:
    replicas: 2
  ingress:
    kourier:
      enabled: true

kubectl apply -f knative-serving.yaml
kubectl get knativeserving -n knative-serving
kubectl get svc kourier -n knative-serving

Нужно дождаться состояния Ready: True.

Публикация Kourier через HAProxy. Сервис Kourier здесь имеет тип ClusterIP, поэтому публичной точкой входа выступает HAProxy. Применяется объект Ingress, который направляет wildcard-хост в Kourier с использованием TLS-секрета инференса:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
  ingressClassName: haproxy
  rules:
    - host: '*.inference.<corp-domain>'
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: kourier
                port:
                  number: 80
  tls:
    - hosts:
        - '*.inference.<corp-domain>'
      secretName: runai-cluster-inference-tls-secret

kubectl apply -f knative-ingress.yaml
kubectl -n knative-serving get ingress knative-serving
# CLASS     HOSTS                          ADDRESS            PORTS
# haproxy   *.inference.<corp-domain>      <haproxy-lb-ip>    80, 443

Включение инференса в кластере NVIDIA Run:ai:

kubectl -n runai patch runaiconfig runai --type merge \
  -p '{"spec":{"global":{"inference":{"enabled":true},"subdomainSupport":true}}}'

Затем нужно убедиться, что кластер принял изменения:

kubectl -n runai logs deploy/inference-workload-controller | grep -i "Knative available"
kubectl -n runai logs deploy/cluster-sync | grep -i "serving-knative"

В выводе должно появиться Knative available: true и успешные синхронизацAI с плоскостью управления.

Дополнительные материалы: Install Optional NVIDIA Run:ai Components: Inference и External access to containers.

Продолжить чтение статьи: Развёртывание NVIDIA Run:ai на VMware Cloud Foundation - часть 2.