这是本节的多页打印视图。 点击此处打印.

返回本页常规视图.

Pod相关问题

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

现象描述

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

环境配置

Kubernetes版本：1.18及以上

存储类型：块存储

根因分析

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

解决措施或规避方法

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

  1. 排查主机的残留盘符。

    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查到的设备号。

      dd: error reading ‘/dev/dm-12’: Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.0236862 s, 0.0 kB/s
      • 是 => 记录残留的dm-xx设备以及关联磁盘号（见步骤1.1），执行清理步骤。
      • 命令卡死 => 继续执行步骤1.3
      • 其他 => 联系技术支持。

    3. 在另一窗口再次登录该节点。

      1. 执行以下命令，查看卡死的进程。

        ps -ef | grep dm-12 | grep -w dd

        命令结果示例如下。

        root     21725  9748  0 10:33 pts/10   00:00:00 dd if=/dev/dm-12 of=/dev/null count=1 bs=10M iflag=direct

      2. 将该pid杀死。

        kill -9 pid

      3. 记录残留的dm-xx设备以及关联磁盘号（见步骤1.1），执行清理步骤。

  2. 清理主机的残留盘符。

    1. 根据步骤1获取的DM多路径设备，执行命令，清理残留的多路径聚合设备信息。

      multipath -f /dev/dm-12

      如果执行报错，请联系技术支持。

    2. 清理残留的SCSI磁盘，根据步骤1获取的残留磁盘的盘符，依次执行命令：

      echo 1 > /sys/block/xxxx/device/delete

      配置多条多路径时，依次根据盘符清除，本次残留路径为sdi/sdj：

      echo 1 > /sys/block/sdi/device/delete
echo 1 > /sys/block/sdj/device/delete

      如果执行报错，请联系技术支持。

    3. 确认DM多路径设备和SCSI磁盘信息是否已经清理干净。

      依次执行下列命令，查询的多路径和磁盘信息显示，残留的dm-12和SCSI磁盘sdi/sdj均已消失，则证明清理完成。

      1. 查看多路径信息。

        multipath -ll

        命令结果示例如下。残留的dm-12已消失。

        mpathb (3618cf24100f8f457014a764c000001f6) dm-3 HUAWEI  ,XSG1            
size=100G features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=-1 status=active
  |- 39:0:0:1        sdd 8:48  active ready running
  `- 38:0:0:1        sde 8:64  active ready running
mpathn (3618cf24100f8f457315a764c000001f6) dm-5 HUAWEI  ,XSG1            
size=100G features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=-1 status=active
  |- 39:0:0:2        sdc 8:32  active ready running
  `- 38:0:0:2        sdb 8:16  active ready running

      2. 查看设备信息。

        ls -l /sys/block/

        命令结果示例如下。SCSI磁盘sdi/sdj均已消失。

        total 0
lrwxrwxrwx 1 root root 0 Aug 11 19:56 dm-0 -> ../devices/virtual/block/dm-0
lrwxrwxrwx 1 root root 0 Aug 11 19:56 dm-1 -> ../devices/virtual/block/dm-1
lrwxrwxrwx 1 root root 0 Aug 11 19:56 dm-2 -> ../devices/virtual/block/dm-2
lrwxrwxrwx 1 root root 0 Aug 11 19:56 dm-3 -> ../devices/virtual/block/dm-3
lrwxrwxrwx 1 root root 0 Aug 11 19:56 sdb -> ../devices/platform/host35/session2/target35:0:0/35:0:0:1/block/sdb
lrwxrwxrwx 1 root root 0 Aug 11 19:56 sdc -> ../devices/platform/host34/target34:65535:5692/34:65535:5692:0/block/sdc
lrwxrwxrwx 1 root root 0 Aug 11 19:56 sdd -> ../devices/platform/host39/session6/target39:0:0/39:0:0:1/block/sdd
lrwxrwxrwx 1 root root 0 Aug 11 19:56 sde -> ../devices/platform/host38/session5/target38:0:0/38:0:0:1/block/sde
lrwxrwxrwx 1 root root 0 Aug 11 19:56 sdh -> ../devices/platform/host39/session6/target39:0:0/39:0:0:3/block/sdh
lrwxrwxrwx 1 root root 0 Aug 11 19:56 sdi -> ../devices/platform/host38/session5/target38:0:0/38:0:0:3/block/sdi

      3. 查看磁盘信息

        ls -l /dev/disk/by-id/

        命令结果示例如下。SCSI磁盘sdi/sdj均已消失。

        total 0
