Модуль Kubernetes не может подключить том iSCSI: не удалось получить путь для диска iscsi - PullRequest
Новая
       41

Модуль Kubernetes не может подключить том iSCSI: не удалось получить путь для диска iscsi

0 голосов
/ 30 апреля 2019

Я хотел бы добавить том iSCSI в модуль, как в этом этом примере . Я уже подготовил цель iSCSI на сервере Debian и установил open-iscsi на все мои рабочие узлы. Я также подтвердил, что могу смонтировать целевой объект iSCSI на рабочем узле с помощью инструментов командной строки (то есть за пределами Kubernetes). Это отлично работает. Для простоты пока нет аутентификации (CHAP) в игре, и на цели уже есть ext4 файловая система.

Теперь я бы хотел, чтобы Kubernetes 1.14 смонтировал ту же цель iSCSI в модуль со следующим манифестом: 

---
apiVersion: v1
kind: Pod
metadata:
  name: iscsipd
spec:
  containers:
  - name: iscsipd-ro
    image: kubernetes/pause
    volumeMounts:
    - mountPath: "/mnt/iscsipd"
      name: iscsivol
  volumes:
  - name: iscsivol
    iscsi:
      targetPortal: 1.2.3.4 # my target
      iqn: iqn.2019-04.my-domain.com:lun1
      lun: 0
      fsType: ext4
      readOnly: true

Согласно kubectl describe pod это работает на начальном этапе (SuccessfulAttachVolume), но затем не работает (FailedMount). Точное сообщение об ошибке гласит: 

Warning  FailedMount ... Unable to mount volumes for pod "iscsipd_default(...)": timeout expired waiting for volumes to attach or mount for pod "default"/"iscsipd". list of unmounted volumes=[iscsivol]. list of unattached volumes=[iscsivol default-token-7bxnn]
Warning  FailedMount ... MountVolume.WaitForAttach failed for volume "iscsivol" : failed to get any path for iscsi disk, last err seen:
Could not attach disk: Timeout after 10s

Как я могу дополнительно диагностировать и устранить эту проблему?

ОБНОВЛЕНИЕ В эта проблема связана с использованием числового IP-адреса для цели. Однако это не помогает в моем случае, так как я уже использую targetPortal в форме 1.2.3.4 (есть также пробовал как с номером порта 3260, так и без него.

ОБНОВЛЕНИЕ Остановка scsid.service и / или open-iscsi.service (как предложено здесь ) также не имела значения.

ОБНОВЛЕНИЕ Ошибка, по-видимому, возникает в pkg/volume/iscsi/iscsi_util.go, если waitForPathToExist(&devicePath, multipathDeviceTimeout, iscsiTransport) не удается. Однако странным является то, что при запуске файл на devicePath (/dev/disk/by-path/ip-...-iscsi-...-lun-...) действительно существует на узле.

ОБНОВЛЕНИЕ Я использовал эту процедуру для определения простой цели iSCSI для этих целей тестирования: 

pvcreate /dev/sdb
vgcreate iscsi /dev/sdb
lvcreate -L 10G -n iscsi_1 iscsi
apt-get install tgt
cat >/etc/tgt/conf.d/iscsi_1.conf <<EOL
<target iqn.2019-04.my-domain.com:lun1>
  backing-store /dev/mapper/iscsi-iscsi_1
  initiator-address 5.6.7.8 # my cluster node #1
  ... # my cluster node #2, etc.
</target>
EOL
systemctl restart tgt
tgtadm --mode target --op show

1 Ответ

1 голос
/ 06 мая 2019

Вероятно, это связано с проблемой аутентификации вашей цели iscsi.

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

$ sudo targetcli
/> /iscsi/iqn.2003-01.org.xxxx/tpg1 set attribute authentication=0 # will disable auth
/> /iscsi/iqn.2003-01.org.xxxx/tpg1 set attribute generate_node_acls=1 # will force to use tpg1 auth mode by default

Если это не поможет, поделитесь своей целевой конфигурацией iscsi или руководством, которому вы следовали.

...