如何恢复丢失的CSI挂载信息问题？

2026-05-05 22:315阅读0评论SEO资源
  • 内容介绍
  • 文章标签
  • 相关推荐

本文共计1285个文字，预计阅读时间需要6分钟。

如何恢复丢失的CSI挂载信息问题？

解决恢复CSI挂载信息的问题，可以采用以下步骤：

1. 首先，检查并确认已安装华为OBS的CSI插件，其基本工作原理如图所示。

2.CSI插件Pod挂载了主机上的+/var/lib/kubelet/pods目录。

3.当创建挂载PVC的业务Pod时，CSI插件会自动挂载该目录。

一个恢复CSI挂载信息的解决方法 问题描述

之前有做过一个华为OBS 的CSI插件，其基本运作原理如下图所示。CSI插件Pod挂载了主机的/var/lib/kubelet/pods目录，当创建挂载Pvc的业务Pod时，CSI插件会启动一个s3fs进程，该进程用于远程连接s3服务，将bucket(也即Pvc)挂载到/var/lib/kubelet/pods中的对应Pod目录下(一般为/var/lib/kubelet/pods/<pod-uuid>/volumes/<pod-uuid>kubernetes.io~csi/<pvc-name>/mount)，然后由kubelet挂载到业务Pod中。

该插件有个问题，就是当CSI插件重启之后，会丢失调内部负责远程连接s3服务的s3fs进程，因此会导致业务Pod内部挂载目录失效，访问/var/lib/kubelet/pods/<pod-uuid>/volumes/<pod-uuid>kubernetes.io~csi/<pvc-name>/mount目录会出现Transport endpoint is not connected的问题。此时为了让业务Pod能够正常访问，需要重启业务Pod，但这种方式很不优雅。

解决思路

为了解决Transport endpoint is not connected问题，首先需要恢复s3fs进程，但恢复进程依赖几个数据：Pvc的名称、Pod的uid、s3服务的地址以及访问使用的AK/SK等。有两种方式可以保存这类数据：

  1. 在CSI插件正常运行过程中，将元数据保存到s3服务，其实就是将s3服务作为一个元数据库使用。但这种方式可能存在元数据被误删以及元数据和系统不一致的情况
  2. 在CSI插件启动后使用client-go动态获取集群中的相关数据

此次采用了第二种方式，执行思路为：

  1. 获取所有命名空间下的Pvc(allPvcs)
  2. 从allPvcs中找到Pvc的metadata.annotations.volume.beta.kubernetes.io/storage-provisioner 为目标storageclass的Pvc(targetPvcs)
  3. 获取挂载了上述targetPvcs的pod(targetPods)
  4. 找到targetPods的uid(targetUid)
  5. 拼接挂载路径/var/lib/kubelet/pods/<targetUid>/volumes/<targetUid>kubernetes.io~csi/<targetPvc-name>/mount
  6. 找到targetPvcs的spec.storageClassName，进而找出负责该Pvc的storageclass(targetStorageclass)
  7. 在targetStorageclass的parameters找到相关的信息，最主要的是保存访问s3服务的AK/SK的secret(targetSecret)
  8. 从targetSecret中找到AK/SK
  9. 执行挂载

上述步骤的主要目的就是找出挂载路径以及s3服务的访问信息。

实施过程

在完成编码之后，经验证发现/var/lib/kubelet/pods/<targetUid>/volumes/<targetUid>kubernetes.io~csi/<targetPvc-name>/mount挂载成功，进入该目录之后可以看到bucket中的内容，但进入业务容器发现，目录并没有成功挂载。

需要提出的一点是，由于CSI插件是被异常重启的，导致挂载失效，并没有执行标准的Unmounting 流程(即调用NodeUnpublishVolume方法)，因此在重新挂载之前首先需要umount掉原来的挂载点。

如何恢复丢失的CSI挂载信息问题？

