Cilium:基于eBPF的高效云原生网络和ServiceMesh方案

Cilium 在 linux 内核的不同点注入 eBPF 程序 , 提供适合云原生时代的连接层 , 该层使用 Kube.NETes identities 而不是 IP 地址 , 并允许绕过部分网络堆栈以获得更好的性能 。

Cilium:基于eBPF的高效云原生网络和ServiceMesh方案

文章插图
Cilium简介Cilium 是一种开源的云原生网络解决方案 , 基于革命性的内核技术 eBPF  , 为工作负载提供高性能、安全、可观测的网络连接 。eBPF 技术通过提供附加自定义程序到内核中的事件为应用程序提供超能力 , Cilium 项目利用 eBPF 的能力开发了多个程序 , 通过这些程序可以有效地管理容器集群 。
目前Clilium项目包含三个项目:Cilium、Hubble、Tetragon 。
解决了容器网络云面临的三大挑战:连接、可观测性、安全 。
Cilium最初由Isovalent创建 , 并于2015年开源 , 非常受欢迎 。有14000+ Github star , 500+贡献者 , 以及14000+用户注册了Cilium社区Slack 。更重要的是 , Cilium 被媒体、金融和搜索等各种垂直行业的组织广泛部署在生产环境中 , AWS、微软、google三大云提供商现在都在其 Kubernetes 服务产品中支持 Cilium 。Cilium 于2021年10月加入CNCF孵化 , 并于2022年10月毕业 。毕业状态是任何 CNCF 项目的一个重要里程碑 , 表明该项目拥有可持续的贡献者社区 , 被广泛采用 , 并且正在成为任何云规模堆栈的预期部分 。
扩展云原生连接Kubernetes 的最大优势在于其动态特性 , 这使其能够按需扩展服务 , 并在出现问题时将 Pod 和服务协调到所需的状态 。例如 , 如果一个节点出现故障 , Kubernetes 将自动重启集群中另一个节点上的 pod , 以弥补其损失 。但是 , 这种动态性给传统网络带来了麻烦 , 因为IP地址在整个集群中被重新分配和重用 。对于人工操作员 , 存在可观测性问题 , 因为您无法再对与特定工作负载匹配的 IP 地址做出假设 。在底层网络堆栈中 , 某些组件不是为不断重用 IP 地址而设计的 , 从而导致大规模性能问题 。
Cilium 在 Linux 内核的不同点注入 eBPF 程序 , 提供适合云原生时代的连接层 , 该层使用 Kubernetes identities 而不是 IP 地址 , 并允许绕过部分网络堆栈以获得更好的性能 。
Cilium:基于eBPF的高效云原生网络和ServiceMesh方案

文章插图
在 Kubernetes 中 , Pod 通常运行自己的网络命名空间 , 这意味着数据包必须经历网络堆栈两次——一次在 Pod 命名空间中 , 一次在主机中 。Cilium 允许绕过主机堆栈的重要部分 , 从而显著提高性能 。就像闪电侠一样 , 它快如闪电 。
Cilium:基于eBPF的高效云原生网络和ServiceMesh方案

文章插图
从上图可以看出 , Cilium 可以绕过网络堆栈中的 iptables 。这是一个在设计时没有考虑到 Kubernetes 行为的组件 , 并且由于 Kubernetes 的动态性质 , iptables 的性能通常会大规模下降 。在节点、Pod 和服务较多的大型集群中 , 通常有大量的 iptables 过滤器和转发规则 , 需要随着 Pod 的来来去去进行更新 。更糟糕的是 , 对于iptables , 更改一个规则意味着整个表被重写 。随着部署的增长 , 每次创建或销毁 Pod 时 , 规则需要越来越长的时间来收敛 , 从而导致大规模正确操作的严重延迟 。
Cilium 不是 iptables , 而是在 eBPF maps 中跟踪 pod endpoints 。这些是存储在内核中的数据结构 , Cilium 的 eBPF 程序可以访问这些数据结构 , 以便就每个网络数据包的发送位置做出高效的决策 。
基于Cilium身份的网络策略传统的 Kubernetes 网络策略基于 iptables filters , 这些 filters 也存在相同的规模问题 。Cilium 采用了不同的方法 , 使用 Kubernetes 标签为 Pod 分配安全身份(类似于 Kubernetes 使用标签识别分配给每个服务的 Pod 的方式) 。网络策略以 eBPF maps 表示 , 并允许在网络流量进入或离开 Cilium 管理的节点时从这些映射进行超快速查找 , 以决定是否允许或拒绝数据包 。这些eBPF程序非常小 , 速度超快 。
使用 Cilium , 您可以编写应用程序感知的 L7 策略!例如 , 您可以编写一个策略来限制 Pod 之间的访问 , 以仅允许特定 API 端点上的特定 HTTP REST 方法 。您还可以根据完全限定的域名或 IP 地址筛选流量 , 以便在流量需要在群集外部通信时进行通信 。


推荐阅读