实战：混沌工程入门，模拟服务器宕机的故障演练

核心提要

混沌工程是通过主动注入可控故障，验证系统韧性与故障自愈能力 的工程实践，核心目标是"在故障发生前发现系统脆弱点"。本次入门实战以模拟服务器宕机 为核心场景，基于Chaos Mesh（轻量级混沌工程工具）+ Kubernetes 技术栈，从环境准备、故障定义、演练执行、结果分析到复盘优化，完整覆盖混沌工程演练全流程，零基础掌握混沌工程核心操作，验证系统在服务器宕机后的服务可用性、流量切换、数据一致性能力，最终实现"发现脆弱点→优化系统→提升韧性"的目标。

本次实战为入门级 ，无需复杂的分布式系统基础，基于单节点K8s（Minikube）搭建演练环境，所有操作均提供可直接执行的命令，快速上手混沌工程核心思路。

一、混沌工程核心概念（入门必知）

📊 实战总览思维导图

快速把握本次混沌演练的全局结构：
混沌工程：模拟服务器宕机演练
🔍 前置认知
混沌工程核心原则
本次实验目标
🛠️ 环境准备
工具栈选型
Docker集群搭建
🧪 混沌实验
基础版：手动模拟宕机
专业版：ChaosBlade工具注入
📈 观测与分析
故障场景表现
系统脆弱点发现
✅ 恢复与优化
故障快速回滚
Nginx健康检查优化
优化后效果验证
📝 复盘与进阶
实验闭环总结
入门避坑指南
进阶场景拓展

1. 核心原则（5大核心原则）

定义稳态明确系统正常基准
提出假设预判故障下的系统表现
受控注入故障严格隔离影响范围
验证假设发现系统脆弱点
恢复与复盘优化系统并闭环

可控故障：仅在指定环境（测试/预发）注入故障，严格控制故障范围、持续时间，避免影响生产；
先定基准：明确系统正常运行的基准指标（如服务可用率99.9%、接口响应时间<500ms）；
假设驱动：先提出假设（如"服务器宕机后，服务可自动切换至备用节点，可用率保持99%以上"），再通过演练验证；
复盘优化：无论演练是否符合假设，均需复盘，针对脆弱点优化系统；
闭环迭代：将演练发现的问题、优化方案纳入迭代，持续提升系统韧性。

2. 本次演练核心目标

我们将搭建极简分布式架构，验证单服务器宕机后系统的容错能力，核心目标如下：
实验验证目标
负载均衡是否自动剔除故障节点
核心服务可用性是否保持100%
用户是否无感知故障发生

掌握混沌工程工具Chaos Mesh的基础部署与使用；
学会定义服务器宕机故障（节点级故障），实现可控注入；
验证目标应用在节点宕机后的服务可用性；
基于演练结果，分析系统脆弱点并给出基础优化建议。

3. 实验架构可视化

本次实战基于Docker搭建隔离环境，结合K8s与Chaos Mesh实现，简化版架构与流量走向如下：
K8s集群环境
宿主机环境（Minikube节点）
访问节点30080端口
轮询转发流量
轮询转发流量
注入宕机故障
用户/测试工具 curl/ab
Chaos Mesh故障注入工具
负载均衡 Ingress-Nginx
Web节点1 nginx-demo-1
Web节点2 nginx-demo-2

4. 技术栈选型

技术/工具	版本	核心作用	选择原因
Kubernetes	Minikube v1.32+	演练基础环境，运行目标应用与Chaos Mesh	轻量级，单节点即可部署，入门友好
Chaos Mesh	v2.5+	混沌工程核心工具，注入服务器宕机故障	专为K8s设计，支持节点/容器/网络等多种故障，操作简单，可视化界面
目标应用	Nginx + 简单Web服务	待验证韧性的测试应用	无业务依赖，易部署，可快速验证服务可用性
监控工具	Prometheus + Grafana	监控系统基准指标与故障期间指标	与K8s/Chaos Mesh无缝集成，直观查看指标变化
测试工具	curl/ab	验证服务可用性与接口响应	系统自带，无需额外部署

二、演练环境准备

1. 环境规划

节点类型	配置	核心组件	作用
K8s节点（Minikube）	2C4G（最低）/4C8G（推荐）	Minikube + Docker	运行目标应用、Chaos Mesh、监控工具
测试终端	任意	curl/ab	向目标应用发起请求，验证服务可用性
系统要求：Linux/macOS（Windows需开启WSL2），已安装Docker（Chaos Mesh与Minikube均基于Docker运行）。

