Настройка CRI для контейнеризации джобов

Виды контейнеризации

YTsaurus поддерживает разные виды контейнеризации джобов в рамках exe-ноды:

simple (используется по умолчанию) — джобы запускаются напрямую в контейнере exe-ноды; данный режим всегда работает и не требует дополнительной настройки, однако он небезопасен, так как джобы могут мешать работе процесса exe-ноды, а также не позволяет использовать в джобах окружение, отличное от окружения контейнера ноды.
cri — схема, в которой для запуска джобов используется система контейнеризации Kubernetes.

Интеграция YTsaurus с CRI

Примечание

Данное описание сделано в предположении использования containerd рантайма.

Текущая интеграция устроена следующим образом. Внутри пода exe-ноды рядом с контейнером ytserver запускается отдельный контейнер jobs. В контейнере jobs запускается демон containerd, который создаёт сокет, через который процесс ноды будет запускать контейнеры джобов. Созданный сокет находится по пути /config/containerd.sock.

Данный сокет предоставляет CRI-интерфейс для создания контейнеров. В нашем случае в качестве системы контейнеризации используется containerd.

Процесс exe-ноды при старте создаёт окружение (в терминах CRI оно называется PodSandbox) для каждого джобового слота. При запуске джоба выбирается слот, после чего в рамках этого окружения создаётся и исполняется контейнер с пользовательским кодом. Эти контейнеры с пользовательским кодом работают внутри контейнера jobs и ограничены его ресурсами.

Настройка CRI

Для включения CRI необходимо сделать следующие изменения в конфигурации exe-нод в спеке кластера:

Включить CRI:

execNodes:
  - ...
    jobEnvironment:
      cri:
        criService: containerd
        apiRetryTimeoutSeconds: 180

Разделить ресурсы между вычислительной нодой и джобами.

Например, если для пода exe-ноды выделено 10 CPU и 50 ГБ памяти, можно указать в конфигурации exe-нод следующие настройки:

execNodes:
  - ...
    resources:
      limits:
        cpu: 2
        memory: 10G
    jobResources:
      limits:
        cpu: 8
        memory: 40G

Указать ImageCache локацию

execNodes:
  - ...
    locations:
      ...
      - locationType: ImageCache
        path: /yt/node-data/image-cache

Важно

Данная локация должна находиться на разделе с файловой системой отличной от overlaysfs (отметим, что по умолчанию рутовый раздел подов в кубернетес-кластере монтируется с помощью overlayfs).

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

Пример конфигурации для оператора.

Проверка работоспособности

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

Проще всего сделать это с помощью вкладки Nodes в UI. При использовании CLI можно выполнить следующие команды, указав в качестве <node-address> адрес конкретной ноды:

$ yt get //sys/exec_nodes/<node-address>/@state
"online"
$ yt get //sys/exec_nodes/<node-address>/@alerts
[]
$ yt get //sys/exec_nodes/<node-address>/@resource_limits
{
    "user_slots" = 32;
    "cpu" = 8.;
    ...
}

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

yt vanilla --proxy <cluster-address> --tasks '{task={command="sleep 1"; job_count=1; docker_image="docker.io/library/ubuntu:24.04"}}'

Диагностика проблем

Если на ноде присутствует алерт, первичная информация о проблеме будет указана непосредственно в нём. Если же нода не переходит в состояние online, следует зайти в контейнер ноды и поискать ошибки в логе exec-node.info.log.

Пример проблемы (сообщение из алерта): failed to create containerd task: failed to create shim task: failed to mount rootfs component: invalid argument: unknown.

Для диагностики рекомендуется выполнить следующие действия:

Убедиться, что выполнены все необходимые шаги для конфигурации CRI.
Убедиться, что контейнер jobs запущен и в нём работает демон containerd.
Убедиться, что сокет /config/containerd.sock создан и доступен в контейнере ytserver.
Изучить логи контейнера jobs; их можно посмотреть с помощью команды kubectl logs --container jobs <pod-name>.

Для приведенного выше примера с алертом проблема состояла в том, что не была указана ImageCache локация, из-за этого containerd использовал локацию по умолчанию, которая находить в рутовой файловой системе пода, поэтому он не мог создать контейнер из-за невозможности смотнировать overlayfs поверх overlayfs.

Тегирование нод кластера

Расширение мастер-сервера