业务容器没有挂载成功的原因是整个恢复流程并没有触发kubelet执行umount/mount来将pvc重新挂载到业务容器。解决方式与CSI插件的/var/lib/kubelet/pods/<targetUid>/volumes/<targetUid>kubernetes.io~csi/<targetPvc-name>/mount一样，执行umount在mount即可。但这么做首先要知道Pod映射到主机上的挂载路径，这样就比较麻烦了，因为pod映射到主机上的路径与使用的CRI相关，如果朝这一方向下去，难度比较大，在CSI Volume Plugins in Kubernetes Design Doc中也提过，正常情况下是由kubelet执行的：

  1. The volume manager component of kubelet, notices a mounted CSI volume, referenced by a pod that has been deleted or terminated, so it calls the in-tree CSI volume plugin’s UnmountDevice method which is a no-op and returns immediately.
  2. Next kubelet calls the in-tree CSI volume plugin’s unmount (teardown) method, which causes the in-tree volume plugin to issue a NodeUnpublishVolume call via the registered unix domain socket to the local CSI driver. If this call fails from any reason, kubelet re-tries the call periodically.
  3. Upon successful completion of the NodeUnpublishVolume call the specified path is unmounted from the pod container.

那么怎么才能让容器重新挂载成功呢？

只要重新触发kubelet的挂载动作即可，可以采用livenessProbe来触发该动作，方式如下：

apiVersion: v1 kind: Pod metadata: name: csi-s3-test-nginx namespace: default spec: containers: - name: csi-s3-test-nginx image: nginx livenessProbe: failureThreshold: 3 initialDelaySeconds: 20 periodSeconds: 5 timeoutSeconds: 5 exec: command: - ls - /var/lib/www/html volumeMounts: - mountPath: /var/lib/www/html name: webroot - mountPath: /var/lib/www/html2 name: webroot2 volumes: - name: webroot persistentVolumeClaim: claimName: csi-s3-pvc readOnly: false - name: webroot2 persistentVolumeClaim: claimName: csi-s3-pvc2 readOnly: false

如果使用这种方式的话，还需要执行之前恢复s3fs进程的操作吗？答案是需要的，重启只会触发kubelet的动作，但不会触发CSI重新挂载，因此恢复s3fs进程和livenessProbe都是同时需要的。

标签：解决方法

相关推荐

143373如何通过SEO秘籍解锁网站霸屏，实现流量飞速增长？143377如何优化华为云CDN策略以提升缓存命中率？143380Java动态代理如何实现不同类型的代理模式？143387如何在Chrome浏览器中成功安装MAC版本的Vue插件？143397惠州SEO建站，有没有推荐的专业团队来帮忙？143405如何制作出令人惊叹的炫酷涡旋互动效果神器？143426如何手动在win10系统中配置IP地址？143430如何进行win7系统磁盘碎片整理？143434如何将多张图片整合成一个文档？143442如何判断activex控件当前是启用还是禁用状态？143446文件锁定无法编辑，如何转为只读模式访问？143447ERP系统主要用于企业资源整合与管理，是干嘛用的？143451win10自动更换的壁纸模糊不清，如何解决？143453操作系统在计算机中扮演什么核心角色？143454计算机主频是指什么频率？143465脱机模式下网页无法访问时该如何解决？

本文共计1285个文字，预计阅读时间需要6分钟。

如何恢复丢失的CSI挂载信息问题？

解决恢复CSI挂载信息的问题，可以采用以下步骤：

1. 首先，检查并确认已安装华为OBS的CSI插件，其基本工作原理如图所示。

2.CSI插件Pod挂载了主机上的+/var/lib/kubelet/pods目录。

3.当创建挂载PVC的业务Pod时，CSI插件会自动挂载该目录。

一个恢复CSI挂载信息的解决方法 问题描述

之前有做过一个华为OBS 的CSI插件，其基本运作原理如下图所示。CSI插件Pod挂载了主机的/var/lib/kubelet/pods目录，当创建挂载Pvc的业务Pod时，CSI插件会启动一个s3fs进程，该进程用于远程连接s3服务，将bucket(也即Pvc)挂载到/var/lib/kubelet/pods中的对应Pod目录下(一般为/var/lib/kubelet/pods/<pod-uuid>/volumes/<pod-uuid>kubernetes.io~csi/<pvc-name>/mount)，然后由kubelet挂载到业务Pod中。

该插件有个问题，就是当CSI插件重启之后，会丢失调内部负责远程连接s3服务的s3fs进程，因此会导致业务Pod内部挂载目录失效，访问/var/lib/kubelet/pods/<pod-uuid>/volumes/<pod-uuid>kubernetes.io~csi/<pvc-name>/mount目录会出现Transport endpoint is not connected的问题。此时为了让业务Pod能够正常访问，需要重启业务Pod，但这种方式很不优雅。

解决思路