2. 基础环境部署（一步到位命令）

（1）安装Minikube（单节点K8s）

Bash 复制代码

# 下载并安装Minikube（Linux/macOS通用）
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# 启动Minikube（分配2C4G资源，驱动为Docker，开启Ingress）
minikube start --cpus=2 --memory=4096 --driver=docker --addons=ingress

# 验证Minikube状态（显示Ready即为正常）
minikube status
kubectl get nodes

（2）安装Chaos Mesh（核心混沌工程工具）

使用官方脚本一键部署，自动适配Minikube环境：

Bash 复制代码

# 下载并执行Chaos Mesh安装脚本
curl -sSL https://mirrors.chaos-mesh.org/v2.5/install.sh | bash -s -- --namespace=chaos-mesh

# 验证Chaos Mesh部署状态（所有Pod均为Running即为正常）
kubectl get pods -n chaos-mesh -w

关键验证 ：出现 chaos-controller-manager、chaos-daemon、chaos-dashboard 三个Pod且状态为Running，说明部署成功。

（3）暴露Chaos Mesh可视化面板（Dashboard）

Bash 复制代码

# 端口转发，访问本地8080端口即可进入Dashboard
kubectl port-forward -n chaos-mesh svc/chaos-dashboard 8080:2333 --address 0.0.0.0

访问地址：http://服务器IP:8080，无需账号密码（入门环境），生产环境需配置认证。

（4）部署目标应用（Nginx Web服务，带多副本）

为了验证服务器宕机后的服务韧性 ，将目标应用部署为2个副本（模拟多实例部署），配置K8s Service暴露服务：

Bash 复制代码

# 创建目标应用命名空间
kubectl create namespace demo-app

# 部署Nginx应用（2个副本）
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo
  namespace: demo-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx
        image: nginx:1.25-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-demo-svc
  namespace: demo-app
spec:
  type: NodePort
  selector:
    app: nginx-demo
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080
EOF

# 验证应用部署状态（2个Pod为Running即为正常）
kubectl get pods -n demo-app

（5）验证目标应用正常访问

Bash 复制代码

# 获取Minikube节点IP
MINIKUBE_IP=$(minikube ip)

# 测试访问（返回Nginx默认页面即为正常）
curl http://$MINIKUBE_IP:30080

预期输出：Nginx的HTML默认页面，说明应用正常运行。

三、演练前置准备

1. 定义系统基准指标

在注入故障前，明确系统正常运行的基准指标，作为故障演练的对比依据：

指标类型	基准值	检测方式
服务可用率	100%	curl连续请求，无失败
接口响应时间	<100ms	curl -w 统计响应时间
应用Pod状态	2个Running，无重启	kubectl get pods -n demo-app
K8s节点状态	Ready，无异常	kubectl get nodes

2. 提出演练假设

本次演练核心假设：当运行目标应用的K8s节点发生宕机故障后，目标应用的服务可用率保持≥99%，接口响应时间仍<500ms，K8s可自动将Pod调度至健康节点（若有）。

3. 制定故障注入规则（可控故障核心）

为避免故障扩散，严格定义故障注入的范围、持续时间、恢复方式：

故障类型：节点级故障（服务器宕机），模拟K8s节点因硬件/网络故障完全不可用；
故障范围：仅针对Minikube的唯一节点（入门环境，单节点）；
持续时间：60秒（超时后Chaos Mesh自动恢复故障，无需人工干预）；
恢复方式：自动恢复（Chaos Mesh内置故障过期机制）+ 人工兜底（可通过Dashboard手动停止故障）；
演练环境：仅Minikube测试环境，无生产环境关联。

4. 启动指标监控（实时查看故障期间变化）

Bash 复制代码

# 实时监控应用Pod状态
kubectl get pods -n demo-app -w

# 新开终端，实时监控K8s节点状态
kubectl get nodes -w

# 新开终端，持续测试服务可用性（每2秒请求一次）
while true; do
  curl -o /dev/null -s -w "时间：%{time_now} 响应码：%{http_code} 响应时间：%{time_total}s\n" http://$MINIKUBE_IP:30080
  sleep 2
done

四、实战步骤：注入服务器宕机故障（两种方式）

实验全流程时序图

