容器网络硬核技术内幕 (24) 知微知彰，知柔知刚 (上)

在前几期专题中，我们已经知道，容器的安全可以通过networkpolicy来描述一个基本的约束。

然而，在kubernetes环境常用的cni插件中，常见的对networkpolicy的实现，实际上大部分是基于iptables的，也就是利用各个node上的CPU来进行软件实现。

iptables这种软件实现的好处是显而易见的。由于它是一个无状态分布式系统，理论上在node无限扩展时，它的处理能力也是无限扩展的。在超大型kubernetes集群时，可以具备近乎完全线性的性能规格扩展性。

凡事有一利必有一弊。对于节点数在50个到1000个之间的中小型的kubernetes集群，iptables的弊病就暴露出来了。

前面说到，iptables运行在每台服务器，或者说，kubernetes的每个node上。每台服务器的内部框图大致如上图：

图中，各网络适配器(网卡)通过PCI-E总线连接到CPU，而RAM也通过FSB(前端总线)与CPU相连。

网卡接收到数据包后，一方面通过DMA(Direct Memory Access)将数据包内容写入到RAM，同时，利用中断机制通知内核。Linux操作系统会在网卡中断下半部(俗称软中断)调用iptables，进行安全处理及转发。

可想而知地，中断对CPU资源的占用是巨大的，因为它会打断正常的指令流水线，并造成cacheline miss，使得服务器的CPU资源被严重浪费在等待DRAM的读写上。

对于这个问题，常见的解决方案有两种：

1. 基于DPDK自行开发NFV组件实现高性能软件防火墙。但这需要使用方具备极强的开发能力，一般只适用于超大型公有云场景；
2. 使用硬件交换机的ACL及防火墙机制，来实现安全机制；

解决方案2，就是我们接下来要介绍的重点。

仍然以上期描述的前端与数据库交互为例：

我们知道，在有了硬件SDN提供的CNI插件后，可以利用硬件交换机实现硬件Overlay：

那么，有没有办法在交换机上配置ACL实现frontend和db容器组之间的访问控制呢？

我们发现，在容器的世界里，IP地址与容器标签是松耦合关系——

同一类容器标签的pod，不一定在同一个网段(CIDR)，而同一个网段中，又有可能有不同的容器标签……

假设db和frontend这两类pod共用网段 10.0.0.0/20，它们的IP如下表：

IP地址/掩码	容器标签
10.0.10.113/20	db
10.0.10.115/20	db
10.0.11.60/20	frontend
10.0.12.8/20	frontend
10.0.13.201/20	db
10.0.13.217/20	frontend

显然，在交换机上，是无法用绑定到网段的ACL来控制这两类容器的。我们需要一种比网段 + ACL更加精细的机制，来识别数据中心交换机上的端点——

这种机制叫微分段 (Micro Segmentation)。

《易经》曰：“君子知微知彰，知柔知刚，万夫之望。”

网络中的交换机，具备了微分段能力以后，才能做到“知微知彰”，更好地适配容器网络。

下一期中，我们将详解利用微分段让容器网络更加安全的机制。