当集群中需要升级 Mount Pod 时，目前推荐的方式是更新配置后重新挂载应用 Pod 进行滚动升级，但这种升级方式的问题在于需要业务重启。
如果对业务的使用模式很清楚时，比如没有数据写入等，也可以选择手动重建 Mount Pod 的方式。在更新配置后，手动删除已有的 Mount Pod，并等待其重建，同时依赖 CSI 对挂载点的自动恢复功能，等待应用 Pod 中挂载点的恢复。这种升级的过程有几个问题：
- 操作繁琐：需要用户自己使用 kubectl 命令，通过应用 Pod 找到对应的 Mount Pod；
- 升级时业务中断：CSI 需要先等待旧的 Mount Pod 完全被删除，才会去创建新的 Mount Pod。这就导致了在旧的 Mount Pod 删除后、新的 Mount Pod 起来前，业务处于不可用状态；
- 挂载点自动恢复对原 I/O 操作的影响：由于 CSI 使用了重新 bind 应用挂载点的方式实现了自动恢复，所以即使在恢复后，原先的 I/O 操作都会报错。
为了解决现有的升级过程遇到的问题，JuiceFS CSI Driver 在 v0.25.0 版本中，实现了 Mount Pod 的平滑升级，即在应用不停服的情况下升级 Mount Pod。
相比有损升级的方式，使用平滑升级的好处在于：
- 操作简单：在 CSI Dashboard 中，可以轻易的在应用 Pod 的页面找到 Mount Pod，且点击按钮即可触发平滑升级；
- 业务不中断：升级过程中，业务不会受到影响，用户也可以使用平滑升级功能来进行 Mount Pod 的参数和配置修改。
01 CSI 如何实现 Mount Pod 的平滑升级
目前 JuiceFS CSI 支持两种平滑升级方式，即二进制升级和 Pod 重建升级。
二进制升级
二进制升级不会重建 Mount Pod，而是升级 Mount Pod 中的客户端二进制。其依赖 JuiceFS 客户端自身的守护进程，即社区版版本在 v1.2.0 以上，商业版版本在 v5.0.0 以上。
整个二进制升级的过程如下：
- 在触发平滑升级后，CSI Node 启动一个使用新镜像的 Job，在 Job 中将 JuiceFS 客户端二进制 copy 到 Mount Pod 中；
- 等 Job 完成后，CSI Node 向 Mount Pod 发送 SIGHUP 信号；
- Mount Pod 接收到 SIGHUP 信号后，将目前的 I/O 请求状态信息保存到临时文件中，此时服务进程退出；
- Mount Pod 的服务进程退出后，守护进程会用新的二进制再次启动新的服务进程；
- 新的服务进程启动后读取中间状态文件，并继续处理之前的请求；
- 新的服务进程向守护进程拿当前的 FUSE fd。
二进制升级使用于仅需要升级客户端的情况。但升级后查看 Pod 的 yaml，其镜像依然是旧的。由于没有重建 Pod，这种升级的好处在于速度快且风险小，缺点在于不能更新 Mount Pod 的其他配置。
Pod 重建升级
Pod 重建升级指的是重建 Mount Pod 进行平滑升级。这种升级方式依赖 JuiceFS 本身的平滑升级功能，即社区版版本在 v1.2.1 以上，商业版版本在 v5.1.0 以上。
整个 Pod 重建升级的过程如下：
- 每个 Mount Pod 在启动后，都会将自身使用的 FUSE fd 传给 CSI Node，CSI Node 维护了每个 Mount Pod 使用的 FUSE fd 的关系表；
- 在触发了平滑升级后，CSI Node 会先起一个与新 Mount Pod 相同配置的空 Job，这一步的作用是提前将新镜像 pull 在节点上，从而节省升级时间；
- 等 Job 完成后，CSI Node 向旧的 Mount Pod 发送 SIGHUP 信号；
- 旧的 Mount Pod 接收到 SIGHUP 信号后，将目前的 I/O 状态信息保存到临时文件中，并退出。此时 Mount Pod 变为 Complete 状态；
- CSI Node 根据 ConfigMap 中的配置，创建新的 Mount Pod；
- 新的 Mount Pod 起来后，读取临时文件中的中间状态信息，从而继续处理之前的请求；
- 新的 Mount Pod 向 CSI Node 拿当前的 FUSE fd。
其中 Mount Pod 和 CSI Node 之间通过 Unix domain socket 来传递文件句柄。当某个 FUSE 请求未能在升级期间完成，会被强制中断，建议在负载比较低的时候进行升级操作。
可以看到整个平滑升级的过程，与宿主机上客户端的平滑升级类似，唯一的区别在于由 CSI Node 向旧的服务进程发送 SIGHUP 信号以及新的服务进程启动后向 CSI Node 拿 FUSE fd。这是因为 Mount Pod 在重建后，其中的守护进程无法向旧的守护进程发送 SIGHUP 信号以及无法通过 Unix domain socket 传递文件句柄，所以在 K8s 环境中这些工作就交由 CSI Node 来完成。
这种升级方式由于重建了 Pod，缺点在于如果集群环境比较复杂，重建 Pod 的过程中出错的风险比较大；其优点在于可以更新 Mount Pod 的其他配置，且查看 Pod 的 yaml，其镜像是新的。
02 如何触发平滑升级
目前平滑升级可以在 CSI Dashboard 或者 kubectl 插件中触发。
Dashboard 中触发
首先在 CSI Dashboard 中，点击「配置」按钮，更新 Mount Pod 需要升级的新镜像版本。
其次，在 Mount Pod 的详情页，有两个升级按钮，分别是「Pod 重建升级」和「二进制升级」。
- Pod 重建升级：Mount Pod 会重建，可用于更新镜像、调整挂载参数、调整 pod 资源等。Mount Pod 的最低版本要求为 1.2.1（社区版）或 5.1.0（企业版）；
- 二进制升级：Mount Pod 不重建，只升级其中的二进制，不可变更其他配置，且升级完成后 Pod yaml 中所看到的依然是原来的镜像。Mount Pod 的最低版本要求为 1.2.0（社区版）或 5.0.0（企业版）。
点击升级按钮，即可触发 Mount Pod 的平滑升级。
触发后可以看到整个过程，完成后页面会自动跳转到新的 Mount Pod 的详情页。
kubectl 插件中触发
使用 kubectl 在 CSI ConfigMap 配置中更新 Mount Pod 所需要升级的镜像版本。
apiVersion: v1
data:
config.yaml: |
mountPodPatch:
- ceMountImage: juicedata/mount:ce-v1.2.0
eeMountImage: juicedata/mount:ee-5.1.1-ca439c2
kind: ConfigMap
使用 JuiceFS kubectl plugin 触发 Mount Pod 的平滑升级。
# Pod 重建升级
kubectl jfs upgrade juicefs-kube-node-1-pvc-52382ebb-f22a-4b7d-a2c6-1aa5ac3b26af-ebngyg --recreate
# 二进制升级
kubectl jfs upgrade juicefs-kube-node-1-pvc-52382ebb-f22a-4b7d-a2c6-1aa5ac3b26af-ebngyg
03 总结
鉴于目前的有损升级方案存在诸多缺陷，JuiceFS CSI Driver 在 v0.25.0 版本中，支持了 Mount Pod 的平滑升级。CSI 提供了两种平滑升级方案，包括二进制升级和 Pod 重建升级。二进制升级风险小，但不支持更新 Mount Pod 的其他配置；Pod 重建升级在集群环境较复杂的情况下有失败的风险，但支持更新 Mount Pod 的其他配置，比如可以根据 Mount Pod 的实际资源使用情况，动态调整资源配比等。用户可以根据需要，选择更适合的升级方式，同时建议在负载比较低的时候进行升级操作。
