CSI (Container Storage Interface) 通俗原理解析:K8s 的“万能存储插头”

CSI (Container Storage Interface) 通俗原理解析:K8s 的"万能存储插头"

CSI (Container Storage Interface) 是 Kubernetes (K8s) 和存储厂商之间的一种标准接口协议

它的出现,彻底解救了 K8s 开发团队,也解放了存储厂商。

1. 为什么需要 CSI?(历史的痛)

之前的"In-Tree"时代(乱七八糟)

早期的 K8s 为了支持各种存储(AWS EBS, Azure Disk, GCE PD, Ceph, NFS...),把所有这些存储厂商的代码都写到了 K8s 自己的核心代码库里

这就像买房子:

  • K8s 是开发商
  • 存储是家具(床、柜子、马桶)。
  • In-Tree 模式 :开发商把所有品牌的家具(IKEA, 全友, 索菲亚)都直接焊死在房子里。
    • 痛点 1:K8s 代码越来越肿,像个巨无霸。
    • 痛点 2:如果某个家具厂(比如 AWS)升级了款式,必须等开发商(K8s)发新版本房子才能用。
    • 痛点 3:如果家具厂的代码有 Bug,可能会把整个房子弄塌(K8s 核心组件崩溃)。

现在的 CSI 时代(插拔式)

K8s 团队受不了了,制定了 CSI 标准

  • CSI 模式 :开发商只在大楼里留好标准的三孔插座(接口)。
  • 任何家具厂(存储厂商),主要你按标准做一个插头(CSI Driver),就能插进来用。
  • 好处:K8s 不用管你是谁,只要你能插进插座就行。存储厂商想怎么升级就怎么升级,不用求 K8s 发版。

2. CSI 是怎么工作的?(存储的三步走)

当你在 K8s 里创建一个使用 PVC (Persistent Volume Claim) 的 Pod 时,CSI Driver 在后台默默做了三件大事。我们可以把它比作 "给电脑接外接硬盘" 的过程。

第一步:Provision (创建/购买硬盘)

  • CSI 术语CreateVolume
  • 动作:K8s 对 CSI Driver 说:"我要一个 100GB 的盘。"
  • 实际发生:Driver 调用云厂商 API(比如 AWS),在云端真的买了一块 100GB 的 EBS 硬盘。
  • 此时,硬盘有了,但还在仓库里,没连上任何机器。

第二步:Attach (插上硬盘)

  • CSI 术语ControllerPublishVolume
  • 动作 :K8s 调度器决定把 Pod 跑在 Node A 上。于是告诉 Driver:"把刚才那块盘,插到 Node A 这台机器上。"
  • 实际发生:Driver 调用 API,把那块云硬盘"挂载"到 Node A 虚拟机上(就像插上 USB 线)。
  • 此时,机器能看到 /dev/xvdb 了,但还不能直接写文件。

第三步:Mount (格式化并挂载)

  • CSI 术语NodePublishVolume
  • 动作:K8s 告诉 Node A 上的 Driver 组件:"把这块盘弄好,让 Pod 能用。"
  • 实际发生 :Driver 把 /dev/xvdb 格式化(mkfs),然后把它 mount 到 Pod 对应的目录里。
  • 此时,Pod 里的应用终于可以愉快地写数据了。

3. CSI Driver 的架构 (Controller 与 Node)

一个完整的 CSI 插件通常包含两部分,就像总公司分公司

  1. Controller Plugin (总公司)

    • 位置:随便跑在集群的哪个节点上,通常是单点的(Deployment)。
    • 职责:负责宏观调控。比如"去云端买个盘"、"把盘挂给某台机器"。它不需要直接操作具体的硬盘文件。
    • 对应上面的一、二步。
  2. Node Plugin (分公司)

    • 位置 :必须跑在每一台干活的节点上(DaemonSet)。
    • 职责:负责干脏活累活。比如"格式化磁盘"、"执行 mount/umount 命令"。它必须在节点本地操作。
    • 对应上面的第三步。

总结

CSI 就是存储界的 USB 标准

它让 Kubernetes (操作系统) 和各种各样的存储系统 (U盘、移动硬盘、鼠标) 彻底解耦。

  • 运维人员:爽,装个插件就能用各种高端存储。
  • 开发人员:爽,不用关心底层是 Ceph 还是 NFS,写好 PVC 就行。
  • 存储厂商:爽,再也不用求 K8s 合并代码了。

4. 关键问题:每个存储都要自己开发 CSI 吗?

答案是:是的,而且必须是自己开发。

这就像电器厂商都要自己生产适配"三孔插座"的插头一样。

  • AWS 负责开发维护 aws-ebs-csi-driver
  • 阿里云 负责开发维护 alibaba-cloud-csi-driver
  • Alluxio 团队负责开发维护 alluxio-csi

为什么这样更好?

因为只有厂商自己最懂自家的存储:

  • AWS 知道怎么调用 API 最省钱、最快。
  • Ceph 知道怎么挂载最稳定。
  • K8s 官方 只需要维护一套通用的"辅助工具库"(Sidecar Containers,如 external-provisioner),帮厂商处理一些通用的脏活(比如监听 K8s 事件),厂商只需要专注写核心的存储逻辑(Provision/Mount)就行了。
相关推荐
人鱼传说16 分钟前
docker desktop是一个好东西
运维·docker·容器
小章UPUP1 小时前
Kubernetes (K8s) 与 Podman 的比较
容器·kubernetes·podman
忆~遂愿1 小时前
CANN metadef 核心解析:计算图原型定义、算子元数据抽象与异构系统互操作机制
docker·容器
说实话起个名字真难啊2 小时前
用docker来安装openclaw
docker·ai·容器
恬静的小魔龙3 小时前
【群晖Nas】群晖Nas中实现SVN Server功能、Docker/ContainerManager等
docker·svn·容器
Zfox_3 小时前
CANN Catlass 算子模板库深度解析:高性能 GEMM 融合计算、Cube Unit Tiling 机制与编程范式实践
docker·云原生·容器·eureka
农民工老王4 小时前
K8s 1.31 私有化部署实战:从 Calico 崩溃到 NFS 挂载失败的排坑全记录
云原生·kubernetes
灰子学技术4 小时前
istio从0到1:如何解决分布式配置同步问题
分布式·云原生·istio
广州中轴线4 小时前
OpenStack on Kubernetes 生产部署实战(十四)
kubernetes·智能路由器·openstack
春日见4 小时前
如何创建一个PR
运维·开发语言·windows·git·docker·容器