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

故障处理

1: 华为CSI服务相关问题

1.1: 启动huawei-csi-node失败，提示错误为：“/var/lib/iscsi is not a directory”
1.2: 启动华为CSI服务失败，提示错误：“/etc/localtime is not a file”
1.3: 启动huawei-csi服务时，服务启动异常，状态显示InvalidImageName

2: 存储后端相关问题

2.1: 使用oceanctl工具管理后端时调用webhook失败
2.2: 使用oceanctl工具创建后端失败，报错：context deadline exceeded
2.3: 存储侧更新密码后账户被锁定

3: PVC相关问题

3.1: 创建PVC时， PVC的状态为Pending
3.2: 删除PVC前，PVC的状态为Pending
3.3: 通用临时卷扩容失败
3.4: PVC扩容的目标容量超过存储池容量导致扩容失败

4: Pod相关问题

4.1: 集群中worker节点宕机并恢复后，Pod完成failover，但是Pod所在源主机出现盘符残留
4.2: 创建Pod时，Pod的状态为ContainerCreating
4.3: 创建Pod时，Pod的状态长时间处于ContainerCreating状态
4.4: 创建Pod失败，日志显示执行mount命令超时
4.5: 创建Pod失败，日志显示执行mount命令失败
4.6: 创建Pod失败，Events日志显示“publishInfo doesn't exist”
4.7: 创建Pod失败或重启kubelet后，日志显示挂载点已存在
4.8: Pod挂载卷目录提示I/O error
4.9: Kubernetes平台第一次搭建时， iscsi tcp服务没有正常启动，导致创建Pod失败

5: 对接Tanzu Kubernetes集群常见问题及解决方法

5.1: 未创建PSP权限导致Pod无法创建
5.2: 修改主机挂载点
5.3: 修改livenessprobe容器的默认端口
5.4: 创建临时卷失败

1 - 华为CSI服务相关问题

1.1 - 启动huawei-csi-node失败，提示错误为：“/var/lib/iscsi is not a directory”

现象描述

启动huawei-csi-node时，无法启动huawei-csi-node服务，使用kubectl describe daemonset huawei-csi-node -n huawei-csi命令查看，提示错误为：“/var/lib/iscsi is not a directory”。

根因分析

huawei-csi-node中容器内部无/var/lib/iscsi目录。

解决措施或规避方法

使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的任意master节点。
进入Helm工程的目录下，如果无法找到之前的Helm工程，则将组件包中的helm目录拷贝到master节点的任意目录下，组件包路径请参考表软件包组件描述。
进入下一级目录templates,找到huawei-csi-node.yaml文件。
```
cd /templates
```
执行以下命令，将huawei-csi-node.yaml > volumes > iscsi-dir > hostPath中“path“设置为“/var/lib/iscsi“ ，然后保存并退出文件。
```
vi huawei-csi-node.yaml
```

执行以下命令升级Helm chart。升级命令将更新Deployment、DaemonSet和RBAC资源。其中，helm-huawei-csi为自定义的chart名称，huawei-csi为自定义的命名空间。

helm upgrade helm-huawei-csi ./ -n huawei-csi values.yaml

命令结果示例如下。

Release "helm-huawei-csi" has been upgraded. Happy Helming!
NAME: helm-huawei-csi
LAST DEPLOYED: Thu Jun  9 07:58:15 2022
NAMESPACE: huawei-csi
STATUS: deployed
REVISION: 2
TEST SUITE: None

1.2 - 启动华为CSI服务失败，提示错误：“/etc/localtime is not a file”

现象描述

安装部署CSI时，Pod运行不起来，处于ContainerCreating状态，查看Pod中有打印告警事件：/etc/localtime is not a file。

根因分析

容器挂载主机/etc/localtime文件时，识别类型有误，容器挂载不上主机侧/etc/localtime文件，导致Pod运行不起来。

操作步骤

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

执行命令，查看CSI服务Pod运行状态。

kubectl get pod -n huawei-csi

命令结果示例如下。其中，huawei-csi为CSI服务部署的命名空间。

NAME                                     READY   STATUS               RESTARTS   AGE
huawei-csi-controller-6dfcc4b79f-9vjtq   9/9     ContainerCreating    0          24m
huawei-csi-controller-6dfcc4b79f-csphc   9/9     ContainerCreating    0          24m
huawei-csi-node-g6f4k                    3/3     ContainerCreating    0          20m
huawei-csi-node-tqs87                    3/3     ContainerCreating    0          20m

