---
metadata:
  - name: generator
    content: Diplodoc Platform v5.50.6
alternate:
  - https://ytsaurus.tech/docs/en/admin-guide/node-cri.md
  - https://ytsaurus.tech/docs/ru/admin-guide/node-cri.md
---
> **Documentation Index:** Fetch the complete configuration index at https://ytsaurus.tech/docs/ru/llms.txt

<!-- source: ru/_includes/admin-guide/node-cri.md -->
# Настройка CRI для контейнеризации джобов

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

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

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

{% note info "Примечание" %}

Данное описание сделано в предположении использования [containerd](https://containerd.io/) рантайма.
<!---
TODO: сделать более универсальное описание с учётом cri-o
---> 

{% endnote %}

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

Данный сокет предоставляет [CRI-интерфейс](https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/cri-api) для создания контейнеров. В нашем случае в качестве системы контейнеризации используется `containerd`.

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

<!---
Написать про скачивание слоёв в containerd
--->

## Настройка CRI

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

1. Включить CRI:
```
execNodes:
  - ...
    jobEnvironment:
      cri:
        criService: containerd
        apiRetryTimeoutSeconds: 180
```

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

Например, если для пода exe-ноды выделено 10 CPU и 50 ГБ памяти, можно указать в конфигурации exe-нод следующие настройки:
```
execNodes:
  - ...
    resources:
      limits:
        cpu: 2
        memory: 10G
    jobResources:
      limits:
        cpu: 8
        memory: 40G
```

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

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

{% note warning "Важно" %}

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

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

{% endnote %}


[Пример конфигурации](https://github.com/ytsaurus/ytsaurus-k8s-operator/blob/main/config/samples/cluster_v1_cri.yaml) для оператора.

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

Следует убедиться, что поды 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`.

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

Для приведенного выше примера с алертом проблема состояла в том, что не была указана `ImageCache` локация, из-за этого `containerd` использовал локацию по умолчанию, которая находить в рутовой файловой системе пода, поэтому он не мог создать контейнер из-за невозможности смотнировать overlayfs поверх overlayfs.
<!-- endsource: ru/_includes/admin-guide/node-cri.md -->