Kubernetes pod 无法挂载 iSCSI 卷：无法获取 iSCSI 磁盘的任何路径答案

【问题标题】：Kubernetes pod cannot mount iSCSI volume: failed to get any path for iscsi diskKubernetes pod 无法挂载 iSCSI 卷：无法获取 iSCSI 磁盘的任何路径
【发布时间】：2019-04-30 11:41:53
【问题描述】：

我想像this example 那样将 iSCSI 卷添加到 pod。我已经在 Debian 服务器上准备了一个 iSCSI 目标，并在我的所有工作节点上安装了 open-iscsi。我还确认我可以使用命令行工具将 iSCSI 目标安装在工作节点上（即仍在 Kubernetes 之外）。这工作正常。为简单起见，目前还没有身份验证 (CHAP)，并且目标上已经存在 ext4 文件系统。

我现在希望 Kubernetes 1.14 将相同的 iSCSI 目标挂载到具有以下清单的 pod 中：

---
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

如何进一步诊断和克服这个问题？

更新在this 相关问题中，解决方案包括为目标使用数字IP 地址。但是，这对我来说没有帮助，因为我已经在使用 targetPortal 形式的 1.2.3.4 （有也尝试了使用和不使用端口号 3260）。

更新停止scsid.service 和/或open-iscsi.service（如建议的here）也没有任何区别。

更新如果waitForPathToExist(&devicePath, multipathDeviceTimeout, iscsiTransport) 失败，则显然会在pkg/volume/iscsi/iscsi_util.go 中触发错误。但是，奇怪的是，当它被触发时，节点上确实存在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

【问题讨论】：

您是否检查了磁盘的权限/等效安全组？
@cookiedough 我该怎么做？我目前可以用iscsiadm ... -login; mount /dev/sdc在命令行挂载目标没有问题，只有Kubernetes不能在同一个节点上挂载。
你好@rookie099，你能分享你的 pv 和 pvc 清单吗？还请向我们提供命令$ kubectl get pv 和$ kubectl describe pv <your_pv> 以及$ kubectl get pvc 和后来的$ kubectl describe pvc <your_pvc> 的输出。 Storageclass 也可能有帮助$ kubectl get sc。
@PjoterS 现在我不使用PersistentVolume/PersistentVolumeClaim（也不是StorageClass），而是直接在给定的pod清单中指定卷。我尝试从最简单的设置开始。
@PjoterS P.S.我刚刚尝试了PersistentVolume/PersistentVolumeClaim 的替代版本，但它以完全相同的方式失败（正如我已经怀疑的那样）。

标签： kubernetes iscsi

【解决方案1】：

这可能是因为您的 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 目标配置，或您遵循的指南。

【讨论】：

我觉得这很难相信，因为我可以毫无问题地将目标挂载到节点的命令行（在 Kubernetes 之外）。但我会按照您的建议将我的 iSCSI 目标配置添加到问题中。由于我没有使用targetcli（据我所知），因此无法尝试您的具体食谱。
是的，您可以通过添加InitiatorName 来挂载节点的命令行，但这也是auth 方法。但是当你尝试使用 pod 挂载时，没有参数可以指定 InitiatorName 到 pod 配置。这就是为什么您需要禁用 auth 方法，或在 TPG 上使用 CHAP 方法。你至少试过了吗？
我的示例必须使用什么确切路径：例如/iscsi/iqn.2019-04.my-domain.com/tpg1 set attribute authentication=0 产生“没有这样的路径”。
如果您的意思是targetcli，当您在/iscsi create 下创建目标时，它会创建默认的iqn 目标名称，您将有一个选项。您可以按照本指南，禁用身份验证方法等。 atodorov.org/blog/2015/04/07/…

【解决方案2】：

这对我有用

iscsi:
     chapAuthSession: false

参考资料：

【讨论】：