Как Kubernetes стандартизирует поведение AI-нагрузок в кластерах
Kubernetes Blog 29 октября 2026 года опубликовал интервью с архитекторами программы AI Conformance — Джанет Куо (Janet Kuo, Google) и Юанем Таном (Yuan Tang, TensorScale AI) — о том, как инициатива прошла путь от программы CNCF до рабочей группы Kubernetes, а теперь вошла в SIG Architecture как постоянный подпроект. Речь о единых правилах поведения GPU-шедулинга, обучения и инференса для AI-нагрузок в кластерах.
Краткий ответ
AI Conformance — подпроект SIG Architecture Kubernetes, который вырабатывает проверяемые стандарты поведения для GPU-нагрузок, распределённого обучения и инференса: как кластер выделяет ускорители, настраивает сеть и шедулинг, оркестрирует запросы на инференс. Certified Kubernetes AI Conformance Program и формальные требования Kubernetes AI Requirements (KAR) дают платформенным командам критерий требовать от облаков и инструментов единообразного поведения. По словам создателей программы, число сертифицированных платформ за несколько месяцев выросло с 18 до 31.
От CNCF-программы до рабочей группы Kubernetes
Идею предложила Джанет Куо — старший инженер Google и мейнтейнер Kubernetes с 2015 года, которая в своё время писала core workload controllers, стандартизировавшие оркестрацию приложений в Kubernetes. Сегодня она возглавляет SIG Apps как со-председатель и технический лид, а также руководит программой AI Conformance.
По её словам, она заметила, что «все начали запускать AI на Kubernetes, но вендоры строили свои инфраструктурные стеки по-разному» — и забеспокоилась о фрагментации экосистемы. Куо написала первоначальное предложение Kubernetes AI Conformance, получила одобрение руководства CNCF и запустила AI Conformance Program, собрав вокруг неё со-председателей Юаня Тана, Риту Чжан (Rita Zhang) и Марио Фаландта (Mario Fahlandt).
Тан — сооснователь TensorScale AI, компании, которая строит AI-инфраструктуру для world models. До этого он был старшим главным инженером в Red Hat, где вёл платформу Red Hat AI и стратегию открытого кода, а также развивал сотрудничество Kubernetes с Kubeflow, Argo и KServe. Путь программы отражён в самом заголовке материала Kubernetes Blog — от Working Group к SIG Architecture: временная рабочая группа интегрировалась в SIG Architecture, группу Kubernetes, которая отвечает за архитектурную целостность проекта и курирует его долгоживущие подпроекты.
Почему экосистема AI на Kubernetes рисковала фрагментироваться
Мотивацию создатели формулируют прямо: ускоряющееся распространение AI-нагрузок на Kubernetes при одновременном риске фрагментации экосистемы. Организации стали запускать распределённое обучение, крупномасштабный инференс, GPU-интенсивные пайплайны и агентные AI-системы на множестве разных платформ Kubernetes. Но вендоры по-разному реализовывали инфраструктурные возможности для AI — особенно вокруг GPU, сети, шедулинга и оркестрации инференса. Это создавало проблемы с переносимостью, операционную непоследовательность и усиливало опасения по поводу привязки к вендору.
Для инженера это знакомая боль: кластер, настроенный под GPU-шедулинг в одном облаке, редко переносится один в один в другое — приходится заново разбираться, как именно платформа делит видеопамять между подами, в каком порядке обслуживает очередь инференс-запросов и что происходит при отказе GPU-узла. Каждый вендор и инструмент решал это по-своему, и единого ответа на вопрос «как должно себя вести» не было. Rабочая группа и была создана, чтобы собрать сообщество вокруг этого вопроса.
Четыре цели рабочей группы и как они оформились в стандарты
Цели рабочей группы её создатели описывают как набор из четырёх пунктов: вендоронейтральные стандарты AI-инфраструктуры, совместимые между собой Kubernetes-платформы для AI, последовательное операционное поведение AI-нагрузок и общие требования к масштабируемому развёртыванию.
Эти цели материализовались в конкретные артефакты. Рабочая группа запустила Certified Kubernetes AI Conformance Program — программу сертификации, по аналогии с другими conformance-программами CNCF: вендор или инструмент прогоняет тесты и подтверждает соответствие, вместо того чтобы платформенная команда вручную выясняла разницу в поведении на каждом новом окружении. Параллельно рабочая группа определила формальные Kubernetes AI Requirements (KAR) — структурированные требования к поведению AI-инфраструктуры, которые можно проверять и расширять по шаблону.
Конкретные результаты: от 18 до 31 сертифицированной платформы
На вопрос, достигла ли рабочая группа своих первоначальных целей, Куо и Тан ответили утвердительно и перечислили конкретные индикаторы. Среди них — запуск Certified Kubernetes AI Conformance Program, определение формальных KAR, широкое участие крупных игроков экосистемы, согласование вокруг новых примитивов Kubernetes, нужных для AI-нагрузок, и выстроенный roadmap автоматизированной верификации соответствия.
Отдельно создатели программы называют и количественный результат: между keynote на KubeCon NA 2025, где программа была анонсирована впервые, и update-keynote на KubeCon EU 2026 число сертифицированных платформ выросло с 18 до 31 — то есть почти удвоилось за несколько месяцев. По словам Куо и Тана, самое главное достижение рабочей группы — не отдельные цифры, а сложившийся в сообществе консенсус: AI-нагрузки теперь рассматриваются как полноценный, first-class сценарий использования Kubernetes, а не специализированное дополнение для ML-платформ и GPU-лабораторий.
По их словам, именно этот сдвиг и объясняет, почему AI Conformance получила заметное место на последнем KubeCon + CloudNativeCon: требования к AI-инфраструктуре — выделение ускорителей, высокопроизводительная сеть, учитывающая нагрузку оркестрация, низкая задержка инференса — сообщество сочло достаточно важными, чтобы стандартизировать их на уровне экосистемы, а не оставлять на усмотрение каждого отдельного вендора.
Переход от рабочей группы к постоянному подпроекту SIG Architecture
В Kubernetes рабочие группы по определению временные: у них есть конкретная цель, после достижения которой группа закрывается. У AI-рабочей группы такой целью было опубликовать первоначальные требования AI Conformance и запустить процесс сертификации. Как только эти вехи были пройдены, рабочую группу архивировали, а AI Conformance перевели в постоянный подпроект SIG Architecture.
По словам Куо и Тан, этот переход прямо доказывает, что AI-инфраструктура нуждается в постоянном архитектурном курировании, а не в разовой инициативе. SIG Architecture уже отвечает за общий Kubernetes Conformance и принципы проектирования API, поэтому размещение там подпроекта AI Conformance логично: это удерживает требования к AI-нагрузкам в согласии с остальной архитектурой Kubernetes на долгий срок. Создатели программы проводят параллель с Dynamic Resource Allocation (DRA) — механизмом выделения ускорителей, который тоже прошёл путь от рабочей группы Device Management к интеграции под крылом SIG Architecture. Теперь внутри SIG Architecture команда AI Conformance обещает больший фокус на том, как возможности для AI вплетаются в саму архитектуру Kubernetes: не как надстройка поверх платформы, а как то, что требует адаптации базовых примитивов — шедулинга и выделения ресурсов — на годы вперёд.
Как AI Conformance балансирует скорость AI и стабильность Kubernetes API
AI-инфраструктура развивается очень быстро, а Kubernetes API по дизайну должны оставаться стабильными годами — и создатели программы признают это напряжение открыто. Чтобы его снять, они используют многоуровневую модель градации: когда появляется новая концепция AI-инфраструктуры, её сначала вводят как рекомендованное требование SHOULD. Это даёт экосистеме пространство для эксперимента и согласования лучших практик, не фиксируя Kubernetes в жёстких API слишком рано. Когда соответствующие API стабилизируются и получают распространение в экосистеме, требование переходит в разряд обязательных MUST.
Второй принцип — осознанная фокусировка на инфраструктурном слое. Рабочая группа тестирует базовые возможности вроде поддержки ускорителей через Dynamic Resource Allocation (DRA), а не углубляется в конкретные AI-фреймворки или серверы обслуживания моделей. Это держит базовую платформу стабильной, позволяя инструментарию над ней развиваться так быстро, как нужно рынку.
Связанные треки: WG Serving, Gateway AI Inference Extension и экосистема инструментов
Тан был со-председателем WG Serving — рабочей группы Kubernetes, сфокусированной на обслуживании моделей, — и именно там набрала обороты инициатива Gateway AI Inference Extension, расширение Kubernetes Gateway API для маршрутизации инференс-трафика. По словам Тана, в сообществе был сильный интерес включить требования, связанные с инференсом, в программу AI Conformance.
Отдельно Тан упоминает, что ещё до AI Conformance выстраивал сотрудничество Kubernetes с Kubeflow (набором инструментов для ML-пайплайнов на Kubernetes), Argo (оркестратором workflow и CD для Kubernetes) и KServe (платформой для обслуживания ML-моделей в кластере). Это не случайные упоминания: именно вокруг таких инструментов сегодня строится большая часть production ML-инфраструктуры на Kubernetes, и они — естественные кандидаты на то, чтобы в будущем подтверждать соответствие стандартам AI Conformance.
Что это значит для платформенных команд и CTO
Для платформенной команды появление проверяемого стандарта — это новый рычаг переговоров. Вместо абстрактных обещаний поддержки AI-нагрузок от облачного провайдера или вендора инструмента можно задавать конкретный вопрос: проходит ли платформа conformance-тесты AI Conformance. Это особенно важно при выборе между managed Kubernetes у разных облачных провайдеров и self-hosted кластером — соответствие единому поведению упрощает перенос GPU-нагрузок между ними и снижает стоимость миграции, которая иначе съедается переписыванием шедулинга и обвязки под инференс.
Для CTO это сигнал зрелости: Kubernetes-сообщество признало, что AI-нагрузки — отдельный класс workload-ов со своими требованиями к GPU и инференсу, и выстраивает для них ту же логику, что когда-то работала для обычных stateless- и stateful-приложений. Рост числа сертифицированных платформ с 18 до 31 за несколько месяцев — довольно конкретное подтверждение того, что индустрия хотела именно такой единый вендоронейтральный стандарт, а не очередную рекомендацию на бумаге. Платформенные команды получают первый формальный язык для разговора с облаками о переносимости AI-нагрузок — и этот язык уже подкреплён растущим числом сертифицированных платформ, а не только декларацией о намерениях.
Как участвовать в работе подпроекта
Куо и Тан описывают несколько практических путей для контрибьюторов. Основной репозиторий проекта — kubernetes-sigs/ai-conformance, там же проходят митинги рабочей группы. Тем, кто хочет предлагать новые требования к поведению AI-инфраструктуры, стоит участвовать в ревью существующих pull request'ов или оформлять собственные предложения по шаблону KAR. Если интересна разработка — рабочей группе нужна помощь в расширении автоматизированных тестовых наборов на Go в директории test репозитория.
Для вендоров, которые хотят сертифицировать свою платформу, все детали процесса собраны в репозитории cncf/k8s-ai-conformance. По словам создателей программы, сообщество отреагировало на инициативу быстрее, чем они ожидали: когда программу впервые анонсировали на keynote KubeCon NA 2025, авторы не были уверены в реакции рынка, но к update-keynote на KubeCon EU 2026 число сертифицированных платформ почти удвоилось.
Где стоит сохранять осторожность
Программа прошла путь от CNCF-инициативы до подпроекта SIG Architecture и уже показывает измеримый результат — рост с 18 до 31 сертифицированной платформы, запущенную Certified Program и формальные KAR. Но в материале Kubernetes Blog не назван конкретный список платформ, прошедших сертификацию, и не раскрыт детальный состав тестового набора по каждому KAR — за этим стоит следить в репозитории cncf/k8s-ai-conformance по мере публикаций.
Также из интервью не до конца ясно, о каком именно KubeCon + CloudNativeCon идёт речь, когда авторы говорят про внимание к AI Conformance на «последнем» мероприятии — явно названы только KubeCon NA 2025, где программу анонсировали, и KubeCon EU 2026, где отчитались о росте с 18 до 31 платформы. Прежде чем закладывать соответствие AI Conformance как жёсткий критерий в закупочные требования, стоит следить за дальнейшими публикациями SIG Architecture и смотреть, появится ли полный и постоянно обновляемый список конформных платформ.
FAQ
Что такое AI Conformance в Kubernetes?
Это подпроект SIG Architecture Kubernetes, который вырабатывает вендоронейтральные стандарты поведения для AI-нагрузок: GPU, сеть, шедулинг и оркестрация инференса. Он прошёл путь от программы CNCF к рабочей группе, а затем стал постоянной частью SIG Architecture.
Как conformance-тесты помогают избежать vendor lock-in?
Тесты дают проверяемый способ подтвердить, что облако или инструмент ведёт себя так же, как другие конформные платформы. Платформенная команда может требовать соответствия при выборе провайдера и проще переносить AI-нагрузки между разными Kubernetes-платформами, включая managed-облака и self-hosted кластеры.
Кто создал AI Conformance Working Group?
Инициативу предложила Джанет Куо из Google, которая написала первоначальное предложение и получила одобрение руководства CNCF. Со-председателями стали Юань Тан из TensorScale AI, Рита Чжан и Марио Фаландт.
Что такое Kubernetes AI Requirements (KAR)?
Это формальные требования к поведению AI-инфраструктуры в Kubernetes, которые рабочая группа определила в рамках программы AI Conformance. Новые требования предлагаются по стандартному шаблону KAR и проходят через тестовые наборы и процесс ревью сообщества.
Насколько выросло число сертифицированных платформ?
По словам создателей программы, между keynote на KubeCon NA 2025, где программу анонсировали впервые, и update-keynote на KubeCon EU 2026 число сертифицированных платформ выросло с 18 до 31.