原文链接#

InfoQ 这篇新闻总结的是 GitHub Engineering 在 2026 年 4 月发布的一篇文章。它讨论的不是常见的 eBPF 网络加速或可观测性案例，而是一个更偏平台工程的问题：部署系统本身会不会依赖它正在修复的系统。

这个角度挺有意思。我们平时谈 Cloud Native 的可靠性，经常会讲多副本、自动扩缩容、健康检查、Service Mesh、GitOps、回滚策略。但当系统真的进入故障态时，一个很实际的问题往往更朴素：修复系统的工具链还能不能工作。

GitHub 这次解决的是什么问题#

GitHub 的基本矛盾是一个典型的循环依赖：GitHub 的源码托管在 github.com 上，但 github.com 如果出现故障，修复它的部署动作又可能需要访问 github.com。

这个显性的循环依赖可以通过代码镜像和构建产物镜像缓解。真正麻烦的是部署脚本里的隐性依赖，比如：

  1. 直接依赖：部署脚本临时从 GitHub 下载某个 open source 工具。
  2. 隐藏依赖：机器上已有的工具启动时自动检查更新，背后访问了 GitHub。
  3. 传递依赖：部署脚本调用内部服务，内部服务再去 GitHub 拉取 release 或 binary。

这些依赖平时可能不容易看出来，因为所有服务都健康时它们只是一次普通的网络访问。等到事故发生，才发现部署链路需要依赖一个已经不可用的服务，于是修复动作被卡住，MTTR 被拉长。

GitHub 的做法不是要求每个团队手工审查脚本，而是把部署脚本放进单独的 cGroup，再用 eBPF 挂到这个 cGroup 的网络出口上。这样可以只观察和限制部署进程的 outbound network access，而不影响同一台 stateful host 上继续承载生产流量的其他进程。

这个方案里 eBPF 做了什么#

我理解这个方案里 eBPF 有四个关键作用。

第一，按进程边界做网络控制。GitHub 使用 BPF_PROG_TYPE_CGROUP_SKB 这类能力，把规则挂在特定 cGroup 的 egress 路径上。也就是说，它不是粗暴地封掉整台机器访问 github.com 的能力，而是只约束部署脚本这个执行环境。

第二，把 IP 规则推进到 DNS 语义。单纯按 IP blocklist 在大规模动态基础设施里很难维护。GitHub 用 BPF_PROG_TYPE_CGROUP_SOCK_ADDR 拦截 DNS 连接，把部署脚本的 DNS 查询导向本机 userspace DNS proxy，再由 proxy 根据域名规则决定是否允许。

第三，把被拦截的请求关联回具体命令。文章里提到他们把 DNS transaction ID 和 PID 写入 eBPF Map，之后 userspace proxy 可以根据 PID 读取 /proc/{PID}/cmdline，给出“哪个命令访问了哪个域名”的日志。这一点很实用，因为平台团队不只需要拦截，还需要把问题定位到团队能改的脚本或工具。

第四，顺手把部署脚本变成可审计的执行单元。有了 cGroup 后，不仅可以限制网络，也可以限制 CPU 和内存；有了 DNS proxy 和 eBPF Map 后，也能产出部署过程访问过哪些域名的审计列表。

一张简化图大概是这样：

flowchart LR A[Deploy Script] --> B[cGroup] B --> C[eBPF egress hook] C --> D{Network request} D -->|DNS| E[Local DNS proxy] E --> F{Domain policy} F -->|allow| G[Resolved target] F -->|block| H[Blocked log with PID and cmdline] D -->|other egress| I[Allow or deny by eBPF rule]

放到 Cloud Native 项目里，可以用 eBPF 做什么#

读完这篇文章后，我觉得 eBPF 在 Cloud Native 项目里的价值可以分成几类。

1. 部署安全：验证恢复链路有没有隐藏依赖#

这是 GitHub 这个案例给我的直接启发。

在 Kubernetes 项目里，类似问题通常会出现在 CI/CD runner、ArgoCD、Helm chart、Job、initContainer、数据库 migration、运维脚本里。它们可能在发布时访问：

  • GitHub、GitLab、artifact registry、container registry
  • 内部配置中心、Service Catalog、feature flag 服务
  • 证书、密钥、镜像、二进制工具下载地址
  • 某个只有主集群可用时才可访问的内部 API

平时这些访问都没问题，但在故障恢复时，它们可能变成恢复链路上的单点依赖。

我会把 GitHub 的思路迁移成两种模式：

  1. dry-run audit：部署任务正常运行，但记录所有 outbound domain、IP、PID、命令行、Pod、Namespace。
  2. failure-mode enforcement：对关键恢复脚本启用更严格的 allowlist，只允许访问镜像仓库镜像站、内部 artifact mirror、Kubernetes API 或明确登记过的基础设施服务。

这比在 runbook 里写“部署脚本不应该访问外部网络”更可靠，因为它能在运行时直接发现偏离。

