• 翻译

【译】eBPF 和服务网格：还不能丢掉 Sidecar

服务网格以典型的 sidecar 模型为人熟知，将 sidecar 容器与应用容器部署在同一个 Pod 中。虽说 sidecar 并非很新的模型（操作系统的 systemd、initd、cron 进程；Java 的多线程），但是以这种与业务逻辑分离的方式来提供服务治理等基础能力的设计还是让人一亮。 随着 eBPF 等技术的引入，最近关于服务网格是否需要 sidecar （也就是 sidecarless）的讨论渐增。 笔者认为任何问题都有其起因，长久困扰服务网格的不外乎性能和资源占用。这篇文章翻译自 Buoyant 的 Flynn 文章 eBPF and the Service Mesh: Don’t Dismiss the Sidecar Yet。希望这篇文章能帮助大家穿透迷雾看透事物的本质。 本文要点 eBPF 是一个旨在通过（谨慎地）允许在内核中运行一些用户代码来提高性能的工具。 在可预见的未来，服务网格所需的第 7 层处理在 eBPF 中不太可能实现，这意味着网格仍然需要代理。 与 sidecar 代理相比，每个主机代理增加了操作复杂性并降低了安全性。 可以通过更小、更快的 Sidecar 代理来解决有关 Sidecar 代理的典型性能问题。 目前，sidecar 模型对服务网格仍是最有意义的。 关于 eBPF 的故事已经在云原生世界中泛滥了一段时间，有时将其描述为自切片面包以来最伟大的事物，有时则嘲笑它是对现实世界的无用干扰。当然，现实要微妙得多，因此仔细研究一下 eBPF 能做什么和不能做什么似乎是有必要的——技术毕竟只是工具，使用的工具应该适合手头的任务。