Привет! Я Дмитрий, инженер и руководитель направления MLOps в Совкомбанке. Специализируюсь на разработке и эксплуатации ML-платформ на базе Kubernetes и GPU.

С 2010 года в ИТ: строю инфраструктуру для машинного обучения, внедряю Kubeflow и GPU-оператор, настраиваю MIG на H100 в корпоративных средах с повышенными требованиями к безопасности и надежности. В последние годы фокусируюсь на оптимизации ML-пайплайнов, повышении утилизации GPU (включая MIG-профили) и интеграции MLOps-практик в процессы продуктовых команд.

В 2022 году в некоторых командах разработки «Совкомбанка» уже существовали проекты с применением искусственного интеллекта. Это были отдельные компоненты, которые хорошо справлялись с конкретными задачами приложения. Но не хватало единой платформы управления.

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

Единая ML-платформа с гибким RBAC позволила бы:

  • Защитить модели и данные — с контролем доступа на уровне команд и проектов

  • Отслежи��ать, кто и когда использует модель — для аудита и безопасности

  • Дать бизнесу самостоятельность — без ожидания инженеров, можно быстро тестировать гипотезы

Мы изучили доступные инструменты, попытались объединить их в одном Kubernetes-кластере, столкнулись с рядом ограничений — и в итоге пришли к архитектуре на базе Kubeflow и GPU-оператора.

В статье рассказываем, какие сложности были в ходе проекта, как выстроили работу с Kubeflow, настраивали H100 с MIG-разделением и что важно учесть, если вы планируете строить ML-платформу на bare-metal-GPU в корпоративной среде.

Что внутри

На рынке в то время были доступны две ML-платформы: проприетарная Caila от Just AI и open-source-решение Kubeflow.

Оба варианта предъявляли схожие требования к инфраструктуре:

  • кластер Kubernetes последних версий

  • bare-metal-серверы с поддержкой GPU

  • административные привилегии в кластере

Для управления кластерами Kubernetes в банке используется платформа «Штурвал», обладающая модульной и расширяемой архитектурой. Большая часть необходимых модулей работала в платформе «из коробки» — и то, что нам потребовалось доработать, никак не повлияло на поддержку решения. Для вычислительных ресурсов выбрали доступные на тот момент bare-metal-серверы с GPU H100.

Сначала мы развернули коммунальный Kubernetes-кластер для обеих ML-платформ. Разделение микросервисов планировалось осуществлять по стандартной схеме с использованием labels и taints для изоляции компонентов разных платформ.

Однако этот подход привел к ряду критических проблем:

  • Конфликты компонентов. Несмотря на использование labels и taints, компоненты Caila и Kubeflow конфликтовали при работе в одном кластере. ML-платформы конкурировали за ресурсы одних и тех же серверов. Распределить их компоненты между разными серверами не удалось, так как у производителей нет такой возможности. Любое обновление компонента платформы приводило бы к изменению конфигурации и откату назад. Из-за этого было сложно применить единую схему маркировки ко всем Kubernetes YAML-манифестам, которые генерировали платформы.

  • Угрозы информационной безопасности. Обе платформы имели административные привилегии в кластере и, следовательно, получали доступ ко всем компонентам друг друга. Это создавало потенциальные риски для безопасности и изоляции данных.

В результате анализа этих проблем мы решили разделить проекты на два независимых кластера.

Создание и настройку кластера Kubernetes в данной статье опустим, в «Штурвале» это делается просто и быстро. Сфокусируемся на самом интересном — установке Kubeflow и настройке видеокарт.

Установка Kubeflow в кластере

Необходимые компоненты:

  • Три виртуальных мастера на RedOS с ядром 6.12.21

  • Три железных рабочих ноды на RedOS с ядром 6.12.21 и видеокартами H100

  • Собранный кластер на «Штурвале»

