版本：v3&v6

ONES 常见场景故障处理-混沌测试

提示

本文基于混沌工程实践，针对 ONES v6.18.x（K3S HA + Longhorn）的集群环境，通过注入服务中断、网络延迟、资源耗尽等典型故障场景，系统性验证系统容错能力。测试结果已转化为可操作的运维知识库，为日常故障预处置提供现象级参考依据。

故障场景

1.实例异常退出模拟（宕机Crash、内存不足OOM、重启、长时间Crash掉线）

涉及组件	MTTR	业务整体影响比例	是否自愈	备注
access(网关)	≤5s	≤1% 几乎无感知	是	多副本故障转移
project-web	≤10s	≤1% 几乎无感知	是	多副本故障转移
wiki-web	≤10s	≤1% 几乎无感知	是	多副本故障转移
devops-api	≤10s	涉及功能不可用	是	单点编排，无故障转移，编排调度重建
oauth-api	≤5s	涉及功能不可用	是	单点编排，无故障转移，编排调度重建
project-api	≤5s	≤1% 几乎无感知	是	多副本故障转移
wiki-api	≤5s	≤1% 几乎无感知	是	多副本故障转移
wiz-editor-server	≤5s	≤1% 几乎无感知	是	多副本故障转移
wiz-convert	≤10s	涉及功能不可用	是	单点编排，无故障转移，编排调度重建
ones-platform-api	≤5s	涉及功能不可用	是	单点编排，无故障转移，编排调度重建
performance-api	≤5s	≤1% 几乎无感知	是	双副本故障转移
plugin-Runtime (某插件运行时)	≤10s	涉及功能不可用	是	单点编排，无故障转移，编排调度重建
kilob-sync	≤5s	涉及功能不可用	是	单点编排，无故障转移，编排调度重建
wiz-editor-gateway	≤10s	≤1% 几乎无感知	是	多副本故障转移
kafka-cdc-connect	≤10s	涉及功能不可用	是	单点编排，无故障转移，编排调度重建
ones-dkron	≤10s	涉及功能不可用	是	单点编排，无故障转移，编排调度重建
camunda-bpm	≤1m	涉及功能不可用	是	单点编排，无故障转移，编排调度重建，camunda-bpm在50s内才恢复正常
attachment-index	≤5s	涉及功能不可用	是	单点编排，无故障转移，编排调度重建
K3s-Server	-	业务不可用100%	是	严重单点故障，当NotReady标记后，驱逐涉及LongHorn instance-manager会连级触发严重不可用, 目前现有架构longhorn仅双节点无法保持业务恢复运行，恢复该节点，业务恢复

2.网络异常（掉线、掉包隔离）

