/tags/cloudnative/ Recent content in cloudnative on Hugo -- gohugo.io en Fri, 22 May 2026 12:00:00 +0800 /reading/github/ebpf-deployment-safety/ Fri, 22 May 2026 12:00:00 +0800 /reading/github/ebpf-deployment-safety/ 原文链接 GitHub Uses eBPF to Eliminate Deployment Risks and Prevent Circular Failures How GitHub uses eBPF to improve deployment safety InfoQ 这篇新闻总结的是 GitHub Engineering 在 2026 年 4 月发布的一篇文章。它讨论的不是常见的 eBPF 网络加速或可观测性案例，而是一个更偏平台工程的问题：部署系统本身会不会依赖它正在修复的系统。 这个角度挺有意思。我们平时谈 Cloud Native 的可靠性，经常会讲多副本、自动扩缩容、健康检查、Service Mesh、GitOps、回滚策略。但当系统真的进入故障态时，一个很实际的问题往往更朴素：修复系统的工具链还能不能工作。 GitHub 这次解决的是什么问题 GitHub 的基本矛盾是一个典型的循环依赖：GitHub 的源码托管在 github.com 上，但 github.com 如果出现故障，修复它的部署动作又可能需要访问 github.com。 这个显性的循环依赖可以通过代码镜像和构建产物镜像缓解。真正麻烦的是部署脚本里的隐性依赖，比如： 直接依赖：部署脚本临时从 GitHub 下载某个 open source 工具。 隐藏依赖：机器上已有的工具启动时自动检查更新，背后访问了 GitHub。 传递依赖：部署脚本调用内部服务，内部服务再去 GitHub 拉取 release 或 binary。 这些依赖平时可能不容易看出来，因为所有服务都健康时它们只是一次普通的网络访问。等到事故发生，才发现部署链路需要依赖一个已经不可用的服务，于是修复动作被卡住，MTTR 被拉长。 GitHub 的做法不是要求每个团队手工审查脚本，而是把部署脚本放进单独的 cGroup，再用 eBPF 挂到这个 cGroup 的网络出口上。这样可以只观察和限制部署进程的 outbound network access，而不影响同一台 stateful host 上继续承载生产流量的其他进程。