Ниже описываем, как пошагово установить и настроить драйверы в любом используемом дистрибутиве Kubernetes.

  1. Закомментируем в /etc/dnf/dnf.conf 

    exclude=kernel* *kernel

  2. Ставим пакет для ядра.

    yum install kernel-lt-devel-6.12.21.red80.x86_64

  3. Проверяем, что в параметрах grub установлены эти значения: 

    module.sig_enforce=0

    rd.driver.blacklist=nouveau

  4. Добавляем драйвер nouveau в blacklist-модулей.

    Создаем файл /etc/modprobe.d/blacklist-nouveau.conf:

    Скрытый текст
    blacklist nouveau
blacklist lbm-nouveau
options nouveau modeset=0
alias nouveau off
alias lbm-nouveau off

    После перезагрузки вывод следующей команды должен быть пустым: lsmod | grep nouveau

    Если это не так, выполняем следующую команду и перезагружаемся:

    dracut –force

  5. Отключаем /etc/dnf/plugins/subscription-manager.conf

    Далее выставляем флаг disable_system_repos=0

  6. Включаем прокси.

    export https_proxy=http://proxy.company.io:3128/
export http_proxy=http://proxy.company.io:3128/

  7. Подключаем два репозитория:

    Создаем в /etc/yum.repos.d/

    cuda-rhel8.repo:

    Скрытый текст
    [cuda-rhel8-x86_64]
name=cuda-rhel8-x86_64
baseurl=https://developer.download.nvidia.com/compute/cuda/repos/rhel8/x86_64
enabled=1
gpgcheck=1
gpgkey=https://developer.download.nvidia.com/compute/cuda/repos/rhel8/x86_64/D42D0685.pub

    nvidia-container-toolkit.repo:

    Скрытый текст
    [nvidia-container-toolkit]
name=nvidia-container-toolkit
baseurl=https://nvidia.github.io/libnvidia-container/stable/rpm/$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://nvidia.github.io/libnvidia-container/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt

    Обязательно включаем репозитории: enabled=0 меняем на enabled=1

  8. Устанавливаем драйверы.

    dnf install dkms
dnf -y module install nvidia-driver:latest-dkms

  9. Проверяем наличие драйвера

    modprobe -vv nvidia
lsmod | grep nvidia

    или

    nvidia-smi

  10. Включаем службу.

    systemctl enable --now nvidia-persistenced.service

  11. Ставим дополнительные пакеты.

    yum install nvidia-docker2.noarch
yum install nvidia-fabric-manager-580.95.05.x86_64

  12. Перезагружаемся и проверяем, что все работает корректно.

    reboot
nvidia-smi

Подводные камни

Во время установки пользователи могут столкнуться с рядом ошибок, которые мы решали совместно с инженерами «Штурвала». Ниже разберем самые распространенные и возможные пути их решения.

  1. После установки драйвера, модуль ядра не подгружается

    При попытке выполнить modprobe nvidia, система выдает вот такую ошибку: Required key not available

    Решение:

    Скрытый текст
    grubby --update-kernel=ALL --args="module.sig_enforce=0"
grubby --update-kernel=ALL --remove-args="lockdown"
grub2-mkconfig -o /boot/grub2/grub.cfg
reboot

  2. DKMS не видит драйверы

    При наборе команды:

    dkms status
    вместо installed:
    nvidia/580.95.05: added

    Собираем и устанавливаем драйвер с помощью dkms: sudo dkms install -m nvidia -v 580.95.05

    Если система выдает подобную ошибку:

    Failed command: 'make' -j128 KERNEL_UNAME=6.12.21.red80.x86_64 modules
Error! Bad return status for module build on kernel: 6.12.21.red80.x86_64 (x86_64)

    Смотрим логи:

    cat /var/lib/dkms/nvidia/580.95.05/build/make.log

    Видим ошибку прав доступа у системного линкера:

    /bin/sh: line 1: /bin/ld: Permission denied

    Далее смотрим права линкера:

    ls -l /usr/bin/ld

    Удаляем файл и создаем символическую ссылку:

    sudo rm -f /usr/bin/ld
