本文地址:2024 年 eBPF 和网络趋势预测 | 深入浅出 eBPF
- 1. eBPF
- 1.1 eBPF 将继续呈指数增长
- 1.2 eBPF 应用市场
- 1.3 eBPF 在手机中得到更广泛的应用
- 1.4 eBPF 滥用带来的风险
- 2. 可观测
- 2.1 最受欢迎的可观测性
- 2.2 降低可观测性开销
- 2.3 上下文感知的 Kubernetes 工作负载
- 2.4 AI 助力网络排查
- 3. 网络
- 3.1 与主机网络性能匹配的容器网络性能
- 3.2 网络行业的变革
- 3.3 Cilium 进行家庭环境
- 3.4 网络人员寻求 LLM 帮助 - 可能并不都如意
- 4. 云原生
- 4.1 Kubernetes 用户开始反击复杂性
- 4.2 IPv6 单栈 Kubernetes 集群成为常态
- 4.3 快速增长的 WSAM
- 4.4 不应该被遗忘的异构网络
- 4.5 平台工程与网络之成长的烦恼
2024 年初,Isovalent 公司高级销售工程师 Nico Vibert 针对网络和 eBPF 提出了一些预测,这里我们将简单给出一些重要的结论,主要涉及到 eBPF/Cilium/云原生/网络/可观测和安全等领域。
1. eBPF
1.1 eBPF 将继续呈指数增长
2023 年,基于 eBPF 技术网络和安全项目快速增长,预计明年基于 eBPF 的项目总数将轻松超过三位数。Liz 的著作 Learning eBPF、eBPF Labs、eBPF 峰会和 eBPF 纪录片的热度,都表明 eBPF 正变得越来越受欢迎。
这部 eBPF 该纪录片自上映以来已获得超过 50,000 次观看。
1.2 eBPF 应用市场
ebpf.io 网站中收录的项目已经从 2 年前的 9 个增加到了 41 个,这些项目或工具涉及了 CNI/高性能负载均衡/云原生运行时安全/可观测等诸多领域。预计未来会出现 eBPF 应用市场,在这里我们不仅能够下载和安装 eBPF 程序,还能够检测程序之间是否存在冲突。预计在未来几年内,eBPF Store 的概念将得到发展。
1.3 eBPF 在手机中得到更广泛的应用
当前 eBPF 每天都会被数百万的 Android 用户使用。eBPF 在 Android 中的初始用途是用来测量网络流量统计,但现在你手机中的每个网络数据包都可能会通过 eBPF 程序。在将来作者预测会有更多的 eBPF 应用在移动设备上的使用案例,不仅限于安卓设备。未来几年,Cilium 项目可能也会在移动设备中运行。
在 Android 上的 eBPF 主要用途有以下几种:
- 数据使用统计和计费;
- 防火墙/网络限制,以便在进入节电模式时实现节能;
- 高速数据包处理,比如共享网络连接或 464xlat(一种在 IPv6 网络上提供 IPv4 连接的方法,因为 Linux 内核本身不支持)。
这段来自日本 IETF 116 会议的视频提供了 Android 上关于 eBPF 的精彩而简短的演示。
1.4 eBPF 滥用带来的风险
随着 eBPF 技术的流行,不可避免会出现滥用。尽管 eBPF 验证器的目标是确保 eBPF 程序安全运行,并防止危险行为,但随着 eBPF技术广泛的应用,可能会出现某些形式的漏洞被利用。这可能会导致某些人对 eBPF 技术产生顾虑,预测基于 eBPF 的应用以控制监视 eBPF 程序应用的成倍增加。
2. 可观测
2.1 最受欢迎的可观测性
根据这篇博客文章的统计表明,可观测性无疑是 KubeCon 上最受欢迎的主题。
虽然许多组织将投入时间和精力建立其内部开发平台(平台工程可能会成为明年 KubeCon 上最受欢迎的主题),但作者预计许多组织将会首先专注于提高其可观测性能力。大型组织将需要针对集群和部署的 Pod 进行治理。
2.2 降低可观测性开销
观测集群中发生的一切将会带来巨大的数据量,这将会显著增加可观测性的成本开销,特别是涉及数百个 Kubernetes 集群和数十万个 Pod 场景中。由于集群中运行着众多用于日志记录、监控和安全等目的守护进程,特定场景下,这些应用自身的资源消耗可能会超过集群上运行的实际应用程序。随着人们对 FinOps 框架的日益关注,预计工程师将开始优化消耗德过多资源的观测工具。这也是 Tetragon 人气飙升的原因之一:低开销的 eBPF 事件监控。
2.3 上下文感知的 Kubernetes 工作负载
上下文感知(Context-Aware)并不是一个新概念(10 年多前在思科工作时曾提出上下文感知安全 ),但这是一个在未来几年将受到更多关注的事情。容器化引入的诸多抽象层导致了过程中上下文丢失。例如一个 Pod 通常包含多个容器 ( 有时甚至有几十个 ),它们共享一个 IP 地址。设置容器应用安全策略通常意味着我们给予 Pod 中容器所需更多的权限。将 Tetragon 的上下文与 Cilium 网络策略集成 ,可能是具有变革性的举措。
2.4 AI 助力网络排查
网络工具将开始与 LLM 原生集成,提供类似聊天的体验以与网络进行交互。
例如登录到 Grafana 仪表板通过对话方式排查做完流量在晚上 10 点到 11 点之间下降的问题,这最有可能是一个配置错误的网络策略所导致。聊天机器人能够响应关于构建架构的简单指示,并给出对应的 Terraform 配置。最终可以通聊天交谈最终排查出为什么陷入了路由环路。
3. 网络
3.1 与主机网络性能匹配的容器网络性能
在芝加哥的 KubeCon 上 ,Daniel Borkmann 发表了 “Turning up Performance to 11: Cilium, NetKit Devices, and Going Big with TCP” 的演讲。在与合作者过去十年中共同创造了最变革性的网络技术 之一(eBPF)之后,Daniel 为自己设定了另一个挑战:提升容器网络性能,使其达到与主机网络相当的水平。
随着最近发布的 netkit(以及在容器级别运行 eBPF 程序的能力),预计我们将在网络性能方面达到同等水平。虽然这些功能可能需要一段时间才能在通常部署的内核上可用,但网络这一功能的确令人兴奋。
Linux 网络协议栈包含如此多的路径,Daniel 需要和 XDP(Express Data Path)/BIG TCP 等技术背后的开发人员一起找到巧妙的方法来寻找捷径或研究优化。
3.2 网络行业的变革
网络行业将在明年经历其最重大的转型之一,这是由于几个趋势共同作用导致的。
- Broadcom 对 VMware 的收购将导致一些组织重新考虑他们对 VMware 技术栈的使用。反过来,这将对采用 NSX 作为虚拟网络技术产生影响。
- 开源网络技术从未如此受欢迎。2023 年见证了首届网络自动化和 NetDevOps 大会 – 这是主要由开源项目支持的技术趋势。Awesome Network Automation GitHub 仓库 及其突出显示的许多工具的热度 – 诸如 GoBGP 和 containerlab 等项目 - 突显出过去十年网络行业的变化。
- 开源网络从未如此强大。过去,开源网络在功能和性能方面与专有解决方案相比有所折扣。当你考虑通过 eBPF 和 XDP 等技术可以实现的一些性能提升时,这一情况得到了明显的改善。这个用例中的性能 改进令人难以置信(谁不希望 CPU 占用空间提高 72 倍)。
预计未来几年将在网络行业出现根本性变革;或许是自软件定义网络开始以来最大的变革。
3.3 Cilium 进行家庭环境
在最近一集的 eCHO 中,探讨了如何以及为什么 Cilium 会出现在家庭的环境中。通过 Cilium,你可以使用网络策略保护应用程序,并通过内置的 BGP 和 Gateway API 支持将其对外发布。预计 Cilium 今年将在家庭使用中会变得非常受欢迎。
近年来,Cilium 在边缘环境中的采用率不断增长。零售和医疗保健等行业的许多组织都在部署云原生边缘计算平台,并使用 Cilium 使网络和防火墙更接近工作负载。
3.4 网络人员寻求 LLM 帮助 - 可能并不都如意
网络工程师已经在使用 ChatGPT 来帮助解决网络问题并生成网络配置。但即使经常使用 ChatGPT,我们还是不能够将决策权放到 LLM 手中。尽管不可避免地会出现小问题,但 AI 和 LLM 仍然将对网络产生变革性影响。
4. 云原生
4.1 Kubernetes 用户开始反击复杂性
云原的生态系统日趋复杂。在社交媒体上可以经常看到人们抱怨操作云原生平台技术栈的复杂性。大量云原生项目和工具的泛滥给使用者带了更多的疲劳感。2024 年平台和 DevOps 工程师想要什么?简单。
作者预计,许多平台和 DevOps 工程师将在 2024 年投入时间来简化他们云原生相关的工具。作为结果,预计云原生生态将开始缩减。
4.2 IPv6 单栈 Kubernetes 集群成为常态
Google 用户使用 IPv6 的比例已经从 3 年前的 31% 提升到了 45%,按目前的速度,预计到 2024 年底,全球 Google 用户看到的主要协议将是 IPv6(在法国和印度等国家,已经超过 70%)。但 IPv6 的普及是否延伸到了 Kubernetes 平台呢?部分是。尽管托管的 Kubernetes 服务提供商(AKS、GKE 和 EKS)已经有了重大改进,但 IPv6 仍然是次要选择,通常缺少较文档也并不被推荐。直到最近,许多基本的云原生工具都存在一些 IPv6 缺点。
Cilium 确实引入了对 NAT46/NAT64 的原生支持,以提供纯 IPv6 集群和 IPv4 世界之间的相互兼容性,也让人看到了积极的一面。
GitHub 和 Docker Hub 也在积极推动 IPv6 的普及。 此外还有一些其他因素将加速 Kubernetes 中 IPv6 的采用:
-
成本:AWS 最近对公共 IPv4 地址 进行的定价上涨也会引导用户转向 IPv6;
-
操作简便性:电信公司使用的 SRv6 技术,也即将应用到 Kubernetes,这可能大规模简化网络连接和可编程性。作者预计电信公司会对在其集群中利用 SRv6 产生浓厚的兴趣。
-
性能:诸如 BIG TCP 等高性能网络特性将给用户更多理由转向 IPv6。
虽然规模和 IP 地址耗尽是 IPv6 推广最普遍的理由,但更便宜、更快的 IPv6 网络,将会被客户更快地被接受。
4.3 快速增长的 WSAM
我们通常用 “eBPF 之于内核,就像 Javascript 之于浏览器一样” 的讲法来描述 eBPF 技术。有趣的是,另一种流行的云原生技术 Wasm 也有类似的说法,Wasm 提供了一个能够在 Web 浏览器中运行 C/C++、C# 和 Rust 程序的抽象。随着 Containerd 原生支持 Wasm,预计 Wasm 将在 2024 年进一步腾飞。更近一步,基于 eBPF 的强大功能,可使用 Cilium 无缝保护和连接这些应用程序。
4.4 不应该被遗忘的异构网络
除了 Kubernetes 平台外,仍然存在着大量的虚机和裸金属服务器部署的服务实例。根据 VMware/Broadcom 统计数据,至少有 8500 万台正在运行在 vSphere 上的虚拟机,并且很可能有同样数量的 EC2 实例在 AWS 上运行。在芝加哥举办的 CiliumCon(在 KubeCon 之前专注于 Cilium 的活动)上的几个专题讨论的是 Kubernetes 外的技术:OpenStack和 Nomad,以及 Cilium 在这些环境中用于网络连接和安全性。
2024 年,我们将看到诸如 Cilium Mesh 类似的项目将致力于填补 Kubernetes 、VM 和 Serverless 世界等之间的空白,并试图连接和保护这些异构工作负载。
4.5 平台工程与网络之成长的烦恼
根据 Gartner 的说法,“平台工程通过提供具有自动化基础设施操作的自助服务能力,改善开发人员的体验和生产效率 ”。
期待看到平台工程和网络领域的交集,但同时一些平台工程师绝对会害怕让开发人员拥有自助服务网络能力。
如何为 IDP(内部开发人员门户)的开发人员和其他使用者提供独立性和灵活性,而不会让他们做出一些糟糕的网络决策并危及他们正在启动的应用程序?组织必须在自主性和控制性之间找到适当的平衡。
虽然在 2024 年,构建开发人员门户仍将是许多人关注的焦点,但预计在提供多少网络独立性方面会有很多成长的烦恼。