Как получить доступ к дисковому устройству в поде?

В моих модулях Kubernetes с подключенными томами у меня, похоже, нет доступа к базовому дисковому устройству в папке /dev. Мне это нужно для работы инструментов XFS. Я запускаю кластер в DigitalOcean.

Примерный том смонтирован на /var/www. Вывод df из работающего модуля:

$ df -h 
Filesystem                                                                Size  Used Avail Use% Mounted on
overlay                                                                   158G  9.7G  142G   7% /
tmpfs                                                                      64M     0   64M   0% /dev
tmpfs                                                                     3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/disk/by-id/scsi-0DO_Volume_pvc-650ccba6-3177-45b5-9ffb-0ac2a931fddc  1.0M  1.0M     0 100% /var/www
/dev/vda1                                                                 158G  9.7G  142G   7% /etc/hosts
shm                                                                        64M     0   64M   0% /dev/shm
tmpfs                                                                     3.9G   12K  3.9G   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                                                                     3.9G     0  3.9G   0% /proc/acpi
tmpfs                                                                     3.9G     0  3.9G   0% /sys/firmware

Однако вывод lsblk не показывает ни одного такого устройства /dev/disk/by-id/scsi-0DO_Volume_pvc-650ccba6-3177-45b5-9ffb-0ac2a931fddc; вместо этого отображается устройство /dev/sdb.

$ lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0    1G  0 disk 
sdb      8:16   0    1G  0 disk /var/www
sdc      8:32   0    1G  0 disk 
sde      8:64   0    1G  0 disk 
vda    254:0    0  160G  0 disk 
|-vda1 254:1    0  160G  0 part /etc/apache2/sites-available
`-vda2 254:2    0    2M  0 part 
vdb    254:16   0  472K  1 disk

Ни одно из устройств не доступно в моем модуле:

$ ls -la /dev
total 4
drwxr-xr-x 5 root root  360 Oct 27 10:59 .
drwxr-xr-x 1 root root 4096 Oct 27 10:59 ..
lrwxrwxrwx 1 root root   11 Oct 27 10:59 core -> /proc/kcore
lrwxrwxrwx 1 root root   13 Oct 27 10:59 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Oct 27 10:59 full
drwxrwxrwt 2 root root   40 Oct 27 10:58 mqueue
crw-rw-rw- 1 root root 1, 3 Oct 27 10:59 null
lrwxrwxrwx 1 root root    8 Oct 27 10:59 ptmx -> pts/ptmx
drwxr-xr-x 2 root root    0 Oct 27 10:59 pts
crw-rw-rw- 1 root root 1, 8 Oct 27 10:59 random
drwxrwxrwt 2 root root   40 Oct 27 10:58 shm
lrwxrwxrwx 1 root root   15 Oct 27 10:59 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root   15 Oct 27 10:59 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root   15 Oct 27 10:59 stdout -> /proc/self/fd/1
-rw-rw-rw- 1 root root    0 Oct 27 10:59 termination-log
crw-rw-rw- 1 root root 5, 0 Oct 27 10:59 tty
crw-rw-rw- 1 root root 1, 9 Oct 27 10:59 urandom
crw-rw-rw- 1 root root 1, 5 Oct 27 10:59 zero

Я также пытался изменить runAsUser, runAsGroup и добавить возможности Linux, такие как SYS_ADMIN и SYS_RESOURCE - не помогло.

Когда я настроил контейнер для работы как privileged, у меня был доступ к /dev/sdb, а затем я мог создать символическую ссылку на /dev/disk/by-id/scsi-0DO_Volume_pvc-650ccba6-3177-45b5-9ffb-0ac2a931fddc, чтобы инструменты XFS могли работать.

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

SOURCE_LINK=$(df -h | grep -- "/var/www" | cut -d" " -f1)
TARGET_DEVICE=$(lsblk | grep -- "/var/www" | cut -d" " -f1)
mkdir -p $(dirname $SOURCE_LINK)
ln -s "/dev/$TARGET_DEVICE" "$SOURCE_LINK"

Итак, мой вопрос: есть ли какая-то конфигурация/настройки/подход, который бы выявлял /dev/disk/by-id/scsi-0DO_Volume_pvc-650ccba6-3177-45b5-9ffb-0ac2a931fddc в поде, в идеале в непривилегированном режиме?

(Это связано с другим моим вопросом о том, как включить квоты XFS.)


kubernetes digital-ocean xfs
person Aleš Krajník    schedule 27.10.2020    source источник
comment
Обычно вы запускаете вещи в контейнерах специально, чтобы они не могли напрямую получить доступ к аппаратному обеспечению хост-системы (и, особенно, к устройствам с необработанным диском, которые позволили бы вам обойти все системные элементы управления). Эту задачу, вероятно, лучше выполнять непосредственно на узлах Kubernetes вне контейнеров.   -  person David Maze    schedule 27.10.2020
comment
Спасибо @DavidMaze! Однако у меня нет доступа к узлу, и мне также нужно запустить его как часть службы, которая динамически изменяет квоты. Сказав это, Kubernetes может быть не лучшей платформой для них.   -  person Aleš Krajník    schedule 03.11.2020

Ответы (1)


arrow_upward
0
arrow_downward

На этот вопрос ответил Тимо из DigitalOcean в другом моем вопросе.

Чтобы получить доступ к устройству, вам также необходимо смонтировать каталог хоста /dev в контейнер.

volumes:
  - name: device-dir
    hostPath:
      path: /dev

и для контейнера:

volumeMounts:
  - name: device-dir
    mountPath: /dev

Это устраняет необходимость создавать символическую ссылку вручную, поскольку она уже существует на хосте. Однако устройство не будет доступно для записи. Как объясняется в документации Kubernetes, контейнер должен работать как privileged и root, чтобы иметь возможность писать в такие каталоги или каталоги хоста, необходимо настроить свои разрешения.

person Aleš Krajník    schedule 03.11.2020