为了解决Transport endpoint is not connected问题，首先需要恢复s3fs进程，但恢复进程依赖几个数据：Pvc的名称、Pod的uid、s3服务的地址以及访问使用的AK/SK等。有两种方式可以保存这类数据：

  1. 在CSI插件正常运行过程中，将元数据保存到s3服务，其实就是将s3服务作为一个元数据库使用。但这种方式可能存在元数据被误删以及元数据和系统不一致的情况
  2. 在CSI插件启动后使用client-go动态获取集群中的相关数据

此次采用了第二种方式，执行思路为：

  1. 获取所有命名空间下的Pvc(allPvcs)
  2. 从allPvcs中找到Pvc的metadata.annotations.volume.beta.kubernetes.io/storage-provisioner 为目标storageclass的Pvc(targetPvcs)
  3. 获取挂载了上述targetPvcs的pod(targetPods)
  4. 找到targetPods的uid(targetUid)
  5. 拼接挂载路径/var/lib/kubelet/pods/<targetUid>/volumes/<targetUid>kubernetes.io~csi/<targetPvc-name>/mount
  6. 找到targetPvcs的spec.storageClassName，进而找出负责该Pvc的storageclass(targetStorageclass)
  7. 在targetStorageclass的parameters找到相关的信息，最主要的是保存访问s3服务的AK/SK的secret(targetSecret)
  8. 从targetSecret中找到AK/SK
  9. 执行挂载

上述步骤的主要目的就是找出挂载路径以及s3服务的访问信息。

实施过程

在完成编码之后，经验证发现/var/lib/kubelet/pods/<targetUid>/volumes/<targetUid>kubernetes.io~csi/<targetPvc-name>/mount挂载成功，进入该目录之后可以看到bucket中的内容，但进入业务容器发现，目录并没有成功挂载。

需要提出的一点是，由于CSI插件是被异常重启的，导致挂载失效，并没有执行标准的Unmounting 流程(即调用NodeUnpublishVolume方法)，因此在重新挂载之前首先需要umount掉原来的挂载点。

如何恢复丢失的CSI挂载信息问题？

业务容器没有挂载成功的原因是整个恢复流程并没有触发kubelet执行umount/mount来将pvc重新挂载到业务容器。解决方式与CSI插件的/var/lib/kubelet/pods/<targetUid>/volumes/<targetUid>kubernetes.io~csi/<targetPvc-name>/mount一样，执行umount在mount即可。但这么做首先要知道Pod映射到主机上的挂载路径，这样就比较麻烦了，因为pod映射到主机上的路径与使用的CRI相关，如果朝这一方向下去，难度比较大，在CSI Volume Plugins in Kubernetes Design Doc中也提过，正常情况下是由kubelet执行的：

  1. The volume manager component of kubelet, notices a mounted CSI volume, referenced by a pod that has been deleted or terminated, so it calls the in-tree CSI volume plugin’s UnmountDevice method which is a no-op and returns immediately.
  2. Next kubelet calls the in-tree CSI volume plugin’s unmount (teardown) method, which causes the in-tree volume plugin to issue a NodeUnpublishVolume call via the registered unix domain socket to the local CSI driver. If this call fails from any reason, kubelet re-tries the call periodically.
  3. Upon successful completion of the NodeUnpublishVolume call the specified path is unmounted from the pod container.

那么怎么才能让容器重新挂载成功呢？

只要重新触发kubelet的挂载动作即可，可以采用livenessProbe来触发该动作，方式如下：

apiVersion: v1 kind: Pod metadata: name: csi-s3-test-nginx namespace: default spec: containers: - name: csi-s3-test-nginx image: nginx livenessProbe: failureThreshold: 3 initialDelaySeconds: 20 periodSeconds: 5 timeoutSeconds: 5 exec: command: - ls - /var/lib/www/html volumeMounts: - mountPath: /var/lib/www/html name: webroot - mountPath: /var/lib/www/html2 name: webroot2 volumes: - name: webroot persistentVolumeClaim: claimName: csi-s3-pvc readOnly: false - name: webroot2 persistentVolumeClaim: claimName: csi-s3-pvc2 readOnly: false

如果使用这种方式的话，还需要执行之前恢复s3fs进程的操作吗？答案是需要的，重启只会触发kubelet的动作，但不会触发CSI重新挂载，因此恢复s3fs进程和livenessProbe都是同时需要的。

标签：解决方法