> 本文是写作规划，不是可发布正文。拆解对象：Rook + Ceph-CSI 在 Kubernetes 上的编排与挂载路径——以 Rook v1.20.4（2026-08；rook.io/docs/rook/v1.20/）与 Ceph-CSI v3.17.0 为主线，把一次 PVC 从 StorageClass / e…

本文讨论Rook/Ceph/CSI升级纪律，强调升级需遵循一次一个主版本、避免HEALTH_ERR强推、注意CSI Operator迁移和快照CRD错位。列出升级前检查清单和反模式，主张数据面升级人工审批，确保版本兼容和健康检查，防止跳版本导致故障。

该文章是一个关于Kubernetes存储编排的系列教程，重点介绍Rook与Ceph-CSI。内容涵盖CSI规范、Rook Operator、RBD/CephFS供给、快照克隆及升级闸门，共16篇。文章提供阅读路径和排障指南，帮助工程师理解PVC生命周期、故障定位及选型决策，强调在K8s环境中有效运维Rook-Ceph。

Rook是Ceph的Kubernetes Operator，通过CRD声明期望状态并调和出守护进程。核心CRD包括CephCluster、CephBlockPool等，v1.20起CSI调谐由Ceph-CSI Operator负责。Rook不管理RADOS内核语义，数据面问题需转向Ceph自身。排障时需明确对象归属、权威控制器及变更来源，避免误判。

本文介绍Rook Operator管理Ceph集群的生命周期：从CephCluster CR创建mon形成quorum，到mgr、OSD设备发现与部署，最后通过健康闸门验证HEALTH_OK。强调设备前置条件、dataDirHostPath清理、HEALTH_ERR时拒绝升级等关键运维纪律，并对比自动发现与显式设备清单的取舍，指出生产应偏向显式配置。

本文探讨Rook中对象存储与NFS的边界：CephObjectStore管理RGW网关生命周期，不涉及PVC语义；NFS CSI为实验特性，不支持升级，依赖CephFS而非RGW。强调区分协议，避免混淆排障，生产路径应选RBD/CephFS CSI，对象走RGW或外部S3。

本文介绍Rook/CSI在K8s上编排Ceph的可观测性方法，强调先选观测层再读字段语义。核心是区分K8s API、CSI sidecar、Ceph数据面等层级，指出csi_liveness仅表示插件存活，不保证供给成功；mgr指标绿不代表CSI健康。排障时需结合PVC Events、sidecar直方图、toolbox命令，避免误判，并建议值班仪表盘同时监控租户面、CSI面和RADOS面三类信号。

本文介绍Rook/CSI在K8s上运行Ceph的故障排查方法，提出六轴归因框架：PVC Pending、MountFailed、RBD特性静默失败、快照未就绪、升级卡住、mon端点/密钥错配。每轴按API、Sidecar、CSI、Rook、Ceph五层顺序排查，强调先选轴再操作，避免盲目重启集群，并给出跨轴并发时的优先级建议。

本文对比Rook+Ceph-CSI、云托管块CSI、Longhorn和裸Ceph四条存储路径，指出它们赢在不同前提：云CSI适合公有云纯块需求，Longhorn适合中小规模块副本，裸Ceph适合独立生命周期，Rook则适合需RADOS语义且用K8s声明式管理的场景。强调选型应基于机制差异而非延迟榜单，避免在公有云云盘上叠Rook等反模式。

本文为“Rook/CSI：K8s上的Ceph编排内核”系列终章，聚焦选型收束。通过排除树机制判断何时该用Rook，明确其甜区为私有云/裸金属需RADOS语义场景，苦区为公有云叠Rook等。关闭与ceph/18的续作边界，列出不该跑Rook的否证条件，并给出ADR友好收束建议，强调先排除再选择，附版本钉与开放问题。

