企业官网建设流程全解析

刚上手Kubernetes那会儿，Deployment、Service、Ingress这些核心概念一个个跑通之后，很容易让人产生一种“集群已经搞定”的错觉。真正的分水岭，是第一次往集群里部署Redis Cluster、Kafka这类有状态中间件。PVC显示Pending、Pod卡在ContainerCreating、数据挂载目录没有写权限，这些问题是Kubernetes集群存储管理里最常见的三座大山，也是这篇文章要拆解的核心。我会从PV/PVC/StorageClass这套抽象体系开始，讲到动态供给如何落地、NFS与Ceph的选型和参数配置，最后再给出一份故障排查速查清单，适合正在维护K8s集群、准备把中间件迁入集群的运维和开发同学参考。

1. Kubernetes集群存储管理的核心痛点与整体设计

1.1 容器调度与数据持久化之间的矛盾

Kubernetes调度的最小单位是Pod，而Pod的生命周期非常脆弱，节点故障、镜像更新、资源不足都会导致Pod被销毁重建。无状态应用还好，副本一拉就起来；但Redis、Kafka、数据库这类有状态中间件，数据一旦随着Pod消失，整个集群的高可用就成了笑话。

这里我常用一个类比：Pod像是路边摊，随时可以换个地方摆，但仓库不能跟着摊位移。存储管理解决的核心问题，就是把“仓库”从“摊位”里剥离出来，变成独立于Pod生命周期的基础设施。实际工作中我看到很多人一开始图省事，直接给Pod挂hostPath，数据确实写到了宿主机上，但Pod一旦迁移到别的节点，数据就留在原节点找不回来了。这种方案测试一下可以，生产环境坚决不要用。

1.2 Kubernetes存储体系里的四个主角

要把存储管理讲清楚，得先认识四个角色：PV、PVC、StorageClass、CSI。

PV是管理员视角的存储资源，一个PV对应一块真实的存储空间，可以来自本地磁盘、NFS共享目录、Ceph块设备，也可以是云上的云盘。PVC是用户视角的声明，开发者不关心底层存储是什么，只写一句“我要5GB、可以读写的盘”，系统就会把合适的PV配给它。StorageClass是供给模板，定义了“这块盘应该由谁、用什么参数创建出来”。CSI则是存储插件层，K8s本身不直接操作存储硬件，所有挂载、格式化、扩容动作都通过CSI接口交给后端驱动去完成。

这四层分工的价值在于，开发和运维的职责被彻底分开了。开发不需要懂Ceph怎么部署、NFS路径怎么规划，只提交PVC就行；运维通过StorageClass统一控制容量、回收策略和数据保留策略，出了问题也能很快定位是抽象层的问题还是后端存储的问题。

1.3 容量规划：从需求推导真实存储规模

接手集群存储规划时，很多人会把PVC里的request直接当成最终占用空间，这是一个非常危险的误解。以3节点的Redis Cluster为例，假设每个节点数据量为4GB，三个节点共12GB。Redis Cluster本身通常会配置1个副本，意味着底层存储系统上同时存在主数据副本和从数据副本，那么物理空间至少是12GB×2=24GB。除此之外还要预留20%左右的空间应付写入增长、临时文件和快照，所以我通常会按“请求量×副本数×1.3”这个粗略公式去估算。

算下来，这个看起来只有12GB数据量的业务，PVC总量建议至少规划30GB。如果你给每个PVC都设置了资源限制，还要考虑PVC已经分配的容量和Pod实际写入量的差距。我见过太多集群因为初期容量规划不足，半年后就出现存储打满、Pod被驱逐的情况。

1.4 为什么我把动态供给作为主线

静态供给适合极简单的测试环境，管理员手动创建PV、开发者手动绑定PVC，数量少时还能接受。但生产集群里中间件十几个，每个服务可能还有多套环境，手工维护一张PV清单会让人崩溃。

动态供给的思路是：PVC提交后，StorageClass里的provisioner自动调用存储后端API创建空间，并生成PV完成绑定，全程不需要管理员介入。这样带来的直接好处是，存储资源的分配速度跟上了业务发布的节奏，环境复制也变得非常容易。我的经验是，除非有极其特殊的数据保留要求，否则生产集群所有有状态服务都应该统一走动态供给。

2. 从零搭建动态存储供给体系：PV、PVC与StorageClass实战

2.1 静态PV：先理解底层绑定关系