sudo ln -s /usr/bin/ld.bfd /usr/bin/ld

    Повторно собираем и устанавливаем драйвер:

    sudo dkms install -m nvidia -v 580.95.05
dkms status

  3. Если под nvidia-operator-validator не стартует с версией драйверов 580.95.05 из официального репозитория nvidia, то читаем логи пода.

    Если видим подобную ошибку:

    Скрытый текст

    Error: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error running prestart hook #0: exit status 1, stdout: , stderr: Auto-detected mode as 'legacy' nvidia-container-cli: mount error: failed to add device rules: unable to generate new device filter program from existing programs: unable to create new device filters program: load program: invalid argument: last insn is not an exit or jmp processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0: unknown

    То решаем ее путем изменения параметров ядра: с net.core.bpf_jit_harden=2 на net.core.bpf_jit_harden=1

    Настраиваем nvidia container toolkit:

    Скрытый текст
    dnf install -y nvidia-docker2
dnf install -y nvidia-container-toolkit
nvidia-ctk runtime configure --runtime=containerd --set-as-default
systemctl restart containerd

    Настраиваем конфиг containerd в /etc/containerd/config.toml

    В секции [plugins."io.containerd.grpc.v1.cri".containerd.runtimes] меняем значения для runtime в подсекциях:

    Скрытый текст
    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia]
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.nvidia.options]
BinaryName = "/usr/bin/nvidia-container-runtime"

    В подсекции [plugins."io.containerd.runtime.v1.linux"] меняем значение на runtime = "nvidia"

Разворачиваем gpu-operator в кластере

  1. Перед деплоем gpu-operator необходимо добавить namespace (gpu-operator) в исключение kyverno

  2. Далее качаем helm chart и добавляем в проект кластера. Описание helm values доступно здесь.

  3. Отключаем лишнее в values (драйвер ставим самостоятельно):

    Скрытый текст
    driver:
  enabled: false
vgpuDeviceManager:
  enabled: false
vfioManager:
  enabled: false
sandboxDevicePlugin:
  enabled: false

    Указываем mig strategy в mixed:

    mig:
  strategy: mixed

    Добавляем (fix bug) в validator:

    Скрытый текст
    driver:
  env:
    name: DISABLE_DEV_CHAR_SYMLINK_CREATION
    value: "true"

    Заносим параметры в tolerations:

    Скрытый текст
    tolerations:
  - key: nvidia.com/gpu
    operator: Exists
    effect: NoSchedule

  4. Запускаем pod для теста:

    https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/getting-started.html#running-sample-gpu-applications

    Смотрим логи:

    kubectl apply -f cuda-vectoradd.yaml
kubectl logs pod/cuda-vectoradd

    Вот так выглядит корректный ответ:

    Скрытый текст
    log
[Vector addition of 50000 elements]
Copy input data from the host memory to the CUDA device
CUDA kernel launch with 196 blocks of 256 threads
Copy output data from the CUDA device to the host memory
Test PASSED
Done

    После удаляем pod:

    kubectl delete -f cuda-vectoradd.yaml

Делим GPU с помощью MIG

MIG (Multi-Instance GPU) в Kubernetes — это функция разделения графического процессора (GPU) на аппаратном уровне. MIG позволяет разделить один GPU на несколько изолированных экземпляров, каждый из которых имеет выделенные вычислительные ядра, память и кэш.

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

