Calico在Openshift上的工作原理与配置步骤：第一篇

由于篇幅和时间有限，本文还会有第二篇。

一、Openshift支持的各种SDN CNI

Openshift Container Platform（简称OCP），在V3.6之前，SDN是由OVS实现的，当时也只支持OVS。

OCP从V3.6开始，正式支持多种容器网络接口，Container Network Interface 简称CNI。CNI可以作为第三方插件，部署到OCP上。当然，OCP默认还是使用OVS，除非在安装OCP时进行容器网络接口的选择。

目前OCP支持的CNI有：

Cisco Contiv (™)

Juniper Contrail (™)

Nokia Nuage (™)

Tigera Calico (™)

VMware NSX-T (™)

下面我们对这几种类型的CNI做简单的介绍，笔者在某些方案商，也没做过多的研究，因此不会对几种方案进行对比。此外，本文介绍的重点将放在Calico在OCP上的实现。

1.1 Cisco Contiv (™)

Contiv是Cisco的Docker SDN方案，它是一个开源项目（http://contiv.github.io/）。Contiv支持2层、3层和ACI（以应用为中心的基础设施）模式作为网络拓扑。使用ACI模式，Contiv提供统一的网络结构，一个单一的网络面板，用于部署在容器、虚拟机和裸机上的云本地和传统应用程序。

1.2 Juniper Contrail

Contrail Networking是一种简 单、开放和敏捷的云网络自动化 产品，它利用SDN来编排如何 创建高度可扩展的虚拟网络。 Contrail Networking采用了一 种可与物理路由器和交换机互操 作的横向扩展架构，能够灵活地 将基础设施扩展到数据中心或云 边界以外，可以在一个混合环境 中支持动态的工作负载移动性。 服务提供商可以使用Contrail Networking来加快创新服务的 部署，同时，企业则可以利用它 将应用和IT资源迁移到更灵活的 私有云或混合云环境，以提高业 务的敏捷性。根据最新的新闻，Juniper已经将 Contrail托管到Linux基金会下。

1.3 Nokia Nuage (™)

Nuage是诺基亚的SDN解决方案，其架构图如下：

1.4 VMware NSX-T (™)

谈到NSX，相信了解VMware方案的朋友都不会陌生。在以前NSX，只能支持vSphere。现在，NSX已经可以支持多平台。

笔者在两年以前，对NSX进行过一些较为深入的学习，目前NSX的认证也过期了，因此可能一些新的功能目前不了解。

1.5 Tigera Calico

Calico是一个开源项目（https://github.com/projectcalico）

https://kubernetes.io/docs/concepts/cluster-administration/networking/

不过，从github上面的代码提交量和贡献者来看，此项目活跃度并不是特别高：

很多朋友比较关注Calico，主要是可以配置成非叠加网络。

二、Calico的架构

Calico整个SDN架构的服务发现使用etcd。在每个容器的计算节点（如OCP Node）上，启动一个名为Calico-node的容器。在OCP集群中，还会部署一个策略管理的容器，它与每个计算节点上的Calico-node通过etcd进行通讯，下发指令。

接下来，我们详细看一下Calico与OCP是如何一起工作的。

首先，每个OCP Node上会安装Calico-CNI和Calico-IPAM两个组件。

Calico在OCP上部署完毕后，Calico-node这个容器会负责本地路由、策略计算以及BGP管理。

此外，在OCP上，还会银行一个策略控制器的容器，作为OCP上Calico整个SDN的管理。

2.1 Calico在OCP上的部署

OCP的默认安装，请参照我同事陈耿的文档（链接如下），这种方式安装的OCP，是基于OVS的：

https://github.com/nichochen/openshift-docs/blob/master/openshift-3.7-1master-cn.md

如果安装基于Calico的OCP，那么首先，在安装之前需要修改OCP安装的/etc/ansible/hosts，加入如下内容：

os_sdn_network_plugin_name=cni

openshift_use_calico=true

openshift_use_openshift_sdn=false

此外，如果Calico的etcd使用OCP的etcd，那么/etc/ansible/hosts加入以上三行内容就可以了。如果要使用独立与OCP etcd，则增加如下配置：

calico_etcd_endpoints=https://192.168.250.100:2379