完整还原从环境搭建、故障注入到恢复优化的全流程时序：
Web2 Web1 Chaos Mesh工具 Web2（nginx-demo-2） Web1（nginx-demo-1） LB负载均衡（Ingress）测试工具工程师 Web2 Web1 Chaos Mesh工具 Web2（nginx-demo-2） Web1（nginx-demo-1） LB负载均衡（Ingress）测试工具工程师 🛠️ 阶段1：环境搭建与稳态验证 ✅ 确认稳态：请求成功率100%，流量轮询分配 🧪 阶段2：注入宕机故障 📈 阶段3：观测故障表现 ❌ 发现脆弱点：无健康检查导致部分请求失败 ✅ 阶段4：故障恢复与系统优化 ✅ 优化验证：服务可用性保持100% 📝 阶段5：复盘总结，完成闭环部署Nginx应用（2副本）部署Nginx应用（2副本）配置NodePort暴露服务多次发起请求转发请求转发请求返回Nginx默认页面返回Nginx默认页面配置节点宕机故障（持续60s）模拟服务器宕机，Pod状态异常持续发起请求尝试转发请求无响应/连接失败返回502错误转发请求返回Nginx默认页面故障自动恢复（60s后）配置存活/就绪探针（健康检查）再次模拟Web1宕机周期性健康探测探测失败将节点从集群中剔除转发全部流量全部请求正常返回

Chaos Mesh支持可视化界面（Dashboard） 和命令行（YAML） 两种故障注入方式，入门推荐使用可视化界面，操作更直观；命令行方式适合自动化演练，本次两种方式均实现。

方式1：可视化界面（Dashboard）注入故障（推荐）

步骤1：进入Chaos Mesh Dashboard

访问 http://服务器IP:8080，左侧导航栏选择混沌实验 → 点击新建实验。

步骤2：选择故障类型

实验范围：选择集群内；
故障类型：点击节点故障（对应服务器宕机）；
实验名称：自定义（如node-down-demo-01）；
实验描述：模拟Minikube节点宕机，验证Nginx服务韧性。

步骤3：配置故障参数（核心）

节点选择 ：选择Minikube的唯一节点（如minikube），仅对该节点注入故障；
故障动作 ：选择节点宕机（node-down）（模拟服务器完全不可用，节点状态变为NotReady）；
故障持续时间 ：填写60s（超时自动恢复，核心可控配置）；
高级配置：保持默认（入门无需修改）。

步骤4：提交实验并启动

点击提交 → 实验列表中找到新建的实验 → 点击启动，故障开始注入。

方式2：命令行（YAML）注入故障（适合自动化）

直接通过kubectl apply创建Chaos Mesh的故障资源，实现无界面故障注入：

Bash 复制代码

# 注入节点宕机故障，持续60秒
kubectl apply -f - <<EOF
apiVersion: chaos-mesh.org/v1alpha1
kind: NodeChaos
metadata:
  name: node-down-demo-01
  namespace: chaos-mesh
spec:
  action: node-down  # 故障类型：节点宕机
  mode: one  # 故障范围：单个节点
  selector:
    nodes:
      - minikube  # 目标节点（Minikube节点名）
  duration: 60s  # 故障持续时间
  scheduler:
    cron: "@once"  # 执行方式：立即执行一次
EOF

验证故障启动：

Bash 复制代码

# 查看故障状态（phase为Running即为注入成功）
kubectl get nodechaos -n chaos-mesh

五、故障期间：实时观察系统状态

故障注入后，观察之前启动的监控终端，记录核心现象（入门级典型现象）：

1. K8s节点状态变化

节点状态从Ready快速变为NotReady，表示服务器宕机故障注入成功。

2. 应用Pod状态变化

Pod状态从Running变为Unknown/NotReady，因为节点宕机，K8s无法监控Pod状态。

3. 服务可用性变化

单节点K8s环境下：服务暂时不可用（curl返回连接失败，响应码非200）；
多节点K8s环境下：K8s会将Pod自动调度至健康节点，服务中断时间极短（秒级），随后恢复可用。

4. 指标变化

接口响应时间：故障期间无响应（超时）；
服务可用率：故障期间降至0%；
故障恢复后：节点状态恢复Ready，Pod状态恢复Running，服务可用率回到100%。

六、故障恢复：自动+人工兜底

1. 自动恢复

故障持续时间（60s）结束后，Chaos Mesh会自动清理故障 ，节点状态从NotReady恢复为Ready，Pod状态也会随之恢复，服务自动恢复可用。