涉及组件	MTTR	业务整体影响比例	是否自愈	备注
MySQL	≤15s	≤1% 几乎无感知	是	单主多从节点出现网络异常，当前系统绝大部分能够自愈，无需修改，考虑极端场景当主节点异常，出现脑裂，则手动完成选主
Redis	≤5s	≤1% 几乎无感知	是	单向断开主到从节点网络，模拟主从通信故障。从节点 Redis 实例能感知连接断开，并触发多次重连与完整同步过程（Full Resync)
Kafka	≤5s	≤1% 几乎无感知	是	Kafka HA 集群具备在 Broker 网络断链场景下的自恢复能力。系统可检测异常节点，自动进行 Leader 重选，并在节点恢复后自动完成副本同步，保障业务连续性和数据一致性
TiKV	≤30s	≤1% 几乎无感知	是	tikv-2 节点与其他节点失联，Raft 重选主，Leader 分布重新平衡；业务短暂秒级TPS波动影响，影响面较小
Clickhouse	≤5m	≤20% 存在业务功能感知	是	业务发生异常感知明显，并未长时间前端阻塞等待现象，出现部分功能业务影响现象（审计日志、报表、迭代概览等），各业务组件连接池clickhouse endpoint service异常，发生读写查询中断，审计(安全)操作日志未及时在clickhouse恢复后 5m内完成数据同步更新
devops-api	≤5s	涉及功能不可用	是	API Pod因单副本，注入网络中断无法提供外部服务，涉及该功能接口TPS下降以及不可用，极端场景建议扩展Ha多副本
oauth-api	≤10s	涉及功能不可用	是	整体故障注入测试影响达到预期。系统在网络波动情况下能够自动恢复，测试期间部分接口在故障期间出现异常，用户体验有明显感知，k8s异常未感知,异常未发生Crash（实例流量未摘除）建议优化业务逻辑以在Endpoint连接失败时直接Crash程序，可以进一步提高系统的容错能力
project-api	≤10s	≤10% 存在一定感知	是	当注入网络中断故障时，Project-API Pod无法连接到MySQL Kafka TIDB等中间件重试机制，过长时间才crash，前端部分请求响应500错误，流量未被及时摘除
wiki-api	≤5s	≤1% 几乎无感知	是	当注入网络中断故障时，Wiki-API Pod无法连接到MySQL Kafka TIDB等中间件，进程会产生Crash，K8S健康探针会有效摘除这部分实例流量，完成有效故障转移，不会导致进一步大面积异常
wiz-editor-server	≤5s	≤1% 几乎无感知	是	由于网络故障，中间件等Endpoint 连接均异常，wiz-editor-serveri进程有Crash存在，当服务重启时K8s健康探针结果为异常，能够及时感知Pod非健康状态，摘除Service服务Endpoint，后面请求均可以有效完成故障转移，不会造成更大面积影响,注入高丢包率故障时（30%-50%）接口调用时未明显发现请求异常现象, 上游Gateway探针工作正常，摘除丢包率较高实例Pod
ones-platform-api	≤10s	涉及功能不可用	是	单实例，在故障注入后，流量不会被摘除；建议优化业务逻辑以在Endpoint连接失败时直接Crash程序，可以进一步提高系统的容错能力
performance-api	≤10s	≤30% 存在一定感知	是	当注入网络中断故障时，performance-api Pod无法连接到Redis等中间件，进程不会产生Crash中断，K8S健康探针无法感知该异常，无法摘除这部分实例流量进行故障转移，会产生二分之一面积请求异常；建议优化业务逻辑以在Endpoint连接失败时直接Crash程序，可以进一步提高系统的容错能力
plugin-runtime-manager	≤1m	涉及功能不可用	是	当注入网络中断故障时，pluginRuntimeManager Pod无法连接到Platform-APi上游，进程会直接产生Crash中断，K8S健康探针能够感知该异常，已摘除这部分实例流量，由于单副本实例，无法进行故障转移，涉及该链路请求均异常,插件-安装-停用启用等生命周期管理能力均受到影响, 有概率触发无法自动恢复

3.磁盘满（读/写异常等）

涉及组件	MTTR	业务整体影响比例	是否自愈	备注
MySQL	-	业务不可用100%	否	本次磁盘填满注入后，主节点崩溃，未能故障转移成主从切换，业务受损。当前集群缺乏对节点存储层异常感知的容错能力
Redis	≤0s	≤0%	是	在此次 Redis 主节点磁盘满测试中，模拟 100% 磁盘占用。由于当前 Redis 实例未使用持久化存储卷RDB/AOF（PVC），注入行为未对服务造成实际影响，系统保持正常写入、同步与高可用状态
Kafka	≤10s	≤0%	是	Kafka HA 集群在单个 Broker 节点磁盘耗尽的情况下，仍可保障其他节点维持分区副本、完成写入与消费任务。Kafka 自动容错能力有效规避了单节点故障对整体服务可用性的影响
TiKV	≤10s	≤0%	是	TiKV-HA 集群在单节点资源争用导致 Leader 不可用的情况下，PD 能及时完成 Leader 自动调度，保持系统高可用与副本一致性
project-api	≤5s	≤20%	是	业务TPS响应状态在故障期间未产生全局大面积异常，由于仅业务附件读写异常，未直接产生进程Crash，也就不会重新调度故障转移，部分上传时异常是有概率调度到异常节点
wiki-api	≤5s	≤1% 几乎无感知	是	容器组在磁盘读写注入故障的情况下wiki功能，并未受到相关异常影响；，附件等链路非该组件直接完成读写操作
wiz-editor	≤5s	≤30%	是	注入磁盘满或读写故障，导致部分请求失败。当流量路由到受影响的Pod时，业务功能（如创建页面、附件读写）无法正常执行，返回错误状态码（如500）。 Kubernetes健康探针无法检测到业务磁盘附件满了或读写异常，因此受影响的Pod不会被自动驱逐或重新调度，导致流量仍然被路由到该Pod，进而影响业务功能
ones-platform-api	≤5s	涉及功能不可用	是	当注入磁盘故障时，Open-Platform-API Pod的磁盘卷 /data/ones/files 和 /data/plugin 读写操作失败，返回错误码 5 (Input/output error)，侧重点为插件工作数据目录。由于磁盘满或读写异常，现状为单副本实例，导致用户明显感知针对插件上传安装等操作请求失败，返回错误状态码，为预期表现，未主动因为该错误Crash； Kubernetes健康探针无法检测到业务磁盘附件满了或读写异常，因此受影响的Pod不会被自动驱逐或重新调度，导致流量仍然被路由到该Pod
performance-api	<0s	≤0%	是	当注入磁盘故障时，performance-api Pod的磁盘卷 /data/ones/files 读写操作失败，返回错误码 5 (Input/output error)，侧重点为报表数据展示读写功能是否正常。业务增删改查，未现异常表现，未返回错误状态码，未依赖存储路径
plugin-runtime（某插件）	<0s	≤0%	是	业务TPS响应状态在故障期间未产生明显异常，插件运行时、插件启动、插件停止、插件功能未出现异常影响，疑似该插件能力无依赖本地文件存储
minio(备份组件)	-	涉及功能不可用	是	MinIO对象存储Pod因磁盘满会导致部分备份任务失败，无法被主动感知，备份客户端返回错误
k3s worker节点	-	（长时掉线）业务不可用100%	是	节点能够正确触发 NodeHasDiskPressure 状态，并尝试回收临时存储空间，符合 Kubernetes 的资源压力处理机制。触发清理或GC策略，会带来严重风险，如污点拒绝Pods 调度、清理镜像 GC机制、驱逐 Pod、节点性能下降，甚至驱逐关键组件业务会导致整体业务不可用，引发为集群事故