lrwxrwxrwx 1 root root 10 Aug 11 19:57 dm-name-mpathb -> ../../dm-3
lrwxrwxrwx 1 root root 10 Aug 11 19:58 dm-name-mpathn -> ../../dm-5
lrwxrwxrwx 1 root root 10 Aug 11 19:57 dm-uuid-mpath-3618cf24100f8f457014a764c000001f6 -> ../../dm-3
lrwxrwxrwx 1 root root 10 Aug 11 19:58 dm-uuid-mpath-3618cf24100f8f457315a764c000001f6 -> ../../dm-5
lrwxrwxrwx 1 root root  9 Aug 11 19:57 scsi-3618cf24100f8f457014a764c000001f6 -> ../../sdd
lrwxrwxrwx 1 root root  9 Aug 11 19:57 scsi-3618cf24100f8f45712345678000103e8 -> ../../sdi
lrwxrwxrwx 1 root root  9 Aug  3 15:17 scsi-3648435a10058805278654321ffffffff -> ../../sdb
lrwxrwxrwx 1 root root  9 Aug  2 14:49 scsi-368886030000020aff44cc0d060c987f1 -> ../../sdc
lrwxrwxrwx 1 root root  9 Aug 11 19:57 wwn-0x618cf24100f8f457014a764c000001f6 -> ../../sdd
lrwxrwxrwx 1 root root  9 Aug 11 19:57 wwn-0x618cf24100f8f45712345678000103e8 -> ../../sdi
lrwxrwxrwx 1 root root  9 Aug  3 15:17 wwn-0x648435a10058805278654321ffffffff -> ../../sdb
lrwxrwxrwx 1 root root  9 Aug  2 14:49 wwn-0x68886030000020aff44cc0d060c987f1 -> ../../sdc

2 - 创建Pod时，Pod的状态为ContainerCreating

现象描述

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

根因分析

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

解决措施或规避方法

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

  2. 执行以下命令，查看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>

  3. 删除Pod。

  4. 使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的 node1 节点。node1 节点为2中查询的节点。

  5. 移除盘符残留，详情请参考解决措施或规避方法。

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

现象描述

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

根因分析

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

解决措施或规避方法

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

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

现象描述

创建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命令超时。

解决措施或规避方法

  1. 执行ping命令判断业务IP网络是否连通，如果无法ping通，则为原因1，请配置可用的业务IP地址，如果可以ping通，则执行2。

  2. 进入任意可以执行mount命令的容器中，指定使用NFSv3执行mount命令。如果命令超时，则可能是原因2，继续执行systemctl status containerd.service命令查看配置文件路径，然后执行cat _/xxx/containerd.service_命令查看配置文件。文件中如果有LimitNOFILE=infinity或LimitNOFILE的值大小为10亿，请执行3。否则请联系华为工程师处理。

  3. 原因2可参考以下方式处理：

    • 尝试使用NFSv4.0及以上协议。
    • 参考社区修改方案，将LimitNOFILE参数值修改为合适的值。该方案将会重启容器运行时，请评估对业务的影响。

  4. 在挂载失败的宿主机手动挂载该文件系统，如果时间超过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

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

现象描述

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

根因分析

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

解决措施或规避方法

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

现象描述

创建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”接口。

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

操作步骤

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

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

    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>

  3. 将该工作负载漂移至其他节点。

  4. 若在集群内无法完成漂移，可在原节点完成工作负载重建，即进行删除-新建操作。

  5. 观察该工作负载是否成功拉起，如果拉起失败请联系华为工程师。

集群工作负载排查

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

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

  2. 执行以下命令，获取VolumeAttachment信息，并保留ATTACHER字段为csi.huawei.com的资源，其中csi.huawei.com为华为CSI驱动名称，可在values.yaml文件中配置，配置项为csiDriver.driverName，配置项详情描述参考表 csiDriver配置项说明。

    kubectl get volumeattachments.storage.k8s.io

    命令结果示例如下。

    NAME          ATTACHER         PV       NODE     ATTACHED   AGE
csi-47abxx   csi.huawei.com   pvc-1xx   node-1   true       12h

  3. 执行以下命令查看VolumeAttachment资源详情，其中csi-47abxx为2中查询到的资源名称。

    kubectl get volumeattachments.storage.k8s.io csi-47abxx -o yaml

    命令结果示例如下。

    kind: VolumeAttachment
metadata:
  annotations:
    csi.alpha.kubernetes.io/node-id: '{"HostName":"node-1"}'
   finalizers:
  - external-attacher/csi-huawei-com
  name: csi-47abxxx
  uid: 0c87fa8a-c3d6-4623-acb8-71d6206d030d
spec:
  attacher: csi.huawei.com
  nodeName: debian-node
  source:
    persistentVolumeName: pvc-1xx
status:
  attached: true
  attachmentMetadata:
     publishInfo: '{<PUBLISH-INFO>}'

  4. 若3中查询到的资源中存在status.attachmentMetadata.publishInfo，则证明node-1节点上使用pvc-1xx创建的若干工作负载不会存在本FAQ描述的错误，其中node-1和pvc-1xx为2中查询结果。若status.attachmentMetadata.publishInfo不存在，请参考解决措施章节解决。

  5. 存在多个VolumeAttachment资源时，重复执行3~4。

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

现象描述

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

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

现象描述

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

根因分析

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

解决措施

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

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

现象描述

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