详细排查与操作全过程复盘以下是本次从GitLab 504到Ceph 存储清理的完整操作流程每一步均包含操作背景、具体命令、预期结果、实际结果及结论。阶段一问题感知与初步定位GitLab 504步骤 1确认 GitLab 服务异常操作用户反馈 GitLab GraphQL API 返回504 Gateway Timeout。命令用户侧curl -I https://gitlab.xxxxx.tech/api/graphql预期结果返回200 OK或200状态码。实际结果返回504 Gateway Timeout。结论后端服务GitLab Rails响应超时需要进一步检查内部组件。步骤 2检查 GitLab 相关 Pod 状态操作查看 GitLab 的webservicePod 健康状态。命令kubectl get pods -n gitlab | grep webservice预期结果webservicePod 状态应为Running且READY 1/1。实际结果Pod 状态为Running但READY 0/1Readiness Probe 失败。结论Pod 已启动但未就绪需要查看探针日志。步骤 3检查 Readiness Probe 失败原因操作查看 Pod 事件。命令kubectl describe pod webservice-pod-name -n gitlab预期结果事件显示探针成功或具体失败原因。实际结果事件显示Readiness probe failed: Get http://10.244.8.21:8080/-/readiness: context deadline exceeded (Client.Timeout exceeded while awaiting headers)。结论webservice容器自身响应超时可能是内部依赖如数据库不可用。步骤 4检查 GitLab 依赖的数据库操作查看 GitLab 配置中的数据库连接信息通常为gitlab-postgresql或共享数据库。命令kubectl get svc -n gitlab | grep postgres预期结果存在gitlab-postgresqlService。实际结果未发现独立的 GitLab 数据库进一步检查发现 GitLab 配置指向 Harbor 的数据库harbor-db-postgresql。结论GitLab 与 Harbor 共用数据库Harbor 数据库可能存在问题。阶段二深入 Harbor 数据库排查步骤 5检查 Harbor 数据库 Pod 状态操作查看harbor-db-postgresql-0Pod 状态。命令kubectl get pod -n kube-infrastructure harbor-db-postgresql-0预期结果状态Running且READY 1/1。实际结果状态Running但READY 0/1。结论PostgreSQL 容器未就绪可能未正常启动。步骤 6查看数据库容器日志操作查看harbor-db-postgresql-0容器的日志。命令kubectl logs -n kube-infrastructure harbor-db-postgresql-0预期结果显示 PostgreSQL 启动日志如database system is ready to accept connections。实际结果日志为空无任何输出。结论PostgreSQL 进程可能根本没有启动或输出被重定向。步骤 7尝试进入容器内部操作使用kubectl exec进入容器。命令kubectl exec -it -n kube-infrastructure harbor-db-postgresql-0 -- /bin/bash预期结果成功进入容器 shell。实际结果命令卡住或报错无法连接到容器。结论容器主进程未运行无法建立交互会话。步骤 8检查健康探针配置操作查看 Pod 的 Liveness/Readiness 探针配置。命令kubectl describe pod -n kube-infrastructure harbor-db-postgresql-0 | grep -A5 -B5 Liveness预期结果探针命令为pg_isready -h localhost -U ...。实际结果探针配置正确但持续失败。结论PostgreSQL 未响应问题可能在存储层。阶段三存储层问题定位步骤 9在节点上检查挂载点操作登录 Pod 所在节点k8s-worker-00查看 PVC 挂载情况。命令mount | grep harbor-db预期结果显示正确的挂载路径。实际结果挂载点存在路径为/var/lib/kubelet/pods/.../mount。结论存储已挂载但可能 I/O 异常。步骤 10尝试访问数据目录操作进入挂载点目录执行ls -la。命令cd /var/lib/kubelet/pods/.../mount ls -la预期结果列出数据目录内容如data、pg_wal等。实际结果ls -la命令卡死无响应。结论存储后端 I/O 阻塞可能存储设备不可用。步骤 11检查内核日志dmesg操作查看系统内核消息。命令dmesg | tail -30预期结果无异常 I/O 错误。实际结果频繁出现libceph: pool 13 is full or reached quota。结论Ceph 存储池ceph-blockpool-retainID 13已满导致所有写入操作阻塞。阶段四Ceph 存储诊断步骤 12进入 Rook 工具箱操作进入 Rook 提供的 Ceph 工具 Pod。命令kubectl exec -it -n rook-ceph rook-ceph-tools-xxx -- bash预期结果进入 bash shell。实际结果成功进入。结论可执行 Ceph 命令。步骤 13检查集群整体使用情况操作查看 Ceph 存储概览。命令ceph df预期结果显示各池使用率。实际结果RAW STORAGE: TOTAL 838 GiB, USED 796 GiB, AVAIL 42 GiB, %USED 94.99 ceph-blockpool-retain: USED 316 GiB, %USED 100.00, MAX AVAIL 0 B结论集群整体接近满94.99%且ceph-blockpool-retain池显示 100% 使用MAX AVAIL为 0。步骤 14检查池配额操作查看池配额设置。命令ceph osd pool get-quota ceph-blockpool-retain预期结果显示配额值。实际结果max objects: N/A, max bytes: N/A。结论未设置配额是物理空间用尽。步骤 15检查 full_ratio 阈值操作查看集群 full 阈值。命令ceph osd dump | grep -E full_ratio|nearfull_ratio预期结果显示阈值。实际结果full_ratio 0.95,nearfull_ratio 0.85。结论使用率达 94.99%接近 95%Ceph 拒绝写入操作。阶段五数据清理尝试初始失败步骤 16列出 RBD 镜像操作列出ceph-blockpool-retain池中的所有镜像。命令rbd ls -l --pool ceph-blockpool-retain预期结果显示镜像列表及大小。实际结果返回约 80 个镜像列表。结论存在大量可能废弃的镜像。步骤 17找出孤儿镜像操作将 Kubernetes PV 中的volumeHandle与 RBD 镜像名进行 UUID 比对。命令示例kubectl getpv-ojson|jq-r.items[] | .spec.csi.volumeHandle|seds/.*-\([^-]*\)-\([^-]*\)-\([^-]*\)-\([^-]*\)-\([^-]*\)$/\1-\2-\3-\4-\5//tmp/k8s_uuids.txt rbdls--poolceph-blockpool-retain|seds/^csi-vol-///tmp/ceph_uuids.txtcomm-23/tmp/ceph_uuids.txt /tmp/k8s_uuids.txt预期结果输出孤儿 UUID 列表。实际结果找到了数个体积较大的孤儿镜像包括疑似 Harbor 数据库的镜像。结论这些镜像没有 PV 引用理论上可以清理。步骤 18尝试删除一个孤儿镜像操作删除其中一个孤儿镜像如csi-vol-fd62458b-...。命令rbd rm --pool ceph-blockpool-retain csi-vol-fd62458b-...预期结果删除成功。实际结果报错(28) No space left on devicerbd rm失败。结论因存储池已满即使删除操作也需要写入元数据无法执行。阶段六临时解除写阻塞并完成清理步骤 19临时提高 full_ratio 阈值操作将 full_ratio 从 0.95 提升至 0.98允许写入操作含删除元数据。命令ceph osd set-full-ratio 0.98和ceph osd set-nearfull-ratio 0.90预期结果无报错。实际结果命令成功执行。结论集群暂时允许写入。步骤 20再次尝试删除镜像成功操作删除之前失败的镜像。命令rbd rm --pool ceph-blockpool-retain csi-vol-fd62458b-...预期结果删除成功。实际结果删除成功输出Removing image: 100% complete...。结论空间开始释放。步骤 21批量删除孤儿镜像操作陆续删除其他孤儿镜像包括 Harbor 数据库对应的镜像csi-vol-5979a964-...。命令重复rbd rm命令。预期结果所有孤儿镜像被删除。实际结果成功删除数个镜像释放约 30 GiB 空间。结论存储池使用率下降至 93% 左右恢复可用空间。步骤 22恢复 full_ratio 阈值操作将阈值恢复至默认值。命令ceph osd set-full-ratio 0.95和ceph osd set-nearfull-ratio 0.85预期结果无报错。实际结果成功恢复。结论集群安全阈值恢复。阶段七服务恢复验证步骤 23检查 Harbor 数据库 Pod操作观察harbor-db-postgresql-0Pod 状态。命令kubectl get pod -n kube-infrastructure harbor-db-postgresql-0 -w预期结果Pod 变为Running且READY 1/1。实际结果Pod 成功启动Readiness Probe 通过。结论PostgreSQL 正常初始化。步骤 24检查 Harbor 服务状态操作访问 Harbor UI 或检查相关 Pod。命令kubectl get pods -n kube-infrastructure | grep harbor预期结果所有 Harbor Pod 均就绪。实际结果Harbor 核心服务恢复。步骤 25检查 GitLab 服务操作查看 GitLabwebservicePod 状态。命令kubectl get pods -n gitlab | grep webservice预期结果Pod 状态Running且READY 1/1。实际结果Readiness Probe 成功。结论GitLab 恢复GraphQL API 正常响应。 总结整个故障源于 Ceph 存储池ceph-blockpool-retain使用率达到 95%触发 Ceph 的保护机制拒绝一切写入操作导致 Harbor 数据库无法启动进而连锁影响 GitLab。通过临时提高 full_ratio 阈值删除无用的孤儿镜像释放空间最终恢复所有服务。关键数据释放空间约 30 GiB删除孤儿镜像数量~8 个总耗时从开始到恢复约 3 小时后续建议建立存储容量监控告警阈值 80% 预警90% 严重定期清理孤儿 RBD 镜像考虑扩容 Ceph 集群梳理服务依赖避免共用数据库导致单点故障以上即为本次排查与操作的完整详细记录。如有遗漏或需要补充的环节请随时指出。