4.异常离线失联

涉及组件	MTTR	业务整体影响比例	是否自愈	备注
Redis	<0s	≤0%	是	同时杀死三实例节点，数据非持久化会产生数据丢失，Redis在我们业务场景特点，可以接受数据丢失
Kafka(Zookeeper失联)	<0s	≤0%	是	Kafka HA 集群在 ZooKeeper 部分节点失联或隔离场景下，依然可以维持 ISR 收缩机制与 Leader 正常迁移机制。集群整体保持高可用，系统业务稳定，验证 Kafka 对 ZooKeeper 异常具备基础的容错能力
TiKV(一实例数据清空)	≤1% 几乎无感知	是	是	tikv-1节点数据清空，Leader 分布重新平衡，标记该节点不可用；业务TPS无影响，且重启不再恢复数据场景下无法自愈, 恢复数据文件后能够完成集群自愈
LongHorn	-	（长时掉线）业务不可用100%	是	LongHorn 高可用集群在模拟 instance-manager Pod 崩溃离线后，未能有效触发故障转移机制，导致业务层出现严重单点问题
HA服务器节点重启	-	（长时掉线）业务不可用100%	有概率需要干预	控制平面节点状态感知延迟、reboot重启 umount 阻塞及存储挂载失败导致业务连续性严重受损，未满足三节点高可用的设计目标。强制断电的潜在风险极大，需谨慎处理。后续应重点优化故障检测、存储挂载稳定性和业务容错能力，确保系统在节点异常时能保障业务持续稳定运行

5.负载资源跑高

涉及组件	MTTR	业务整体影响比例	是否自愈	备注
MySQL	<0s	≤1% 几乎无感知	是	在MySQL主实例注入15G内存压力及负载压力，并未出现明显性能下降及业务不可用中断情况，极端压力场景下会导致Crash OOM，尤为主实例会有切主表现，参考宕机用例
Redis	<0s	≤1% 几乎无感知	是	本次 Redis 高负载测试模拟主节点资源过高情况，通过 CPU + 内存压力注入j 较平时资源用量50%，并未观察到系统响应耗时明显增加、未触发 Sentinel 切换
Kafka	<0s	≤1% 几乎无感知	是	Kafka HA 集群具备在 Broker 内存耗尽场景下的自恢复能力。系统能检测 Broker 中断，触发分区重选 Leader，并在节点恢复后自动恢复副本同步，确保业务连续性和数据一致性
Coredns	<0s	（长时掉线）业务不可用100%	是	目标CoreDNS Pod被注入高负载压力故障，导致服务响应延迟增加，负载压力较高情况下可能触发OOM。由于当前HA CoreDNS为单副本部署，不存在故障转移机制，业务请求完全依赖于该单个CoreDNS实例，故出现服务发现异常，严重不可用现象，副本数扩容至三副本；如果有其他CoreDNS实例正常，业务请求将被重定向到健康的实例

