白月光与朱砂痣-Flannel略糙，Cilium太美

社交网络有一股神奇的力量，它总是能重新定义一些老的词汇。比如“白月光”和“朱砂痣”早已不是张爱玲小说里说的那个意思了，如今在网上它们会被用来表示人的喜新厌旧。借我们的专业术语来讲，这叫“词汇重载”。我想把K8s原生的Flannel比作朱砂痣，而本文及接下来几篇要说到的Cilium看成白月光。这个系列我老早就想跟大家分享了，因为Cilium它太香，太漂亮了。Cilim读音是 ['siliəm]，译作纤毛；睫毛。

Cilium速览

图 1：Cilium的生态

Cilium是什么？它是一个K8s CNI插件，但这只是它的起点，它的目标是星辰大海。

上图是Cilium及以它作为数据源所形成的一个集Networking， Observability和Security于一体的生态，这个生态里包含ES，Redis，Service Mesh等等。而Cilium的核心是eBPF。

Networking方面：

• 首先它是一个K8s CNI插件，所以它可以被无缝集成到K8s中。
• 它可以代替kube-proxy，包括 ClusterIP， NodePort， ExternalIPs 和 LoadBalancer，同时提供更好的性能、可靠性以及可调试性，当然，这些都要归功于 eBPF。 我们知道kube-proxy是K8s的组件，它会监控API server上面的pod，service 和 endpoint的修改，并对宿主机的iptables做相应的更新，以便实现virtual service IP:Port 到多个Pod IP:Port的转变。这个过程也是一种Load Balance。 我忍不住强调一下，每一个Pod的创建和删除操作都会使得kube-proxy在所有的node上更新iptables。K8s的问题列表里面曾经记录了一个问题#44613：在100个Node的K8s集群里，kube-proxy有时会消耗70%的CPU。 还有一个更恐怖的对比数据：当K8s里有5k个services（每个service平均需要插入8条rule，一共40k iptables rules）的时候，插入一条新的rule需要11分钟；而当services数量scale out 4倍到20k（160k rules）时，需要花费5个小时，而非44分钟，才能成功加入一条新的rule。可以看到时间消耗呈指数增加，而非线性。
• K8s多个Cluster间的连接。K8s cluster的规模会逐渐变大，但我们总归需要把cluster控制在合理的大小，而不可能让它无限膨胀，所以在某一个时间点会需要切割cluster成若干个规模相对小一点的集群。这种情况下，需要将支持service的所有endpoint(pod)分散编排部署在不同的cluster里，也即K8s需要跨集群编排，Pod需要跨集群服务请求。 这个功能开始慢慢变成刚需，但对我们而言，它又有点遥远，暂时略过。

Observability方面：

• Identity-aware（身份感知）的网络可视化。如图2所示。传统的基于IP和Port的网络可视化对K8s来说已经不适用，因为Pod的创建和销毁非常频繁，这导致IP和Pod的关系是动态变化的，这一刻192.168.1.24是Pod A在使用，下一秒可能已经被另做它用。 Cilium所提供的网络可视化可以识别service/pod/container的类似name之类的标识，甚至到Pod Label的粒度，这无疑比用传统的IP+Port的方式更有实际意义。
• 提供网络流量的metric，并可以无缝集成到Prometheus。这些Metric里面还会包含traffic是被哪些Network Policy所允许或禁止的。 可以和普罗米修斯无缝集成则意味着以Prometheus为数据源的Grafana可以直接将Cilium的metric显示在它优美的曲线图上。
• 可以通过HTTP，gRPC，Kafka等协议和其它服务集成。

图 2：身份感知的网络可视化示意图

Security方面：

• 支持K8s的Network Policy，例如Label + CIDR匹配方式。 注意：并不是每个CNI插件都实现了Network Policy，比如Flannel就没有。CNI规范也没有要求插件一定要支持Network Policy。
• 基于DNS-aware的Policy，例如只允许查询 *.google.com的IP，而不允许查询 *.food.com。
• 基于API-aware的Policy，例如不允许访问HTTP DELETE /concern。

• 支持Cluster-scope的Network Policy，而K8s的Network Policy是Namespace scope。
• Node-scope的防火墙。
• 透明加密。这是一个非常有意思的功能。这等于是将加密功能做成了一个对Pod无感的中间件和基础设施。

• 提供丰富的基于Identity的audit log供安全取证(security forensics)分析。为什么基于Identity的audit log这么重要呢？如上文所说，基于IP和Port的log信息对安全取证分析来说已经没有参考价值。下面是基于Identity的audit log示例，可以看到IP已经被替换成了pod name： Sep 27 06:59:46.576: kube-system/hubble-ui-9b6d87f-vl5nq:60608 -> kube-system/hubble-relay-84999fcb48-cckqs:4245 to-endpoint FORWARDED (TCP Flags: ACK) Sep 27 06:59:46.576: kube-system/hubble-relay-84999fcb48-cckqs:4245 <> kube-system/hubble-ui-9b6d87f-vl5nq:60608 to-overlay FORWARDED (TCP Flags: ACK) Sep 27 06:59:46.585: kube-system/hubble-ui-9b6d87f-vl5nq:60608 <> kube-system/hubble-relay-84999fcb48-cckqs:4245 to-overlay FORWARDED (TCP Flags: ACK)

Cilium架构

每研究一个新的东西或者做一个新的项目时，我总喜欢看它的架构图。架构图的意义如同地图，拿着架构图做项目就像对着地图旅游，进可知细节，退可揽全局。我们来看看Cilium的架构。

它分为三大部分：Cilium本体，和编排系统集成部分，与Kernel集成部分。

图 3：Cilium架构

Cilium本体部分：

Cilium自身是一个庞大的系统，包含daemon(agent)，CNI plugin，CLI，Policy repo等等。其中CLI用于Cilium的安装和对Cilium的配置。

其中agent是以DaemonSet方式部署的Pod（container name: cilium-agent），所以在每个node上都会有它的身影。一方面它会接收来自通过K8s和API等方式送过来的配置，另一方面它会尤其关注K8s里关于container的创建、停止、删除等事件并随之执行与eBPF Hook相关的动作。

从架构图中可以看出来，daemon是整个系统的信息、决策和执行中枢。

和编排系统集成部分：

Cilium首先是一个K8s CNI插件。一个平台要做成一个开放性的生态的话，设计上需要留下空间和接口，让平台里面的某一个功能模块可以被以插件形式任意替换。而一个插件，通常会作为一个工作在一线的使者专门与平台对接、打交道，并把平台安排的具体任务转交至它的背后团队处理。Cilium plugin作为一个插件，将K8s的网络相关的任务接下来并转移至后方的daemon进一步处理，我们将会在后文的IPAM中看到这个详细过程。

与Kernel集成部分：

这个部分满眼望去都是eBPF。是的，Cilium是eBPF的维护者。前文提到的Networking，Observability和Security三大方面的各式各样的功能很多都是得益于eBPF。没有了eBPF，在众多CNI插件中，Cilium也只能是普通的路人甲。

Cilium太大，要说的东西太多，但篇幅有限，今天我们只聊到这里。下一篇我们聊IPAM。