执行命令，通过查看容器的“Events”参数。

kubectl describe pod huawei-csi-controller-6dfcc4b79f-9vjtq -n huawei-csi

命令结果示例如下。其中，huawei-csi-controller-6dfcc4b79f-9vjtq 为2中查找到的状态显示为“ContainerCreating”的Pod名称，huawei-csi为该Pod所在的命名空间。

...
Events:
  Type     Reason       Age                From               Message
  ----     ------       ----               ----               -------
  Normal   Scheduled    96s                default-scheduler  Successfully assigned huawei-csi/huawei-csi-controller-6dfcc4b79f-9vjtq to node1
  Warning  FailedMount  33s (x8 over 96s)  kubelet            MountVolume.SetUp failed for volume "host-time" : hostPath type check failed: /etc/localtime is not a file

执行命令cd /helm/esdk/templates，进入到CSI的安装包路径下。路径请参见表软件包组件描述。
以huawei-csi-controller.yaml文件为例，执行以下命令，查看文件内容。
```
vi huawei-csi-controller.yaml
```
找到对应volumes配置下的host-time挂载项，删除type: File这一行配置内容。对templates目录下涉及该配置项的huawei-csi-node.yaml部署文件，执行相同的操作。
```
...
...
volumes:
  - hostPath:
      path: /var/log/
      type: Directory
    name: log
  - hostPath:
      path: /etc/localtime
      type: File
    name: host-time
...
...
```
参考Helm卸载华为CSI卸载服务后，重新安装服务。

执行以下命令，查看华为CSI服务Pod运行状态为Running。

kubectl get pod -n huawei-csi

命令结果示例如下。

NAME                                     READY   STATUS    RESTARTS   AGE
huawei-csi-controller-6dfcc4b79f-9vjts   9/9     Running   0          24m
huawei-csi-controller-6dfcc4b79f-csphb   9/9     Running   0          24m
huawei-csi-node-g6f41                    3/3     Running   0          20m
huawei-csi-node-tqs85                    3/3     Running   0          20m

1.3 - 启动huawei-csi服务时，服务启动异常，状态显示InvalidImageName

现象描述

启动huawei-csi时，无法启动huawei-csi服务（huawei-csi-controller服务或者huawei-csi-node服务），使用kubectl get pod -A | grep huawei命令查看，显示状态为InvalidImageName

kubectl get pod -A | grep huawei

命令结果示例如下。

huawei-csi     huawei-csi-controller-fd5f97768-qlldc     6/9     InvalidImageName     0          16s
huawei-csi     huawei-csi-node-25txd                     2/3     InvalidImageName     0          15s

根因分析

controller和node的yaml配置文件中，配置Huawei CSI的镜像版本号错误。例如：

        ...
        - name: huawei-csi-driver
          image: huawei-csi:4.5.0
        ...

解决措施或规避方法

使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的任意master节点。
执行以下命令，修改huawei-csi-node服务的配置文件。按I或Insert进入编辑状态，修改相关参数。修改完成后，按Esc，并输入 :wq! ，保存修改。
```
kubectl edit daemonset huawei-csi-node -o yaml -n=huawei-csi
```
- 示例yaml文件中huawei-csi-driver的参数image配置项，修改华为CSI镜像huawei-csi:4.5.0。
```
containers:
  ...
  - name: huawei-csi-driver
    image: huawei-csi:4.5.0
```
执行以下命令，修改huawei-csi-controller服务的配置文件。按I或Insert进入编辑状态，修改相关参数。修改完成后，按Esc，并输入 :wq! ，保存修改。
```
kubectl edit deployment huawei-csi-controller -o yaml -n=huawei-csi
```
- 示例yaml文件中huawei-csi-driver的参数image配置项，修改华为CSI镜像huawei-csi:4.5.0。
```
containers:
  ...
  - name: huawei-csi-driver
    image: huawei-csi:4.5.0
```
等待huawei-csi-node和huawei-csi-controller服务启动。

执行以下命令，查看huawei csi服务是否启动。

kubectl get pod -A  | grep huawei

命令结果示例如下。Pod状态为“Running“说明服务启动成功。

huawei-csi   huawei-csi-controller-58799449cf-zvhmv   9/9     Running       0          2m29s
huawei-csi   huawei-csi-node-7fxh6                    3/3     Running       0          12m

