上个月帮一个朋友排查k8s集群的存储故障发现很多人对“文件存储”的理解还停留在挂NFS的层面——单点、无高可用、性能一上来就垮。后来我把三节点集群的共享目录切到Ceph文件存储CephFS上用最新版tentacle版本的Ceph作为k8s后端存储读写冲突和扩容问题才算真正解决。这篇博文就以tentacle版本为主线聊一下Ceph文件存储如何落地到k8s里解决多节点共享读写的问题顺带把部署、配置和踩坑的经验整理成可直接抄作业的操作。如果你正在做k8s存储选型或者手头集群需要一个稳定的后端存储这篇内容应该能帮你少走不少弯路。1. 为什么k8s后端存储要选Ceph而不是Longhorn、GlusterFS或NFS1.1 存储选型先看这四个硬指标我们平时说的“k8s后端存储”本质上是给Pod提供持久卷PV。PV的背后是一套存储系统它必须解决四个问题数据怎么放、数据怎么不丢、数据怎么扩展、数据怎么读写。第一个硬指标是接口类型。k8s的存储卷分成块存储、文件存储、对象存储三类对应的使用场景完全不一样。块存储RBD适合单Pod独占读写比如数据库文件存储CephFS适合多个Pod同时读写同一份数据比如日志聚合、媒体共享对象存储RGW适合海量非结构化数据比如备份归档。一个存储系统能把三种接口都提供出来这在选型时的优势是压倒性的。第二个是数据可靠性。k8s本身不解决数据持久化问题Pod删了重新调度数据还得在。Ceph靠多副本或者纠删码把数据分散到不同节点默认三副本能把坏磁盘、节点宕机这种风险消化掉。只要集群没超过故障域上限数据不会丢。第三个是扩展性。存储不能做到一半就卡在瓶颈上。Ceph的设计目标是水平扩展加节点、加磁盘就能扩大容量和性能不需要业务停机。对于k8s这种本身就冲着弹性去的平台存储也必须能跟着弹性走。第四个是自愈和运维成本。存储系统一旦上线运维动作越少越好。Ceph在节点故障后会自己做数据再平衡把副本补回来不需要人工介入。这块能力在工作日半夜特别值钱。这些硬指标组合在一起能同时满足的方案很少。这也是为什么很多k8s集群最终都选择了Ceph。1.2 各路方案横向对比差距全在细节上我接触过的k8s持久化方案里除了Ceph还有Longhorn、GlusterFS以及最原始的NFS。简单对比一下各自情况方案接口类型高可用方式动态供给性能特点运维复杂度Ceph块/文件/对象多副本/纠删码CSI驱动成熟万兆网络下表现优秀组件多前期学习成本高Longhorn块多副本CSI驱动简单小规模够用重负载一般轻量适合边缘/小集群GlusterFS文件复制卷heketi已停维护中等生态下滑明显组件相对简单NFS文件依赖外部HA方案需额外配置单点瓶颈突出部署快但别指望它扛生产Longhorn的优点是部署极简单对硬件要求低几百GB的小环境、边缘机房用起来很顺手。但它的副本机制是基于节点层同步的数据链路比Ceph长热点数据一旦上来性能就是短板。GlusterFS早年用得很多但heketi这个动态供给组件停止维护后很多团队不敢再往生产里放。它的文件接口在并发小文件场景下表现不如CephFS稳定。NFS就不用多说了。小规模验证可以生产环境最大的问题是没有内置高可用一个NFS节点挂了所有依赖它的Pod全部遭殃。你要是只在集群里跑几个无状态应用NFS勉强能用但数据库、消息队列这类有状态负载千万别硬上NFS。Ceph的问题只有一个组件多、概念多第一次搭容易懵。但一旦跑起来它给到的收益是最全面的。tentacle版本在稳定性和容器化适配上的进步让这个“难”又往下走了一步。2. tentacle版本到底带来哪些变化值不值得升级2.1 从Squid到Tentacle版本迭代的逻辑Ceph的版本代号一直按字母表顺序用海洋动物命名Squid之后就是Tentacle。如果你关注过Ceph的版本史会发现它的大版本分为两类一类是LTS长期支持版本比如Quincy、Reef适合生产环境钉住不动另一类是更新较快的开发主线版本功能新但需要你更频繁地跟进。tentacle20.x是在Squid基础上继续演进的版本。它的定位更偏“在稳定基础上做体验升级”而不是推倒重来。对我们用k8s存储的人来说最关心的不是它加了多少花哨功能而是它跟Rook Operator、CSI驱动的配合是否够顺。有一点务必注意如果你用Rook部署CephCeph版本和Rook版本不是脱钩的。Rook每个版本会声明支持的Ceph版本范围比如Rook v1.14、v1.15对Tentacle的兼容情况就不一样。升级Ceph之前先查Rook官方文档里的版本支持矩阵。我见过有人在旧版Rook里强行把Ceph镜像tag改成新版本结果OSD起不来、MON反复重启的例子。2.2 新版本里和k8s存储强相关的几处变化tentacle版本有几个变化对k8s后端存储影响比较直接。一个是容器化部署的适配更完善。Ceph的组件越来越多地通过cephadm管理容器环境里对存储、网络、PID namespace的处理比老版本更规范。这意味着用Rook拉起Ceph集群时组件之间互相等待、启动顺序导致的问题会减少。一个是性能优化。Ceph近几个版本持续在BlueStore存储引擎上做优化tentacle对高并发小文件的处理、OSD内存管理都有调整。在我自己的测试里CephFS处理小文件时的延迟抖动比Squid早期版本要平滑。还有一个是稳定性相关的默认行为变化。比如MON和MGR的看护逻辑更严格网络分区时不那么容易脑裂。对k8s这种存储容器本身也是跑在Pod里的场景节点网络抖动是常态这个改进很关键。当然也有需要适应的变化tentacle对内核版本、编译工具链的要求更高了。如果你手头的k8s节点还是老内核比如4.x早期版本跑最新版Ceph容器可能会遇到兼容性问题。所以别一上来就追新先确认节点内核、文件系统类型xfs还是ext4、网卡驱动这些底层环境是否达标。2.3 升级前一定要看的兼容性清单我建议升级到tentacle版本前把下面这几项列成清单逐项确认k8s版本建议1.26以上太老的k8s对CSI驱动的支持不完备。Rook版本确认你用的Rook版本支持Tentacle必要时同步升级Rook。节点内核至少5.x并确认xfs/ext4文件系统支持。CSI驱动版本配置里csi image tag要和Ceph版本匹配。数据备份升级前用cephfs snapshot或rbd mirror做一次完整数据验证。维护窗口Ceph升级是滚动操作MON和OSD会逐一重启务必留足时间窗。这些检查做完升级才谈得上“平稳”。我在生产环境里见过太多人跳过兼容性清单直接升级最后花周末两天回滚这个教训不小。3. 用Rook在k8s里部署Ceph tentacle完整实操记录3.1 环境准备节点、磁盘、网络、内核参数部署前先把环境准备扎实后面能省很多事。我用的是三节点集群每个节点一块独立的SSD充当OSD数据盘另外系统盘和数据盘分开绝不让Ceph的数据目录和k8s系统目录挤在同一块盘上。节点与磁盘规划3个k8s工作节点分别打上ceph-osd相关标签。每节点至少一块裸设备没有分区、没有文件系统用作OSD。如果条件允许给OSD节点配单独的万兆网卡数据流量不要和业务流量混跑。所有节点时间必须同步用chronyd或systemd-timesyncd都行。Ceph对时钟漂移极其敏感MON节点时钟跳变会引发大规模故障。内核参数Ceph容器运行时会消耗大量文件描述符和内存映射建议在节点上调整sysctl -w vm.max_map_count262144 sysctl -w fs.aio-max-nr1048576这些参数不调OSD容器在高负载下容易出现“out of memory”或者“Too many open files”的报错。Rook版本选择到Rook官方GitHub的release页面确认当前支持Tentacle的版本。不要选太新的beta版我习惯选最新的稳定patch版本例如v1.15.x。3.2 部署Rook Operator并创建Ceph集群Rook的部署方式很简单核心就是三个yamlcommon.yaml、operator.yaml、cluster.yaml。先去Rook仓库下载对应的部署文件然后在operator.yaml里把Ceph镜像改成你要用的tentacle版本ROOK_CEPH_IMAGE: quay.io/ceph/ceph:v20.0.0版本号按实际可用的tag填写如果用镜像仓库拉取不稳定建议提前推到自己的私有仓库。接下来是cluster.yaml这里有几个关键参数决定集群是否健康spec: dataDirHostPath: /var/lib/rook mon: count: 3 storage: storageClassDeviceSets: - name: set1 count: 3 resources: requests: storage: 200Gi volumeClaimTemplates: - metadata: name: data spec: resources: requests: storage: 200GidataDirHostPath是Rook存储配置数据的路径务必放在独立分区别和docker/containerd的数据目录混在一起。storageClassDeviceSets是Rook推荐的方式它通过PVC自动给OSD分配磁盘免去手工指定节点磁盘的麻烦。应用顺序如下kubectl create -f common.yaml kubectl create -f operator.yaml kubectl create -f cluster.yamloperator启动后会自动创建Ceph集群。你可以用下面命令观察状态kubectl -n rook-ceph get pods kubectl -n rook-ceph logs -l approok-ceph-operator正常情况下一两分钟能看到mon和mgr进入Running状态OSD的prepare任务开始跑。这里常见的一个等待期是OSD的PVC还在创建和绑定耐心等几分钟别急着删Pod。3.3 集群验证与Dashboard开启Ceph集群起来后第一件事是进工具Pod验证健康状态。Rook会创建一个rook-ceph-tools的Deployment参考官方文档把它启用起来然后执行kubectl -n rook-ceph exec -it deploy/rook-ceph-tools -- bash ceph -s看到HEALTH_OK说明集群基本正常。如果显示HEALTH_WARN最常见原因是PG数量不均衡或者MON时钟偏差这在后面第5章细说。调试期建议开启Dashboard方便用浏览器看OSD状态、PG分布和性能曲线。Rook提供了一条简单的命令生成NodePort服务kubectl -n rook-ceph create route or nodePort我用的是NodePort方式kubectl -n rook-ceph get svc rook-ceph-mgr-dashboard然后把Service改成NodePort暴露。默认用户是admin密码从secret里取kubectl -n rook-ceph get secret rook-ceph-dashboard-password -o jsonpath{.data.password} | base64 -dDashboard里重点看三块OSD是否全up、PG状态是否为activeclean、容量是否均衡。这三项没有异常存储层才算是真正准备好。4. 配置CephFS文件存储打通PVC动态供给4.1 创建CephFS文件系统与存储池CephFS是Ceph的文件接口部分提供符合POSIX语义的共享文件系统。要把它接进k8s得先有一个文件系统实例包含数据池和元数据池。用Rook的CRD方式创建最简单。下面这个CephFilesystem会帮我们自动创建两个pool并启动MDS元数据服务apiVersion: ceph.rook.io/v1 kind: CephFilesystem metadata: name: cephfs-k8s namespace: rook-ceph spec: metadataPool: replicated: size: 3 dataPools: - name: data0 replicated: size: 3 metadataServer: activeCount: 2 activeStandby: truemetadataPool的副本数必须和数据池一样而且元数据池我建议强制三副本。元数据一旦损坏整个文件系统的目录结构、文件属性全部完蛋这不是省那点容量的时候。activeCount: 2意味着同时运行2个活跃MDS读多写多的场景下吞吐会更好activeStandby: true会额外起热备MDS主MDS挂掉时秒级切换。应用这个CRD后验证MDS是否正常kubectl -n rook-ceph get cephfilesystem kubectl -n rook-ceph get pods -l approok-ceph-mds4.2 编写StorageClass并挂载PVCCephFS就绪后创建一个StorageClass让k8s能动态给Pod分配文件存储。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: cephfs-storage provisioner: rook-ceph.cephfs.csi.ceph.com parameters: clusterID: rook-ceph fsName: cephfs-k8s pool: cephfs-k8s-data0 csi.storage.k8s.io/provisioner-secret-name: rook-csi-cephfs-provisioner csi.storage.k8s.io/provisioner-secret-namespace: rook-ceph csi.storage.k8s.io/controller-expand-secret-name: rook-csi-cephfs-provisioner csi.storage.k8s.io/controller-expand-secret-namespace: rook-ceph csi.storage.k8s.io/node-stage-secret-name: rook-csi-cephfs-node csi.storage.k8s.io/node-stage-secret-namespace: rook-ceph reclaimPolicy: Delete allowVolumeExpansion: truefsName要和上面创建的CephFilesystem名字一样pool填数据池名称。secret名称一般是Rook安装时自动创建好的不要随便改除非你有自定义需求。声明PVC时核心是accessModesapiVersion: v1 kind: PersistentVolumeClaim metadata: name: cephfs-pvc spec: accessModes: - ReadWriteMany storageClassName: cephfs-storage resources: requests: storage: 10GiReadWriteMany是文件存储的核心价值多个Pod可以同时挂载同一个PVC。这在RBD块存储上是做不到的。挂载到Deployment里volumes: - name: share-data persistentVolumeClaim: claimName: cephfs-pvc containers: - name: app image: nginx volumeMounts: - name: share-data mountPath: /data等Pod起来后去任意一个Pod里写点文件再到另一个Pod里看文件是共享的。这个验证通过说明CephFS已经真的打通了。4.3 CephFS和RBD怎么分工别一锅炖很多人拿到Ceph后就问是不是所有数据都放CephFS不是。块存储RBD适合单Pod独占的读写场景比如MySQL、PostgreSQL这种数据库实例。它走的是高带宽、低延迟的块设备路径性能比文件系统好。缺点是同一块卷同一时间只能被一个节点挂载不支持多Pod共享。文件存储CephFS适合多Pod并发读写的场景比如多个应用节点共享一个上传目录、日志收集多写者写入、静态资源统一存放。它牺牲了一部分性能上限换来了共享写入能力。对象存储RGW适合海量非结构化数据比如备份、图片、视频原始归档访问走S3协议完全不占k8s节点磁盘。我的建议是数据库用RBD应用间共享数据用CephFS冷数据备份用RGW。三种接口各有适用边界硬把数据库跑在CephFS上、或者把共享目录塞进RBD单节点挂载都会在容量或性能上付出代价。5. 生产环境实战问题排查与性能调优5.1 部署期高频故障从OSD准备失败到MON起不来部署阶段最容易翻车的地方一个是OSD一个是MON。OSD prepare失败现象是rook-ceph-osd-prepare这个Job状态失败。90%的原因是磁盘没有清理干净。节点上如果磁盘之前做过分区或者文件系统Rook会拒绝把它初始化。处理办法# 找到对应盘符后清掉所有分区 sudo sgdisk --zap-all /dev/sdX sudo dd if/dev/zero of/dev/sdX bs1M count100然后重启kubelet让Rook重新扫描。如果还失败看Job日志里是否有deviceFilter匹配错误——检查cluster.yaml里是不是把盘符写成了系统盘。MON起不来MON是Ceph的大脑起不来的原因集中在两类网络不通或者时间不同步。检查所有节点能否互通mon端口默认3300然后确认timedatectl status的偏差。Ceph对时间偏移容忍度极低超过50毫秒就可能报时钟偏移告警超过1秒基本起不来集群。如果MON起来的慢不要不停重启。先看日志里有没有clock skew字样如果有就去修时间而不是反复重启Pod。dashboard密码获取失败这个不是故障是使用问题。密码存在rook-ceph-dashboard-password这个secret里要用base64解码。不要试图重置密码重置反而容易把mgr的配置搞乱。5.2 运行期麻烦事HEALTH_WARN、慢请求、MDS抖动集群跑着跑着出现HEALTH_WARN最常见的两类PG不平衡、OSD down。PG不平衡常出现在加盘之后。新加入的OSD上PG数量少是正常的Ceph会逐渐回填。但如果你用的是自动调平可以在Dashboard里看OSD的PG分布图把明显超载的OSD手动调整或者等回填完成。这里别急强制迁移PG很容易造成性能雪崩。OSD down之后核心是判断它是真宕机还是网络抖动。看对应OSD的日志如果是heartbeat timeout检查交换机端口、网卡丢包率ip -s link show eth0 netstat -iCephFS慢请求业务反馈文件写入卡顿进Dashboard看File System的延迟曲线。如果MDS延迟高多半是元数据池的性能跟不上。把MDS的日志级别临时调到debug观察是不是单目录文件太多导致锁竞争。实在不行给元数据池换到SSD、增加副本数或者拆目录。MDS抖动MDS频繁重启经常和内存限制有关。CephFS对元数据缓存占内存很敏感默认MDS容器内存上限不够时内核会杀MDS进程。把MDS的资源limits提高到2Gi以上再看存活时间。还有一个坑是CephFS根目录被业务疯狂创建小文件导致元数据增长不受控这种情况要在业务侧做治理存储侧只能不停加MDS。5.3 性能压测与调优的基本套路存储部署完压测是必须的。我习惯用fio在PVC里跑一轮明确性能和瓶颈。先创建一个大PVC挂到测试Pod里跑fiofio --namerandwrite --rwrandwrite --bs4k --size4G --numjobs8 --runtime60 --group_reporting重点看IOPS和时延。CephFS在4K小文件随机写的表现和底层硬盘、网络MTU关系最大。调优的几个方向网络确认k8s集群网络和Ceph存储网络隔离MTU设置到9000避免包碎片化。OSD内存每个OSD建议给4Gi以上内存蓝存储引擎的缓存设置直接在ceph.conf里调。PG数量PG不是越多越好。按公式估算PG数 OSD总数 × 100÷ 副本数再取最近的2的幂。三节点三副本的场景每节点1个OSDPG总数给128左右够用。快照策略CephFS支持subvolume快照但快照过多会占用元数据池空间定时快照最多保留7份别无限堆积。压测结果出来后要记录基线。存储毕竟是慢变量现在性能正常不代表半年后正常定期对比基线能提前发现硬件损耗或数据增长带来的变化。最后说点实在话关于Ceph和k8s的组合我踩过最大的坑就是“盲目追新”。版本不是越新越好关键是和Rook、CSI驱动、内核环境形成匹配。tentacle版本确实在文件存储的稳定性和容器化适配上有明显进步但如果你的集群还在老内核上跑硬上反而增加负担。我个人在实际操作中体会最深的一点是Ceph给k8s做后端存储文件存储CephFS的配置并不复杂复杂的是对它运行规律的理解——PG是否健康、MDS是否够用、网络是否夹带私货。把这三个基本功打扎实tentacle版本是能够稳定扛住生产压力的。如果你现在还在选型阶段我建议先拿一套三节点测试环境按这篇文章的步骤完整跑一遍再决定要不要上生产。存储系统这东西亲手操作一遍比看十篇文档都管用。