Kubernetes Pod无法挂载iSCSI卷:无法获得iscsi磁盘的任何路径 [英] Kubernetes pod cannot mount iSCSI volume: failed to get any path for iscsi disk

问题描述

我想在此此示例.我已经在Debian服务器上准备了iSCSI目标，并在所有工作节点上安装了open-iscsi.我还确认可以使用命令行工具将iSCSI目标安装在工作节点上(即仍然在Kubernetes之外).这很好.为简单起见，目前尚没有身份验证(CHAP)，并且目标上已经存在ext4文件系统.

I would like to add an iSCSI volume to a pod as in this this example. I have already prepared an iSCSI target on a Debian server and installed open-iscsi on all my worker nodes. I have also confirmed that I can mount the iSCSI target on a worker node with command line tools (i.e. still outside Kubernetes). This works fine. For simplicity, there is no authentication (CHAP) in play yet, and there is already a ext4 file system present on the target.

我现在希望Kubernetes 1.14将相同的iSCSI目标安装到具有以下清单的Pod中:

I would now like for Kubernetes 1.14 to mount the same iSCSI target into a pod with the following manifest:

---
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).确切的错误消息显示为:

According to kubectl describe pod this works in the initial phase (SuccessfulAttachVolume), but then fails (FailedMount). The exact error message reads:

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

如何进一步诊断和克服此问题?

How can I further diagnose and overcome this problem?

更新在此相关问题中，解决方案包括使用数字IP地址作为目标的过程.但是，这对我的情况没有帮助，因为我已经在使用1.2.3.4形式的targetPortal(具有 也尝试使用端口号3260和不使用端口号3260.

UPDATE In this related issue the solution consisted of using a numeric IP address for the target. However, this does not help in my case, since I am already using a targetPortal of the form 1.2.3.4 (have also tried both with and without port number 3260).

更新(正在停止scsid.service和/或open-iscsi.service(如建议此处)也没有任何区别.

UPDATE Stopping scsid.service and/or open-iscsi.service (as suggested here) did not make a difference either.

更新该错误显然是在 pkg/volume/iscsi/iscsi_util.go ，如果waitForPathToExist(&devicePath, multipathDeviceTimeout, iscsiTransport)失败.但是，奇怪的是，当触发该文件时，devicePath(/dev/disk/by-path/ip-...-iscsi-...-lun-...)上的文件实际上确实存在于节点上.

UPDATE The error apparently gets triggered in pkg/volume/iscsi/iscsi_util.go if waitForPathToExist(&devicePath, multipathDeviceTimeout, iscsiTransport) fails. However, what is strange is that when it is triggered the file at devicePath (/dev/disk/by-path/ip-...-iscsi-...-lun-...) does actually exist on the node.

更新为了以下测试目的，我已使用此过程定义了一个简单的iSCSI目标:

UPDATE I have used this procedure for defining an simple iSCSI target for these test purposes:

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

推荐答案

这可能是由于iscsi目标的身份验证问题.

This is probably because of authentication issue to your iscsi target.

如果尚未使用CHAP身份验证，则仍然必须禁用身份验证. 例如，如果使用targetcli，则可以运行以下命令来禁用它.

If you don't use CHAP authentication yet, you still have to disable authentication. For example, if you use targetcli, you can run below commands to disable it.

$ 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目标配置，或指导您进行后续操作.

If this doesn't help you, please share your iscsi target configuration, or guide that you followed.

这篇关于Kubernetes Pod无法挂载iSCSI卷:无法获得iscsi磁盘的任何路径的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！