在设计这套容器集群服务时，我从原来的k3s架构中分离出一个问题，那就是容器网络插件应该选择哪个。因为我设计的目标是给服务器领域使用的容器引擎，所以我就不需要考虑太多边缘IOT设备的情况，直接拉满技能找了cilium。cilium借助内核ebpf技术的出现，让我看到了网络性能更好的选择。

问题：

我一直是自己用k8e来解决需要容器服务的需求，所以没有太在意iptables的能力问题。有一天看到cilium提供了去除kube-proxy的解决方案，我特别高兴的把k8e中自带的kube-proxy代码去掉了。这个太好了。大家知道在kube-proxy时代，SVC的规则是通过不断刷iptables的规则表实现的。因为是clusterip，那么一个业务ip，就需要刷所有主机的iptables规则表。早期100台服务器还可以，老外使用k8s也没有那么大集群。随着中国IaaS厂商的all in，这把k8s的集群规则拉满到上万台，iptables的问题就被暴露出来了。华为云马上提出了使用IPVS技术来解决部分问题：南北向的规则本身就是Proxy机制，使用IPVS可以通配符规则，这样就可以一个网段一个网段的配置，规则数量马上就下来了。几千台机器刷一遍也不成问题。但是这里还是甩不掉kube-proxy来解决东西向网络的DNAT网络的问题，解决方法好办，请使用更高级的SDN overlay网络插件来解决，比如cilium。几千台机器使用flannel是搞不定了。知道吧。但是经过实践发现，我们误解了cilium的能力，在kernel 4.19环境下，我们仍然无法丢掉iptables。好多特性kernel还是搞不定。

注意：

cilium的官方文档默认提示基础网络功能，Kernel >=4.9，但是cilium依据ebpf还提供了