Сейчас пошагово расскажем, как с этим работать.

  1. Разбиваем GPU на отдельные виртуальные части mig, чтобы получить:

    Изоляцию ресурсов

    Каждая MIG-инстанция работает независимо — как отдельная GPU. Нет «шумных соседей» — если один под грузит GPU — другие не страдают. Изоляция на уровне железа, а не софта (как в контейнерах).

    Максимальную утилизацию GPU

    Вместо одной тяжелой задачи — можно запустить несколько легких. Например: A100 80GB → 7 MIG 1g.10gb → 7 задач inference.

    Гарантированную производительность

    Каждая MIG получает фиксированный объем памяти и вычислительных ядер. Идеально для inference-задач, где нужна предсказуемая задержка.

    Безопасность

    Изоляция на уровне железа — даже если один под «сломается», другие продолжат работать. Это отлично подходит для мультитенантных сред, где разные команды/проекты используют одну GPU.

    Поддержку ML/DL/Inference

    Идеально для inference, batch processing, ML pipelines. Не подходит для heavy training — там лучше использовать целую GPU.

  2. Работа с MIG

    Так как уже развернут gpu-operator со стратегией "mig strategy: mixed" и точно известно, что карты поддерживают разделение на MIG, важно выполнить несколько шагов, чтобы разбить имеющиеся у нас карты.

    Первым делом смотрим доступные GPU на нодах:

    kubectl get node -o json | jq '.items[].metadata.labels'

    Меняем профиль MIG на ноде (all-1g.10gb или all-1g.20gb — профиль, необходимо выбрать подходящий):

    kubectl label nodes $NODE nvidia.com/mig.config=all-1g.10gb --overwrite

    Можем изменить профиль на сбалансированный, то есть разбить всю карту на части разных размеров:

    kubectl label nodes <node-name> nvidia.com/mig.config=all-balanced --overwrite

    При желании отключить MIG на ноде вводим эту команду:

    kubectl label nodes $NODE nvidia.com/mig.config=all-disabled --overwrite

    Для того чтобы посмотреть список профилей MIG'ов, достаточно на ноде с GPU выполнить:

    nvidia-smi mig -lgip

    Запускаем поды с MIG — для этого указываем в манифесте следующее:

    Скрытый текст
        resources:
      limits:
        nvidia.com/mig-1g.10gb: 1

    Если нужен конкретный MIG-инстанс, даем больше информации:

    Скрытый текст
        resources:
      limits:
        nvidia.com/mig-1g.10gb: 1
      requests:
        nvidia.com/mig-1g.10gb: 1

    Далее проверяем корректность работы с помощью команды.

    kubectl get pods -o jsonpath='{range
.items[]}{.metadata.name}{"\t"}{.spec.containers[].resources.limits}{"\n"}{end}'

    Если вы все сделали правильно, то на выходе получаете такой ответ:

    my-pod-1 map[nvidia.com/mig-1g.10gb:1]

  3. Принципы и примеры разбиения на MIG.

    Существует несколько подходов:

  • По нагрузке — меняем объем GB: MIG 1g.10gb или MIG 2g.20gb.

  • По количеству задач — меняем цифру в начале: 4 MIG 1g.10gb. или 2 MIG 2g.20gb.

  • По вычислительной мощности — изменяем количество ядер: 1g → 1/7 ядер, 2g → 2/7 ядер

  • По типу задач:

    Inference — 1g.10gb
    Training — 7g.40gb
    Batch processing — 2g.20gb

  • По изоляции — при работе с критичными задачами важно выделить отдельную MIG.

  • По стоимости: MIG дешевле, чем целая GPU.

    Примеры разбиения:

    H100 80 GB:

  • 14 MIG 1g.10gb (для inference)

  • 4 MIG 2g.20gb (для training)

  • 2 MIG 4g.40gb (для heavy training)

  • 1 MIG 7g.80gb (для super-heavy training)

    4. Недоступность MIG

    Поды не могут переопределить MIG, если одна MIG становится недоступна, так как это физическая изоляция.

    Что же происходит, если MIG недоступна:

  • Под не запускается — то есть Kubernetes не может выделить MIG.

  • Pod переходит в состояние Pending, пока не освободится MIG.

  • Восстановление реализуется через livenessProbe, readinessProbe, HorizontalPodAutoscaler.

    Есть несколько доступных механизмов, позволяющих обойти это:

  • Failover. Можно переключиться на другую GPU, например, на GPU 1.

  • Circuit Breaker. Не нужно работать с MIG, если она недоступна. Если inference-сервис не отвечает, стоит переключиться на резервный.

  • Retry с экспоненциальной задержкой через 1s, 2s, 4s, 8s.

    5. Планирование разбиения на MIG.

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

  • Сколько нужно памяти и вычислительных ресурсов?

  • Какие MIG-инстанции доступны и сколько MIG можно создать?

  • Сколько задач могут запускать одновременно?

  • Нужна ли изоляция между задачами? А гарантированная производительность?

  • Какие метрики, логи, трейсы, дашборды важны для MIG?

  • Что важно учесть в CI/CD?