2 - 存储后端相关问题

2.1 - 使用oceanctl工具管理后端时调用webhook失败

现象描述

当webhook的配置发生改变后，例如修改webhookPort参数值后，此时使用oceanctl工具对后端进行管理时调用webhook报错，如下：

根因分析

当webhook的配置发生改变后，导致validatingwebhookconfiguration资源失效。

解决措施或规避方法

执行以下命令，删除validatingwebhookconfiguration资源。

kubectl delete validatingwebhookconfiguration storage-backend-controller.xuanwu.huawei.io

执行以下命令，重启CSI Controller，请通过“–replicas=*”恢复CSI Controller的副本数，下例为恢复至1个，请根据实际情况修改。
```
kubectl scale deployment huawei-csi-controller -n huawei-csi --replicas=0 
kubectl scale deployment huawei-csi-controller -n huawei-csi --replicas=1
```

执行以下命令，检查CSI Controller是否成功拉起。

kubectl get pod -n huawei-csi

命令结果示例如下。Pod状态为“Running“说明Controller成功拉起。

NAME                                     READY   STATUS    RESTARTS   AGE
huawei-csi-controller-58d5b6b978-s2dsq   9/9     Running   0          19s
huawei-csi-node-dt6nd                    3/3     Running   0          77m

2.2 - 使用oceanctl工具创建后端失败，报错：context deadline exceeded

现象描述

用户使用oceanctl工具创建存储后端失败，控制台回显：“failed to call webhook: xxx :context deadline exceeded; error: exist status 1”。

根因分析

创建存储后端时，将会调用CSI提供的webhook服务校验与存储管理网络的连通性和存储账号密码信息，出现该问题原因可能是以下两种原因：

华为CSI校验存储管理网络连通性失败。
kube-apiserver和CSI webhook通信异常。

华为CSI校验存储管理网络连通性失败

请按照以下步骤检查是否是华为CSI校验存储管理网络连通性失败。

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

执行命令，获取CSI服务信息。其中，huawei-csi为CSI服务部署的命名空间。

kubectl get pod -n huawei-csi -owide

命令结果示例如下：

NAME                        READY   STATUS    RESTARTS   AGE   IP         NODE       NOMINATED NODE   READINESS GATES
huawei-csi-controller-xxx   9/9     Running   0          19h   host-ip1   host-1     <none>           <none>
huawei-csi-node-mnqbz       3/3     Running   0          19h   host-ip1   host-1     <none>           <none>

登录huawei-csi-controller所在节点，如2中的host-1。
进入到/var/log/huawei目录。
```
# cd /var/log/huawei
```

查看storage-backend-controller日志，以连接存储超时为例。

tail -n 1000 storage-backend-controller

日志示例如下：

2024-01-01 06:30:44.280661 1 [INFO]: Try to login https://192.168.129.155:8088/deviceManager/rest
2024-01-01 06:31:44.281626 1 [ERROR]: Send request method: POST, Url: https://192.168.129.155:8088/deviceManager/rest/xx/sessions, error: Post "https://192.168.129.155:8088/deviceManager/rest/xx/sessions": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
2024-01-01 06:31:44.281793 1 [WARNING]: Login https://192.168.129.155:8088/deviceManager/rest error due to connection failure, gonna try another Url
2024-01-01 06:31:44.291668 1 [INFO]: Finished validateCreate huawei-csi/backend-test.
2024-01-01 06:31:44.291799 1 [ERROR]: Failed to validate StorageBackendClaim, error: unconnected

如果日志中有相关登录超时、登录失败或者请求耗时较长，请检查宿主机和存储连通性或网络情况。
如果日志中没有收到任何请求，则是kube-apiserver和CSI webhook通信异常。

kube-apiserver和CSI webhook通信异常

联系Kubernetes平台管理员查看kube-apiserver与CSI webhook网络问题。例如kube-apiserver存在HTTPS代理时可能无法访问CSI webhook服务。

临时规避方案中，将会删除webhook资源，该资源用于在创建存储后端时校验输入的账户信息是否正确和能否和存储建立连接，因此删除该资源仅影响创建后端时的校验，无其他功能影响，但需要注意以下几点。
请保证huawei-csi-controller服务所在宿主机能和存储通信。
请保证输入的账号密码正确。

可执行以下命令查看CSI webhook信息。