calico_etcd_ca_cert_file=/etc/calico/etcd-ca.crt

calico_etcd_cert_file=/etc/calico/client.crt

calico_etcd_key_file=/etc/calico/client.key

calico_etcd_cert_dir=/etc/calico/

除此之外，我们还需要关注Calico的使用策略，比如使用ipip方式，还是使用扁平网络。

根据需要，将下面的内容注释或者反注释（ /usr/share/ansible/openshift-ansible/roles/calico/defaults/main.yaml）。

在OCP上安装Calico的时候，OCP会尝试从github上获取几个文件。由于文件较大，如果在线获取，超时安装失败的概率很大。

因此，建议本地搭建http服务器，将 /usr/share/ansible/openshift-ansible/roles/calico/defaults/main.yaml中软件包的地址，改成本地的http服务器。另外，calico的docker image，也需要提前down下来；calicoctl这个可执行文件，down下来以后，copy到OCP节点的/usr/bin下，并增加可执行权限。

我搭建的本地http服务器：

在修改完/etc/ansible/hosts和 /usr/share/ansible/openshift-ansible/roles/calico/defaults/main.yaml两个配置文件以后，就可以按照相同的安装命令，开始安装OCP3.7了。

安装成功以后，在OCP上，可以查看Calico的状态。我们实验环境有两个节点：一个Master（192.168.137.10）、一个node（192.168.137.11）。

在Master上查看：

在node上查看：

2.2 Calico在OCP上的架构验证

首先，我们在master和node上都可以看到Calico-node这个容器：

我们可以很容易发现，master和node上的Calico-node并不是一个。

这两个容器，不是被OCP控制的，而是被OCP master和node的calico系统服务控制的：

这个系统服务的配置文件：

/usr/lib/systemd/system/calico

除了master和node上的docker-node容器。OCP上还有一个Calico SDN整体控制管理的策略管理器容器，它是由OCP控制的（pod放到了一个project中）。

我们查看OCP中所有调用Calico API的namespace（实际上启动Calico的OCP集群上，所有project都会调用Clico API，不存在OVS和Calico共存于一个OCP集群的情况）

查看调用Calido API的pods：

我们查看一下Calico的etcd中节点信息的记录：

查看master节点：

查看node节点：

三、Calico on OCP与OVS ON OCP的对比

在进行Calico on OCP与OVS on OCP对比之前，我们需要了解OVS on OCP默认下，SDN的工作原理。

3.1 OVS on OCP

Openshift Container Platform（下面简称OCP）的整体架构如下：

和网络有关的有两块：Routing Layer和Service Layer。

Routing layer是一个容器化的HAproxy。每个计算节点最多有一个，一个OCP集群中可以有多个。需要注意的是，这个容器化的HAproxy，目前只能处理7层的http/https/websockets/TLS（with SNI）请求。Routing Layer负责将应用的FQDN最终解析成容器的Pod IP。

Service IP其实就是K8S中的Cluster IP方式,这也是OCP是默认的方式。在这种方式下，service将会暴露给cluster ip，cluster ip只能被内部访问。如果service想被外部访问，要想被外部访问，就要用router。cluster IP是集群内部svc之间通讯的时候的寻址方案。换言之，负责pod的东西向流量。

3.1.1 Openshift流量访问详解

接下来，我们看一下，应用访问容器里的应用的详细介绍。

举个例子，我们从笔记本客户端，要访问myadd.mydomain.org:80。在浏览器输入这个地址以后：

第一步：DNS将会解析这个域名，将它解析成运行routing layer所在的OCP Node IP。这就需要数据中心的DNS，将应用的FQDN，解析成OCP集群物理服务器的IP地址（如果OCP集群有两个router，那需要给两个router所在的两个物理服务器的IP配置一个VIP，然后将应用的FQDN解析成这个VIP）。

第二步：客户端对80端口的访问请求，将会到达routing layer。

第三步：routing查看FQDN对应的enpoints（Pod IP）。如果pod在routing layer所在的ocp节点，那么直接内部通讯。

第四步：如果pod不在routing layer所在的ocp节点，请求将会通过OCP内部的OVS，转到到对应ocpnode上的pod IP：10.1.0.2:8080。