Деплой kubeflow 1.10

  1. Для работы kubeflow необходимы cert-manager и istio, которые есть в репе с Kubeflow.

    А для создания деплоя на джамп-хост необходимо установить kustomize и yq.

  2. Первым делом клонируем проект:

    Скрытый текст
    git clone https://github.com/kubeflow/manifests.git
cd manifests/
git checkout tags/v1.10
git branch

  3. Устанавливаем kubeflow в кластер по инструкции на странице проекта по адресу https://github.com/kubeflow/manifests с помощью kustomize.

  4. Пропускаем установку cert-manager, так как он уже присутствует в кластере «Штурвала».

    Поэтому устанавливаем только cert-manager-kubeflow-Issuer.

    Istio устанавливаем, как указано для oauth-proxy, а oauth-proxy устанавливаем для dex.

  5. Создаем файл ingress с типом сервиса istio-ingressgateway и названием ingress.yaml:

    Пример манифеста ingress.yaml представлен ниже (вместо переменных $clustername и $env подставьте свои значения):

    Скрытый текст
    apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
  name: ingress-kubeflow
  namespace: istio-system
spec:
  ingressClassName: nginx
  rules:
  - host: kubeflow.apps.k8s-$clustername-$env.company.io
    http:
      paths:
      - backend:
          service:
            name: istio-ingressgateway
            port:
              number: 80
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - kubeflow.apps.k8s-$clustername-$env.company.io

  6. Применяем манифест командой kubectl  apply -f ingress.yaml

  7. Kubeflow состоит из множества компонентов и разворачивается довольно долго. В процессе деплоя возможно появление различных ошибок, во всяком случае у нас они постоянно появлялись, которые необходимо будет дебажить по мере их появления.

  8. После деплоя Kubeflow выполняем вход по адресу (вместо переменных подставьте свои значения):

    kubeflow.apps.k8s-$clustername-$env.company.io/ru

    и авторизуемся с профилем по умолчанию —
    user@example.com и паролем 12341234.

  9. Первоначальная установка Kubeflow завершена.

А что дальше?

Изначально в банке использовались две системы, которые не могли корректно работать вместе. Мы задеплоили их в два разных кластера, которые синхронно управляются платформой «Штурвал» — и благодаря этому они больше не конфликтуют.

В результате мы получили управляемую, безопасную и надежную ML-платформу. Теперь бизнес-заказчики могут быстро разворачивать модели для тестирования своих идей, а инженеры — заказывать и получать необходимые ресурсы.

Гибкое управление видеокартами, включая их разбиение, позволило равномерно использовать GPU-ресурсы. Сейчас они используются оптимально и могут быть при необходимости переконфигурированы. Решение успешно работает на отечественном софте в закрытом окружении.

В планах — автоматизировать процесс подготовки новых worker-нод для ML-платформы. Также мы хотим реализовать управление MIG'ами через подход «Инфраструктура как код». А команда «Штурвала» добавит больше «автоматики» в ближайших релизах 2.13 и 2.14.

Что вы думаете об этом опыте? Какие сложности вы видите при построении ML-платформ на Kubernetes? Какие вопросы остались без ответа в статье? Делитесь своим мнением или задавайте мне вопросы в комментариях.