Pod相关问题 on Huawei

集群中worker节点宕机并恢复后，Pod完成failover，但是Pod所在源主机出现盘符残留

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

worker节点 A上运行Pod, 并通过CSI挂载外置块设备到该Pod；异常掉电节点worker节点A； Kubernetes平台会在感知到节点故障后，将Pod切换至worker节点B；恢复worker节点A，节点A上的盘符会从正常变为故障。

环境配置

Kubernetes版本：1.18及以上

存储类型：块存储

根因分析

worker节点A恢复后，Kubernetes会向存储发起解除映射操作，但是不会发起主机侧的移除盘符操作。在Kubernetes解除映射后，worker节点A上就会出现盘符残留。

解决措施或规避方法

目前的解决方法只能人工介入，手动清理掉主机的残留盘符（或者再次重启主机，利用主机重启过程中扫盘机制，清理掉残留盘符）。具体方法如下：

排查主机的残留盘符。
1. 执行命令，判断是否存在多路径状态异常的DM多路径设备：
```
multipath -ll
```
  命令结果示例如下。路径状态为failed faulty running表示异常，对应的DM多路径设备为dm-12，关联的SCSI磁盘为sdi和sdj，在配置多条路径时，会有多个SCSI磁盘。记录这些SCSI磁盘。
```
mpathb (3618cf24100f8f457014a764c000001f6) dm-12 HUAWEI ,XSG1 
size=100G features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=-1 status=active
 |- 39:0:0:1 sdi 8:48 failed faulty running
 `- 38:0:0:1 sdj 8:64 failed faulty running
