Openshift网络架构详解与规划设计

前言：

本文仅代表作者个人观点，用户生产上的Openshift网络规划，还要需要咨询红帽架构师或实施专家。本文仅作为参考，并且不对个案的结果负责。

本文的网络介绍，是基于Openshift3.6版本，此前版本的Opeshift在网络细节方面略有不同。

本文在书写过程中，咨询了红帽郭跃军、张春良、张亚光、周荣等专家，在此表示感谢！

在本文中OCP指：Openshift Container Platform、OCP Node指Openshift集群的计算节点。

整体架构

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的东西向流量。

Openshift的网络规划

OCP如何做网络规划这个问题，很多人问过我。我们举个例子来说明。

一个客户有10台物理服务器，前3台做Master，后7台做node节点。存储使用NAS。

网络规划：

网络1：默认的Openshift集群内部使用的网络(不与网络冲突即可）

在这个网络中，有两个网段：Service IP网段和Pod IP网段（通通过编辑

/etc/origin/master/master-config.yaml进行修改）。

ServiceIP默认网段是172.30.0.0/16

Pod IP的默认网段是：10.128.0.0/14

这两个网段，都不需要分配数据中心IP。

网络2：生产环境业务网络：共需要12个IP。

其中：10个物理服务器，每个都需要1个IP。而因为Master节点是三个，需要有高可用，因此需要一个VIP。客户端访问Master的时候（通过浏览器、命令行），访问这个VIP即可。此外，为了保证routing layer的高可以用，在两个物理服务器上配置分别部署两个routing，然后给两台服务服务器配置一个VIP。

网络3：NAS网络。

需要保证10台物理服务器都可以与NAS网络正常通讯，因此需要配置与NAS网络可通讯的IP地址，每个服务器需要一个。

网络4：服务器硬件管理网络。

如果是HP服务器，硬件管理口是ilo，如果是联想的服务器，管理口是IMM。也需要10个IP。

因此，物理服务器配置，建议每个服务器至少配置两个双口网卡。前两个网卡做NIB，配置的是网络2：生产网络IP。后两个双口网卡配置NIB，配置网络3的IP，负责与NAS通讯。服务器一般有单独的物理管理口，不需要PCI网卡提供端口。

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。

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的环境变量来实现。

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。

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，对外进行通讯。

关于iptables的表，可以通过iptables -L进行查看：

#iptables -L

名词解释：

• br0: the OVS bridge device that pod containers will be attached to. OpenShift SDN also configures a set of non-subnet-specific flow rules on this bridge.br0会被分配Pod IP的网关。br0也是OVS的网桥，pod会与这个网桥链接在一起。CNI - openshift-sdn负责分配IP，具体而言，是在每个OCP节点的/opt/cni/bin下二进制的程序负责：

• tun0: an OVS internal port (port 2 on br0). This gets assigned the cluster subnet gateway address, and is used for external network access. OpenShift SDN configures netfilter and routing rules to enable access from the cluster subnet to the external network via NAT. tun0是OVS的内部端口，是整个OCP集群的默认网关，pod对外网的访问流量，从tun0出去。
• vxlan：该端口用于OCP Node之间pod通讯的流量，东西向流量。

参考文档：

https://docs.openshift.org/latest/architecture/networking/sdn.html

https://docs.openshift.org/latest/architecture/networking/routes.html#env-variables

https://docs.openshift.org/latest/architecture/networking/routes.html