共计 2830 个字符，预计需要花费 8 分钟才能阅读完成。
近期公布的 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 环境。
