存储异常问题排查

1.检查Pod异常是否由存储问题导致

通过Pod或PVC事件，确认Pod无法启动是由存储问题导致。

1. 查看异常Pod的事件。

   kubectl describe pod <pod-name>

   • 若Events中存在相关事件表明是存储问题（例如示例的FailedScheduling的Message中表明是由于Volume与节点不匹配导致调度失败），请参考下文继续排查。

     Events:
       Type     Reason            Age    From               Message
       ----     ------            ----   ----               -------
       Warning  FailedScheduling  4m37s  default-scheduler  0/1 nodes are available: 1 node(s) had volume node affinity conflict. preemption: 0/1 nodes are available: 1 Preemption is not helpful for scheduling.,

   • 若Events中存在相关事件表明Volume已成功挂载（例如示例的SuccessfulAttachVolume），此时Pod未启动（例如CrashLoopBackOff）不属于存储问题，请根据Events排查其他问题，或者提交工单处理。

     Events:
       Type    Reason                  Age   From                     Message
       ----    ------                  ----  ----                     -------
       Normal  Scheduled               97s   default-scheduler        Successfully assigned default/disk-test-0 to cn-shanghai.192.168.5.2
       Normal  SuccessfulAttachVolume  97s   attachdetach-controller  AttachVolume.Attach succeeded for volume "d-uf6b8s2l5ypf48*****"

2. 若Pod事件中未看到存储相关事件，可查看所有事件。

   kubectl get events

   • 若Events中存在相关事件表明是存储问题（例如示例的FailedBinding表明PVC绑定PV失败），请参考下文继续排查。

     LAST SEEN   TYPE      REASON                 OBJECT                                                  MESSAGE
     2m56s       Normal    FailedBinding          persistentvolumeclaim/data-my-release-mariadb-0         no persistent volumes available for this claim and no storage class is set
     41s         Normal    ExternalProvisioning   persistentvolumeclaim/pvc-nas-dynamic-create-subpath8   waiting for a volume to be created, either by external provisioner "nasplugin.csi.alibabacloud.com" or manually created by system administrator
     3m31s       Normal    Provisioning           persistentvolumeclaim/pvc-nas-dynamic-create-subpath8   External provisioner is provisioning volume for claim "default/pvc-nas-dynamic-create-subpath8"

   • 若Events中没有存储相关事件，请根据Events排查其他问题，或者提交工单处理。

2.检查存储组件是否正常

1. 检查CSI存储组件是否正常工作。

   kubectl get pod -n kube-system |grep csi

   返回示例如下。如果Pod状态非Running，可执行kubectl describe pods <pod-name> -n kube-system查看具体Container退出的原因及Pod的Event。

   说明

   CSI存储组件包括csi-plugin和csi-provisioner，其中csi-provisioner默认安装托管版。托管版组件由阿里云负责运维，您在集群中无法看到相关Pod。

   NAME                     READY   STATUS        RESTARTS   AGE
   csi-plugin-bpz28         4/4     Running       0          3d
   csi-plugin-h2tdg         4/4     Running       0          3d
   csi-plugin-qpnm4         4/4     Running       0          3d
   csi-plugin-wczgm         4/4     Running       0          3d

2. 检查CSI存储组件是否为最新版本。

   kubectl get ds csi-plugin -n kube-system -o yaml |grep image

   在返回信息的image中可以确认镜像版本，示例如下：

   image: registry-cn-shanghai-vpc.ack.aliyuncs.com/acs/csi-plugin:v1.33.1-67e8986-aliyun

   若存储组件不是最新版本，请升级csi-plugin和csi-provisioner。存储组件最新版本信息，请参见csi-plugin。

   说明

   您也可以在控制台的组件管理页面，找到csi-plugin和csi-provisioner组件，确认版本信息并升级组件。

3. 检查PV、PVC和StorageClass的YAML，确认驱动配置（driver或provisioner字段）为使用CSI存储组件，与当前集群使用的存储组件一致。

3.检查PVC是否为Bound状态

1. 查看PVC状态。

   kubectl get pvc

