摘要：# 搞懂K8s存储插件CSI：手把手教你挂载云硬盘，别再踩坑了 我前两天帮一个朋友排查问题，他们团队在K8s里用CSI挂载云硬盘，结果应用动不动就报“卷不可用”。一查日志，好家伙，配置写得那叫一个“教科书”——完美复刻了官方文档，但就是没考虑自己业务的实…

搞懂K8s存储插件CSI：手把手教你挂载云硬盘，别再踩坑了

我前两天帮一个朋友排查问题，他们团队在K8s里用CSI挂载云硬盘，结果应用动不动就报“卷不可用”。一查日志，好家伙，配置写得那叫一个“教科书”——完美复刻了官方文档，但就是没考虑自己业务的实际读写压力。这种场景你应该不陌生吧？很多团队都觉得CSI对接云硬盘是个“配置完就没事”的活儿，真出了性能问题或者故障，才发现当初的配置全是坑。

今天咱就抛开那些晦涩的官方术语，用大白话把K8s里用CSI挂载云硬盘这事儿聊透。我会结合我自己在几个中型项目里趟过的坑，告诉你哪些配置是花架子，哪些才是真管用。

一、CSI到底是个啥？—— 别被名字唬住了

首先，咱得把心态放平。CSI（Container Storage Interface） 这名字听起来高大上，说白了，它就是K8s和底层存储（比如云硬盘、文件存储这些）之间的一套标准“接头”。

在CSI出现之前，那叫一个乱。每家云厂商（阿里云、腾讯云、AWS）都得自己写一套跟K8s对接的插件，代码耦合深，升级起来能要人命。CSI干了件好事：它定了套规矩，让存储厂商按这个规矩来开发驱动，K8s这边也按这个规矩来调用。结果就是，你换云厂商，或者换存储类型，上层的K8s应用配置几乎不用大改。

这就好比以前每家手机充电口都不一样，现在统一成Type-C了，是不是方便多了？

二、准备工作：云平台那边你得先动动手

很多人一上来就在K8s的yaml文件里埋头苦干，其实第一步错了。在配置K8s之前，云平台控制台里有几件事必须先搞定。我自己就吃过亏，跳过了这步，后面debug到怀疑人生。

1. 开通和授权：确保你的K8s集群所在的云账号，已经开通了对应的云硬盘（CBS）服务，并且给集群的Worker节点角色（比如腾讯云的TKE_QCSRole）赋予了操作云硬盘的权限（例如CBS的全读写策略）。没权限，一切都是白搭。
2. 搞清楚存储类型：云硬盘一般分好几档：高性能云硬盘、SSD云硬盘、增强型SSD。价格和性能差得不是一星半点。你要是跑一个偶尔读写日志的应用，用高性能云硬盘就够了；但如果是MySQL、Redis这类对IOPS要求高的，不上SSD真扛不住，别硬撑。
3. 规划好容量和购买方式：是按量计费还是包年包月？初始容量多大？这里有个关键点： 云硬盘通常有扩容功能，但K8s PVC（PersistentVolumeClaim）的扩容需要CSI驱动和StorageClass都支持AllowVolumeExpansion: true才行，而且文件系统扩容还得在Pod里操作一下。所以初期容量尽量估算得宽裕点，省去后续麻烦。

三、核心四步走：从创建到挂载的实操流水账

好了，前置条件搞定，咱们进入正题。在K8s里用CSI挂云硬盘，核心就四步，我画个土味流程图给你看：

创建StorageClass -> 创建PVC -> Pod里声明使用PVC -> 等K8s自动完成挂载

看着简单吧？但每一步都有细节能卡住你。

第一步：定义StorageClass（存储类）—— “菜单”

StorageClass不是具体的存储资源，而是一个“菜单”或者“模板”，它定义了创建云硬盘的“配方”：用什么类型的硬盘、怎么加密、买多大、要不要快照等等。

给你看个腾讯云TKE环境下比较实用的StorageClass例子，我加了些注释：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cbs-ssd-highspeed # 类名，后面PVC会引用它
provisioner: com.tencent.cloud.csi.cbs # 关键！指明用腾讯云的CBS CSI驱动
parameters:
  type: CLOUD_PREMIUM # 磁盘类型。CLOUD_PREMIUM是高性能云硬盘，CLOUD_SSD是SSD云硬盘
  # diskChargeType: POSTPAID_BY_HOUR # 计费模式，按量计费。包年包月是PREPAID
  # encrypt: true # 是否加密
reclaimPolicy: Delete # PVC删除后，云硬盘也一起删除。Retain是保留，但需要你手动清理
allowVolumeExpansion: true # 允许后续扩容，这个建议打开
volumeBindingMode: Immediate # 立即绑定。还有WaitForFirstConsumer（延迟绑定），能优化调度

把这个yaml apply到你的集群，kubectl get sc就能看到它了。StorageClass通常由集群管理员创建，一次创建，团队多人复用。

第二步：创建PVC（持久卷声明）—— “下单”

