文章目录

云原生利器之Cilium
- 一、什么是cilium
- 二、Cilium使用场景
- - 关于容器网络接口 ( CNI )
- 三、网络解决方案Flannel，Calico 和 Cilium 对比
- - DPDK
- 四、Cilium架构
- 五、Cilium 和 eBPF - 云原生世界的理想搭配
- 六、eBPF 革命开始
参考

云原生利器之Cilium

一、什么是cilium

官网： https://cilium.io/
官方文档：https://docs.cilium.io/en/stable/intro/
官方github： https://github.com/cilium/cilium

Cilium 是一个用于容器网络领域的开源项目，主要是面向容器而使用，用于提供并透明地保护应用程序工作负载（如应用程序容器或进程）之间的网络连接和负载均衡。

Cilium的基础是一种新的Linux内核技术，称为EBPF，它可以动态插入Linux本身中强大的安全可见性和控制逻辑。由于EBPF在Linux内核内运行，因此可以应用和更新Cilium Security策略，而无需更改应用程序代码或容器配置。

Cilium 是一个在 eBPF 之上设计的开源项目，旨在满足容器工作负载的网络、安全和可观测性要求。它在 eBPF 之上提供了一个高级抽象。Cilium 之于 eBPF，就像 Kubernetes 和容器运行时之于 Linux 内核namespace、cgroups 和 seccomp。

二、Cilium使用场景

官方：https://cilium.io/get-started/

如官方所示，Cilium使用场景有3个方向，一个是网络、一个是可观测性、一个是安全。

Cilium 提供了 CNI 和 kube-proxy replacement 功能，相比 iptables 性能要好很多。Cilium 作为第一个通过eBPF实现了kube-proxy所有功能的Kubernetes网络方案,

Cilum 1.6发布基于BPF的服务发现代理(完全替换基于iptables的kubeproxy)。

现有问题
**传统的Linux网络访问安全控制机制（如iptables）是基于静态环境的IP地址和端口配置网络转发、过滤等规则，但是IP地址在微服务架构下是不断变化的，非固定的；出于安全目的，协议端口(例如HTTP传输的TCP端口80)也不再固定用来区分应用系统。**为了匹配大规模容器实例快速变化的生命周期，传统网络技术需要维护成千上万的负载均衡规则和访问控制规则，并且需要以不断增长的频率更新这些规则，而如果没有准确的可视化功能，要维护这些规则也是十分困难，这些对传统网络技术的可用性和性能都是极大的挑战。比如经常会有人对kube-proxy基于iptables的服务负载均衡功能在大规模容器场景下具有严重的性能瓶颈，同时由于容器的创建和销毁非常频繁，基于IP做身份关联的故障排除和安全审计等也很难实现。

解决方案
Cilium作为一款Kubernetes CNI插件，从一开始就是为大规模和高度动态的容器环境而设计，并且带来了API级别感知的网络安全管理功能，通过使用基于Linux内核特性的新技术——BPF，**提供了基于service/pod/container作为标识，而非传统的IP地址，来定义和加强容器和Pod之间网络层、应用层的安全策略。**因此，Cilium不仅将安全控制与寻址解耦来简化在高度动态环境中应用安全性策略，而且提供传统网络第3层、4层隔离功能，以及基于http层上隔离控制，来提供更强的安全性隔离。

另外，由于BPF可以动态地插入控制Linux系统的程序，实现了强大的安全可视化功能，而且这些变化是不需要更新应用代码或重启应用服务本身就可以生效，因为BPF是运行在系统内核中的。

以上这些特性，使Cilium能够在大规模容器环境中也具有高度可伸缩性、可视化以及安全性。

关于容器网络接口 ( CNI )

官方：https://www.cni.dev/
官方github： https://github.com/containernetworking/cni

容器网络接口 ( CNI ) 的创建是为了在容器执行和网络层之间定义一个标准化的通用接口。

CNI 项目是云原生计算基金会 (CNCF) 的一部分。**CNI 规范描述了如何为 Linux 容器配置网络接口。它将其重点领域定义为仅限于容器网络连接并在容器消失时移除分配的资源。**由于这个重点，CNI 规范简单并被广泛采用，支持大量插件。许多容器编排框架，包括 Kubernetes，都实现了这个规范。如果你想了解有关 CNI 规范、使用它的运行时以及实现它的第三方插件的更多信息，CNI GitHub 项目是一个很好的起点。

CNI 插件必须符合 CNI 规范定义的标准。每个实现 CNI 规范的插件都试图解决容器网络的不同方面。

这些插件是：
Flannel
Calico
Weave
Cilium

三、网络解决方案Flannel，Calico 和 Cilium 对比

Flannel
Flannel 常见采取 UDP Overlay 方案，flannel是overlay network, 主要是L2(VXLAN)。
Calico
Calico 是一个纯三层的方案，不需要 Overlay，基于 Etcd 维护网络准确性，也基于 Iptables 增加了策略配置。
calico主要是L3，用BGP路由。
Cilium
cilium的主要卖点就是这个BPF。BPF的性能非常强悍，要比iptables强上数倍。
Cilium 基于 eBPF 和 XDP 的方案，eBPF/XDP 处理数据包的速度可以和 DPDK 媲美，零拷贝直接内核态处理，缺点就是用户不太容易进行配置，而 cilium 解决了这个问题，可以支持 L3/L4/L7 的策略。