6.其他类（IO跑高、DNS毒化）

涉及组件	MTTR	业务整体影响比例	是否自愈	备注
Coredns(响应毒化)	<5s	涉及域名不可用	是	由于CoreDNS为单副本部署，不存在故障转移机制，业务请求完全依赖于该单个CoreDNS实例，进行DNS毒化，故出现服务发现异常，严重不可用现象，属于预期表现
k3s worker节点（IO延迟）	<5s	≤1% 几乎无感知	是	kubelet API响应延迟增加，影响节点状态检测和Pod调度效率，如果IO指标及负载进一步加剧，将会标记Notready ，并进行负载资源驱逐会引发业务不可用问题

处理建议

1. K3s Server / Worker 节点故障

优先级: P0
描述:
- K3s Server或Worker节点在重启或长时间磁盘压力后触发NotReady状态，导致业务不可用，进行负载实例驱逐。
- 长时间磁盘压力等会导致节点标记为NotReady，进而触发LongHorn instance-manager级联故障，导致业务完全不可用 kubelet异常处理。
原因:
- 磁盘空间不足触发Kubernetes资源压力机制
- 节点重启后存储挂载失败、服务器reboot重启失败,因硬挂载未释放
- kubelet服务异常
- 空间不足镜像驱逐 K3S镜像被驱逐处置
能否自愈:
- 视异常原因，一般情况能够，极端场景如"磁盘空间不足"、"服务器重启失败" 等需要人工介入。
影响:
- 节点长时下线引起Longhorn级联故障，导致业务不可用。

解决方法:

立刻处理

如磁盘不足，登录到受影响的节点，清理不必要的文件和日志。