有了“菜单”（StorageClass），现在应用团队可以来“点菜”了。这个动作就是创建PVC。PVC是用户对存储需求的声明：“我要一个10Gi的、高速的、能读写的盘子”。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myapp-data-pvc # PVC的名字，Pod里会用到
spec:
  storageClassName: cbs-ssd-highspeed # 指定用哪个“菜单”（StorageClass）
  accessModes:
    - ReadWriteOnce # 访问模式。RWO是最常见的，表示只能被一个节点挂载为读写
  resources:
    requests:
      storage: 10Gi # 需要的存储大小

执行kubectl apply -f pvc.yaml后，神奇的事情发生了：K8s看到这个PVC，发现它指定了cbs-ssd-highspeed这个StorageClass，就会自动去调用腾讯云的CSI驱动。驱动会去腾讯云后台，真的帮你买一块10Gi的高性能云硬盘！ 这块硬盘在K8s里对应的资源叫PV（PersistentVolume），是自动创建并与PVC绑定的。

用kubectl get pvc看状态，如果是Bound，就说明云硬盘已经买好并绑定了。

第三步：在Pod里使用PVC—— “上菜”

硬盘（PV）已经准备好了，现在就是让Pod（你的应用容器）用上它。这步最简单，就是在Pod的volumeMounts里引用PVC的名字。

apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: data-storage # 挂载到容器内的名字
      mountPath: /usr/share/nginx/html # 容器内的挂载路径
  volumes:
  - name: data-storage # 定义卷的名字，和上面对应
    persistentVolumeClaim:
      claimName: myapp-data-pvc # 关键！指定使用哪个PVC

Pod创建后，K8s调度器会把它调度到某个Worker节点上，然后该节点上的CSI驱动会执行“挂载”操作：将云硬盘从云平台挂载到这台宿主机（比如挂到/var/lib/kubelet/...某个路径），然后再把这个宿主机的目录映射到你的容器内部。 对你来说，透明无感，在容器里直接访问/usr/share/nginx/html就行了。

四、避坑指南：那些官方文档里不提的“实战细节”

上面是标准流程，但真想在生产环境用稳，下面这几条经验之谈，可能比文档更有用。

• 坑1：ReadWriteOnce的陷阱 刚才说ReadWriteOnce (RWO)是“单节点读写”。注意，是单节点，不是单Pod！如果你的应用是Deployment，并且replicas大于1，所有副本都想用同一个PVC，那就会出问题。因为多个Pod可能被调度到不同节点，而RWO模式的卷在同一时间只能挂在一个节点上。解决方案： 对于需要多Pod共享存储的场景（比如日志收集），应该考虑使用支持ReadWriteMany (RWX)的文件存储（如CFS），而不是块存储（云硬盘）。

• 坑2：磁盘性能与实例规格不匹配 你买了一块顶配的PCI-E SSD云硬盘，但把它挂载到了一个最低配的、CPU和网络都受限的Pod所在节点上。这就像给五菱宏光装了个F1的引擎，根本发挥不出来。磁盘性能的上限，受限于你所挂载的云服务器实例的规格。 在选择磁盘类型时，也得掂量一下Worker节点的档次。

• 坑3：忘记设置fsType 有些应用对文件系统有要求（比如必须是ext4），但云硬盘默认格式化的可能是xfs。如果没在StorageClass的parameters里指定fsType: ext4，可能导致应用报错。虽然大部分时候CSI驱动会处理，但明确指定更保险。

• 坑4：PVC和Pod的删除顺序 如果你的StorageClass的reclaimPolicy是Delete（生产环境慎用），那么删除PVC时，底层的PV和云硬盘也会被自动删除，数据就没了！ 所以，一定要先确认Pod已经不再使用这个卷，并且数据已备份或无需保留，再删PVC。更稳妥的做法是，生产环境设为Retain，删除PVC后PV状态变为Released，由管理员手动清理。

五、高级玩法：快照、扩容与监控

• 存储快照：CSI支持给云硬盘打快照（备份）。你可以通过VolumeSnapshotClass和VolumeSnapshot来创建，快照可以用于恢复数据或创建新的云硬盘。这功能对于数据库类的有状态服务，是救命稻草。
• 在线扩容：前面提过，在StorageClass里打开allowVolumeExpansion: true后，你直接修改PVC的spec.resources.requests.storage为一个更大的值（比如20Gi），K8s和CSI驱动就会联动，先扩容云硬盘，然后你需要进入Pod，用resize2fs或xfs_growfs命令扩容文件系统。记住：扩容通常可以，缩容不行！
• 监控：别以为挂上就万事大吉。务必关注云硬盘的监控指标：磁盘使用率、IOPS、吞吐量、读写延迟。在云监控平台设置告警，快满了或者IOPS长期打满，都要及时处理。

写在最后

其实吧，K8s CSI对接云硬盘，技术本身不复杂，它就是个“ connector”。真正的功夫在技术之外：根据业务特性（IO需求、共享需求、备份需求）选择正确的存储类型和配置参数，并建立配套的运维流程（监控、备份、灾难恢复）。

很多所谓“稳定”的方案，配置文档很漂亮，真遇到流量高峰或者磁盘写满的时候，该崩还是崩。所以，理解了原理，配好了参数，只是开始。定期看看监控，模拟一下磁盘故障做次演练，心里才真正有底。

行了，关于CSI和云硬盘，今天就聊这么多。如果你在配置过程中遇到其他妖魔鬼怪，欢迎随时来交流——毕竟，踩坑这事儿，人多力量大嘛。