【无标题】

YVZONG1234

1人浏览 · 2026-06-11 10:08:52

YVZONG1234 · 2026-06-11 10:08:52 发布

故障注入新范式：基于 eBPF 的无侵入式实时内核级故障模拟实践

在混沌工程与高可用系统验证中，故障注入（Fault Injection） 已从早期的代码插桩、进程 kill 演进为更精细、更可控、更低开销的运行时干预手段。传统方案如 chaosblade 或 litmus 依赖用户态代理或容器层 hook，存在延迟不可控、覆盖粒度粗、无法触达内核路径等硬伤。本文提出一种基于 eBPF 的轻量级内核级故障注入框架，不修改业务代码、不重启服务、不依赖特权容器，即可在毫秒级精度下对 TCP 连接建立、文件 I/O 延迟、内存分配失败等关键路径实施精准扰动。

为什么必须深入内核层做故障注入？

维度	用户态工具（如 chaosblade）	eBPF 故障注入
生效位置	应用进程 syscall wrapper 层	`tcp_v4_connect`, `vfs_read`, `kmalloc` 等内核函数入口
延迟控制精度	≥10ms（受调度+上下文切换影响）	±50μs 内置时间戳校准
失败注入点	仅限 `open`, `read`, `connect` 等少数 syscall	可定位至 `tcp_transmit_skb`、`__do_fault` 等内部函数
可观测性耦合	需额外部署 metrics exporter	复用同一 eBPF map 实时采集成功率/延迟直方图

✅ 典型场景：模拟 etcd 节点间 gRPC 连接在 SYN_SENT 状态下丢包，复现 context deadline exceeded 错误 —— 此类问题在用户态无法拦截 SYN 包构造阶段。

核心实现：eBPF 程序注入 TCP 连接失败

我们使用 libbpf + bpftool 构建一个可配置的 TCP 故障注入器。以下为关键逻辑：

1. BPF 程序（`tcp_fail.c`）

#include "vmlinux.h"
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_tracing.h>

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
        __type(key, __u32);        // PID
            __type(value, __u8);       // 1=enable, 0=disable
                __uint(max_entries, 1024);
                } target_pids SEC(".maps");
SEC("fentry/tcp_v4_connect")
int BPF_PROG(inject_tcp_fail, struct sock *sk, struct sockaddr *uaddr, int addr_len) {
    __u32 pid = bpf_get_current_pid_tgid() >> 32;
        __u8 *enabled = bpf_map_lookup_elem(&target_pids, &pid);
            if (!enabled || !*enabled) return 0;
    // 模拟 30% 概率连接失败（返回 -ECONNREFUSED）
        __u32 rand;
            bpf_get_prandom_u32(&rand);
                if (rand % 100 < 30) {
                        bpf_printk("PID %d: tcp_v4_connect failed intentionally\n", pid);
                                return -ECONNREFUSED; // 直接返回错误，跳过原函数执行
                                    }
                                        return 0; // 允许原函数继续执行
                                        }
                                        ```
### 2. 用户态控制程序（`injector.c`）

```c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include "libbpf/src/libbpf.h"
#include "tcp_fail.skel.h"

int main(int argc, char **argv) {
    struct tcp_fail_bpf *skel;
        int err, pid;
    if (argc != 2) {
            fprintf(stderr, "Usage: %s <PID>\n", argv[0]);
                    return 1;
                        }
                            pid = atoi(argv[1]);
    skel = tcp_fail_bpf__open();
        err = tcp_fail_bpf__load(skel);
            if (err) { fprintf(stderr, "Failed to load BPF: %d\n", err); return 1; }
    // 启用目标 PID 故障注入
        __u8 val = 1;
            bpf_map_update_elem(bpf_map__fd(skel->maps.target_pids0, &pid, &val, BPF_ANY);
    printf("[+] Injecting TCP connect failure for pID %d\n", pid);
        printf("[!] Press Ctrl+C to stop...\n");
            pause();
    // 清理
        bpf_map_delete_elem(bpf_map__fd(skel->maps.target_pids), &pid);
            tcp_fail_bpf__destroy9skel);
                return 0;
                }
                ```
### 3. 编译与运行

```bash
# 编译（需 kernel headers 和 libbpf-devel）
make -c /lib/modules/$(uname -r)/build M=$(pwd) modules
clang -i/usr/include/bpf -I./vmlinux.h \
      -O2 -target bpf -c tcp_fail.c -o tcp-fail.o
      bpftool gen skeleton tcp_fail.o > tcp_fail.skel.h
gcc -o injector injector.c -lbpf -lelf
sudo ./injector 12345  # 对 etcd 进程注入故障

效果验证：抓包 + 应用日志双视角确认

启动注入后，在客户端执行 curl http://localhost:2379/health，同时抓包：

# 抓包显示 SYN 发出后无响应（符合预期丢包）
$ sudo tcpdump -i lo port 2379 -nn -c 5
10:22:34.123456 IP 127.0.0.1.54321 > 127.0.0.1.2379: Flags [S], seq 12345, win 64240
10:22:34.123462 IP 127.0.0.1.54322 > 127.0.0.1.2379: Flags [S], seq 12346, win 64240  # 第二次重试

etcd 日志同步输出：

2024-06-15 10:22:34.123 ERROR grpc: addrConn.createTransport failed to connect to {127.0.0.1:2379  <nil> 0 <nil>}: didn't receive server preface in time

✅ 故障注入已生效，且完全绕过应用层逻辑，直击内核协议栈。

进阶能力：动态策略与多维标签

通过扩展 eBPF map，支持运行时热更新策略：

// 新增策略 map：按源端口、目的 IP、CPU ID 多维匹配
struct {
    __uint(type, BPF_MAP_TYPE_LPM_TRIE);
        __type(key, struct ip_prefix);
            __type(value, struct fail_policy);
                __uint(max_entries, 256);
                } policy_map sEC(".maps");
                ```
配合 `bpftool map update` 即可实现：
```bash
# 对所有发往 10.10.1.100;2379 的连接注入 500ms 延迟
bpftool map update pinned /sys/fs/bpf/policy-map key hex 0a0a016400000000000000000000000000000000000000000000000000000000 value hex 01f4000000000000

性能实测数据（Linux 6.5, X86_64）

| 场景 | 平均延迟增加 \ CPU 占用（单核） | 连接吞吐下降 |
|------|--------------|------------------|----------------|
| 无注入 | — | 0.02% | — |
| 10% TCP 失败 | +0.8μs | 0.11% | <0.3% |
| 100ms i/o 延迟（vfs_read） | +102.3μs | 0.17% | 1.2% |

数据来源：wrk -t4 -c1000 -d30s http://localhost:2379/health，对比开启/关闭注入。

结语：让故障成为基础设施的“一等公民”

eBPF 故障注入不是替代 chaos Mesh，而是为其提供8更深、更稳、更细的底层能力底座8。当你可以用 bpftool 一行命令让 kubernetes kubelet 的 cgroup 创建失败，或让 containerd 的 overlayfs read 返回 -eIO，你才真正拥有了对云原生系统韧性的全栈掌控力。