2. 人工兜底恢复（若自动恢复失败）

方式1：可视化界面停止故障

Dashboard → 混沌实验 → 找到对应实验 → 点击停止，故障立即恢复。

方式2：命令行删除故障资源

Bash 复制代码

# 删除节点宕机故障资源，立即恢复
kubectl delete nodechaos node-down-demo-01 -n chaos-mesh

# 验证节点状态恢复
kubectl get nodes

3. 验证故障完全恢复

Bash 复制代码

# 测试服务访问（返回Nginx页面即为恢复）
curl http://$MINIKUBE_IP:30080

# 验证Pod状态（2个Running）
kubectl get pods -n demo-app

七、演练结果分析与复盘

故障场景对比可视化

直观展示「有无健康检查」两种情况下，服务器宕机后的系统表现差异：
🟢 配置健康检查后
Web1服务器宕机
LB周期性执行健康探测
连续探测失败，将Web1从集群剔除
所有流量自动转发到正常节点Web2
服务可用性保持100%，用户无感知
🔴 未配置健康检查
Web1服务器宕机
LB仍按轮询规则转发流量到Web1
部分请求出现502错误
服务可用性下降，用户感知故障

1. 验证演练假设

本次演练为单节点K8s环境，核心假设验证结果：

❌ 服务可用率：故障期间降至0%，未达到≥99%的目标；
❌ 接口响应时间：故障期间无响应，超出<500ms的目标；
✅ 自动恢复：故障超时后，系统自动恢复至正常状态；
多节点K8s环境下：✅ 服务可用率可保持≥99%，Pod自动调度至健康节点。

2. 分析系统脆弱点（核心）

从演练结果中提炼系统韧性的脆弱点，这是混沌工程的核心价值：

单节点部署风险 ：目标应用与K8s节点强绑定，单节点宕机直接导致服务不可用（最核心脆弱点）；
无备用节点：未部署多节点K8s集群，K8s无法进行Pod调度和故障转移；
无服务发现/负载均衡：入门环境未配置专业的负载均衡器，单节点故障后无流量切换能力；
无健康检查兜底：虽K8s有自带健康检查，但单节点环境下无实际容错效果。

3. 针对性优化建议（入门级可落地）

针对以上脆弱点，给出低成本、可落地的优化方案，从根本上提升系统韧性：

部署多节点K8s集群：替换单节点Minikube为多节点K8s集群（如k3s/CKA），实现Pod跨节点调度，避免单节点故障导致服务不可用；
提升应用副本数 ：将应用副本数提升至3个及以上 ，并通过K8s的podAntiAffinity配置，让Pod分布在不同节点，实现"节点级容灾"；
配置专业负载均衡：使用Ingress-Nginx/Traefik作为负载均衡器，替代NodePort，实现流量的智能分发和故障节点隔离；
强化K8s健康检查 ：为应用配置存活探针（livenessProbe） 和就绪探针（readinessProbe），让K8s快速发现故障Pod并重启/剔除：

Bash 复制代码

# 为Nginx添加健康检查（更新Deployment）
kubectl patch deployment nginx-demo -n demo-app --type='json' -p '[
  {
    "op": "add",
    "path": "/spec/template/spec/containers/0/livenessProbe",
    "value": {
      "httpGet": {"path": "/", "port": 80},
      "initialDelaySeconds": 5,
      "periodSeconds": 10
    }
  },
  {
    "op": "add",
    "path": "/spec/template/spec/containers/0/readinessProbe",
    "value": {
      "httpGet": {"path": "/", "port": 80},
      "initialDelaySeconds": 5,
      "periodSeconds": 10
    }
  }
]'

配置资源限制 ：为应用Pod配置CPU/内存的请求（requests） 和限制（limits），避免单应用占用节点全部资源导致节点宕机。

4. 实验闭环总结

未配置健康检查，故障节点无法自动剔除
Nginx添加健康检查规则+多节点部署
单节点宕机后服务可用性100%
分布式架构需配套健康检查与容灾机制

八、进阶演练：扩展故障场景（入门后尝试）

掌握基础的服务器宕机演练后，可基于本次环境，扩展以下常见混沌工程故障场景，进一步验证系统韧性：

1. 容器级故障

模拟单个应用Pod宕机（而非整个服务器），验证K8s的Pod重启/重建能力：

故障类型：容器故障（container-kill）；
核心验证：Pod被杀死后，K8s是否自动重建Pod，服务是否无感知。