> 本文是写作规划，不是可发布正文。拆解对象：Ceph RADOS 存储内核——以 Ceph Squid v19.2.5（2026-07；docs.ceph.com/en/squid/）为主线，把一次客户端写从 librados / Messenger 经 PG / PrimaryLogPG、BlueStore，到 r…

本文介绍Ceph RADOS存储内核系列首篇，定位为填补站内Ceph概览与工程细节间的缺口。文章提出五条坐标系（Map传播、通信、一致性、本地存储、接入代价）及三条不变量（本地放置、PG协商、Primary序列化），用于排障和深入理解。内容涵盖OSDMap epoch、PG peering、BlueStore等关键机制，并规划18篇阅读路线，强调以字段级锚点分析故障，而非依赖调参玄学。

本文介绍Ceph RADOS中MON/MGR与Map机制：MON用Paxos变体维护OSDMap等强一致状态，epoch递增触发增量传播；MGR聚合PGMap提供弱一致统计；客户端通过Objecter缓存map并透明追赶，epoch变化影响peering与可见性窗口，中心化架构在超大规模下存在瓶颈。

本文介绍Ceph OSD通信层架构：msgr2协议负责连接建立与帧传输，AsyncMessenger用epoll多路复用处理I/O，ShardedOpWQ按PG哈希分片调度操作。重点分析Op从TCP帧进入OSD队列的路径、心跳机制独立性，以及mClock调度器如何管理优先级，帮助定位通信层故障。

本文深入解析Ceph CRUSH机制细节：bucket类型影响迁移量，straw2最优；rule的step语法控制失败域，firstn用于副本、indep用于EC；weight三层体系（device weight、OSD reweight、primary_affinity）不可混用；CRUSH与一致性哈希根本差异在于显式失败域约束和中心化map传播。upmap作为二次修正，需权衡迁移字节与peering风暴。

本文介绍Ceph BlueStore架构，替代FileStore解决双写与目录元数据问题。核心组件包括BlockDevice（裸盘I/O）、BlueFS（RocksDB专用文件系统）、RocksDB（对象元数据存储）和Allocator（空闲空间管理）。BlueStore将数据直写裸盘，元数据存KV，支持校验和与压缩，但面临compaction带宽竞争和挂载延迟等挑战。

Ceph的ECBackend实现中，整条带写无需读旧数据，而部分写需读改写（RMW），增加延迟。EC修复从k个存活分片重建缺失分片，网络效率优于副本池。EC池空间效率高（4+2为1.5倍），但随机小写延迟高，适合顺序大写场景如RGW。allow_ec_overwrites支持覆盖写，但RMW代价仍在。编码插件有Jerasure、ISA-L等，LRC可降低重建读取。

CephFS将POSIX文件系统构建于RADOS之上，MDS作为可恢复状态机，通过journal持久化元数据。其核心挑战包括：MDS故障恢复、capability机制维持客户端缓存一致性、多active MDS的subtree迁移可能引发thrashing，以及fsync/stat操作的高网络往返成本。相比RBD，CephFS在元数据面（journal、caps、subtree、dirfrag）付出更高代价，快照需客户端协作，性能与一致性权衡复杂。

RGW是Ceph的S3/Swift对象网关，将HTTP请求映射到RADOS操作。核心机制包括：head/tail对象模型（小对象内联，大对象分条）、bucket index的OMAP存储与动态reshard、multipart上传的manifest引用、版本控制的delete marker、GC异步删除、多站点bi-log同步。主要瓶颈是bucket index的LIST性能与GC积压，S3 Select仅做RGW侧过滤，无法下推OSD。

本文介绍Ceph集群监控的关键指标与语义，强调“集群能写”不等于“集群健康”。文章详细解析ceph status、PG状态、OSD性能、Prometheus指标等字段含义，指出常见误判如active+degraded不等于数据丢失、均值掩盖尾延迟等，并提供容量规划与排障建议，帮助读者准确理解Ceph可观测性。