Google открыла k8s-aibom — контроллер Kubernetes для инвентаризации ИИ-нагрузок

Google Cloud опубликовала исходный исходник k8s-aibom — контроллера Kubernetes, который обнаруживает запущенные в кластере ИИ-компоненты и автоматически формирует ведомости компонентов машинного обучения в формате CycloneDX 1.6 ML-BOM. Средство собирает информация из фактического состояния кластера, следовательно способен находить в том числе нагрузки, которые не были зарегистрированы во внутренних системах компании.

Что попадает в ML-BOM

k8s-aibom отслеживает стандартные ресурсы Kubernetes: Deployment, StatefulSet, DaemonSet, Job, CronJob, а равным образом KServe InferenceService.

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

• среды выполнения моделей, включая vLLM, NVIDIA Triton, Hugging Face TGI и Ollama;

• агентские фреймворки — LangChain, AutoGen, CrewAI и другие;

• векторные базы данных и компоненты RAG, в частности Milvus, Qdrant и pgvector;

• задачи обучения и дообучения на PyTorch, JAX, KubeRay и Hugging Face Accelerate;

• инструменты оценки моделей, в том числе Ragas и lm-evaluation-harness.

Итог сохраняется как источник AIBOM: полный документ ML-BOM помещается в поле status.bomDocument. Дополнительно данные можно отправлять в Google Cloud Storage или на внешний адрес через веб-хук.

Без агентов на узлах и изменений в приложениях

Контроллер разворачивается как один непривилегированный Deployment в отдельном пространстве имён. Ему не нужны побочные контейнеры, привилегированные DaemonSet, модули eBPF или доступ к ядру и узлам.

Менять спецификации существующих подов и конвейеры CI/CD тоже не требуется. k8s-aibom получает информацию через стандартный программный оболочку Kubernetes и начинает обрабатывать пространство имён только после добавления соответствующей метки.

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

Объявлено, определено или неизвестно

Для каждого обнаруженного свойства k8s-aibom указывает уровень достоверности:

• declared — значение явно задано разработчиком в конфигурации нагрузки;

• inferred — значение определено контроллером по шаблонам и косвенным признакам;

• unresolved — наличие ИИ-компонента обнаружено, но его точные параметры инсталлировать не удалось.

В частности, модель, переданная через аргумент --model, получит статус declared. Среда vLLM, найденная по имени образа контейнера, будет отмечена как inferred.

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

Чем это отличается от сканирования при сборке

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

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

Документация формируются детерминированно, за исключением временных меток. Это позволяет использовать их в GitOps-процессах: сравнивать версии ML-BOM и отслеживать изменения ИИ-зависимостей.

Защита журнала аудита

Для выгрузки в Google Cloud Storage контроллеру в достаточной степени роли roles/storage.objectCreator, без прав на чтение и изменение объектов.

При записи используется условие DoesNotExist: если объект по выбранному пути уже существует, повторная запись завершится ошибкой. Это не позволяет незаметно перезаписать ранее сохранённую версию ML-BOM.

Google также связывает средство с требованиями EU AI Act, NIST AI Risk Management Framework и ISO/IEC 42001. Одновременно сам k8s-aibom не подтверждает соответствие этим стандартам — он только собирает сведения, которые могут использоваться в процедурах контроля и аудита.

Пока альфа-версия

Текущий версия обозначен как v1.0 alpha. Авторы считают его пригодным для некритичных сценариев наблюдения, но проект пока не является официально поддерживаемым продуктом Google.

Готового образа контейнера и публичного Helm-репозитория нет: образ необходимо собрать самостоятельно и загрузить в собственный реестр. Для быстрого запуска требуется Kubernetes 1.27 или новее. Инициатива тестировался с версиями Kubernetes от 1.27 до 1.35.

Несмотря на привязку анонса к GKE, контроллер не ограничен Google Cloud. Его можно запускать в GKE Standard и Autopilot, Amazon EKS, Azure AKS, OpenShift и локальных или собственных Kubernetes-кластерах. Специфичным для Google Cloud остаётся только необязательный экспорт в Cloud Storage.

Продолжить тему можно на двух бесплатных открытых уроках преподавателей-практиков — о выборе платформы для ИИ-нагрузок и безопасной работе с секретами в Kubernetes.

• 21 июля, 20:00. «Выбор между Serverless и Kubernetes для AI-ворклоадов: как определить оптимальную платформу под задачу». Записаться

• 27 июля, 20:00. «K8S + Vault — как получать секреты?». Записаться