共计 2868 个字符,预计需要花费 8 分钟才能阅读完成。
Kubernetes 作为资源调度和利用编排的开源零碎,正在成为云计算和古代 IT 基础架构的通用平台。JuiceFS CSI Driver 实现了容器编排零碎的存储接口,使得用户能够在 Kubernetes 中以原生的形式应用 JuiceFS。
因为 Kubernetes 本身的复杂性,用户反馈在部署和应用 JuiceFS CSI Driver 时,会遇到不少疑难问题。本文将为大家介绍 JuiceFS CSI Driver 架构、常见问题排查思路。
1. JuiceFS CSI Driver 架构介绍
组件
JuiceFS CSI Driver 的架构如下图,共有两个组件:
Controller Service:以 PV id 为名在 JuiceFS 文件系统中创立子目录。
Node Service:创立 Mount Pod(JuiceFS 客户端),并挂载利用 Pod。
CSI Node 的工作机制如下图,次要将 JuiceFS 客户端放在独自的 pod 中运行,这样做有如下好处:
- 多个 Pod 共用 PV 时,不会新建 Mount Pod,而是对已有的 Mount Pod 做援用计数,计数归零时删除 Mount Pod。
- CSI 驱动组件与客户端解耦,不便 CSI 驱动本身的降级。
创立 PV 和应用的流程
动态创建 PV(不应用 StorageClass 的跳过此步骤):
- 用户创立 PVC,应用 JuiceFS 作为 StorageClass;
- CSI Controller 负责在 JuiceFS 文件系统中做初始化,默认以 PV ID 为名字创立子目录,同时创立对应的 PV;
- Kubernetes (PV Controller 组件) 将上述用户创立的 PVC 与 CSI Controller 创立的 PV 进行绑定,此时 PVC 与 PV 的状态变为「Bound」;
Pod 中应用 PVC: - 用户创立利用 Pod,Pod 中申明应用先前创立的 PVC;
- CSI Node Service 负责在利用 Pod 所在节点创立 Mount Pod;
- Mount Pod 启动,执行 JuiceFS 客户端挂载,运行 JuiceFS 客户端,挂载门路裸露在宿主机上,门路为
/var/lib/juicefs/volume/[pv-name]
; - CSI Node Service 期待 Mount Pod 启动胜利后,将 PV 对应的 JuiceFS 子目录 bind 到容器内,门路为其申明的 VolumeMount 门路;
- Kubelet 创立利用 Pod。
PVC – PV – MountPod 的关系能够用下图示意,在同一个节点上,一个 PVC 会对应一个 Mount Pod。
2. 动静配置和动态配置应用示范
创立 Secret:
apiVersion: v1
kind: Secret
metadata:
name: juicefs-secret
type: Opaque
stringData:
name: <JUICEFS_NAME>
metaurl: <META_URL>
storage: s3
bucket: https://<BUCKET>.s3.<REGION>.amazonaws.com
access-key: <ACCESS_KEY>
secret-key: <SECRET_KEY>
动态配置
在利用 YAML 中申明 PVC,同时 PVC 指定 PV。
动静配置
在利用 YAML 中申明 PVC,同时 PVC 指定 StorageClass,PV 会主动创立。
3. Mount Pod 的治理
CSI Node 负责管理 Mount Pod 的生命周期,有一些个性能够依据业务状况抉择应用。
第一,多个利用 pod 应用同一个 PVC 时,共用 Mount Pod。次要的做法是:
- Mount Pod 的 annotation 中记录了利用的挂载门路,作为援用计数
- CSI 在后盾查看其记录挂载的利用是否存活,当没有利用援用时,对其进行回收
第二,Mount Pod 意外退出后,CSI 主动拉起,并复原容器内的挂载点。该个性须要用户在利用端开启HostToContainer
或Bidirectional
。并且,在挂载点损坏前关上的文件不能复原,须要用户侧做好重试。
第三,能够设置 Mount Pod 的资源申请及限度(CPU/Memory requests & limit
)。
第四,Mount Pod 提早退出,所有的利用都退出后,Mount Pod 延后退出。次要的应用场景数大量利用应用同一 PVC,且利用会频繁创立删除。
第五,Mount Pod 退出时清理缓存。默认状况下,Mount Pod 应用的缓存会留在宿主机上,且退出后不会清理;开启这个性能后,CSI 在回收 Mount Pod 时,会启动一个 job,清理宿主机上的缓存。
第六,设置 Mount Pod 所应用的缓存门路。默认状况缓存应用的是本地磁盘;也能够应用独立 PVC 作为缓存门路。
第七,设置 Mount Pod 的镜像。首先,CSI Node 的环境变量设置默认的 Mount 镜像;也能够在 PV/StorageClass
中设置特定的 Mount 镜像。
4. CSI 应用倡议
对于 JuiceFS CSI Driver 的应用,有以下几点倡议:
- 开启 Mount pod 的监控,能够实时查看以后集群的应用负载、缓存、I/O 等状况;
- 收集 Mount pod 的日志,利于故障排查;
- 开启挂载点主动复原性能,进步可用性;
- 不要在 CSI 环境中应用 writeback 参数,writeback 须要有至多有一个客户端异步将数据上传到对象存储中,Mount Pod 与利用同生命周期,不会始终存在,有丢数据的危险。
5. 问题排错思路
常见谬误有两种:一种是 PV 创立失败,属于 CSI Controller 的职责;另一种是利用 Pod 创立失败,属于 CSI Node 和 Mount Pod 的职责。
具体问题排查思路请拜访,排查办法文档。
对于更多 JuiceFS CSI Driver 的文档,包含应用办法、运维治理等,能够对立拜访 JuiceFS CSI Driver 文档。
一些对于 CSI 的 Q&A
- 如何挂载曾经存在的 JuicFS 数据?
应用动态挂载,利用申明 PVC,指定 PV;动静配置会保障每个利用应用独自的子目录作为隔离,不能拜访已有的数据。
2. 同一个 JuiceFS 卷,如何实现挂载不同参数?
申明不同的 PVC 和 PV/StorageClass,在 PV/StorageClass 中指定不同的挂载参数。
- 同一个 PVC,多个 pod 如何实现不同子目录挂载?
同一个 PVC 对应同一个 MountPod(juicefs fuse 客户端)的,利用 pod 中能够在 volumeMount 中定义不同的 subPath 实现挂载不同的子目录。
- “trash-days”等配置参数如何设置?
juicefs format 的参数,如 trash-days、inodes、capacity 等,在 secret 的 format-options 里设置。
- 如何在 CSI 环境中做缓存预热?
应用 kubectl exec 命令进入到 Mount Pod 中,df 命令查看挂载点,再用 juicefs warmup 命令做预热,其中社区版的二进制门路为 /usr/local/bin/juicefs,商业版的二进制门路为 /usr/bin/juicefs。
更多问题排查案例请拜访排查案例文档。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟!(0ᴗ0✿)