为了把动态供给讲明白，先看一个最基础的本地静态PV。它的作用是把某个节点上的目录暴露成持久化存储资源：

apiVersion: v1 kind: PersistentVolume metadata: name: pv-local-1 spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: "" local: path: /data/vol1 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - node-01

注意这里的storageClassName必须是空字符串，这样PVC声明也不带StorageClass时才能精确匹配，而不是被默认StorageClass拦截。local类型的PV必须配置nodeAffinity，因为这段路径只存在于node-01上，如果不做节点亲和限制，Pod被调度到别的节点时K8s就找不到这个卷。

对应的PVC如下：

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-local-1 spec: accessModes: - ReadWriteOnce storageClassName: "" resources: requests: storage: 5Gi

静态PV的局限是显而易见的：每块盘都要手动创建PV，容量、路径、节点信息全靠人维护，一旦节点故障，这个PV上的数据恢复也很麻烦。所以静态PV只适合学习、离线测试或极少数固定场景。

2.2 StorageClass动态供给：用一段配置解决重复劳动

动态供给依赖StorageClass和对应的provisioner。以常见的nfs-subdir-external-provisioner为例，StorageClass配置长这样：

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: nfs-storage provisioner: k8s-sigs.io/nfs-subdir-external-provisioner parameters: archiveOnDelete: "true" pathPrefix: k8s-pv onDelete: retain reclaimPolicy: Delete volumeBindingMode: Immediate allowVolumeExpansion: true mountOptions: - hard - nfsvers=4

几个关键参数的逻辑要理清。provisioner决定谁去创建PV，这个名称必须和实际部署的provisioner完全一致，拼错一个字符PVC就会一直Pending。archiveOnDelete为true时，删除PVC不会直接销毁数据，而是归档到指定目录，这对中间件场景非常重要，能防止手滑误删。reclaimPolicy虽然有Delete回收策略，但archiveOnDelete提供的归档机制如同给Delete上了一道保险。

volumeBindingMode默认是Immediate，也就是PVC提交后立刻创建PV；但如果存储后端依赖Pod的调度节点（比如本地SSD），应该改成WaitForFirstConsumer，让K8s先把Pod调度到某个节点，再决定在哪台节点创建PV。否则可能出现PV建好了，Pod却调度不到那个节点的尴尬局面。

allowVolumeExpansion必须设为true，这是后续在线扩容的前提。mountOptions里的hard和nfsvers=4属于常见实践补充，NFS挂载参数直接影响异常时的稳定性，生产环境建议加上。

2.3 验证整套链路是否打通

配置完成后，可以建一个测试PVC并挂载到一个临时Pod上验证链路：

kubectl create namespace middleware kubectl create -f pvc-redis-test.yaml kubectl get pvc -n middleware kubectl get pv | grep middleware

正常状态下PVC状态会从Pending变成Bound，同时系统自动生成一个以pvc-开头的PV。如果PVC一直处于Pending，先用kubectl describe pvc查看事件，通常能看到Failed provision或者StorageClass not found这类提示。我验证动态供给时还会专门看一眼provisioner Pod的日志，因为很多底层权限错误不会显示在PVC事件里，只会出现在Controller日志中。

2.4 回收策略与绑定模式最容易翻车

生产环境里最常见的翻车点是把reclaimPolicy设为Delete，然后直接在测试集群随手删PVC，结果底层数据目录被一起清掉。虽然没有提示但建议只用Retain或依赖archiveOnDelete。另一个容易忽视的是绑定模式：对于Ceph RBD这类不感知节点位置的存储，用Immediate还能接受；但使用本地PV或云盘且指定可用区时，一定要配合WaitForFirstConsumer，否则跨可用区调度会让Pod调度失败。

3. 接入NFS与Ceph：不同业务规模的选型与配置

3.1 NFS：中小规模业务最省事的存储后端

NFS简单、易上手、共享读写能力强，特别适合日志汇聚、静态文件、制品包这类RWX场景。中小规模集群如果暂时没有条件上Ceph，NFS是性价比最高的起步方案。

它的缺点是架构上有单点风险，NFS服务器一旦故障，所有挂载它的Pod都会卡住。我的建议是，生产环境至少给NFS加一层高可用，比如用rsync+NFS-Ganesha+Keepalived做主备切换，或者用云上的NAS产品规避硬件问题。性能方面，NFS对高并发小文件读写不太友好，数据库类负载不要放在NFS上。

3.2 NFS接入集群的落地配置