```
  - 是 => 继续执行步骤1.2 。
  - 否 => 不涉及。
2. 执行以下命令，判断残留的DM多路径设备是否可读。
```
dd if=/dev/dm-12 of=/dev/null count=1 bs=1M iflag=direct
```
  命令结果示例如下。如果返回结果为：Input/output error，且读取数据为“0 bytes (0 B) copied”，表示该设备不可读。其中，_dm-xx_为步骤1.1 查到的设备号：

创建Pod时，Pod的状态为ContainerCreating

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

执行完成Pod的创建操作，一段时间后，Pod的状态仍然处于ContainerCreating，查看具体日志信息（详情请参考如何查看华为CSI日志），报错“Fibre Channel volume device not found”。

根因分析

该问题是因为在主机节点有磁盘残留，导致下次创建Pod时，查找磁盘失败。

解决措施或规避方法

使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的任意master节点。

执行以下命令，查看Pod所在节点信息。

kubectl get pod -o wide

命令结果示例如下：

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mypod 0/1 ContainerCreating 0 51s 10.244.1.224 node1 <none> <none>

删除Pod。
使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的_node1_节点。node1 节点为 2 中查询的节点。
移除盘符残留，详情请参考解决措施或规避方法。

创建Pod时，Pod的状态长时间处于ContainerCreating状态

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

创建Pod时，Pod长时间处于ContainerCreating状态，此时查看huawei-csi-node的日志信息（详情请参考如何查看华为CSI日志），huawei-csi-node的日志中无创建Pod的日志记录，执行kubectl get volumeattachment命令后，PV列无该Pod使用的PV名称。在等待较长时间后（超过十分钟），Pod正常创建，Pod状态变为Running状态。

根因分析

该问题是因为Kubernetes的kube-controller-manager组件服务异常导致。

解决措施或规避方法

请联系容器平台侧工程师解决。

创建Pod失败，日志显示执行mount命令超时

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

创建Pod时，Pod一直处于ContainerCreating状态，此时查看huawei-csi-node的日志信息（详情请参考如何查看华为CSI日志），日志显示执行mount命令超时。

根因分析

原因1：该问题可能由于配置的业务IP网络不通，导致mount命令执行超时失败。

原因2：对于部分操作系统，如Kylin V10 SP1和SP2，使用NFSv3从容器内执行mount命令耗时较长，导致mount命令超时并报错“error: exit status 255”，该问题可能由于容器运行时containerd的LimitNOFILE参数值过大（10亿+）。

原因3：可能由于网络问题导致挂载失败，CSI默认挂载超时时间为30秒，超过30秒仍挂载失败，日志会显示执行mount命令超时。

解决措施或规避方法

执行ping命令判断业务IP网络是否连通，如果无法ping通，则为原因1，请配置可用的业务IP地址，如果可以ping通，则执行 2 。
进入任意可以执行mount命令的容器中，指定使用NFSv3执行mount命令。如果命令超时，则可能是原因2，继续执行systemctl status containerd.service命令查看配置文件路径，然后执行cat _/xxx/containerd.service_命令查看配置文件。文件中如果有LimitNOFILE=infinity或LimitNOFILE的值大小为10亿，请执行 3 。否则请联系华为工程师处理。
原因2可参考以下方式处理：
- 尝试使用NFSv4.0及以上协议。
- 参考社区修改方案，将LimitNOFILE参数值修改为合适的值。该方案将会重启容器运行时，请评估对业务的影响。
在挂载失败的宿主机手动挂载该文件系统，如果时间超过30秒，需要用户自行排查该宿主机到存储节点网络是否存在问题。mount命令示例如下：
- 执行以下命令创建测试目录。
```
mkdir /tmp/test_mount
```
- 执行mount命令，挂载文件系统，并观察耗时，其中ip:nfs_share_path可以从huawei-csi-node日志中获取，详情请参考如何查看华为CSI日志
```
time mount ip:nfs_share_path /tmp/test_mount
```
- 测试结束，执行以下命令解挂载文件系统
```
umount /tmp/test_mount
```

创建Pod失败，日志显示执行mount命令失败

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

NAS场景下，创建Pod时，Pod一直处于ContainerCreating状态，此时查看huawei-csi-node的日志信息（详情请参考如何查看华为CSI日志），日志显示执行mount命令失败。

根因分析

该问题可能由于存储侧未开启NFS 4.0/4.1/4.2协议，主机在使用NFS v4协议挂载失败后，未进行协商使用NFS v3协议挂载。

解决措施或规避方法

开启存储侧的NFS 3/4.0/4.1/4.2协议，重新尝试默认挂载。
直接指定可用的NFS协议进行挂载，参考配置存储类。

创建Pod失败，Events日志显示“publishInfo doesn't exist”

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

创建Pod时，Pod一直处于ContainerCreating状态，查看Pod中有打印告警事件：rpc error: code = Internal desc = publishInfo doesn’t exist。

根因分析

按照CSI协议约定，工作负载要使用一个PV卷时，CO（Container Orchestration system，通过RPC请求与CSI插件通信）会调用CSI插件提供的 CSI协议中的“ControllerPublishVolume”接口（huawei-csi-controller服务提供）完成PV卷的映射，然后调用CSI插件提供的“NodeStageVolume”接口（huawei-csi-node服务提供）完成PV卷的挂载。导致出现“publishInfo doesn’t exist”错误的原因是在一次完整的挂载时，仅huawei-csi-node服务收到了“NodeStageVolume”请求，而在此之前huawei-csi-controller服务未收到“ControllerPublishVolume”请求，导致huawei-csi-controller服务未完成PV卷的映射，没有把映射信息传递给huawei-csi-node服务。

解决措施

解决该问题，需要触发Kubernetes调用“ControllerPublishVolume”接口。

如果集群中所有旧版本创建的工作负载均触发了该操作，则后续将不会出现该问题。

操作步骤

使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的任意master节点。

执行以下命令，获取工作负载所在节点信息。

kubectl get pod error-pod -n error-pod-in-namespace -owide

命令结果示例如下：

NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-nfs 0/1 ContainerCreating 0 3s <none> node-1 <none> <none>

将该工作负载漂移至其他节点。
若在集群内无法完成漂移，可在原节点完成工作负载重建，即进行删除-新建操作。
观察该工作负载是否成功拉起，如果拉起失败请联系华为工程师。

集群工作负载排查

Kubernetes调用CSI插件完成卷映射时，将使用VolumeAttachment资源保存映射信息，用于表示将指定的卷从指定的节点上附加或分离。由于该问题是由于publishInfo不存在导致，因此可通过查看VolumeAttachment资源信息排查集群中其他工作负载是否存在该问题。具体步骤如下：

使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的任意master节点。
执行以下命令，获取VolumeAttachment信息，并保留ATTACHER字段为csi.huawei.com的资源，其中csi.huawei.com为华为CSI驱动名称，可在values.yaml文件中配置，配置项为csiDriver.driverName，配置项详情描述参考表4 。
```
kubectl get volumeattachments.storage.k8s.io 
```
命令结果示例如下：
```
NAME ATTACHER PV NODE ATTACHED AGE
csi-47abxx csi.huawei.com pvc-1xx node-1 true 12h
```
执行以下命令查看VolumeAttachment资源详情，其中csi-47abxx为 2 中查询到的资源名称。

创建Pod失败或重启kubelet后，日志显示挂载点已存在

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

创建Pod时，Pod一直处于ContainerCreating状态，或者重启kubelet后，日志中显示挂载点已存在。此时查看huawei-csi-node的日志信息（详情请参考如何查看华为CSI日志），日志提示错误为：The mount /var/lib/kubelet/pods/xxx/mount is already exist, but the source path is not /var/lib/kubelet/plugins/kubernetes.io/xxx/globalmount

根因分析

该问题的根因是Kubernetes进行重复挂载操作。

解决措施或规避方法

执行以下命令，将已存在的路径解除挂载，其中“/var/lib/kubelet/pods/xxx/mount”为日志中提示的已存在的挂载路径。

umount /var/lib/kubelet/pods/xxx/mount

Pod挂载卷目录提示I/O error

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

Pod对所挂载卷进行读写时，提示I/O error。

根因分析

使用SCSI等协议时，如果Pod持续往挂载目录写入数据时，存储发生重启，导致主机上设备到存储的链路中断，触发I/O error。存储恢复时，挂载目录仍然为只读。

解决措施

重新挂载该卷，即通过重建Pod可以触发重新挂载。

Kubernetes平台第一次搭建时， iscsi_tcp服务没有正常启动，导致创建Pod失败

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

创建Pod时报错，在/var/log/huawei-csi-node日志中报错“ Cannot connect ISCSI portal *.*.*.*: libkmod: kmod_module_insert_module: could not find module by name=‘iscsi_tcp’。

根因分析

搭建Kubernete和安装iSCSI服务后， iscsi_tcp服务可能会被停掉，可通过执行以下命令查看服务是否被停掉。

lsmod | grep iscsi | grep iscsi_tcp

命令结果示例如下：

iscsi_tcp 18333 6 
libiscsi_tcp 25146 1 iscsi_tcp
libiscsi 57233 2 libiscsi_tcp,iscsi_tcp
scsi_transport_iscsi 99909 3 iscsi_tcp,libiscsi

解决措施或规避方法

执行以下命令，手动加载iscsi_tcp服务。

modprobe iscsi_tcp
lsmod | grep iscsi | grep iscsi_tcp

创建Pod失败，日志显示启动器已关联至其他主机

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

使用SAN存储创建Pod时，Pod一直处于ContainerCreating状态，查看Pod中有打印告警事件：rpc error: code = Internal desc = initiator xxx is already associated to another host。

根因分析

原因1：CSI会根据一定规则自动创建主机、主机组、启动器，若相同资源在使用CSI前已经在存储侧存在，则会出现冲突。该报错原因可能为使用CSI前已添加过相同的启动器。

原因2：容器集群中，不同工作节点的启动器名称重复，请根据下列步骤进行排查：

登录到容器集群的不同工作节点，执行命令查看启动器名称，确认是否存在不同工作节点使用相同启动器名称。
- 查看iSCSI启动器名称，执行下列命令：
```
cat /etc/iscsi/initiatorname.iscsi
```
- 查看FC启动器名称，执行下列命令：
```
cat /sys/class/fc_host/host*/port_name
```
- 查看RoCE启动器名称，执行下列命令：
```
cat /etc/nvme/hostnqn
```
若存在不同工作节点使用相同启动器名称，请按解决措施或规避方法解决。

解决措施或规避方法

确认启动器关联的主机是否存在使用中的卷，若有使用中的卷，需先将使用中的Pod漂移至其他节点。
确认主机中不存在使用中的卷后，修改启动器名称，确保启动器的唯一性。
执行下列命令，重启iscsid服务。
```
systemctl restart iscsid
```
重启iscsid服务可能导致I/O中断，请确保启动器关联的主机中没有正在使用中的卷，再进行重启操作。
重启huawei-csi-node服务。

创建Pod失败，日志显示“Get DMDevice by alias: dm-x failed”

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

创建Pod时，Pod长时间处于ContainerCreating状态，此时查看huawei-csi-node的日志信息（详情请参考如何查看华为CSI日志），报错：

check device: dm-1 is a partition device failed. error: Get DMDevice by alias:dm-1 failed. error: Can not get DMDevice by alias: dm-1

根因分析

DM-Multipath的配置文件中未配置user_friendly_names参数为yes。

解决措施或规避方法

确认Pod运行所在工作节点是否存在使用中的卷，若有使用中的卷，需先将使用中的Pod漂移至其他节点。
按照检查主机多路径配置章节，配置 /etc/multipath.con 文件。
执行下列命令，重启多路径软件。
```
systemctl reload multipathd.service
systemctl restart multipathd
```
重启多路径软件可能导致I/O中断，请确保Pod运行所在工作节点中没有正在使用中的卷，再进行重启操作。

使用nvme协议，批量删除同一节点上Pod后，节点上nvme链路残留

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

nvme协议场景，批量删除同一节点的Pod，Pod成功删除，但节点上nvme链路没有被清理干净

# nvme list-subsys
nvme-subsys0 - NQN=nqn.xxx.nvme:nvm-subsystem-sn-xxxxxxx
\
 +- nvme0 tcp traddr=xxx.xxx.xxx.xxx,trsvcid=4420,src_addr=xxx.xxx.xxx.xxx live 
 +- nvme1 tcp traddr=xxx.xxx.xxx.xxx,trsvcid=4420,src_addr=xxx.xxx.xxx.xxx live

根因分析

使用nvme协议，只有主机与存储资源解映射完成后，主机上的设备路径才会被清理。在多个Pod挂载同一个卷，且执行批量删除的场景下，CSI在解挂载阶段(NodeUnstageVolume)无法感知到后续解映射阶段(ControllerUnpublishVolume)的设备路径清理情况，导致无法及时清理nvme链路。

解决措施或规避方法

nvme链路残留不影响CSI功能使用，但是会导致后续挂载的存储资源按照当前残留的链路扫描出对应的设备路径，若无链路数量减少的要求，则可不处理残留链路。
若需要减少后续挂载时的链路数量，可以手动删除节点上的残留链路。以清理上述现象描述中的链路为例，需要执行以下命令：
```
nvme disconnect -d nvme0
nvme disconnect -d nvme1
```

SAN双活场景，已挂载的卷对应聚合盘的子路径丢失

Mon, 01 Jan 0001 00:00:00 +0000

现象描述

已挂载的资源对应聚合盘的子路径丢失。

根因分析

图 1 SAN双活子路径丢失故障示意图

如图1 所示，当HBA卡/网卡异常，交换机/网络抖动，存储阵列业务端口故障等因素导致主机与存储一端链路断开后，主机发生重启并触发重新扫盘，此时主机上缺失已故障一端存储的链路。待故障恢复后，由于主机重新扫盘后，链路信息已丢失，缺失的链路不会自动恢复。

想要恢复缺失的链路，通常可以通过漂移Pod到其他主机方式，交由CSI自动重新挂载，并补齐缺失的链路。若需手动在当前主机上恢复缺失链路，请参考以下方法。

解决措施或规避方法（iSCSI协议）

执行以下命令，查询主机上对应业务IP的iSCSI节点是否存在，其中"192.168.1.100"为业务IP。若节点存在则跳转到 3 ，不存在则到 2 。
```
iscsiadm -m node | grep 192.168.1.100
```

执行以下命令，发现iSCSI节点。

iscsiadm -m discovery -t st -p 192.168.1.100

执行以下命令，登录iSCSI节点。
```
iscsiadm -m node -p 192.168.1.100 -l
```
执行以下命令，并根据对应的业务IP，查找其下iSCSI host编号。
```
iscsiadm -m session -P3
```
登录存储DM界面，通过服务->主机组->主机->映射，找到lun对应的主机LUN ID
执行以下扫盘命令，补齐缺失的链路，其中"host_lun_id"为 5 中找到的主机LUN ID，“host_no"为 4 中获取的host编号
```
echo "- - <host_lun_id>" > /sys/class/scsi_host/host<host_no>/scan
```
执行以下命令，查看链路是否已经补齐
```
multipath -ll
```

解决措施或规避方法（FC协议）

执行以下命令，查找所有当前主机上的FC启动器

cat /sys/class/fc_host/host*/port_name | awk 'BEGIN{FS="0x";ORS=" "}{print $2}'

执行以下命令，查找路径缺失启动器下对应的host编号，其中"port_name"为 1 中获取的启动器名称