Sidecar-详解 JuiceFS CSI Driver 新模式
Sidecar-详解 JuiceFS CSI Driver 新模式
近期发布的 JuiceFS CSI Driver v0.18 版本中，我们提供了一种全新的方式访问文件系统，即 JuiceFS 客户端以 Sidecar 方式运行于应用 Pod 中，且客户端与应用同生命周期。
这个全新的功能将帮助用户在 Serverless Kubernetes 环境中使用 JuiceFS；与传统的 Mount Pod 模式相比，问题排查更方便、客户端管理更简单。
今天在这篇文章中，将为大家介绍 Sidecar 模式的工作原理以及应用场景， 另外在文末还附上了用户关心的问题与解答。
What is a sidecar in cloud? Sidecar 是一种常见的设计模式，这个概念在容器和微服务的领域中非常流行。回到 sidecar 的字面意思，如下图所示，就是指摩托车边上安装的这个小车，以增加摩托车的承载能力，它非常形象地表达了Sidecar 容器和应用容器的关系。在云环境中，他们成为一体，共享 Kubernetes pod 的环境，并且同一 pod 内的所有容器生命周期一致。
基础介绍
一些名词解释
? Pod：可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元 ? Deployment / DaemonSet / StatefulSet / Job：声明式资源，对 Pod 的不同管理方式 ? PV（PersistentVolume）：集群中的一块存储 ? PVC（PersistentVolumeClaim）：表达的是用户对存储的请求 ? StorageClass：为管理员提供了描述存储 "类" 的方法 ? CSI（Container Storage Interface）：容器存储接口
如何使用
存储的管理是一个与计算实例的管理完全不同的问题。PV 表示的是集群中的一块存储，可以由管理员事先创建；或者使用 StorageClass 来动态创建，然后用户在 Pod 中通过指定 PVC 来使用。根据 PV 的创建方式，可以分为静态配置和动态配置两种使用方式，下面一一介绍。
静态配置 由系统管理员创建若干 PV，在 PV 中声明包含了 JuiceFS 系统参数的 Secret，以备用户使用。用户创建 PVC，声明使用具体的 PV，在应用 Pod 中配置使用 PVC 即可。
资源间的关系如下图所示：
静态配置每一个应用使用都需要系统管理员对应创建一个 PV，在简单测试场景或者应用间数据共享时使用比较广泛。
动态配置 由系统管理员创建 StorageClass，在 StorageClass 中声明包含了 JuiceFS 系统参数的 Secret；然后用户创建 PVC，声明使用具体的 StorageClass，PVC 创建之后，Kubernetes 会根据 StorageClass 自动创建出一个 PV 与 PVC 进行绑定，最后用户在应用 Pod 中配置使用 PVC。
资源间的关系如下图所示：
JuiceFS CSI Driver 的工作原理
用户通过在 PV / StorageClass 中指定 JuiceFS 的参数，进而在集群中使用 JuiceFS。JuiceFS CSI Driver 则负责挂载 JuiceFS 文件系统。
JuiceFS CSI Driver 提供了两种方式挂载文件系统，一种是现有的 Mount Pod 模式，另一种则是本次发布的版本中提供的 Sidecar 容器的方式。下面一一介绍两种模式以及二者的对比。
Mount Pod 模式
组件 Mount Pod 模式涉及到的组件包括 CSI Controller Service 和 CSI Node Service，职责分别为：
? Controller Service：以 PV id 为名，在 JuiceFS 文件系统中创建子目录。 ? Node Service：创建 Mount Pod（JuiceFS 客户端），并挂载应用 Pod。下文会详细介绍其工作机制。
这种模式对环境的要求： ? 可以使用 FUSE 设备，在容器中体现为需要特权（Privilege）； ? 可以运行 DaemonSet ，默认每台机器上都需要运行一个 CSI Node pod。
工作原理 CSI Node Service 的工作机制如下图所示：
- 用户创建应用 Pod，Pod 中声明使用 JuiceFS 的 PVC；
- CSI Node 负责在应用 Pod 所在节点创建 Mount Pod；
- Mount Pod 启动，执行 JuiceFS 客户端挂载，运行 JuiceFS 客户端，挂载路径暴露在宿主机上；
- CSI Node 等待 Mount Pod 启动成功后，将 PV 对应的 JuiceFS 子目录 bind 到容器内，路径为其声明的 VolumeMount 路径；
- Kubelet 创建应用 Pod。
PVC 与 Mount Pod 的关系 PVC、PV 和 Pod 的关系可以用下图表示，即在同一个节点上，一个 PVC 会对应一个 Mount Pod。
Sidecar 模式
组件 JuiceFS FUSE 客户端以 sidecar 容器的方式与应用容器一起运行在同一个 Pod 中。
CSI Driver 组件只有 CSI Controller Service。其职责为：
- 以 PV id 为名在 JuiceFS 文件系统中创建子目录；
- 向 ApiServer 注册 webhook，在 pod 中注入 JuiceFS 客户端的 sidecar 容器。
工作原理 工作机制如下图所示：
- CSI Controller 启动时向 ApiServer 注册 webhook；
- 应用 Pod 指定使用 JuiceFS 的 PVC；
- ApiServer 在创建应用 Pod 前调用 CSI Controller 的 webhook 接口；
- CSI Controller 向应用 Pod 中注入 JuiceFS 客户端容器（sidecar）；
- ApiServer 创建 Pod，sidecar 容器启动后执行挂载，并运行 JuiceFS 客户端，客户端则按需访问元数据引擎和对象存储；应用容器启动后可直接访问文件系统。
PVC 与 Sidecar 的关系 PVC、PV 和 Pod 的关系可以用下图表示，即每个应用 pod 单独拥有自己的 JuiceFS 客户端，应用的挂载点相互隔离。
这种模式下，对环境的要求是可以使用 FUSE 设备，在容器中体现为需要特权（Privilege）容器。
Sidecar 容器的资源请求默认为 1 CPU 和 1GiB 内存，资源约束默认为 2 CPU 和 5GiB 内存。当集群资源紧俏时，我们还可以在 PV/StorageClass 中对 Sidecar 容器的使用资源进行配置。
另外，Sidecar 容器和应用容器的挂载点共享是通过 HostPath 实现的，不是直接共享，所以当 Sidecar 容器发生意外重启后，应用容器中的挂载点不会自行恢复，需要整个 Pod 重新创建。
两种模式的优缺点及使用场景
Sidecar 模式：
? 优势：故障排查简单；所有环境都可用； ? 缺点：资源开销大，每个应用 Pod 独享 JuiceFS 客户端； ? 使用场景：Serverless Kubernetes 环境（可以使用 FUSE）；应用任务量不大的标准 Kubernetes 环境。
Mount Pod 模式：
? 优势：资源开销小，使用相同 PVC 的所用应用 Pod 共享同一个 JuiceFS 客户端； ? 缺点：故障排查复杂；Serverless 环境不可用。 ? 使用场景：应用任务较多、标准的 Kubernetes 环境。