把NFS接入K8s主要有三步。第一步，在每个Worker节点安装nfs-common，保证内核支持NFS挂载。第二步，把NFS服务端的导出目录准备好，并设置好权限和no_root_squash，这一点很关键，否则Pod里以root运行的应用很可能在挂载目录上没写权限。第三步，在K8s中部署nfs-subdir-external-provisioner，用ServiceAccount授权，再创建上一节那样的StorageClass。

部署完provisioner后，我会再创建一个共享读写模式的PVC，挂载到两个不同副本的Pod里测试并发写入，确认确实是同一个NFS目录而不是意外各自创建了子目录。这个验证能提前暴露很多配置问题。

3.3 生产级分布式存储：Rook+Ceph

业务规模上来之后，多副本、自动修复、快照这些能力变得必不可少，这时候Ceph是生产环境的主流选择。Ceph可以把多台节点的磁盘聚合成一个存储池，从底层提供RBD块设备和CephFS文件系统两类接口。Rook则相当于把Ceph的部署和运维能力封装成了K8s Operator，让你可以通过CRD声明式地管理Ceph集群。

Rook部署Ceph的步骤概括起来是：安装Rook Operator、创建CephCluster CR、等待Monitor和OSD健康、再创建CephBlockPool或CephFilesystem、最后为它们创建StorageClass。这个过程中最容易踩坑的是磁盘配置和网络配置，Rook默认不会接管节点系统盘，只允许使用指定的存储设备，创建CephCluster之前一定要核对好节点上的磁盘和partition信息。

3.4 三副本与纠删码的容量账

Ceph的副本策略会直接影响可用容量，这个账必须算清楚。假设三个节点，每节点有2TB裸容量，总原始容量为6TB。如果选择三副本池，每个数据块会写三份，实际可用容量约为总原始容量的三分之一，也就是2TB。很多第一次规划Ceph的人看到这个折扣会非常难受，但这就是高可用的真实成本。

如果需要更高的空间利用率，可以用纠删码池，比如k=2、m=1的配置下，可用容量约为原始容量的k/(k+m)=2/3，也就是4TB。但纠删码的CPU开销偏高，重新构建速度也更慢，数据库这类低延迟业务不太适合。我的建议是，数据库等重型负载用三副本RBD，日志或冷数据用纠删码CephFS。

3.5 RBD与CephFS怎么选

这张选型表是我在项目中反复用到的参考：

一句话总结：需要单Pod独占、低延迟的用RBD；需要多Pod共享读写的，选CephFS。我刚才提过Spark集群搭建、Hadoop集群搭建这类大数据场景通常都要挂载共享存储，CephFS会比RBD顺手很多。

4. 集群故障转移与调度：存储层面的稳定性设计

4.1 节点故障时，Pod的存储为什么会卡死

集群调度保证了计算资源可以漂移，但存储资源不一定跟着漂。如果Pod使用local PV绑定在某台节点上，节点宕机后PV所在的路径也跟着不可用，Pod即使被重新调度到别的节点，也会发现绑定卷无法匹配，最终只能一直Pending。原因在于local PV的nodeAffinity把卷钉死在那台节点上。

想实现真正的有状态服务故障转移，底层存储必须支持跨节点访问。NFS和Ceph RBD天然满足这个条件，所以Redis Cluster、Kafka的Pod可以漂到其他节点重新挂载volume。这也是为什么我把存储抽象层做得越统一，集群调度越灵活的重要原因。

4.2 CSI的挂载生命周期：一次跨节点迁移的背后

当Pod从节点A迁移到节点B，存储控制器会走一段复杂的流程：先在节点A上执行Unpublish/unmount，再Detach卷；然后在节点B上Attach卷，接着Format并Mount到目标路径，最后启动容器里的Pod。整个过程的角色由kube-controller-manager、kubelet和CSI Driver协同完成。

生产环境里这个流程经常卡在节点异常场景。比如节点A被强制关机，K8s还想让这个节点上的volume正常Detach，但节点A的kubelet已经失联，于是节点B上同一个volume会报Multi-Attach错误。排查这类问题要看csi-attacher和csi-node的日志，必要时手动VolumeDetach清状态。对于这类故障，提前设计好存储后端的强制解挂能力比临时处理更可靠。

4.3 存储拓扑与调度策略：让数据靠近计算