kubectl get validatingwebhookconfiguration storage-backend-controller.xuanwu.huawei.io

命令结果如下。

NAME                                          WEBHOOKS   AGE
storage-backend-controller.xuanwu.huawei.io   1          4d22h

联系Kubernetes平台管理员检查kube-apiserver与CSI webhook是否存在通信异常。

临时规避方案：可执行以下命令删除webhook。

kubectl delete validatingwebhookconfiguration storage-backend-controller.xuanwu.huawei.io

创建存储后端，可参考管理存储后端。
如果kube-apiserver与CSI webhook通信恢复正常，需要重建webhook，执行以下命令，重启CSI Controller，通过指定“–replicas=*”恢复CSI Controller的副本数，下例为恢复至1个，请根据实际情况修改。
先将副本数修改为0。
```
kubectl scale deployment huawei-csi-controller -n huawei-csi --replicas=0 
```
再将副本数恢复为原数量。
```
kubectl scale deployment huawei-csi-controller -n huawei-csi --replicas=1
```

2.3 - 存储侧更新密码后账户被锁定

现象描述

用户在存储侧修改后端密码之后，该后端账号被锁定。

根因分析

CSI登录存储时使用存储后端配置的账户和密码，当存储侧修改了该账户密码之后，CSI登录失败后会重试。以OceanStor Dorado存储为例，默认的登录策略是密码校验失败3次后将会锁定账户，因此当CSI重试超过3次之后，该账户就会被锁定。

解决措施或规避方法

如果后端配置的账户是admin，请执行以下命令，将huawei-csi-controller服务副本数置为0，如果使用的是非admin账户，忽略此步骤。
```
kubectl scale deployment huawei-csi-controller -n huawei-csi --replicas=0
```
使用admin账户登录存储，修改登录策略。以OceanStor Dorado存储为例，在DeviceManager管理界面，选择“设置 > 用户与安全 > 安全策略 >登录策略 >修改>密码锁定”，取消密码锁定。
如果如果后端配置的账户是admin，执行以下命令，通过“–replicas=*”恢复CSI Controller的副本数，下例为恢复至1个，请根据实际情况修改。如果使用的是非admin账户，忽略此步骤。
```
kubectl scale deployment huawei-csi-controller -n huawei-csi --replicas=1
```
使用oceanctl工具修改存储后端密码，修改后端密码请参考更新存储后端章节。
使用admin账户登录存储，修改登录策略，以OceanStor Dorado存储为例，在DeviceManager管理界面，选择“设置 > 用户与安全 > 安全策略 >登录策略 >修改>密码锁定”，恢复密码锁定。

3 - PVC相关问题

3.1 - 创建PVC时， PVC的状态为Pending

现象描述

执行完成PVC的创建操作，一段时间后，PVC的状态仍然处于Pending。

根因分析

原因1：由于没有提前创建指定名称的StorageClass，导致Kubernetes在创建PVC时无法找到指定StorageClass名称。

原因2：由于存储池能力和StorageClass能力不匹配，导致huawei-csi选择存储池失败。

原因3：由于存储RESTful接口执行返回具体错误码（例如：50331651），导致huawei-csi在执行创建PVC时失败。

原因4：由于存储在huawei-csi设定的超时时间内没有返回，huawei-csi向Kubernetes返回超时错误。

原因5：其他原因。

解决措施或规避方法

创建PVC时，如果PVC处于Pending状态，需要根据以下不同的原因采取不同的解决措施。

使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的任意master节点。
执行以下命令，查看PVC的详细信息。
```
kubectl describe pvc mypvc
```

根据PVC详细信息中Events信息，执行相应操作。

如果由原因1导致PVC处于Pending状态，执行以下步骤。

Events:
  Type     Reason              Age                  From                         Message
  ----     ------              ----                 ----                         -------
  Warning  ProvisioningFailed  0s (x15 over 3m24s)  persistentvolume-controller  storageclass.storage.k8s.io "mysc" not found

删除PVC。
创建StorageClass，可参考动态卷供应典型场景StorageClass配置示例。
创建新的PVC，可参考动态卷供应PVC参数说明。

如果由原因2导致PVC处于Pending状态，执行以下步骤。

