★ FEATURED ARTICLE 1. 项目概述为什么Ceph成了K8S存储方案里的“常驻主力”在某公司推进容器化平台升级的第三年运维团队终于把最后一套MySQL主从集群从物理机迁进了K8S。但上线不到48小时开发反馈“挂载PVC后写入延迟飙升批量导入卡在50%”。排查发现——底层用的是NFS而NFS在高并发小文件场景下元数据锁争用直接拖垮了整个StorageClass。这事儿让我想起去年在某高校实验室做存储架构咨询时遇到的类似问题他们用GlusterFS支撑AI训练任务结果GPU节点频繁报IO超时日志里全是stale file handle。两次事故背后是同一个现实K8S原生不带存储而随便塞个网络存储进去就像给F1赛车装拖拉机轮胎——能跑但根本发挥不出平台潜力。Ceph对接K8S说白了就是让K8S的PersistentVolume能真正“读懂”Ceph的分布式能力而不是把它当普通NAS使。它不是简单配个Secret、写个StorageClass就完事而是要打通三个层面控制面Rook或手动部署的Ceph-CSI驱动、数据面Ceph集群与K8S节点间的网络路径与权限、策略面如何把Ceph的Pool、PG、CRUSH规则映射成K8S里可调度、可隔离、可扩缩的存储资源。我试过用Helm一键部署Rook也手撸过Ceph-CSI的DaemonSet实测下来前者适合快速验证后者才能真正掌控每个Pod挂载时的rbd map参数和mount flags。尤其在混合工作负载场景下——比如一个命名空间里同时跑着日志采集高IOPS、模型训练大块顺序读、配置中心低延迟随机读——Ceph的RADOS层天然支持按应用特征划分Pool再通过K8S的StorageClass绑定不同CRUSH规则这才是它碾压其他方案的核心价值。如果你正被StatefulSet扩容慢、PV回收失败、跨AZ存储不可用这些问题反复折磨那这篇内容就是为你写的。它不讲Ceph原理课也不堆K8S YAML模板只聚焦一件事怎么让Ceph在K8S里真正“活”起来而不是当个摆设。2. 整体设计思路与方案选型逻辑2.1 为什么必须绕开“裸装Ceph 手动PV”这种老路五年前我接手的第一个K8S存储项目就是用传统方式先在三台物理机上搭好Ceph集群然后在K8S里手工创建几十个PersistentVolume对象每个PV对应一个RBD镜像。当时觉得挺稳——毕竟Ceph集群自己跑得好好的。但三个月后问题集中爆发开发提了个需求“给新服务分配100G高性能存储”我得登录Ceph节点执行rbd create --size 100G --image-feature layering poolname/image-xxx再回K8S里写PV YAML最后还得改StorageClass的provisioner字段指向自定义脚本某次Ceph OSD故障自动恢复时PG状态卡在peering但K8S里对应的PV状态还是Bound导致Pod死锁在ContainerCreating更致命的是权限失控所有PV共用一个CephX密钥一旦某个开发误删了Secret整个集群的存储访问全挂。这些不是操作失误而是架构缺陷。K8S的存储抽象核心是动态供给Dynamic Provisioning和声明式生命周期管理而手工PV违背了这两条铁律。Ceph本身是分布式的但手工PV把它降级成了“带网络的本地磁盘”彻底浪费了其多副本、自动重平衡、快照克隆的能力。所以现在所有生产环境我都强制要求走CSIContainer Storage Interface标准——它用标准化的gRPC接口把存储厂商的实现和K8S解耦Ceph-CSI就是这个标准下的“翻译官”。2.2 Rook vs 纯Ceph-CSI两种主流路径的硬核对比当前社区主要有两条技术路径选错一条后续维护成本翻倍维度Rook方案纯Ceph-CSI方案部署复杂度高需部署Operator、CephCluster CRD、监控栈首次启动耗时30分钟低仅需部署csi-nodeplugin、csi-provisioner等DaemonSet/Deployment5分钟内就绪Ceph版本控制强绑定Rook v1.12只支持Ceph Quincy17.2.x升级需同步更新Rook自由只要Ceph集群版本≥14.2.0NautilusCSI插件可独立升级故障域隔离内置Rook Operator能感知K8S Node Label自动将OSD调度到指定AZ/机架依赖外部需手动在Ceph集群配置CRUSH MapCSI层不参与拓扑感知调试难度极高问题可能出在Operator逻辑、CephCluster状态、CSI插件三者任一环节日志分散在多个Pod中等问题基本收敛在csi-provisioner日志供给逻辑和csi-nodeplugin日志挂载逻辑适用场景新建集群、需要全托管Ceph生命周期、运维人力充足已有Ceph集群、追求轻量可控、对Ceph底层有深度定制需求我去年在某金融客户落地时他们已有运行3年的Ceph Pacific集群且定制了专用的CRUSH规则按业务线分桶。如果强行上Rook就得迁移整个Ceph集群风险不可控。最终我们选了纯Ceph-CSI方案用Ansible脚本预生成各命名空间所需的CephX密钥再通过K8S Secret注入供给逻辑完全由csi-provisioner控制。实测下来单个PVC创建时间从手工模式的2分钟压缩到8秒且密钥轮换时只需更新SecretCSI会自动触发renew。提示别迷信“全托管”。Rook的Operator本质是个“智能胶水”它把Ceph的复杂性封装起来了但也让你失去了对底层的直接触达能力。就像汽车自动驾驶L3和L4的区别——L3要求驾驶员随时接管L4则完全放手。在存储这种关键路径上我更倾向L3用CSI保底必要时能SSH进Ceph节点调参。2.3 CSI插件版本与Ceph集群的兼容性陷阱这是踩坑最多的地方。Ceph-CSI官方文档写着“支持Ceph Nautilus及以上”但实际部署时版本匹配错一位就会触发静默失败。比如Ceph集群为16.2.13Octopus但用了cephcsi:v3.8.0插件 → 创建PVC时csi-provisioner日志显示failed to create rbd image: rbd: create failed: rbd: unknown option --image-feature因为v3.8.0默认用--image-feature layering,striping,exclusive-lock,object-map,fast-diff,deep-flatten而Octopus早期版本不支持fast-diffCeph集群为17.2.6Quincy却用了cephcsi:v3.5.0 → PVC状态卡在Pending查csi-provisioner日志发现failed to get ceph cluster info: rados: failed to connect to cluster原因是v3.5.0的librados库不兼容Quincy的认证协议。我的解决方案是建立版本矩阵表每次升级前必查# 查Ceph集群版本 ceph -v # 输出ceph version 17.2.6 (a5f9da9d1b1e3c1a1b2c3d4e5f6a7b8c9d0e1f2a) quincy (stable) # 查CSI插件推荐版本来自https://github.com/ceph/ceph-csi/releases # 17.2.x → 必须用 v3.9.0实操中我会在部署CSI前先在任意K8S节点执行rbd --version确认客户端版本再比对CSI镜像的Dockerfile里编译的librados版本。宁可多花10分钟验证也不愿半夜被PVC Pending告警叫醒。3. 核心细节解析与实操要点3.1 CephX密钥安全分发为什么不能共用admin密钥几乎所有初学者都会犯这个错把Ceph集群的client.admin密钥直接Base64编码后塞进K8S Secret然后让所有StorageClass都引用它。这相当于把银行金库的总钥匙发给每个柜员——表面省事实则灾难。风险具象化某天开发误操作删除了这个Secret所有PVC立即变为Lost状态Pod无法启动更隐蔽的是权限泛滥client.admin拥有集群全部权限包括osd blacklist、mon dump一旦Pod被入侵攻击者可直接黑进Ceph监控面K8S的RBAC对CephX密钥无效你无法用RoleBinding限制某个命名空间只能访问特定Pool。正确做法是按命名空间粒度生成最小权限密钥。以prod-db命名空间为例# 在Ceph集群节点执行 ceph auth get-or-create client.prod-db mon profile rbd osd profile rbd poolprod-db-pool -o /tmp/client.prod-db.keyring # 提取密钥并Base64编码 ceph auth get-key client.prod-db | base64 -w0 # 输出QVFESmJkZnVzY2xhZEFBQUFBSUJqTlJjM2pWZ0tZV2xuZGJyZ0FBRUFBQUFBQ0FBQXc9PQ然后在K8S中创建SecretapiVersion: v1 kind: Secret metadata: name: ceph-client-prod-db namespace: prod-db type: Opaque data: key: QVFESmJkZnVzY2xhZEFBQUFBSUJqTlJjM2pWZ0tZV2xuZGJyZ0FBRUFBQUFBQ0FBQXc9PQ关键点在于osd profile rbd poolprod-db-pool——它把权限严格限定在prod-db-pool这个Pool内。即使密钥泄露攻击者也无法访问dev-test-pool或其他敏感数据。我在某电商项目中曾为23个命名空间分别生成了独立密钥配合ArgoCD的GitOps流程密钥轮换时只需提交新Secret YAMLCI流水线自动完成滚动更新。注意profile rbd是Ceph内置的最小权限模板它等价于allow rwx poolpool-name。千万别手写allow *那是给自己埋雷。3.2 StorageClass的关键参数不只是填个pool名StorageClass看似简单但几个参数没配对就会让Ceph的分布式优势荡然无存apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ceph-rbd-prod provisioner: rbd.csi.ceph.com parameters: clusterID: a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8 # 必须与Ceph集群fsid一致 pool: prod-db-pool # 对应Ceph中的pool名 imageFormat: 2 # 必须为2否则不支持layering特性 imageFeatures: layering,striping,exclusive-lock # striping提升大文件吞吐exclusive-lock保障并发安全 csi.storage.k8s.io/provisioner-secret-name: ceph-client-prod-db csi.storage.k8s.io/provisioner-secret-namespace: prod-db csi.storage.k8s.io/node-stage-secret-name: ceph-client-prod-db csi.storage.k8s.io/node-stage-secret-namespace: prod-db reclaimPolicy: Retain # 关键Delete策略会导致rbd image被rm -f数据永久丢失 volumeBindingMode: Immediate参数深挖clusterID不是随便写的字符串必须是Ceph集群的fsidceph fsid命令输出。我见过最离谱的案例运维把clusterID写成my-ceph-cluster结果csi-provisioner连Ceph Monitor都连不上日志里只有connection refused排查了两天才发现是这个字段错了imageFormat: 2Ceph RBD镜像有v1和v2两种格式。v1不支持快照、克隆、分层而K8S的VolumeSnapshot功能强依赖v2的layering特性。如果这里写1创建PVC时csi-provisioner会静默降级但后续所有快照操作都失败reclaimPolicy: Retain这是血泪教训。K8S默认StorageClass的回收策略是Delete意味着PVC删除时会自动执行rbd rm pool/image-name。但在生产环境我们必须人工审核——比如数据库备份是否完成归档日志是否上传所以强制设为RetainPVC删除后PV进入Released状态管理员需手动执行rbd rm并记录审计日志。3.3 CRUSH规则与K8S拓扑的精准对齐Ceph的CRUSH算法决定了数据如何分布在OSD上而K8S的Topology Spread Constraints决定了Pod如何调度到Node。如果两者不协同就会出现“数据在A机房Pod在B机房”的跨AZ高延迟访问。假设你的Ceph集群按机架rack划分故障域CRUSH Map里有rule replicated_rule { ruleset 0 type replicated min_size 1 max_size 10 step take default step chooseleaf firstn 0 type rack step emit }那么在K8S中必须给Node打Label标记所属机架kubectl label node k8s-node-01 topology.kubernetes.io/zonerack-a kubectl label node k8s-node-02 topology.kubernetes.io/zonerack-b然后在StorageClass中启用拓扑感知parameters: # ... 其他参数 csi.storage.k8s.io/fstype: xfs # 启用拓扑感知让CSI插件根据Node Label选择对应rack的OSD csi.storage.k8s.io/node-publish-secret-name: ceph-client-prod-db csi.storage.k8s.io/node-publish-secret-namespace: prod-db更进一步在StatefulSet中声明拓扑约束spec: topologySpreadConstraints: - maxSkew: 1 topologyKey: topology.kubernetes.io/zone whenUnsatisfiable: DoNotSchedule labelSelector: matchLabels: app: mysql这样当K8S调度Pod到rack-a的Node时CSI插件会优先在rack-a的OSD上创建RBD镜像确保90%以上的IO都在本地机架内完成。我们在某视频平台测试过开启拓扑感知后4K视频转码任务的平均IO延迟从32ms降到8msSSD寿命延长了40%因跨机架网络IO减少。4. 实操过程与核心环节实现4.1 从零部署Ceph-CSI跳过Rook的极简路径以下步骤基于Ceph Quincy17.2.6和K8S v1.26全程无需Rook Operator所有YAML均可直接kubectl apply第一步准备Ceph集群访问凭证在Ceph集群节点生成专用密钥如3.1节所述并创建K8S Secret# 假设已获取client.prod-db的base64密钥 kubectl create secret generic ceph-client-prod-db \ --namespaceprod-db \ --from-literalkeyQVFESmJkZnVzY2xhZEFBQUFBSUJqTlJjM2pWZ0tZV2xuZGJyZ0FBRUFBQUFBQ0FBQXc9PQ \ --from-literalidentityclient.prod-db第二步部署CSI插件核心组件下载官方YAMLhttps://github.com/ceph/ceph-csi/releases/download/v3.9.0/cephfsplugin.yaml但需修改三处将namespace: default改为namespace: kube-systemK8S 1.26要求CSI插件在kube-system在csi-rbdpluginDaemonSet中添加hostPath卷挂载/dev和/sys必需否则rbd map失败volumeMounts: - name: dev mountPath: /dev - name: sys mountPath: /sys volumes: - name: dev hostPath: path: /dev - name: sys hostPath: path: /sys修改csi-rbdplugin-provisionerDeployment的args增加--feature-gatesTopologytrue启用拓扑感知。部署命令kubectl apply -f cephfsplugin.yaml # 包含rbd和cephfs插件 kubectl apply -f csi-config-map.yaml # 配置Ceph集群连接信息第三步创建StorageClass与PVC验证使用3.2节的StorageClass YAML然后创建测试PVCapiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-pvc namespace: prod-db spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: ceph-rbd-prod验证是否成功# 查看PVC状态 kubectl get pvc -n prod-db # 应显示Bound # 查看底层RBD镜像 ceph -s # 确认prod-db-pool中有新镜像 rbd ls prod-db-pool | grep test-pvc # 进入Pod验证挂载 kubectl exec -n prod-db deploy/test-app -- df -h /data # 输出应显示/dev/rbd0大小为10G关键检查点如果PVC卡在Pending立刻kubectl logs -n kube-system csi-rbdplugin-provisioner-xxx90%的问题出在csi-config-map.yaml里的monitors地址写错或clusterID不匹配如果Pod启动后df -h看不到挂载检查kubectl describe pod -n prod-db test-appEvent里会有FailedMount提示大概率是Node上缺少rbd命令需在所有Node安装ceph-common包。4.2 动态调整RBD镜像参数应对突发IO压力生产环境中经常遇到“计划外”的IO峰值。比如某天凌晨ETL任务突然增加原本100G的PVC出现IO饱和。这时不能重启Pod而要在线调整RBD镜像参数。实操步骤查找PVC对应的RBD镜像名kubectl get pvc -n prod-db test-pvc -o jsonpath{.spec.volumeName} # 输出pvc-12345678-9abc-def0-1234-567890abcdef # 对应Ceph镜像名kubernetes-dynamic-pvc-12345678-9abc-def0-1234-567890abcdef在Ceph节点执行在线调参无需停服# 增加stripe_count提升并发原为64调至256 rbd image-meta set prod-db-pool/kubernetes-dynamic-pvc-12345678-9abc-def0-1234-567890abcdef stripe_count 256 # 调整stripe_unit原为4M调至1M以适配小文件 rbd image-meta set prod-db-pool/kubernetes-dynamic-pvc-12345678-9abc-def0-1234-567890abcdef stripe_unit 1048576 # 启用fast-diff需Ceph Quincy rbd feature enable prod-db-pool/kubernetes-dynamic-pvc-12345678-9abc-def0-1234-567890abcdef fast-diff在K8S中触发重新挂载不中断业务# 删除PodK8S自动重建并重新挂载 kubectl delete pod -n prod-db -l apptest-app效果验证用iostat -x 1监控Node IO调整前await平均等待时间为120ms调整后降至22msrbd diff命令显示快照生成速度提升3倍。这个操作我每周在某风控系统执行一次因为他们的特征计算任务IO模式每天变化。实操心得rbd image-meta set是Ceph的隐藏神器但它只对v2格式镜像生效。执行前务必确认rbd info pool/image-name | grep format输出为2。另外stripe_count不是越大越好——超过OSD数量会导致部分OSD空转我们测试得出最优值是min(256, OSD总数*2)。4.3 多集群联邦存储跨K8S集群共享Ceph Pool某跨国企业要求上海集群的AI训练任务需实时读取旧金山集群产生的标注数据。传统方案是用rsync同步但延迟高、一致性差。我们用Ceph的多站点multisite能力CSI跨集群复用实现了毫秒级数据可见。架构要点两个Ceph集群shanghai、sanfrancisco配置为同一Realm下的不同Zone在上海K8S集群的StorageClass中parameters.pool指向sanfrancisco-data-pool该Pool在shanghai集群中以remote模式挂载CSI插件通过Ceph的rbd-mirror守护进程自动同步无需K8S干预。关键配置在上海Ceph集群中创建远程Pool# 在shanghai Ceph节点执行 ceph orch apply rgw shanghai-rgw --realmglobal-realm --zoneshanghai rbd mirror pool enable sanfrancisco-data-pool image rbd mirror pool peer add sanfrancisco-data-pool client.sanfranciscoglobal-realm http://sanfrancisco-rgw:8000然后在上海K8S的StorageClass中pool参数直接写sanfrancisco-data-poolCSI插件会自动识别这是远程Pool并通过RGW网关访问。实测上海Pod读取旧金山数据的延迟为18ms跨太平洋光纤比S3 API调用快4倍。这个方案的价值在于存储层统一应用层无感。开发不用改一行代码就能享受全球数据就近访问。当然它要求两个Ceph集群版本严格一致且RGW网关带宽足够——我们为此在上海-旧金山间单独拉了一条10Gbps专线。5. 常见问题与排查技巧实录5.1 PVC Pending的五大高频原因及速查表PVC卡在Pending是对接中最常见的问题以下是按发生概率排序的根因分析排查顺序现象检查命令解决方案1. CSI插件未就绪kubectl get pods -n kube-systemgrep csi显示CrashLoopBackOffkubectl logs -n kube-system csi-rbdplugin-xxx2. Ceph连接失败日志中出现failed to connect to cluster: rados: failed to connectceph -s --clusterceph --conf/etc/ceph/ceph.conf --keyring/etc/ceph/keyring检查csi-config-map.yaml中monitors地址是否可达telnet mon-ip 6789clusterID是否与ceph fsid一致3. 密钥权限不足日志显示permission denied或no such poolceph auth get client.prod-db确认密钥有osd profile rbd poolxxx权限且Pool真实存在ceph osd lspools | grep xxx4. 存储空间不足ceph -s显示HEALTH_WARNpgs有degradedceph df扩容OSD或清理旧镜像rbd trash list pool-name临时方案在StorageClass中加parameters.thickProvision: true避免thin-provisioning空间碎片5. CSI版本不兼容日志出现unknown option --image-feature或invalid argumentrbd --version和ceph version严格按2.3节版本矩阵表升级CSI插件切勿混用独家技巧当遇到疑难Pending时我习惯用kubectl get events -n kube-system --field-selector reasonProvisioningFailed快速定位最近一次失败事件比翻日志高效十倍。5.2 Pod挂载失败从Kernel日志追根溯源Pod卡在ContainerCreatingkubectl describe pod显示Unable to attach or mount volumes此时必须深入Node Kernel日志# 登录对应Node dmesg -T | tail -50 | grep -i rbd\|ceph # 常见输出 # [Wed Oct 12 10:23:45 2023] libceph: connect to 10.10.1.101:6789 failed: Connection refused # [Wed Oct 12 10:23:46 2023] rbd: image kubernetes-dynamic-pvc-xxx is not foundKernel级问题分类Connection refusedNode防火墙拦截了6789端口或Ceph Monitor服务宕机image not foundCSI插件创建镜像失败但未上报错误常见于Ceph集群满负荷时rbd create超时device busy上一个Pod未完全卸载rbd unmap残留执行rbd showmapped查看手动rbd unmap /dev/rbd0。我在某车企项目中曾遇到device busy持续15分钟原因是K8S的volume-attacher控制器异常未触发UnmountDevice。最终方案是在Node上部署systemd定时任务每5分钟扫描rbd showmapped自动清理超时30分钟的映射。5.3 性能瓶颈诊断三步定位IO卡点当应用抱怨“存储慢”时不要急着扩容先做三层诊断第一层K8S视角# 查看PVC的IO统计需K8S 1.26 kubectl top pvc -n prod-db # 检查PV的事件 kubectl describe pv pv-name # 关注Events中是否有VolumeResizeFailed或VolumeResizeInProgress第二层Ceph视角# 查看集群整体IO ceph -s # 关注ops和kb/s指标 # 定位慢Pool ceph osd pool stats prod-db-pool # 检查PG状态 ceph pg dump_pgs_brief \| grep -E (stale|inconsistent|degraded)第三层OSD节点视角# 查看OSD进程IO pidstat -d -p $(pgrep -f ceph-osd.*--id0) 1 5 # 检查磁盘健康 smartctl -a /dev/sdb \| grep -E (Reallocated_Sector|UDMA_CRC_Error_Count)经典案例某证券系统交易库PVC延迟飙升三层诊断发现K8S层kubectl top pvc显示1200 IOPS正常Ceph层ceph -s显示ops: 1500但prod-db-pool的read_lat高达200msOSD层pidstat显示OSD进程CPU 99%iostat显示%util100%smartctl发现磁盘Reallocated_Sector为23。结论某块SSD即将故障更换后延迟回归12ms。这说明存储性能问题80%出在硬件层而非配置层。5.4 数据安全兜底PVC误删后的黄金48小时reclaimPolicy: Retain虽防误删但总有疏忽。某次运维误删PVC后PV进入Released状态但rbd ls还能看到镜像。此时有48小时黄金窗口恢复步骤立即冻结镜像防止被自动清理rbd lock add prod-db-pool/kubernetes-dynamic-pvc-xxx client.frozen创建新PVC手动绑定到原PVapiVersion: v1 kind: PersistentVolumeClaim metadata: name: recovered-pvc namespace: prod-db spec: volumeName: pvc-xxx # 原PV名 storageClassName: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi验证数据完整性kubectl exec -n prod-db pod/recovered-app -- md5sum /data/file.txt # 与备份记录比对预防机制在Ceph集群启用rbd trashrbd trash move所有rbd rm操作先进回收站用Prometheus监控ceph_rbd_trash_objects指标0时触发告警每周自动执行rbd trash purge --keep-last 5保留最近5次删除。这个流程我在某银行实施过成功挽回了价值千万的交易流水数据。记住没有100%的安全只有48小时的响应窗口。6. 生产环境加固与长期运维建议6.1 监控体系不止看ceph -s的健康灯很多团队只监控ceph -s的HEALTH_OK但这是“伪健康”。真正的生产监控必须覆盖四层K8S层监控项kube_persistentvolumeclaim_status_phase{phasePending} 0 → 立即告警kubelet_volume_stats_used_bytes{namespaceprod-db}/kubelet_volume_stats_capacity_bytes 0.85 → 容量预警ceph_csi_provisioner_operations_total{operationcreate_volume, resultfailed}突增 → CSI插件异常。Ceph层监控项ceph_cluster_total_bytesvsceph_cluster_total_used_bytes→ 容量趋势ceph_osd_up{osd0} 0 → OSD宕机ceph_pool_read_bytes_total{poolprod-db-pool}/ceph_pool_write_bytes_total→ IO基线偏离。网络层监控项node_network_receive_bytes_total{devicebond0}→ 确认K8S Node到Ceph Monitor的带宽充足probe_success{jobceph-mon} 0 → Monitor服务不可达。硬件层监控项node_disk_io_time_seconds_total{devicesdb} 1000 → 磁盘IO饱和smartmon_device_smart_temperature_celsius{devicesdb} 60 → 温度过高。我用Grafana搭建了四层联动看板当ceph_osd_up告警时自动展开该OSD所在Node的node_disk_*指标5秒内定位是磁盘故障还是网络中断。这套监控体系上线后存储类故障平均修复时间MTTR从47分钟降至6分钟。6.2 升级策略如何零停机升级Ceph集群Ceph升级是运维噩梦但用对方法可实现无缝切换。以Octopus15.2.x升级到Quincy17.2.x为例分阶段策略预检阶段运行cephadm upgrade check确认所有OSD、MON、MGR兼容MON升级逐个滚动升级Monitorcephadm upgrade --image quay.io/ceph/ceph:v17.2.6每次升级后ceph -s确认quorum正常OSD升级按OSD所在机架分批每批不超过3个升级前ceph osd out osd.0升级后ceph osd in osd.0CSI插件升级在K8S中
阅读完成 · 觉得有帮助？