3.1.2 Routing Layer的负载均衡功能

当一个应用对应多个pod，routing layer将会做不同pod之间的负载均衡。负载均衡有三种策略：

roundrobin、leastconn、source。

roundrobin：根据每个pod的权重，平均轮询分配。在不改变routing的默认规则下，每个pod的权重一样，haproxy转发包也是轮着来。

如果我们更改了每个pod的权重，那轮询的时候，也会根据权重来转发请求。如下图：V2和V1是3:2。那么haproxy会给V2发两个包，给V1发一个，周而复始。

leastconn：routing layer转发请求的时候，按照哪个pod的连接数最少，将新的请求发给连接数最少的pod。一般这种方式适合长连接，短链接不建议使用。

source：将源IP地址先进行哈希，然后除以正在运行的pod总权重，然后算出哪个节点接受请求。这确保了只要没有服务器发生故障，相同的客户端IP地址将始终到达同一个pod。

三种方式，可以通过设置routing layer的环境变量来实现。

3.1.3 OCP租户网络隔离的设置

在OCP中，租户（project）之间的网络，有两种方式：ovs-subnet和ovs-multitenant。

ovs-subnet是默认的方式，在这种情况下，project之间是可以相互内部通信的。而在ovs-multitenant模式下，每个project之间是不能相互通讯的，除非手动指定哪两个或哪几个项目之间可以内部通讯。

在OCP中，OVS模式的设置，在master和node上是分别设置的。

每个Master上的配置文件：

/etc/origin/master/master-config.yaml

默认是redhat/openshift-ovs-subnet，如果想改成租户隔离，则修改为：redhat/openshift-ovs-multitenant

每个Node上的配置文件：/etc/origin/node/node-config.yaml

默认是redhat/openshift-ovs-subnet，如果想改成租户隔离，则修改为：redhat/openshift-ovs-multitenant。

3.1.4 Pod通讯方式详解

Pod的通讯，分为两大种情况：

• pod之间的通讯
• pod与外部网络的通讯

针对第一种情况，pod直接的通讯又分为两种情况：

（1）两个pod在一个OCP Node上：

例如Pod1要和pod2进行通讯（在ovs的br0中转发是依赖于Openflow的流表规则）：

通讯流量是这样走的：pod1的eth0→veth1→br0→veth2→pod2的eth0

（2）两个pod在不同的OCP Node上：

Pod1（OCP NodeA）要与Pod3（OCP NodeB）进行通讯。

通讯流量是这样走的：Pod1的eth0→veth1→br0→vxlan0→ OCP nodeA的eth0网卡→OCP NodeB的eth0网卡→vxlan0→br0→veth3→ Pod3的eth0.

针对第二种情况，pod对外通讯：

PodA的eth0→vethA→br0→tun0→ 通过iptables实现NAT→ OCP nodeA的eth0(physical device) → Internet

所以，综上所述，pod通讯的流量总图如下：

总结：

1. 一个OCP Node上的pod通讯，流量只会到br0，不会到节点的物理网卡；
2. 不同OCP Node上的pod通讯，流量会穿过VXLAN和OCP Node的物理网卡，最终到另外一个OCP Node的物理网卡和vxlan，流量不会走到交换机的uplink。
3. 一个pod与外网进行通讯，流量领过br0的时候，不会再经过vxlan，而是通过iptables进行地址转换，转换为OCP的Node IP，对外进行通讯。

3.2 Calico on OCP对比 OVS on OCP

看完了以上的内容，下表中左边一列，理解起来就不成问题了（下表为Tigera, Inc提供，不代表Redhat官方观点，仅供参考）。从技术角度，左边一列对OVS on OCP的藐视，是准确的。

以上表格右边一列，由于目前篇幅和时间有限，笔者将在第二篇文章中展开讨论和研究。届时分享给读者，届时我们一起印证结果。

参考文献

http://blog.sina.com.cn/s/blog_9fb1c50f0102xgps.html

https://www.juniper.net/assets/cn/zh/local/pdf/datasheets/1000521-cn.pdf

https://www.slideshare.net/ZvikaGazit/kubernetes-networking-in-aws

Simplifying and Securing Your OpenShift Network with Project Calico