📚 课程目录第4章 eBPF技术概述

4. eBPF 技术概述：架构、程序类型与 K8s 典型应用

在深入节点池容量规划之前，必须理解 eBPF 的核心技术原理。eBPF 允许用户在 Linux 内核中安全、高效地运行沙箱化程序，无需修改内核源码或加载内核模块。它通过在内核事件（如系统调用、网络数据包、函数入口/出口）上挂载钩子，实现了对系统行为的可编程观测与控制。

eBPF 架构由三个核心组件构成，确保程序的安全性与高性能：

组件	功能描述	在 K8s 场景中的意义
eBPF 验证器	静态分析程序字节码，确保无死循环、无非法内存访问、无内核崩溃风险。	保障生产集群中运行的数据面程序不会影响节点稳定性。
eBPF 映射	键值存储结构，用于在内核态与用户态之间共享数据（如统计计数、配置规则）。	存储 Pod 网络策略、服务端点信息，实现低延迟数据交换。
辅助函数	内核提供的稳定 API 集合，eBPF 程序只能通过这些函数访问内核数据结构。	获取进程 PID、网络命名空间、cgroup 信息，用于识别容器上下文。

  关键设计原则： eBPF 程序必须通过验证器检查才能加载。验证器会模拟程序执行路径，拒绝任何可能超过指令数限制（当前为 100 万条）或存在循环的程序。这保证了即使程序逻辑有误，也不会导致内核死锁。

eBPF 程序类型决定了其挂载位置和可访问的上下文。在 Kubernetes 环境中，以下类型最为关键：

XDP (eXpress Data Path)： 在网络驱动层之前执行，用于 DDoS 防护、负载均衡、数据包过滤。延迟极低，适合节点池网络策略的早期丢弃。
TC (Traffic Control)： 在内核协议栈的 ingress/egress 路径上执行，用于容器网络策略、带宽管理、流量镜像。
Kprobe / Kretprobe： 动态插桩到任意内核函数入口/返回点，用于监控系统调用、文件操作、内存分配。在节点池中用于追踪 Pod 的资源使用模式。
Tracepoint： 静态定义的跟踪点，API 稳定，用于采集容器生命周期事件（创建、销毁、cgroup 变化）。
cgroup 相关类型： 挂载到 cgroup v2 上，用于控制 Pod 的 sysctl 设置、设备访问权限、套接字选项。

容量规划关联： 在节点池中，XDP 和 TC 程序直接影响网络吞吐量和延迟；Kprobe 程序用于采集 Pod 级别的 CPU/内存/IO 指标，是资源模型数据源的基础。

eBPF 正在重塑 K8s 的数据面与控制面。以下四个场景与节点池容量规划直接相关：

应用场景	eBPF 实现方式	对节点池资源的影响
容器网络 (CNI)	通过 TC 钩子实现 Pod 网络策略、Service 负载均衡（如 Cilium）。	减少 iptables 规则数量，降低 CPU 开销；但 eBPF 程序本身占用少量 CPU 和内存。
安全观测 (Runtime Security)	通过 Kprobe/Tracepoint 监控特权系统调用、文件访问、进程执行（如 Falco）。	高频率事件采集可能增加节点 CPU 负载，需规划采样率。
可观测性 (Observability)	通过 Kprobe 自动追踪 HTTP/gRPC 请求、数据库调用，生成分布式追踪数据。	数据采集和聚合会消耗内存和网络带宽，需评估存储与传输开销。
资源管理 (Resource Management)	通过 cgroup eBPF 程序实时统计 Pod 的 CPU 使用、内存分配、IO 延迟。	提供细粒度资源指标，支撑基于 Deployment 的容量模型校准。

容量规划警示： eBPF 程序虽然轻量，但并非零开销。每个挂载点都会引入微秒级的延迟。在节点池中部署过多或过于复杂的 eBPF 程序（尤其是高频 Kprobe），可能导致 CPU 占用上升 5%~15%。建议在规划阶段通过 bpftool 或 perf 工具测量基线开销。

eBPF 为基于 Deployment 的资源模型提供了两个关键能力：

精确的资源计量： 通过 cgroup eBPF 程序，可以实时获取每个 Pod 的 CPU 使用量、内存分配峰值、网络吞吐量，而非依赖 cgroup 的近似统计。这使资源模型的输入数据更准确。
动态策略执行： 当节点池资源紧张时，eBPF 程序可以动态调整网络限速、IO 优先级，甚至触发 Pod 驱逐决策，实现容量规划的闭环控制。