【理解 Cilium 系列文章】(一) 初识 Cilium

Cilium 作为近两年最火的云原生网络方案，可谓是风头无两。作为第一个通过 ebpf 实现了 kube-proxy 所有功能的网络插件，它的神秘面纱究竟是怎样的呢？本系列文章将带大家一起来慢慢揭晓

作为《理解 Cilium 系列文章》的第一篇，本文主要介绍 Cilium 的发展，相关功能以及使用，深入理解及底层原理将在后续文章中继续介绍

背景

随着云原生的普及率越来越高，各大厂商基本上或多或少都实现了业务的 k8s 容器化，头部云计算厂商更是不用说。

而且随着 k8s 的 普及，当前集群逐渐呈现出以下两个特点：

1. 容器数量越来越多，比如：k8s 官方单集群就已经支持 150k pod

2. Pod 生命周期越来****越短，Serverless 场景下甚至短至几分钟，几秒钟

随着容器密度的增大，以及生命周期的变短，对原生容器网络带来的挑战也越来越大

当前 k8s Service 负载均衡的实现现状

在 Cilium 出现之前， Service 由 kube-proxy 来实现，实现方式有 userspace，iptables，ipvs 三种模式。

Userspace

当前模式下，kube-proxy 作为反向代理,监听随机端口，通过 iptables 规则将流量重定向到代理端口，再由 kube-proxy 将流量转发到 后端 pod。Service 的请求会先从用户空间进入内核 iptables，然后再回到用户空间，代价较大，性能较差。

Iptables

存在的问题：

1.可扩展性差。随着 service 数据达到数千个，其控制面和数据面的性能都会急剧下降。原因在于 iptables 控制面的接口设计中，每添加一条规则，需要遍历和修改所有的规则，其控制面性能是O(n²)。在数据面，规则是用链表组织的，其性能是O(n)

2.LB 调度算法仅支持随机转发

Ipvs 模式

IPVS 是专门为 LB 设计的。它用 hash table 管理 service，对service 的增删查找都是O(1)的时间复杂度。不过 IPVS 内核模块没有 SNAT 功能，因此借用了 iptables 的 SNAT 功能。

IPVS 针对报文做 DNAT 后，将连接信息保存在 nf_conntrack 中，iptables 据此接力做 SNAT。该模式是目前 Kubernetes 网络性能最好的选择。但是由于 nf_conntrack 的复杂性，带来了很大的性能损耗。腾讯针对该问题做过相应的优化【绕过conntrack，使用eBPF增强 IPVS优化K8s网络性能】

Cilium 的发展

Cilium 是基于 eBpf 的一种开源网络实现，通过在 Linux 内核动态插入强大的安全性、可见性和网络控制逻辑，提供网络互通，服务负载均衡，安全和可观测性等解决方案。简单来说可以理解为 Kube-proxy + CNI 网络实现。

Cilium 位于容器编排系统和 Linux Kernel 之间，向上可以通过编排平台为容器进行网络以及相应的安全配置，向下可以通过在 Linux 内核挂载 eBPF 程序，来控制容器网络的转发行为以及安全策略执行

简单了解下 Cilium 的发展历程：

1. 2016 Thomas Graf 创立了 Cilium, 现为 Isovalent (Cilium 背后的商业公司)的 CTO