2. 网络故障

模拟服务器网络中断/延迟，验证系统的网络韧性：

故障类型：网络故障（network-partition/network-latency）；
核心验证：网络中断后，服务是否有降级策略，网络恢复后是否正常。

3. 资源耗尽故障

模拟服务器CPU/内存耗尽，验证应用的资源隔离能力：

故障类型：压力故障（stress-cpu/stress-memory）；
核心验证：单个应用资源耗尽后，是否影响其他应用，K8s是否触发资源限制。

4. 持久化存储故障

模拟服务器存储卷挂载失败，验证应用的数据一致性能力：

故障类型：存储故障（pod-failure）；
核心验证：存储故障后，应用是否有数据备份，恢复后数据是否一致。

九、混沌工程入门核心经验总结

可控是第一原则 ：入门阶段务必在独立测试环境（如Minikube）进行演练，严格控制故障范围和持续时间，避免影响生产；
先简后繁 ：从节点宕机/容器宕机等简单故障开始，掌握核心操作后，再尝试网络/存储/资源等复杂故障；
基准指标是基础：注入故障前必须明确系统正常的基准指标，否则无法判断演练结果，也无法发现脆弱点；
复盘比演练更重要 ：混沌工程的核心不是"注入故障"，而是通过演练发现脆弱点并优化，即使演练结果符合假设，也需复盘是否有优化空间；
工具只是手段 ：Chaos Mesh等工具是实现混沌工程的手段，核心是建立"主动发现故障"的思维，而非单纯使用工具；
循序渐进：不要一次性在复杂分布式系统中注入多个故障，入门阶段单故障、单节点、单应用即可，逐步提升演练复杂度。

十、常见问题排查（入门踩坑指南）

混沌工程入门避坑核心要点

❌ 禁止直接在生产环境开展入门实验

✅ 从隔离环境（本地/测试环境）开始

✅ 从小故障（单节点宕机）到复杂故障（网络分区、资源耗尽）逐步进阶

✅ 实验前必须明确故障回滚预案

✅ 配套监控工具，提升故障观测能力

1. Chaos Mesh部署后Pod状态为ImagePullBackOff

原因：镜像拉取失败，国内网络无法访问官方镜像；

解决：使用国内镜像源重新部署：

Bash 复制代码

# 卸载原有Chaos Mesh
curl -sSL https://mirrors.chaos-mesh.org/v2.5/uninstall.sh | bash -

# 使用国内镜像源部署
curl -sSL https://mirrors.chaos-mesh.org/v2.5/install.sh | bash -s -- --namespace=chaos-mesh --image-registry=registry.aliyuncs.com/chaos-mesh

2. 注入节点宕机故障后，节点状态未变为NotReady

原因：Minikube节点未开启特权模式，Chaos Mesh无权限修改节点状态；

解决：重新启动Minikube并开启特权模式：

Bash 复制代码

minikube stop && minikube delete
minikube start --cpus=2 --memory=4096 --driver=docker --addons=ingress --privileged

3. 故障恢复后，应用Pod仍为Unknown状态

原因：K8s节点缓存未刷新；

解决：手动重启应用Deployment：

Bash 复制代码

kubectl rollout restart deployment nginx-demo -n demo-app

4. Chaos Mesh Dashboard无法访问

原因：端口转发失败，或服务器防火墙未开放8080端口；

解决：

重新执行端口转发命令：kubectl port-forward -n chaos-mesh svc/chaos-dashboard 8080:2333 --address 0.0.0.0；
开放服务器8080端口：sudo ufw allow 8080（Linux）。

5. 注入故障后，服务未按预期恢复

原因：故障持续时间配置过长，或故障资源未被清理；

解决：

手动停止故障（Dashboard/命令行）；
检查故障资源是否残留：kubectl get nodechaos/podchaos -n chaos-mesh，残留则执行delete删除。

可视化内容扩展方案

若需提升文档可视化效果，可参考以下方式优化：

可视化类型	实现工具/方法
精美架构图	ProcessOn、Figma、Draw.io，可导出高清矢量图
流程动画	将Mermaid时序图导出为SVG，通过Canva、AE制作分步动画；或使用Mermaid Live Editor生成动态演示
数据报表	结合ab压测工具，用Excel、Grafana生成故障前后的请求成功率、响应时间对比报表
交互式文档	将内容导入Notion、语雀，实现图表与文字的联动交互