本文介绍了一个数据中心网络方案Calico，包括其优势、架构、性能分析、工作原理，以及分析了生态云Kubernetes版应用引擎在Calico中的policy设置策略。
小米生态云旨在为小米生态链企业及合作伙伴提供云计算、大数据、人工智能、安全及合规等一站式云服务和整体解决方案。生态云上有一款基于Kubernetes研发的新版应用引擎已经为几十家企业提供服务，每家企业的数据保护最为重要，为此我们探讨了诸多方案的可行性，最终使用Calico网络方案。
Calico简介
Calico是纯3层的数据中心网络方案，它是目前Kubernetes networkpolicy概念的最佳实现方案之一，利用虚拟路由代理虚拟交换，每一台虚拟路由通过BGP协议传播可达信息(路由)到剩余数据中心。
Calico优势
1. 支持Kubernetes networkpolicy概念
2. 容器间网络三层隔离，无需要担心arp风暴
3. 自由控制的policy规则
4. 网络拓扑直观易懂，扩展性强
5. 通过iptables和kernel包转发，效率高，损耗低
Calico架构图
Calico包括如下重要组件：Felix，Etcd，BGP Client，BGP Route Reflector。Felix 、BGPClient 部署在node节点，BGPRouteReflector部署在Master，下面分别说明一下这些组件。
Felix：主要负责路由配置以及ACLS规则的配置以及下发，它存在在每个node节点上。
Etcd：分布式键值存储，主要负责网络元数据一致性，确保Calico网络状态的准确性，一般与Kubernetes共用。
BGP Client(BIRD)：负责把Felix在各node上设置的路由信息广播到Calico网络( 通过BGP协议)。
BGP Route Reflector：集中式的路由分发。
Calico原理
如下图所示：原网络通过路由表和iptables，再经过数据中心路由，最终到达目地网络路由，最后分配到目地容器。
Kubernetes版应用引擎的设置策略
因为企业用户会在Kubernetes版应用引擎中建立多个namespace，故不能使用基于namespace的policy策略，我们使用label的方式进行policy的自定义。
以A公司为例子：
实验环境所用的3个namespace是：ami-a、ami-b、bmi三个
1. 新建namespace并打标签org=ami、org=bmi
kubectl create -f - <2.Calico默认策略是相同子网的pod互相访问是通的，不管namespace是否相同。
为此我们需要先建一个全局策略来禁业pod IP访问。然后再单独为ami和bmi建立policy。
(1)全局禁业策略如下：
kubectl create -f - <(2)单独为ami和bmi创建策略如下：
calicoctl create -f - <order越小代表执行策略越靠前，Calico执行的是聚合策略。
通过这样的配置 即使namespace不同，但只要label相同，网络就会互通，我们为每家企业提供不同的label，这样就达到我们目地。
3.让我们来验证一下
(1)我们新建了三个namespace别分是：
ami-a label org-ami
ami-b label org-ami
bmi label org-bmi
两个ami label相同，bmi单独一个label。
建立完成后，使用命令kubectl get namespace ns -o yaml 分别看下建立后的namespace label。
(2)分别在每个namespace中建一个container ，使用kubectl create -f .建立三个container。
创建完成的pod IP如下：
(3)PING测试
登陆ami-a的nginx pod 去PING ami-b的pod IP看是否通：
结果是通的。
登陆ami-b的nginx pod 去PING ami-a的pod IP看是否通：
结果也是通的。
登陆 ami-a中nginx pod 去PING bmi的pod IP是否相通：
结果显示不通。
以上结果验证了我们使用Calico做的policy策略得以生效，并满足我们的需求。
Calico性能
Calico是基于Golang开发，CNI网络模型，并发性能好，且policy也是基于iptables,建立各种ACLS，iptables又是基于内核转发，再加上不像flannel有对包进行加解密的操作，节省了CPU的资源。
经过网上测试和内部测试，结论：性能仅次于物理连接。
1. 网上各网络组件测试结果：
2. 内部Calico和flannel 对比测试：
总结
Calico之所以能大规模应用，主要是其良好的性能，并且policy的配置足够灵活，可以满足大部分公有云厂商的需求。Calico不光可以应用于Kubernetes，还可以应用于像openstack、VM等其他云管理平台。
唯一的不足就是当node过多(几万台级)，维护的路由表就会过大，全表扫描会有性能问题(目前生态云还未有)，如果出现性能问题可以改成IPVS的方式。