2. 可观测性：少改业务代码地看见真实运行行为#

Cloud Native 项目经常有一个现实问题：服务很多，语言栈也不统一，想让所有服务都正确接入 metrics、tracing、logging，并不总是容易。

eBPF 的优势是可以从 kernel 层观察网络、系统调用、进程、文件访问等事件。它不能替代应用层 tracing，但很适合补齐这些问题：

  • 哪个 Pod 在频繁创建连接？
  • 哪个进程在访问某个外部域名？
  • 某个服务的 TCP 重传、连接失败、DNS 延迟是否异常？
  • 某个节点上是哪个 container 触发了大量系统调用或 I/O？
  • 应用没打 tracing 时，能不能先看到服务间调用关系的大致形态？

在 Kubernetes 里，Cilium、Hubble、Pixie、Parca、Tetragon 这类工具都在不同程度上利用 eBPF。对平台团队来说，eBPF 更像是“运行时事实层”：当应用埋点不完整或事故现场已经混乱时，它能提供一层不依赖业务代码的观察视角。

3. 网络与安全策略：把规则落到运行时#

Kubernetes 的 Network Policy 通常以 Pod、Namespace、label 为边界。这个模型很适合声明服务间访问关系，但对更细的运行时行为不一定够用。

eBPF 可以把策略推进到更接近实际行为的位置，比如：

  • 基于进程、cGroup、Pod identity 控制 egress。
  • 对 DNS、connect、socket、syscall 等行为做审计或拦截。
  • 检测容器里异常的 shell、文件访问、网络扫描、可疑 binary 执行。
  • 对 sidecar-less 的网络策略和可观测性做增强。

这里我不会把 eBPF 理解成“替代所有安全产品”。更现实的定位是：它通常适合做低开销、贴近 runtime 的信号采集和部分 enforcement。至于策略生命周期、误报处理、审计留痕、团队协作，仍然需要上层平台来承接。

4. 性能排查：从节点和内核层面找瓶颈#

Cloud Native 把应用包装成 Pod 后，很多性能问题会跨越应用、容器、内核和网络边界。只看应用日志，经常只能看到“慢了”或“超时了”，看不到底层原因。

eBPF 可以用在这些排查场景：

  • TCP retransmit、连接队列、DNS 解析、TLS 握手相关延迟。
  • 磁盘 I/O、page cache、文件系统调用热点。
  • CPU profile、off-CPU time、锁等待、调度延迟。
  • Node 上不同 Pod 对资源的真实消耗。

对我自己的项目经验来说，这类工具适合放在“第二层排查”里：第一层先看 SLI、日志、业务指标；当问题指向网络、内核、节点资源或跨服务调用时，再用 eBPF 工具下钻。

不是所有问题都需要自己写 eBPF#

这篇 GitHub 文章很有工程味的一点是，他们确实写了自己的 eBPF 程序。但对大多数 Cloud Native 团队来说，第一步未必是自己写 C 或 Go 去加载 eBPF program。

更稳妥的路径可能是：

  1. 先用成熟工具解决通用问题，比如 Cilium/Hubble 做网络可观测性，Tetragon 做 runtime security，Parca 做 profiling。
  2. 对 CI/CD 和部署恢复链路做 outbound dependency audit，先把“部署时到底访问了什么”看清楚。
  3. 只有当现成工具无法表达本团队特定边界时，再考虑写小范围的 eBPF program 或 userspace controller。

尤其是 enforcement 场景，最好从 audit mode 开始。直接阻断网络请求很容易引入发布失败，应该先积累一段时间的真实访问清单，再把规则收敛成 allowlist 或 blocklist。

我的 takeaway#

这篇文章给我的主要启发不是“eBPF 很强”，而是：平台工程里的很多约束，如果只靠文档和人工 review，很难长期有效。对恢复路径这类约束来说，我更倾向于把它们尽量变成运行时可观察、可审计、可阻断的机制。

放到 Cloud Native 项目里，我会优先考虑这些落点：

  1. 部署链路依赖审计：发布、回滚、migration、灾备脚本到底访问了哪些外部和内部服务。
  2. 关键恢复路径隔离：核心修复动作尽量只依赖少数经过验证的基础设施。
  3. 运行时网络可观测性：在应用埋点之外补一层真实的连接、DNS、进程视角。
  4. 安全行为检测：把可疑进程、网络扫描、异常文件访问等行为前移到 runtime。
  5. 性能下钻工具：在节点、网络、系统调用层面定位容器化之后更难看清的问题。

如果从一个方向开始，我会选“部署链路依赖审计”。它不需要一开始就阻断，也不要求业务改代码，但通常能较快暴露系统在故障恢复时可能踩到的隐性依赖。等这些依赖被看清楚后，再逐步引入 allowlist、mirror、offline artifact、runner 隔离和更严格的 egress policy，收益会更稳。