Events:
  Type     Reason                Age                From                                                                                       Message
  ----     ------                ----               ----                                                                                       -------
  Normal   Provisioning          63s (x3 over 64s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  External provisioner is provisioning volume for claim "default/mypvc"
  Warning  ProvisioningFailed    63s (x3 over 64s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  failed to provision volume with StorageClass "mysc": rpc error: code = Internal desc = failed to select pool, the capability filter failed, error: failed to select pool, the final filter field: replication, parameters map[allocType:thin replication:True size:1099511627776 volumeType:lun]. please check your storage class

删除PVC。
删除StorageClass。
根据Events信息修改StorageClass.yaml文件。
创建StorageClass，详细请参考动态卷供应典型场景StorageClass配置示例。
创建新的PVC，详情请参考动态卷供应PVC参数说明。

如果由原因3导致PVC处于Pending状态，请联系华为工程师处理。

Events:
  Type     Reason                Age                From                                                                                       Message
  ----     ------                ----               ----                                                                                       -------
  Normal   Provisioning          63s (x4 over 68s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  External provisioner is provisioning volume for claim "default/mypvc"
  Warning  ProvisioningFailed    62s (x4 over 68s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  failed to provision volume with StorageClass "mysc": rpc error: code = Internal desc = Create volume map[ALLOCTYPE:1 CAPACITY:20 DESCRIPTION:Created from Kubernetes CSI NAME:pvc-63ebfda5-4cf0-458e-83bd-ecc PARENTID:0] error: 50331651

如果由原因4导致PVC处于Pending状态，执行以下步骤。

Events:
  Type     Reason                Age                From                                                                                       Message
  ----     ------                ----               ----                                                                                       -------
  Normal   Provisioning          63s (x3 over 52s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  External provisioner is provisioning volume for claim "default/mypvc"
  Warning  ProvisioningFailed    63s (x3 over 52s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  failed to provision volume with StorageClass "mysc": rpc error: code = Internal desc = context deadline exceeded (Client.Timeout exceeded while awaiting headers)

请先等待10分钟，参考本章节再次检查PVC详细信息
如果还处于Pending状态，请联系华为工程师处理。

如果由原因5导致PVC处于Pending状态，请联系华为工程师处理。

3.2 - 删除PVC前，PVC的状态为Pending

现象描述

在执行删除PVC前，PVC的状态处于Pending。

根因分析

原因1：由于没有提前创建指定名称的StorageClass，导致Kubernetes在创建PVC时无法找到指定StorageClass名称。

原因2：由于存储池能力和StorageClass能力不匹配，导致huawei-csi选择存储池失败。

原因3：由于存储RESTful接口执行返回具体错误码（例如：50331651），导致huawei-csi在执行创建PVC时失败。

原因4：由于存储在huawei-csi设定的超时时间内没有返回，huawei-csi向Kubernetes返回超时错误。

原因5：其他原因。

解决措施或规避方法

删除Pending状态下的PVC，需要根据以下不同的原因采取不同的解决措施。

使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的任意master节点。
执行以下命令，查看PVC的详细信息。
```
kubectl describe pvc mypvc
```

根据PVC详细信息中Events信息，执行相应操作。

如果由原因1导致PVC处于Pending状态，可以执行 kubectl delete pvc mypvc 命令，删除PVC。

Events:
  Type     Reason              Age                  From                         Message
  ----     ------              ----                 ----                         -------
  Warning  ProvisioningFailed  0s (x15 over 3m24s)  persistentvolume-controller  storageclass.storage.k8s.io "mysc" not found

如果由原因2导致PVC处于Pending状态，可以执行 kubectl delete pvc mypvc 命令，删除PVC。

Events:
  Type     Reason                Age                From                                                                                       Message
  ----     ------                ----               ----                                                                                       -------
  Normal   Provisioning          63s (x3 over 64s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  External provisioner is provisioning volume for claim "default/mypvc"
  Warning  ProvisioningFailed    63s (x3 over 64s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  failed to provision volume with StorageClass "mysc": rpc error: code = Internal desc = failed to select pool, the capability filter failed, error: failed to select pool, the final filter field: replication, parameters map[allocType:thin replication:True size:1099511627776 volumeType:lun]. please check your storage class

如果由原因3导致PVC处于Pending状态，可以执行 kubectl delete pvc mypvc 命令，删除PVC。

Events:
  Type     Reason                Age                From                                                                                       Message
  ----     ------                ----               ----                                                                                       -------
  Normal   Provisioning          63s (x4 over 68s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  External provisioner is provisioning volume for claim "default/mypvc"
  Warning  ProvisioningFailed    62s (x4 over 68s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  failed to provision volume with StorageClass "mysc": rpc error: code = Internal desc = Create volume map[ALLOCTYPE:1 CAPACITY:20 DESCRIPTION:Created from Kubernetes CSI NAME:pvc-63ebfda5-4cf0-458e-83bd-ecc PARENTID:0] error: 50331651

如果由原因4导致PVC处于Pending状态，请联系华为工程师处理。

Events:
  Type     Reason                Age                From                                                                                       Message
  ----     ------                ----               ----                                                                                       -------
  Normal   Provisioning          63s (x3 over 52s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  External provisioner is provisioning volume for claim "default/mypvc"
  Warning  ProvisioningFailed    63s (x3 over 52s)  csi.huawei.com_huawei-csi-controller-b59577886-qqzm8_58533e4a-884c-4c7f-92c3-6e8a7b327515  failed to provision volume with StorageClass "mysc": rpc error: code = Internal desc = context deadline exceeded (Client.Timeout exceeded while awaiting headers)

如果由原因5导致PVC处于Pending状态，请联系华为工程师处理。

3.3 - 通用临时卷扩容失败

现象描述

在Kubernetes版本低于1.25环境中，对LUN类型的通用临时卷扩容失败，显示PV已经扩容，但PVC未成功更新容量。

根因分析

该问题是由Kubernetes的bug导致，Kubernetes在1.25版本中修复了该问题。

3.4 - PVC扩容的目标容量超过存储池容量导致扩容失败

现象描述

在低于1.23版本的Kubernetes环境中，对PVC进行扩容，当目标容量超过存储池容量时，扩容失败。

根因分析

Kubernetes社区已知问题，详情请参考处理扩充卷过程中的失败。

解决措施或规避方法

参考处理扩充卷过程中的失败。

4 - Pod相关问题

4.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. 执行命令，判断是否存在多路径状态异常的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），执行清理步骤。

清理主机的残留盘符。

根据步骤1获取的DM多路径设备，执行命令，清理残留的多路径聚合设备信息。
```
multipath -f /dev/dm-12
```
如果执行报错，请联系技术支持。
清理残留的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
```
如果执行报错，请联系技术支持。

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

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

查看多路径信息。

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

查看设备信息。

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

查看磁盘信息

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

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

现象描述

执行完成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中查询的节点。
移除盘符残留，详情请参考解决措施或规避方法。

4.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.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命令超时。

解决措施或规避方法

执行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
```

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

现象描述

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协议进行挂载，参考动态卷供应典型场景StorageClass配置示例。

4.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”接口。

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

操作步骤

使用远程访问工具（以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，配置项详情描述参考表 csiDriver配置项说明。
```
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中查询到的资源名称。

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

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

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

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

现象描述

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

根因分析

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

解决措施

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

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

5 - 对接Tanzu Kubernetes集群常见问题及解决方法

本章节用于说明对接Tanzu Kubernetes集群时常见问题及解决办法，目前对接Tanzu Kubernetes集群时主要有以下三个问题：

未创建PSP权限导致Pod无法创建
主机挂载点与原生Kubernetes不同导致挂载卷失败
livenessprobe容器端口与Tanzu vSphere端口冲突导致容器不断重启

5.1 - 未创建PSP权限导致Pod无法创建

现象描述

创建huawei-csi-controller和huawei-csi-node时，仅Deployment和DaemonSet资源创建成功，controller和node的Pod未创建。

根因分析

创建资源使用的service account没有PSP策略的“use”权限。

解决措施或规避方法

使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的任意master节点。
执行vi psp-use.yaml 命令，创建psp-use.yaml文件。
```
vi psp-use.yaml
```

配置psp-use.yaml文件。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: huawei-csi-psp-role
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs: ['use']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: huawei-csi-psp-role-cfg
roleRef:
  kind: ClusterRole
  name: huawei-csi-psp-role
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts:huawei-csi
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts:default

执行以下命令，创建PSP权限。
```
kubectl create -f psp-use.yaml
```

5.2 - 修改主机挂载点

现象描述

创建Pod时失败，华为CSI日志中报错“mount point does not exist”。

根因分析

huawei-csi-node中的“pods-dir”目录原生Kubernetes集群与Tanzu Kubernetes集群不一致。

解决措施或规避方法

进入helm/esdk/目录，执行vi values.yaml命令打开配置文件。
```
vi values.yaml
```

将kubeletConfigDir参数修改为kubelet实际的安装目录。

# Specify kubelet config dir path.
# kubernetes and openshift is usually /var/lib/kubelet
# Tanzu is usually /var/vcap/data/kubelet
kubeletConfigDir: /var/vcap/data/kubelet

5.3 - 修改livenessprobe容器的默认端口

现象描述

huawei-csi-controller组件中livenessprobe容器一直重启。

根因分析

huawei-csi-controller的livenessprobe容器的默认端口（9808）与已有的Tanzu的vSphere CSI端口冲突。

解决措施或规避方法

将livenessprobe容器的默认端口修改为未占用端口。

进入“helm/esdk”目录，执行vi values.yaml命令打开配置文件。
```
vi values.yaml
```
将controller.livenessProbePort默认值9808修改为其他未占用端口，例如改为9809。
```
controller:
  livenessProbePort: 9809
```
使用Helm更新华为CSI，具体信息请参考升级华为CSI。

5.4 - 创建临时卷失败

现象描述

创建通用临时卷失败，报错PodSecurityPolicy: unable to admit pod: [spec.volumes[0]: Invalid value: “ephemeral”: ephemeral volumes are not allowed to be used spec.volumes[0]

根因分析

当前使用的PSP策略中没有使用“ephemeral”卷的权限。

解决措施或规避方法

在默认PSP “pks-privileged"和"pks-restricted"中增加使用“ephemeral”卷的权限，以修改"pks-privileged"举例：

使用远程访问工具（以PuTTY为例），通过管理IP地址，登录Kubernetes集群的任意master节点。
执行命令，修改pks-privileged的配置。
```
kubectl edit psp pks-privileged
```

在spec.volumes中增加“ephemeral”，示例如下：

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  annotations:
    apparmor.security.beta.kubernetes.io/allowedProfileName: '*'
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
  creationTimestamp: "2022-10-11T08:07:00Z"
  name: pks-privileged
  resourceVersion: "1227763"
  uid: 2f39c44a-2ce7-49fd-87ca-2c5dc3bfc0c6
spec:
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - glusterfs
  - hostPath
  - iscsi
  - nfs
  - persistentVolumeClaim
  - ephemeral

执行命令，确认是否添加成功。
```
kubectl get psp pks-privileged -o yaml
```

故障处理

1 - 华为CSI服务相关问题

1.1 - 启动huawei-csi-node失败，提示错误为：“/var/lib/iscsi is not a directory”

现象描述

根因分析

解决措施或规避方法

1.2 - 启动华为CSI服务失败，提示错误：“/etc/localtime is not a file”

现象描述

根因分析

操作步骤

1.3 - 启动huawei-csi服务时，服务启动异常， 状态显示InvalidImageName

现象描述

根因分析

解决措施或规避方法

2 - 存储后端相关问题

2.1 - 使用oceanctl工具管理后端时调用webhook失败

现象描述

根因分析

解决措施或规避方法

2.2 - 使用oceanctl工具创建后端失败，报错：context deadline exceeded

现象描述

根因分析

华为CSI校验存储管理网络连通性失败

kube-apiserver和CSI webhook通信异常

2.3 - 存储侧更新密码后账户被锁定

现象描述

根因分析

解决措施或规避方法

3 - PVC相关问题

3.1 - 创建PVC时， PVC的状态为Pending

现象描述

根因分析

解决措施或规避方法

3.2 - 删除PVC前，PVC的状态为Pending

现象描述

根因分析

解决措施或规避方法

3.3 - 通用临时卷扩容失败

现象描述

根因分析

3.4 - PVC扩容的目标容量超过存储池容量导致扩容失败

现象描述

根因分析

解决措施或规避方法

4 - Pod相关问题

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

现象描述

环境配置

根因分析

解决措施或规避方法

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

现象描述

根因分析

解决措施或规避方法

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

现象描述

根因分析

解决措施或规避方法

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

现象描述

根因分析

解决措施或规避方法

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

现象描述

根因分析

解决措施或规避方法

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

现象描述

根因分析

解决措施

操作步骤

集群工作负载排查

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

现象描述

根因分析

解决措施或规避方法

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

现象描述

根因分析

解决措施

1.3 - 启动huawei-csi服务时，服务启动异常，状态显示InvalidImageName