ssh <node_ip>
sudo rm -rf /var/log/xx
检查工作目录 `/var/lib/rancher/k3s/` 占用情况，如系统盘磁盘分配不合理，请完成迁移或采用软连接形式修复 [磁盘IO隔离](https://opsdoc.ones.cn/docs/common/centos-linux-fix#94-%E5%8D%95%E6%9C%BA%E5%A4%9A%E5%9D%97%E6%95%B0%E6%8D%AE%E7%A3%81%E7%9B%98io%E5%88%86%E7%A6%BB%E9%85%8D%E7%BD%AE) 。

重启受影响的节点，确保其恢复正常状态。
```
sudo systemctl restart k3s
sudo reboot
```
增加节点磁盘使用率和资源压力的监控告警，及时发现并处理类似问题。
调整节点的资源配置，确保有足够的磁盘空间和资源。

2. LongHorn 存储引擎故障

优先级: P0
描述:
- LongHorn存储引擎在instance-manager 节点实例Pod崩溃后，未能有效触发故障转移机制，导致业务层出现严重单点问题。
- 业务不可用，需要手动恢复节点才能恢复业务。
原因:
- LongHorn高可用集群在模拟instance-manager Pod崩溃后，未能触发故障转移机制。
能否自愈:
- 服务器自愈/重启成功/,极端场景需要人工介入。
影响:
- 业务完全不可用，相关引用RWX卷将被驱逐阻塞。
解决方法:
- 立刻处理
  - 手动删除异常的longhorn-system命名空间下异常Pod实例，让Kubernetes自动重新调度，恢复instance-manager share-manager Pod实例，恢复后再检查对应关联业务Pod PVC挂载状态。
    kubectl -n longhorn-system get po kubectl -n longhorn-system delete pod <pod_name>
  - 确认数据是否完整，如有必要，从备份中恢复数据。
  - 评估替换LongHorn 共享存储解决方案，考虑将关键业务数据迁移到S3对象存储，升级最新版本降低RWX共享存储依赖，或选择接入外置NFS Server（参考专项文档）。
  - 增加存储相关的监控告警，及时发现并处理类似问题。

3. ClickHouse 主节点故障

优先级: P2
描述:
- ClickHouse主节点异常后，无故障转移能力，导致部分接口受影响，业务部分功能不可用。
- 主节点实例发生异常后，业务部分接口受阻，如卡片概览、报表、审计日志等。
原因:
- 当前HA架构决定，主实例异常后，无故障转移能力。
能否自愈:
- 是，恢复主实例即可。
影响:
- 业务部分功能不可用，服务中断。
解决方法:
- 立刻处理
  - 手动恢复主节点，确保其恢复正常状态。
  - 业务侧实现真正的双写机制，确保主从节点数据一致性。
  - 增加ClickHouse相关的监控告警，及时发现并处理类似问题。

4. CoreDNS 单实例故障

优先级: P1
描述:
- CoreDNS单实例副本异常，导致集群级DNS失效，业务服务不可用。
- 由于该部署脚本等原因，CoreDNS为单副本部署，不存在故障转移机制，业务请求完全依赖于该单个CoreDNS实例。
原因:
- CoreDNS实例异常或被毒化，导致服务发现异常。
能否自愈:
- 是，恢复Pod实例，扩容至多副本。
影响:
- 整体业务服务不可用，可能导致服务中断。
解决方法:
- 立刻处理
  - 登录终端重启CoreDNS服务，观察状态。
    kubectl rollout restart deployment coredns -n kube-system
  - 将CoreDNS副本数扩容至多副本，提高容错能力。
    kubectl scale deployment coredns -n kube-system --replicas=3
  - 增加CoreDNS相关的监控告警，及时发现并处理类似问题。

5. MySQL 主节点故障

优先级: P0
描述:
- MySQL主节点宕机后，从节点能在25s内接管主，并保持数据一致，业务恢复快。
- 主节点宕机后，从节点接管主节点，业务恢复时间≤30s。
- 磁盘空间不足无法完成切主识别，请完成备份，评估扩容或迁移动作。
原因:
- 主节点实例宕机或网络异常。
能否自愈:
- 是，从节点会自动接管。
影响:
- 业务短暂不可用，但恢复时间较短。

解决方法:

视情况介入处理

确认是否能够自动切主完成，主从同步状态 MySQL实例是否工作存在异常的现象
是否出现资源紧缺的状态
配置相应监控告警服务
磁盘空间不足，请完成对应扩容或迁移动作
极端场景下手动完成切主

ones-ai-k8s.sh
# 一、切主操作：
bash script/mysql/status.sh ones # 主从角色同步状态
# 主库从 mysql-pod1 切换到 mysql-pod2
bash script/mysql/graceful-master-takeover.sh <namespace> <mysql-pod1> <mysql-pod2>
bash script/mysql/status.sh ones # 再次查看主从角色同步状态
# 尽量重启业务组件实例，确保连接池至新主库（避免客户端问题，数据丢失）

# 二、从库异常修复：
# 进入异常不同步的从库，例如（mysql-cluster-mysql-2），极端场景下需要完成LocalStorage卷下数据目录清理，或清理PVC
# 必须保证主库工作正常
# localstorage卷 cd /data/ones/ones-local-storage/mysql/ones/mysql-cluster-mysql-2
# 完成对应备份
kubectl -n ${ONESNAMESPACE} exec -it mysql-cluster-mysql-2 bash
cd /var/lib/mysql
rm -rf * # 建议使用mv替代
exit
# 删掉对应异常实例mysql Pod
kubectl -n ${ONESNAMESPACE} delete pod mysql-cluster-mysql-2

# 三、异常关闭/断电因素导致MySQL实例MyISAM表损毁，无法启动实例
# 参考修复文档：https://opsdoc.ones.cn/docs/common/fix-mysql

# 四、未存在主库，ROLE均为replica（由严重网络问题，集群orchestrator脑裂引发）
# 需要人工查询多个实例中GTID值作为判断,查询多个实例对应GTID
kubectl -n ones-ymh exec -it mysql-cluster-mysql-{0,1,2} -- mysql -uroot -p***** -e 'show master status\G';
# 移除落后的实例： 例：mysql-cluster-mysql-0 和 mysql-cluster-mysql-1
kubectl -n ones -c orchestrator exec -it mysql-operator-0 -- curl -s "http://localhost:3000/api/forget/mysql-cluster-mysql-0/3306"
kubectl -n ones -c orchestrator exec -it mysql-operator-0 -- curl -s "http://localhost:3000/api/forget/mysql-cluster-mysql-1/3306"
# 提升 mysql-cluster-mysql-2 为主库
kubectl -n ones -c orchestrator exec -it mysql-operator-0 -- curl -s "http://localhost:3000/api/force-master-failover/mysql-cluster-mysql-2/3306"

# 五、数据丢失损毁其他场景参考备份恢复，这里不再展开，极端场景联系ONES技术支持。

6. Redis 主节点故障

优先级: P0
描述:
- Redis主节点宕机后，Sentinel在容忍时间内完成主从切换，业务继续正常运行。
- 主节点宕机后，从节点接管主节点，业务恢复时间≤5s。
- 未进行数据快照持久化，当遇到极端场景，可以考虑同时清理三个实例，重建集群。
原因:
- 主节点宕机或网络异常。
能否自愈:
- 是，从节点会自动接管。
影响:
- 业务短暂不可用，但恢复时间较短。
解决方法:
- 立刻处理
  - 增加Redis主从状态的监控告警，及时发现并处理类似问题。
  - 确保Sentinel配置正确，减少恢复时间。

7. Kafka Broker 故障

优先级: P0
描述:
- Kafka HA集群能有效应对单节点Broker宕机故障，各分区Leader会被重新分配，系统具备较好的高可用能力和数据可靠性。
- 主节点宕机后，从节点接管主节点，业务恢复时间≤10s。
原因:
- 主节点宕机或网络异常。
能否自愈:
- 是，从节点会自动接管。
影响:
- 业务短暂不可用，但恢复时间较短。
解决方法:
- 立刻处理
  - 增加Kafka主从状态的监控告警，及时发现并处理类似问题。
  - 确保Kafka HA配置正确，减少恢复时间。

8. 因集群严重网络波动断网，或网络分区异常导致服务不可用

优先级: P1
描述:
- 网络中断导致部分业务API服务无法连接到中间件(MySQL/Redis/Kafka等)
- 服务进程未Crash但处于Hang或重试状态，流量未被及时摘除，由于网络故障不稳定等，会造成流量异常。
- 主要影响组件：oauth-api、project-api、ones-platform-api、performance-api
- 影响较为严重时会引发数据同步/分布式存储/MySQL等集群反复切主以及脑裂。
原因:
- 集群场景不稳定对于集群分布式系统是致命的，需要保证内网集群稳定性。
- 业务连接池未设置合理超时机制，或Crash机制
- Kubernetes健康检查配置不敏感，探针无法完全覆盖
- 单副本服务无故障转移能力
能否自愈:
- 部分可自愈，严重情况需人工介入
影响:
- 部分API请求失败(视情况影响面10%-30%)
- 用户体验明显感知

解决方法:

# 强制重启异常Pod
kubectl -n ones delete pod <pod_name> --force --grace-period=0

# 滚动重启Deployment（适用于多副本服务）
kubectl -n ones rollout restart deployment <deployment_name>

# 通过传统排查手段，检查网络连接状态，这里不展开，复杂场景需要抓包分析。
kubectl -n ones exec <pod_name> -- ping <middleware_service>

9. 磁盘空间耗尽导致服务异常（进程Hang住不Crash）

优先级: P0
描述:
- 磁盘空间耗尽导致服务异常但进程未Crash，Server流量流入。
- 业务表现为部分请求阻塞/失败（上传、写入类操作）可能某节点磁盘空间不足
- 主要影响组件：
  - MySQL（数据目录满）
  - MinIO（备份存储满）
  - 业务Pod（日志/附件目录满）
  - Longhorn（存储卷空间满）
  - k3s运行时 (工作目录空间满)
原因:
- 未配置磁盘空间监控告警
- 业务未实现磁盘空间检查机制，组件针对极端场景空间不足异常被吞没。
- Kubernetes无法感知磁盘满异常，通常探针无法识别此类问题
- 避免将备份服务同部署在该节点，备份服务建议独立磁盘
能否自愈:
- 不能，必须人工干预
影响:
- 可能只读，写操作持续失败（影响面100%）
- 可能导致数据丢失风险
- 因对应磁盘空间满，业务组件服务异常捕获原因未主动Crash无法摘除k8s流量

解决方法: 磁盘IO隔离

# 通用处理流程：

# 1. 定位问题磁盘
df -h # 如果网络磁盘会存在阻塞使用下面命令
df -hl

# 2. 根据组件类型选择清理扩容方案：
# localstorage? 云csi? longhorn? ceph? 进一步需要确认扩容是否支持动态resize 扩容需要安全停机操作。

# 3. 扩容后建议完成一次重启，或选择性重启业务服务
kubectl -n ones delete pod <pod_name> 
# 滚动重启Deployment（适用于多副本服务）
kubectl -n ones rollout restart deployment <deployment_name>

10. MinIO备份服务因磁盘满异常

优先级: P1
描述:
- MinIO存储空间耗尽导致备份任务失败
- 备份进程持续重试但无法完成，且无法被主动感知识别
- 备份客户端返回"disk full"等错误信息
- 可能伴随日志报错："write: no space left on device"
原因:
- 备份文件未设置自动清理的生命周期策略(清理过往长期持久化数据)
- 未配置存储空间使用率监控告警
- 备份文件增长速度超出预期
- 未及时扩容存储空间
能否自愈:
- 不能，必须人工干预
影响:
- 所有定时备份任务中断
- 数据恢复能力完全丧失
- 影响关联关键数据间隔备份
- 极端场景和业务服务同磁盘会造成业务不可用（清理后，参考问题9完成服务重启恢复业务）
解决方法:

# 1. 确认存储空间状态
kubectl -n [namespace] exec -it <minio_pod> -- df -h 
# 确认备份客户端日志，以及服务器磁盘占用情况

# 2. 紧急清理过期备份（保留最近日常备份）
# mysql过期备份删除
# 默认删除30天之前的备份
make delete-mysql-backup NAMESPACE=ones
# 紧急情况，删除7天之前的备份
make delete-mysql-backup NAMESPACE=ones BEFORE=7d

# 3. 检查备份服务客户端状态
make logs-mysql-xbackup NAMESPACE=ones

# 4. 配置自动清理策略（长期方案）

# 一、可以选择降低备份频率，配置清理生命周期
# 关键配置项说明（视情况调整）：
# mysqlXbackupcleanBackupMinAge: "180d" # 清理几天前的备份, 默认清除180天(6个月)前备份, 表达式 m|d|w|M|y 含义: minute|day|week|month|year
# clickhouseBackupCleanDaysMinAge: "60" # 清理几天前的备份, 这个60天是最近一次全量备份的60天前，假如最近一次全量备份是 2025-01-08, 那么实际清理的就是 2024-11-09 之前的备份
# mysqlXbackupCronAll: "0 20 3 * * SAT"  # 全量备份crontab。 对应 mysql_cron_all
# mysqlXbackupCronInc: "0 30 * * * *"  # 增量备份crontab。

# 二、推荐操作（完成对备份落地磁盘扩容，或迁移，避免与业务系统同一磁盘设备块以免影响业务使用）

# 三、可以选择针对minio落盘磁盘原数据进行存档压缩备份，再清理
# 注意事项：
# 清理前确保关键备份已另行保存
# 建议在业务低峰期执行清理操作
# 清理后需验证备份服务是否自动恢复
# 长期方案应配置存储空间扩容

ONES 常见场景故障处理-混沌测试

故障场景​

1.实例异常退出模拟（宕机Crash、内存不足OOM、重启、长时间Crash掉线）​

2.网络异常（掉线、掉包隔离）​

3.磁盘满（读/写 异常等）​

4.异常离线 失联​

5.负载资源跑高​

6.其他类（IO跑高、DNS毒化）​

处理建议​

1. K3s Server / Worker 节点故障​

2. LongHorn 存储引擎故障​

3. ClickHouse 主节点故障​

4. CoreDNS 单实例故障​

5. MySQL 主节点故障​

6. Redis 主节点故障​

7. Kafka Broker 故障​

8. 因集群严重网络波动断网，或网络分区异常导致服务不可用​

9. 磁盘空间耗尽导致服务异常（进程Hang住不Crash）​

10. MinIO备份服务因磁盘满异常​

故障场景

1.实例异常退出模拟（宕机Crash、内存不足OOM、重启、长时间Crash掉线）

2.网络异常（掉线、掉包隔离）

3.磁盘满（读/写异常等）

4.异常离线失联

5.负载资源跑高

6.其他类（IO跑高、DNS毒化）

处理建议

1. K3s Server / Worker 节点故障

2. LongHorn 存储引擎故障

3. ClickHouse 主节点故障

4. CoreDNS 单实例故障

5. MySQL 主节点故障

6. Redis 主节点故障

7. Kafka Broker 故障

8. 因集群严重网络波动断网，或网络分区异常导致服务不可用

9. 磁盘空间耗尽导致服务异常（进程Hang住不Crash）

10. MinIO备份服务因磁盘满异常