> For the complete documentation index, see [llms.txt](https://atomoh.gitbook.io/kubernetes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atomoh.gitbook.io/kubernetes/es/ce-yan-ji-he/quizzes/05-ebpf-fundamentals-quiz.md). # eBPF 基础与实践应用测验 > **支持版本**：Linux Kernel 4.18+, Kubernetes 1.25+ **最后更新**：February 23, 2026 本测验测试你对 eBPF (extended Berkeley Packet Filter，扩展 Berkeley 数据包过滤器) 的整体理解，涵盖从基本概念到其在 Kubernetes 环境中的应用。 ## 选择题 1. eBPF verifier 不会检查什么？ * A) 没有无限循环 * B) 没有越界内存访问 * C) 程序执行速度 * D) 没有使用未初始化变量
查看答案 **答案：C) 程序执行速度** **解释：** 为了确保程序安全，eBPF verifier 会检查没有无限循环（DAG 结构验证）、没有越界内存访问、没有使用未初始化变量、helper function 调用是否正确，以及程序是否保证终止。程序执行速度不是 verifier 的验证项目。
2. 哪个 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 stack * `XDP_TX`：将数据包返回到同一块 NIC * `XDP_REDIRECT`：转发到另一个接口 * `XDP_ABORTED`：错误处理 当你想将数据包发回接收它的网络接口时，会使用 XDP\_TX。
3. 哪一项不是 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 的作用。
4. 当 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 使用率和每秒连接数等各方面都显著提升了性能。
5. bpftrace 的主要用途是什么？ * A) 将 eBPF 程序编译为 C * B) 加载 kernel modules * C) DTrace 风格的高级 tracing * D) 构建 container images
查看答案 **答案：C) DTrace 风格的高级 tracing** **解释：** bpftrace 是一种 DTrace 风格的高级 tracing 语言，可让你用简单的单行命令跟踪系统。例如，你可以轻松执行统计 system calls、跟踪每个进程读取的字节数、跟踪文件打开以及跟踪 TCP 连接等任务。
6. 在 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 信号立即终止进程。这用于实时阻止敏感文件访问或恶意网络连接。
7. 哪一项不是 Hubble 的主要功能？ * A) 网络流量观察 * B) DNS 查询跟踪 * C) 编译 eBPF 程序 * D) Policy 决策监控
查看答案 **答案：C) 编译 eBPF 程序** **解释：** Hubble 是内置于 Cilium 的网络可观测性平台，用于收集和监控网络 flows、DNS 查询、HTTP 请求、policy 决策等。Hubble 是可观测性工具，不提供 eBPF 程序编译功能。
8. 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 版本重新编译的需要。
9. Falco 使用 eBPF 检测什么？ * A) 网络带宽使用量 * B) 运行时异常行为 * C) 磁盘容量 * D) CPU 温度
查看答案 **答案：B) 运行时异常行为** **解释：** Falco 是一个 CNCF 项目，它使用 eBPF 检测运行时异常行为。它基于规则检测敏感文件读取、在 containers 中执行 shells、权限提升尝试等安全威胁，并发出告警。
10. 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 安全。
## 简答题 11. 将 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 来启用它。
12. 动态跟踪 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 连接信息。
13. 内置于 Cilium 的网络可观测性平台名称是什么？
查看答案 **答案：Hubble** **解释：** Hubble 是内置于 Cilium 的网络可观测性平台，可从 eBPF dataplane 收集数据，包括网络 flows、DNS 查询、HTTP 请求和 policy 决策。你可以通过 Hubble CLI、Hubble UI 和 Hubble Relay 实时观察 cluster 的网络流量。
14. 加载 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`。
15. 使用 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 能耗）。
## 动手实践题 16. 编写使用 bpftool 列出当前加载在系统上的 eBPF 程序，并查询某个特定程序详细信息的命令。
查看答案 **答案：** ```bash # 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 ` 查询特定程序的详细信息，并使用 `dump xlated` 和 `dump jited` 查看 bytecode 和 JIT 编译后的 native code。
17. 编写一个 bpftrace 单行命令，用于实时跟踪系统上所有进程发生的 TCP 连接。
查看答案 **答案：** ```bash # 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 地址和端口信息。
18. 编写使用 Hubble CLI 仅观察来自特定 namespace 的 dropped packets 的命令。
查看答案 **答案：** ```bash # 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 问题或配置错误。
## 高级题 19. 说明 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 开发更容易，可实现快速功能开发和部署。
20. 设计一种方法，在 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 实现** ```yaml 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 process ``` **3. Falco Rules 实现** ```yaml # /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. 部署和监控** ```bash # 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 -f ``` **5. 架构说明** ``` ┌─────────────────────────────────────────────────┐ │ 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，在无需修改应用程序的情况下，实时检测并响应敏感文件访问。
*** [返回学习资料](/kubernetes/es/ji-chu/05-ebpf-fundamentals.md) | [下一测验：Container Technology](/kubernetes/es/ce-yan-ji-he/quizzes/03-container-technology-quiz.md)