DPDK

DPDK让用户态程序直接处理网络流，bypass掉内核，使用独立的CPU专门干这个事。

新技术出现的历史原因
iptables/netfilter 是上个时代Linux网络提供的优秀的防火墙技术，扩展性强，能够满足当时大部分网络应用需求。但该框架也存在很多明显问题：

iptables 基于一个非常庞大的内核框架（Netfilter），这个框架出现在内核 datapath 的多个地方，有很大冗余。

路径太长
netfilter 框架在IP层，报文需要经过链路层，IP层才能被处理，如果是需要丢弃报文，会白白浪费很多CPU资源，影响整体性能；极端情况下，报文需要依次遍历所有规则，才能匹配中，极大影响报文处理性能；
规则太多
netfilter 框架类似一套可以自由添加策略规则专家系统，并没有对添加规则进行合并优化，这些都严重依赖操作人员技术水平，随着规模的增大，规则数量n成指数级增长，而报文处理又是0（n）复杂度，最终性能会直线下降。
内核协议栈
随着互联网流量越来愈大, 网卡性能越来越强，Linux内核协议栈在10Mbps/100Mbps网卡的慢速时代是没有任何问题的，那个时候应用程序大部分时间在等网卡送上来数据。

现在到了1000Mbps/10Gbps/40Gbps网卡的时代，数据被很快地收入，协议栈复杂处理逻辑，效率捉襟见肘，把大量报文堵在内核里。

四、Cilium架构

Cilium由在您的环境中在所有群集节点和服务器上运行的代理组成。它为在该节点上运行的工作负载提供网络，安全性和可观测性。工作负载可以在系统上进行容器或本地运行。

Cilium 是一个很好的 eBPF 之上的通用抽象，覆盖了分布式系统的绝大多数场景。Cilium 封装了 eBPF，提供一个更上层的 API。

五、Cilium 和 eBPF - 云原生世界的理想搭配

eBPF - 网络与安全的未来
参考URL: https://cilium.io/blog/2020/11/10/ebpf-future-of-networking/

是什么让 eBPF 和 Cilium 如此适合应对新的云原生挑战？

可编程性
eBPF 不是特定于网络或绑定到特定域的。eBPF 的通用性不仅吸引了更大的社区进行创新，而且还避免了对解决未来问题所需的构建块做出过早的假设。与任何特定于网络的可编程性解决方案（例如 iptables、Open vSwitch 或 nftables）相比，这是一个巨大的优势。
嵌入在 Linux 内核中
之前可编程性已经以用户空间网络的形式存在。eBPF 可编程性的独特新方面被嵌入到 Linux 内核中。应用程序使用系统调用通过网络进行交互，Linux 内核负责处理这些系统调用。为了让用户空间网络框架对应用程序保持透明，它仍然必须遍历 Linux 内核的套接字层。eBPF 通过完全保留在内核中来避免这种情况。

之前这点之所以不重要，是因为对于虚拟机，管理程序在物理机的网络设备和虚拟机内部的套接字之间创建了一个自然边界。而对于容器，这一切都发生在同一个内核中。

安全和效率
那么为什么不直接加载 Linux 内核模块呢？它显然以非常高的效率提供了任意可编程性。
主要缺点：需要深入了解跨内核版本的内核模块的成本，安全性的同时保持效率。

通过要求 eBPF 程序通过验证过程，eBPF 程序比加载内核模块安全得多。
效率由即时 (JIT) 编译器保证，该编译器确保 eBPF 字节码的本机执行速度。
所有这些都使得 eBPF 非常强大，但它也是一种底层技术，主要供 Linux 内核开发人员使用。

六、eBPF 革命开始

eBPF - 网络与安全的未来
参考URL: https://cilium.io/blog/2020/11/10/ebpf-future-of-networking/

在 Kubernetes 启动的同一年，eBPF 首次被合并到 Linux 内核中，作为长期存在的数据包过滤器 BPF 的继承者。因此名称扩展 BPF 或简称：eBPF。一年后，eBPF 后端被合并到 LLVM 编译器套件中，允许 LLVM 编译出 eBPF 字节码。同时，集成到内核的流量控制层使 Linux 网络可以使用 eBPF 进行编程。

2016 年，XDP 被合并到 Linux 内核中，通过允许 eBPF 程序直接在网络设备的驱动程序中运行来实现高性能数据路径。这就是后来开发基于 eBPF 的高性能负载均衡器的原因，这些负载均衡器驱动着当今一些最大的数据中心。

从那时起，eBPF 就处于一个令人难以置信的陡峭轨迹中，需要进一步发展，并且每年都变得越来越强大。eBPF 的通用性允许围绕它形成一个多样化的社区，涵盖网络、跟踪、安全性、概要分析和可观察性。

参考

如何基于 Cilium 和 eBPF 打造可感知微服务的 Linux？
参考URL: https://www.sohu.com/a/314798806_198222
星云实验室：「云原生技术研究」CILIUM网络概述
参考URL: http://blog.nsfocus.net/cilium-network-0713/