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)就行了。
相关推荐
亿牛云爬虫专家1 小时前
采集架构的三次升级:脚本、Docker 与 Kubernetes
爬虫·docker·架构·kubernetes·脚本·代理ip·采集
qq_273900231 小时前
Docker 与 Singularity 镜像实战指南
运维·docker·容器
mqiqe2 小时前
K8S 算力架构
容器·架构·kubernetes
为什么要做囚徒2 小时前
Docker实战系列之Root目录迁移指南:单机环境下的完整实践
运维·docker·容器
2301_767902643 小时前
第 4 章 docker容器
运维·docker·容器
喵同志不止步于码农3 小时前
Docker + k8s 探索
docker·容器·kubernetes
努力也学不会java3 小时前
【Spring Cloud】 服务注册/服务发现
人工智能·后端·算法·spring·spring cloud·容器·服务发现
孤岛悬城3 小时前
64 K8s安全机制
kubernetes·云计算·k8s
fanruitian3 小时前
centos 安装minikube
docker·kubernetes·centos