2. 如果PVC为非Bound状态，参考以下方式进行排查和处理。

   问题原因

   • 静态：由于PVC和PV之间的Selector无法满足互相绑定的条件导致。例如：PVC中Selector配置与PV中的不一致，StorageClass Name不一致、PV状态是Released等问题。

   • 动态：由于csi-provisioner组件的某种原因导致。

   解决方案

   • 静态：请检查相关的YAML书写是否正确。相关参考如下：

     • 使用云盘静态存储卷

     • 使用NAS静态存储卷

     • 使用ossfs 1.0静态存储卷或使用ossfs 2.0存储卷

     说明

     若PV状态为Released，则该PV无法被复用，需要获取PV中关于存储资源的相关信息，然后重新创建PV。

   • 动态：通过kubectl describe pvc <pvc-name> -n <namespace>查看PVC的Event。

     • 根据Event提示信息进行处理。处理方法参考如下：

       • 云盘存储卷FAQ

       • NAS存储卷FAQ

       • ossfs 1.0存储卷FAQ或ossfs 2.0存储卷FAQ

     • 若没有相关Event信息，请提交工单处理。

   • 如果使用云盘存储卷，可能是ECS OpenAPI创建云盘时出现了问题，请参见ECS错误中心进行排查。如果排查失败，请提交工单处理。

4.检查Pod是否为Running状态

1. 查看Pod状态。

   kubectl get pod

2. 如果PVC为Bound状态，Pod为非Running状态，请根据存储卷类型，参考以下方式进行排查和处理。

   云盘存储卷

   重要

   使用云盘存储卷时，需确保待挂载云盘的Pod所调度到的ECS节点的规格支持挂载该类型云盘，并且Pod和云盘处于同一地域可用区。关于云盘类型和ECS实例规格的匹配关系，请参见实例规格族。

   问题原因

   • 没有满足条件的节点可以调度。

   • 云盘挂载出现问题。

   • ECS节点和云盘类型不匹配。

   解决方案

   • 通过将Pod调度到其他节点快速恢复。具体操作，请参见调度应用至指定节点。

   • 通过kubectl describe pods <pod-name>查看Pod的Event。

     • 根据Event提示信息进行处理。处理方法请参见云盘存储卷FAQ。

     • 若没有相关Event信息，请提交工单处理。

   • 由于ECS节点和云盘类型不匹配导致的，请选择合适类型的云盘。更多信息，请参见实例规格族。

   • 其他ECS OpenAPI类型问题的处理方法，请参见ErrorCode。

   NAS存储卷

   重要

   • 节点与NAS必须在同一个VPC下。若不在同一VPC，请使用云企业网打通。

   • NAS支持跨可用区挂载。

   • 极速型NAS的挂载目录需要以/share开头。

   问题原因

   • 挂载NAS时使用了fsGroups，文件较多，导致chmod速度较慢。

   • 安全组中限制了2049端口，导致NAS无法挂载。

   • NAS和节点不在同一个VPC下。

   解决方案

   • 检查是否设置fsGroups，如有，去掉后重启Pod并重新挂载。

   • 确认Pod调度的节点是否限制了2049端口，如果该端口被限制，将2049端口放开后，重新挂载。具体操作，请参见添加安全组规则。

   • 确认NAS和节点在同一VPC下，若不在同一VPC，请使用云企业网打通。

   • 其他问题，通过kubectl describe pods <pod-name>查看Pod的Event。

     • 根据Event提示信息进行处理。处理方法请参见NAS存储卷FAQ。

     • 若没有相关Event信息，请提交工单处理。

   OSS存储卷

   重要

   • 节点挂载OSS时，PV中需填写AccessKey信息，可通过Secret方式使用 。

   • 跨地域使用OSS时，需将Bucket URL改成公网地址，同一地域建议使用内网地址。

   问题原因

   • 挂载OSS时使用了fsGroups，文件较多，导致chmod速度较慢。

   • 跨地域使用了内网地址，导致无法连接到Bucket Endpoint。

   解决方案

   • 检查是否设置fsGroups，如有，去掉后重启Pod并重新挂载。

   • 检查是否跨地域且使用内网访问Bucket，如是，请改用公网地址。

   • 其他问题，通过kubectl describe pods <pod-name>查看Pod的Event。

     • 根据Event提示信息进行处理。处理方法请参见ossfs 1.0存储卷FAQ或ossfs 2.0存储卷FAQ。

     • 若没有相关Event信息，请提交工单处理。

常见问题

0/x nodes are available: x pod has unbound immediate PersistentVolumeClaims. preemption: 0/x nodes are available: x Preemption is not helpful for scheduling