跨可用区访问存储会带来额外延迟和带宽成本，生产环境的存储创建和Pod调度最好做拓扑对齐。StorageClass支持allowedTopologies字段，可以把PV创建范围限制在特定zone或rack内。配合volumeBindingMode的WaitForFirstConsumer，K8s会等Pod确定了调度节点，再在对应拓扑域创建PV，最大程度保证计算和存储靠近。

另外要注意，在有状态服务中使用topologySpreadConstraints或PodAntiAffinity时，不能只看Pod副本分布，还要把存储副本的分布考虑进去。Ceph的三副本如果落在同一节点，整个数据池的可靠性是虚假的。部署Ceph时最好把OSD分布在至少三个物理节点上，OSD数量也要保证奇数个Mon，否则脑裂时集群很容易进入不可用状态。

4.4 数据备份与恢复：不能只依赖高可用

高可用不等于数据安全。误操作、应用Bug、勒索攻击都可能让所有副本上的数据同时损坏，这时快照和备份就是最后一道防线。Ceph本身支持RBD快照，Rook还提供了VolumeSnapshot支持，可以在PVC级别做时间点快照。但快照仍然存储在同一个Ceph集群里，如果整个集群故障，快照也会丢失。

更稳妥的做法是定期把数据通过备份工具复制到独立的存储位置，比如Velero配合对象存储，或者用Restic对Pod数据卷做增量备份。我的习惯是，核心中间件每天全量备份、每小时增量，保留至少7天副本，并定期做恢复演练。只有真的还原成功过，才能算备份有效。

5. 常见问题与排查技巧实录

5.1 PVC一直Pending怎么查

这是运维群里问得最多的一个问题。排查步骤按顺序走很快能定位：

kubectl describe pvc <pvc-name> -n <namespace> kubectl get storageclass <sc-name> -o yaml kubectl logs -f -n <provisioner-namespace> -l app=nfs-provisioner

大部分Pending的根因都集中在几类：StorageClass不存在或provisioner名字写错、后端存储没有可用空间、存储后端网络不通、权限不足无法创建目录。PVC事件如果什么都没报，就去看provisioner的日志，很多底层错误只会出现在那里。我遇到过一次nfs-provisioner一直报权限问题，最后发现是NFS服务端的导出目录用了root_squash，把容器里的root用户都压成了nobody，改成no_root_squash后马上恢复。

5.2 PVC扩容后没有体现

PVC扩容成功不代表Pod里立刻能看到新容量。首先要确认StorageClass的allowVolumeExpansion是true，其次要保证存储后端本身支持在线扩容。前端只改PVC字段，K8s会调用CSI扩容接口，但很多后端需要Pod重启后重新挂载卷，扩容结果才真正反映到Pod文件系统里。

操作时务必先kubectl edit pvc修改storage字段，观察PV的Capacity是否跟随变化，然后滚动重启Pod。NFS作为后端时，如果目录本身是LVM或文件系统的扩展，不能只改NFS共享的大小，还需要在NFS服务端完成底层的resize流程。

5.3 挂载目录没有写权限

这个问题多发于NFS和CephFS。NFS挂载后没有写权限，多半是root_squash或者导出目录权限不足；CephFS则需要通过Rook的CephFilesystemSubVolumeGroup给PVC授权。Pod内应用的运行用户如果不是root，需要给PVC挂载目录设置正确的fsGroup，K8s会在挂载时尝试把卷所有权改成指定组。要注意，fsGroup的修改对已有大量文件的大卷有时会非常慢，因为K8s需要递归chown。

5.4 常见问题速查表

5.5 几个长期踩坑后的个人习惯

第一，绝对不要在测试集群里随手删除名字带有production字样的PVC。我吃过一次亏，一个Delete回收策略的PVC删下去，整个Redis实例的数据目录瞬间清空，后来才理解到回收策略和生产流程必须强绑定。

第二，给存储资源做好标签管理。我部署每个应用都会在PVC上打app、env、owner标签，比如app=redis-middleware、env=prod。集群PVC多起来之后，没有标签用kubectl get pvc列出几十条记录，完全无法快速定位业务归属。

第三，StorageClass的命名不要直接叫default，留给它一个带有业务含义的名字，比如nfs-shared、ceph-rbd-ssd。这能让每个团队在申请存储时快速理解底层能力，避免把高性能RBD和慢速NFS混用。

最后再分享一个小技巧：每次创建有状态服务前，先做一次存储选型小备忘，写下访问模式、副本因子、回收策略、是否需要快照，再动手写yaml。看起来多花几分钟，实际上能把后面几天的排障时间提前吃掉。