eBPF 基础测验
支持版本：Linux Kernel 4.18+, Kubernetes 1.25+ 最后更新：February 23, 2026
本测验测试你对 eBPF (extended Berkeley Packet Filter，扩展 Berkeley 数据包过滤器) 的整体理解，涵盖从基本概念到其在 Kubernetes 环境中的应用。
选择题
- eBPF verifier 不会检查什么？
- A) 没有无限循环
- B) 没有越界内存访问
- C) 程序执行速度
- D) 没有使用未初始化变量
查看答案
答案：C) 程序执行速度
解释： 为了确保程序安全，eBPF verifier 会检查没有无限循环（DAG 结构验证）、没有越界内存访问、没有使用未初始化变量、helper function 调用是否正确，以及程序是否保证终止。程序执行速度不是 verifier 的验证项目。
- 哪个 XDP (eXpress Data Path) 程序返回值会将数据包发回同一块 NIC？
- A) XDP_DROP
- B) XDP_PASS
- C) XDP_TX
- D) XDP_REDIRECT
查看答案
答案：C) XDP_TX
解释： XDP 程序返回值具有以下含义：
XDP_DROP：丢弃数据包XDP_PASS：传递给 kernel stackXDP_TX：将数据包返回到同一块 NICXDP_REDIRECT：转发到另一个接口XDP_ABORTED：错误处理
当你想将数据包发回接收它的网络接口时，会使用 XDP_TX。
- 哪一项不是 eBPF Maps 的主要作用？
- A) kernel 和 user space 之间的数据共享
- B) 状态存储
- C) 编译 eBPF 程序
- D) 事件数据传输
查看答案
答案：C) 编译 eBPF 程序
解释： eBPF maps 是用于在 kernel 和 user space 之间共享数据以及存储状态的数据结构。Maps 用于事件数据传输（PERF_EVENT_ARRAY、RINGBUF）、键值存储（HASH）、统计信息收集（PERCPU_ARRAY）等。编译 eBPF 程序由 Clang/LLVM 处理，不是 maps 的作用。
- 当 Cilium 替代 kube-proxy 时，eBPF 提供的主要优势是什么？
- A) 与 Service 数量成正比的 O(n) 性能
- B) 需要 iptables 规则评估
- C) 通过 map lookup 实现 O(1) 性能
- D) 使用 Netfilter
查看答案
答案：C) 通过 map lookup 实现 O(1) 性能
解释： 传统 kube-proxy（iptables 模式）会随着 Service 数量增加而出现 O(n) 性能下降。Cilium 使用 eBPF maps 提供恒定的 O(1) lookup 性能。这在连接建立时间、CPU 使用率和每秒连接数等各方面都显著提升了性能。
- bpftrace 的主要用途是什么？
- A) 将 eBPF 程序编译为 C
- B) 加载 kernel modules
- C) DTrace 风格的高级 tracing
- D) 构建 container images
查看答案
答案：C) DTrace 风格的高级 tracing
解释： bpftrace 是一种 DTrace 风格的高级 tracing 语言，可让你用简单的单行命令跟踪系统。例如，你可以轻松执行统计 system calls、跟踪每个进程读取的字节数、跟踪文件打开以及跟踪 TCP 连接等任务。
- 在 Tetragon 的 TracingPolicy 中，当检测到恶意文件访问时，哪个 action 会立即终止进程？
- A) action: Block
- B) action: Sigkill
- C) action: Deny
- D) action: Terminate
查看答案
答案：B) action: Sigkill
解释： 在 Tetragon 的 TracingPolicy 中，当发生与 policy 匹配的事件时，matchActions 中的 action: Sigkill 会使用 SIGKILL 信号立即终止进程。这用于实时阻止敏感文件访问或恶意网络连接。
- 哪一项不是 Hubble 的主要功能？
- A) 网络流量观察
- B) DNS 查询跟踪
- C) 编译 eBPF 程序
- D) Policy 决策监控
查看答案
答案：C) 编译 eBPF 程序
解释： Hubble 是内置于 Cilium 的网络可观测性平台，用于收集和监控网络 flows、DNS 查询、HTTP 请求、policy 决策等。Hubble 是可观测性工具，不提供 eBPF 程序编译功能。
- CO-RE (Compile Once, Run Everywhere) 解决了什么问题？
- A) 提高 eBPF 程序执行速度
- B) 跨不同 kernel 版本的可移植性
- C) 降低内存使用量
- D) 降低网络延迟
查看答案
答案：B) 跨不同 kernel 版本的可移植性
解释： CO-RE 使用 libbpf 和 BTF (BPF Type Format)，让编译一次的 eBPF 程序可以在各种 kernel 版本上运行。这减少了对 kernel header 的依赖，并自动处理 struct relocation，消除了针对每个 kernel 版本重新编译的需要。
- Falco 使用 eBPF 检测什么？
- A) 网络带宽使用量
- B) 运行时异常行为
- C) 磁盘容量
- D) CPU 温度
查看答案
答案：B) 运行时异常行为
解释： Falco 是一个 CNCF 项目，它使用 eBPF 检测运行时异常行为。它基于规则检测敏感文件读取、在 containers 中执行 shells、权限提升尝试等安全威胁，并发出告警。
- eBPF 程序的 stack size 限制是多少？
- A) 128 bytes
- B) 256 bytes
- C) 512 bytes
- D) 1024 bytes
查看答案
答案：C) 512 bytes
解释： eBPF 程序有 512 byte 的 stack size 限制。要绕过此限制，需要使用 PERCPU_ARRAY 等 maps 来分配更大的 buffers。此限制的存在是为了确保 kernel 安全。
简答题
- 将 eBPF bytecode 转换为 native machine code 的 compiler 名称是什么？
查看答案
答案：JIT compiler (Just-In-Time compiler)
解释： JIT compiler 将 eBPF bytecode 转换为 native machine code。与 interpreter 相比，这可提供 4-5 倍的性能提升，并应用特定于架构的优化。可以通过将 /proc/sys/net/core/bpf_jit_enable 设置为 1 来启用它。
- 动态跟踪 kernel function calls 的 eBPF program type 名称是什么？
查看答案
答案：Kprobes（或 Kprobe）
解释： Kprobes 是一种 eBPF program type，用于动态跟踪 kernel function calls。与跟踪 user space functions 的 Uprobes 不同，Kprobes 跟踪 kernel 内部的 functions。例如，你可以跟踪 tcp_connect function 来收集 TCP 连接信息。
- 内置于 Cilium 的网络可观测性平台名称是什么？
查看答案
答案：Hubble
解释： Hubble 是内置于 Cilium 的网络可观测性平台，可从 eBPF dataplane 收集数据，包括网络 flows、DNS 查询、HTTP 请求和 policy 决策。你可以通过 Hubble CLI、Hubble UI 和 Hubble Relay 实时观察 cluster 的网络流量。
- 加载 eBPF 程序需要哪种 Linux capability？（kernel 5.8 及以上）
查看答案
答案：CAP_BPF
解释： 在 kernel 5.8 及以上版本中，加载 eBPF 程序需要 CAP_BPF capability。在早期版本中，需要 CAP_SYS_ADMIN。此外，附加到 performance monitoring events 需要 CAP_PERFMON，附加 XDP/TC 程序需要 CAP_NET_ADMIN。
- 使用 eBPF 监控 container 能耗的 CNCF 项目名称是什么？
查看答案
答案：Kepler (Kubernetes-based Efficient Power Level Exporter)
解释： Kepler 是一个使用 eBPF 监控 container 能耗的项目。它提供 Prometheus 格式的指标，例如 kepler_container_joules_total（每个 container 的能耗）和 kepler_container_gpu_joules_total（GPU 能耗）。
动手实践题
- 编写使用 bpftool 列出当前加载在系统上的 eBPF 程序，并查询某个特定程序详细信息的命令。
查看答案
答案：
# List loaded eBPF programs
sudo bpftool prog list
# Query detailed information for a specific program (ID: 123)
sudo bpftool prog show id 123
# Dump program bytecode
sudo bpftool prog dump xlated id 123
# Dump JIT compiled code
sudo bpftool prog dump jited id 123解释：bpftool prog list 会显示当前已加载的所有 eBPF 程序列表。你可以查看每个程序的 ID、type、name、attachment location 等。使用 bpftool prog show id <ID> 查询特定程序的详细信息，并使用 dump xlated 和 dump jited 查看 bytecode 和 JIT 编译后的 native code。
- 编写一个 bpftrace 单行命令，用于实时跟踪系统上所有进程发生的 TCP 连接。
查看答案
答案：
# TCP connection tracing (Method 1: using kprobe)
sudo bpftrace -e 'kprobe:tcp_connect { printf("%s (PID: %d) connecting...\n", comm, pid); }'
# TCP connection tracing (Method 2: using tracepoint, more detailed info)
sudo bpftrace -e 'tracepoint:tcp:tcp_connect { printf("%s -> %s:%d\n", ntop(args->saddr), ntop(args->daddr), args->dport); }'
# Count TCP connections by process
sudo bpftrace -e 'kprobe:tcp_connect { @[comm] = count(); }'解释： bpftrace 是一种 DTrace 风格的高级 tracing 语言，可让你使用简单的单行命令跟踪系统。kprobe:tcp_connect 会在 kernel 的 tcp_connect function 被调用时触发。comm 表示进程名称，pid 表示进程 ID。使用 tracepoints 还可以获取源/目标 IP 地址和端口信息。
- 编写使用 Hubble CLI 仅观察来自特定 namespace 的 dropped packets 的命令。
查看答案
答案：
# Observe dropped packets in a specific namespace
hubble observe --namespace production --verdict DROPPED
# Observe dropped packets with real-time streaming
hubble observe --namespace production --verdict DROPPED -f
# Output detailed information of dropped packets in JSON format
hubble observe --namespace production --verdict DROPPED -o json
# Observe dropped packets from a specific Pod
hubble observe --from-pod production/frontend --verdict DROPPED解释： Hubble 是内置于 Cilium 的网络可观测性工具。--namespace 选项按特定 namespace 进行过滤，--verdict DROPPED 仅过滤 dropped packets。-f 选项提供实时 streaming，-o json 提供 JSON 格式输出。分析 dropped packets 有助于诊断 network policy 问题或配置错误。
高级题
- 说明 eBPF 相比 kernel modules 的三个主要优势，并具体描述每个优势在 Kubernetes 环境中带来的好处。
查看答案
答案：
相比 kernel modules，eBPF 的主要优势及其在 Kubernetes 环境中的好处：
1. 安全性（通过 verifier 保证安全）
- 优势：eBPF verifier 会在加载程序之前检查无限循环、内存访问违规、未初始化变量等，从而防止 kernel 崩溃。
- Kubernetes 好处：CNI plugins（Cilium）和安全工具（Tetragon、Falco）可以安全地在生产 clusters 中运行。与 kernel modules 不同，即使存在 bugs，整个系统也不会崩溃，从而保持高可用性。
2. 可移植性（通过 CO-RE 实现 kernel 版本独立）
- 优势：使用 CO-RE (Compile Once, Run Everywhere) 和 BTF，编译一次的 eBPF 程序可以在各种 kernel 版本上运行。无需针对每个 kernel 版本重新编译。
- Kubernetes 好处：相同的网络和安全解决方案可以部署到异构 node 环境中（具有不同 kernel 版本的 nodes）。在 cluster 升级或添加 node 时，兼容性问题会大幅减少。
3. 动态加载（无需 reboot 即可加载/卸载程序）
- 优势：eBPF 程序可以在不 reboot 系统的情况下动态加载和卸载。可以在 runtime 添加或更改功能。
- Kubernetes 好处：Network policies、安全规则和可观测性设置可以立即应用，而无需重启 nodes。对 Cilium NetworkPolicy 或 Tetragon TracingPolicy 的更改会实时反映，从而在不中断运维的情况下增强安全性。
其他优势：
- 性能：JIT 编译提供 native code 级别的性能，在替代 kube-proxy 时可实现 O(1) Service lookup。
- 开发难度：相较于 kernel module 开发更容易，可实现快速功能开发和部署。
- 设计一种方法，在 Kubernetes cluster 中使用基于 eBPF 的安全解决方案（Tetragon 或 Falco）检测并阻止 containers 内的敏感文件访问。请在说明中包含 TracingPolicy 或 Falco rule 示例。
查看答案
答案：
基于 eBPF 的敏感文件访问安全设计
1. 安全需求定义
- 检测目标：
/etc/shadow、/etc/passwd、/etc/sudoers、/var/run/secrets/（Kubernetes secrets） - 响应方式：检测到时告警，严重情况下终止进程
2. Tetragon TracingPolicy 实现
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: sensitive-file-protection
spec:
kprobes:
# Monitor sensitive file opens
- call: security_file_open
syscall: false
args:
- index: 0
type: file
selectors:
# Detect and log Kubernetes secret access
- matchArgs:
- index: 0
operator: Prefix
values:
- /var/run/secrets/kubernetes.io/
matchActions:
- action: Post # Event logging
# Block system authentication file access
- matchArgs:
- index: 0
operator: Prefix
values:
- /etc/shadow
- /etc/sudoers
matchNamespaces:
- namespace: default
operator: In
matchActions:
- action: Sigkill # Immediately terminate process3. Falco Rules 实现
# /etc/falco/rules.d/sensitive-files.yaml
- rule: Read Kubernetes Secrets
desc: Detect reading of Kubernetes secret files in containers
condition: >
open_read and
container and
(fd.name startswith /var/run/secrets/kubernetes.io/ or
fd.name startswith /etc/shadow or
fd.name startswith /etc/sudoers) and
not proc.name in (kubelet, containerd)
output: >
Sensitive file access detected
(file=%fd.name user=%user.name process=%proc.name
container=%container.name namespace=%k8s.ns.name
pod=%k8s.pod.name)
priority: WARNING
tags: [security, filesystem]
- rule: Write to Sensitive System Files
desc: Detect writing to sensitive system files
condition: >
open_write and
container and
fd.name in (/etc/passwd, /etc/shadow, /etc/sudoers)
output: >
Attempt to modify sensitive file
(file=%fd.name user=%user.name process=%proc.name
container=%container.name)
priority: CRITICAL
tags: [security, filesystem]4. 部署和监控
# Install Tetragon and apply policy
helm install tetragon cilium/tetragon -n kube-system
kubectl apply -f sensitive-file-protection.yaml
# Monitor events
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon \
-c export-stdout -f | tetra getevents -o compact
# Install Falco (eBPF driver)
helm install falco falcosecurity/falco \
--namespace falco --create-namespace \
--set driver.kind=modern_ebpf
# Check Falco alerts
kubectl logs -n falco -l app.kubernetes.io/name=falco -f5. 架构说明
┌─────────────────────────────────────────────────┐
│ Kubernetes Cluster │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Application │ │ Application │ │
│ │ Pod │ │ Pod │ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ ┌────────▼──────────────────────▼────────┐ │
│ │ eBPF Layer │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Tetragon │ │ Falco │ │ │
│ │ │ TracingPol. │ │ Rules │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │
│ │ ▼ ▼ │ │
│ │ [File Access Event Capture] │ │
│ └────────────────────────────────────────┘ │
│ │ │
│ ┌───────────────────▼───────────────────┐ │
│ │ Security Response │ │
│ │ • Event logging (Post) │ │
│ │ • Process termination (Sigkill) │ │
│ │ • SIEM alert forwarding │ │
│ └───────────────────────────────────────┘ │
└─────────────────────────────────────────────────┘该设计利用 eBPF 的 kernel-level visibility，在无需修改应用程序的情况下，实时检测并响应敏感文件访问。