升级 JuiceFS CSI 驱动
我们推荐你及时跟进主要版本的升级,不要在大小版本上落后太久(patch 版本如果没有特殊需要,不必频繁升级)。如果你不清楚当前所使用的版本,只需要查询 CSI 驱动组件所使用的镜像 tag,就能确认当前版本。可以用下方一行命令快速检查:
kubectl get pods -l app=juicefs-csi-node -ojsonpath='{range .items[*]}{..spec..image}{"\n"}{end}' --all-namespaces | head -n 1 | grep -oP 'juicefs-csi-driver:\S+'
阅读 JuiceFS CSI 驱动的发布说明以了解是否需要升级。需要注意的是:
- 升级 CSI 驱动,会伴随着 JuiceFS 客户端(也就是 mount 镜像)的升级,不过不用担心,正在运行的 Mount Pod 并不受影响,应用滚升或重建以后才会生效
- 如果已经通过其他手段显式指定了 mount 镜像,那么升级 CSI 驱动就不再“顺便”升级 JuiceFS 客户端版本了
- 若需要单独升级 JuiceFS 客户端,而不升级 CSI 驱动,参考「升级 JuiceFS 客户端」
升级 CSI 驱动(容器挂载模式)
v0.10.0 开始,JuiceFS 客户端与 CSI 驱动进行了分离,升级 CSI 驱动将不会影响已存在的 PV。因此升级过程大幅简化,同时不影响已有服务。
但这也意味着,升级 CSI 驱动后,应用并不会自动地享受到新版 JuiceFS 客户端。你还需要重新创建应用容器,这样一来,CSI Node 会使用新版 Mount Pod 容器镜像创建挂载点,让应用使用新版 JuiceFS 客户端。
特别地,如果你修改了 Mount Pod 容器镜像,那么升级 CSI 驱动就完全不影响 JuiceFS 客户端版本了,你需要按照文档,继续自行管理 Mount Pod 容器镜像。
通过 Helm 升级
仔细按照下方列表进行确认和操作。
-
找到该集群安装时使用的 Helm 配置文件,比如
values-mycluster.yaml
,在文件名中体现出集群名是为了方便管理。如果该文件没有进行源码管理、已经丢失,那么可以尝试用下方命令恢复:# 根据实际情况修改命名空间和 Release 名称
helm get values juicefs-csi-driver -n kube-system > values-mycluster.yaml -
打开
values-mycluster.yaml
,将其与 CSI 驱动默认的values.yaml
进行比对,精简删去重复内容,尤其不应包含镜像 Tag。如果你通过复制粘贴的方式生成最初的values-mycluster.yaml
,那么会包含如下配置:image:
repository: juicedata/juicefs-csi-driver
tag: "v0.28.1"按照上述示范,由于
tag
被固定在v0.28.1
,就算运行了helm repo update
,再次安装的时候,也不会进行升级。因此,我们**不推荐用复制的方式生成 Helm 集群配置。**如果确实需要修改某些字段,比如容器镜像的仓库地址,应该删去其他无关字段:image:
repository: registry.mycompany.com/juicefs-csi-driver如此一来,在
values-mycluster.yaml
中仅仅覆盖了镜像仓库,不影响版本号,那么在升级操作的时候,Helm 仍然会以默认values.yaml
中的内容为准,如此方可顺利升级。 -
如果你的工作电脑可以顺利访问
https://juicedata.github.io/charts/
,那么并不需要将 Helm Chart 离线下载到本地,直接运行下方命令就能更新升级:helm repo update
helm upgrade --install juicefs-csi-driver juicefs/juicefs-csi-driver -n kube-system -f ./values-mycluster.yaml如果你的环境属于这种情况,用上方的示范命令升级完毕以后,就可以检查组件状态、核实升级 结果,不需要再继续阅读后续步骤。
-
如果网络条件不佳,无法访问我们的 Helm 仓库,则可以通过下列操作,将安装资源全部离线下载、保存在本地:
# 在另一个可以顺利访问 Helm 仓库的环境提前下载好 Helm Chart
helm repo add juicefs https://juicedata.github.io/charts/
helm repo update
helm fetch --untar juicefs/juicefs-csi-driver下载好 Helm Chart 后,将集群配置文件移入该目录,并创 建 Git 仓库,将所有资源纳入源码管理。最终的目录结构类似下方示范:
$ tree -L1
.
├── Chart.yaml
├── README.md
├── templates
├── values-mycluster.yaml
└── values.yaml在未来需要升级 CSI 驱动的时候,也需要再次下载 Chart,对 本地资源进行删除和替换(注意不能直接
cp -r
覆盖,必须采用删除替换的方式,避免新版本可能淘汰了特定资源)。注意在删除本地旧版资源之前,务必确认是否存在定制化改动,比如在
templates
目录下增删或修改相关资源,来对集群进行特殊适配。如果有此类修改,也需要将定制化的部分重新施加在新版 Chart 中。由于此类操作的复杂性,我们不推荐任何针对 Chart 资源的定制,请与 Juicedata 工程师讨论协商,贡献代码来支持特殊的定制需求。
# 将新版 Chart 下载到临时目录,方便后续替换操作
helm repo update
helm fetch --untar juicefs/juicefs-csi-driver --untardir=temp
# 删除旧版相关资源,替换为新版 Chart
rm -rf juicefs-csi-driver/templates
mv temp/juicefs-csi-driver/* juicefs-csi-driver
# 进入 Chart 目录,用本地资源执行升级
helm upgrade --install juicefs-csi-driver . -n kube-system -f ./values-mycluster.yaml
通过 kubectl 升级
如果你使用 kubectl 的安装方式,我们不建议你对 k8s.yaml
做任何定制修改,这些修改将会在升级时带来沉重的负担:你需要对新旧版本的 k8s.yaml
进行 diff 比对,辨认出哪些改动是需要保留的,哪些改动则是新版 CSI 驱动所需要的、应当覆盖。随着你的修改增多,这些工作会变得十分艰难。
因此如果你的生产集群仍在使用 kubectl 安装方式,务必尽快切换成 Helm 安装方式(参考下一小节了解如何迁移到 Helm 安装方式)。考虑到默认的容器挂载模式是一个解耦架构,卸载 CSI 驱动并不影响正在运行的服务,你可以放心地卸载、使用 Helm 重新安装 CSI 驱动,享受更便利的升级流程。
当然了,如果你并未对 CSI 驱动配置做任何改动,那么直接下载最新的 k8s.yaml
,然后用下边的命令进行覆盖安装即可。
kubectl apply -f ./k8s.yaml
但如果你的团队自行维护 k8s.yaml
,已经对其中的配置做了变更,那就需要对新老版本的 k8s.yaml
进行内容比对,将新版引入的变动追加进来,然后再进行覆盖安装:
curl https://raw.githubusercontent.com/juicedata/juicefs-csi-driver/master/deploy/k8s.yaml > k8s-new.yaml
# 梳理配置前,对老版本安装文件进行备份
cp k8s.yaml k8s.yaml.bak
# 对比新老版本的内容差异,在保留配置变更的基础上,将新版引入的变动进行追加
# 比方说,新版的 CSI 驱动组件镜像往往会更新,例如 image: juicedata/juicefs-csi-driver:v0.21.0
vimdiff k8s.yaml k8s-new.yaml
# 配置梳理完毕,进行覆盖安装
kubectl apply -f ./k8s.yaml
如果安装过程中报错提示 CSI 驱动无法更新,报错提示资源无法变更:
csidrivers.storage.k8s.io "csi.juicefs.com" was not valid:
* spec.storageCapacity: Invalid value: true: field is immutable
这往往表示新版 k8s.yaml
引入了 CSI 驱动的资源定义更新(比方说 v0.21.0 引入了 podInfoOnMount: true
),你需要手动删除相关资源,才能重装:
kubectl delete csidriver csi.juicefs.com
# 覆盖安装
kubectl apply -f ./k8s.yaml
复杂的梳理流程、以及安装时的异常处理,对生产环境的维护极不友好,因此在生产环境务必使用 Helm 的安装方式。