【摘要】PaaS的抽象逻辑使得其网络模型与IaaS有所不通，本次通过重点说明Kubernetes和Docker的网络，从而来探究PaaS的网络模型设计。

PaaS和IaaS的网络需求

概念上来说，IaaS是基础架构即服务，PaaS是平台即服务。从服务化角度来说两者对于网络的需求有共同点：

1. 一台宿主机的网络隔离，一台宿主机要运行多个环境黑盒（VM或者容器），这时候每个环境黑盒的网络需要隔离。

2. 环境变更后的访问一致性，比如VM或者容器迁移到其他宿主机的时候，如何保证外部访问不感知，比较通用的解决方案网络代理层来解决。

实现上来说，IaaS是VM管理，PaaS是容器编排，两者的网络也会有些不同：

1. 容器比VM轻量级，启停更快，更方便迁移，所以PaaS的整个调度策略会更灵活，容器的迁移频率是高于VM，当容器迁移的时候，PaaS需要更加快速的解决变化后的网络访问。

2. VM安全高于容器，IaaS这部分会更多在隔离和安全上有所考虑，当然这个可能是公有云和私有云的一个定位，个人认为IaaS比较适合公有云，PaaS比较适合私有云。

PaaS的网络模型设计

以上部分我们讨论了PaaS网络需求，总结来说PaaS需要解决宿主机的网络隔离和环境变更后的访问一致性问题，然后在灵活性上需要更加注重，私有云的定位可以减少因为安全和隔离的代价，保证高性能。

宿主机的网络隔离

网络隔离最基本问题就是要解决端口冲突，一种思路是容器通过端口映射访问，宿主机的端口由系统分配避免端口冲突，这种方式对使用的便利性是有意义的，但并不理想，因为需要对各种端口进行映射，这会限制宿主机的能力，在容器编排上也增加了复杂度。

端口是个稀缺资源，这就需要解决端口冲突和动态分配端口问题。这不但使调度复杂化，而且应用程序的配置也将变得复杂，具体表现为端口冲突、重用和耗尽。

NAT将地址空间分段的做法引入了额外的复杂度。比如容器中应用所见的IP并不是对外暴露的IP，因为网络隔离，容器中的应用实际上只能检测到容器的IP，但是需要对外宣称的则是宿主机的IP，这种信息的不对称将带来诸如破坏自注册机制等问题。

所以就要引入一层网络虚拟层来解决网络隔离，现在说的比较多的大二层网络，L2 over L3，比如OVS、Flannel、Calico等等。

环境变更后的访问一致性

一个通用方案来说通过代理层提供不变的访问入口，像OpenStack的网络节点就是一个L3（IP）的访问入口，而PaaS更多的是提供L4（TCP、UDP）和L7（HTTP）的访问，L4比较流行的开源方案有LVS，L7的是Nginx和Haproxy。

因此PaaS的网络结构有：

1. 物理网络

2. 虚拟层网络

3. 代理层网络

Kubernetes和Docker的网络说明

Kubernete Docker作为目前最流行的开源PaaS实现，通过其实现细节可以更加理解PaaS的网络模型实践。

容器网络

Docker使用Linux桥接，在宿主机虚拟一个Docker容器网桥（docker0），Docker启动一个容器时会根据Docker网桥的网段分配给容器一个IP地址，称为Container-IP，同时Docker网桥是每个容器的默认网关。因为在同一宿主机内的容器都接入同一个网桥，这样容器之间就能够通过容器的Container-IP直接通信。

Docker网桥是宿主机虚拟出来的，并不是真实存在的网络设备，外部网络是无法寻址到的，这也意味着外部网络无法通过直接Container-IP访问到容器。

Pod内部容器通信

Kubernetes中Pod是容器的集合，Pod包含的容器都运行在同一个宿主机上，这些容器将拥有同样的网络空间，容器之间能够互相通信，它们能够在本地访问其他容器的端口。

实际上Pod都包含一个网络容器，它不做任何事情，只是用来接管Pod的网络，业务容器通过加入网络容器的网络从而实现网络共享。

Pod的启动方式类似于：

		$ docker run -p 80:80 --name network-container -d <network-container-image>

所以Pod的网络实际上就是Pod中网络容器的网络，所以往往就可以认为Pod网络就是容器网络，在理解Kubernetes网络的时候这是必须要需要清楚的，比如说Pod的Pod-IP就是网络容器的Container-IP。

Pod间通信

Kubernetes网络模型是一个扁平化网络平面，在这个网络平面内，Pod作为一个网络单元同Kubernetes Node的网络处于同一层级。

在这个网络拓扑中满足以下条件：

• Pod间通信：Pod1和Pod2（同主机），Pod1和Pod3（跨主机）能够通信

• Node与Pod间通信：Node1和Pod1/ Pod2（同主机），Pod3（跨主机）能够通信

为此需要实现：

• Pod的Pod-IP是全局唯一的。其实做法也很简单，因为Pod的Pod-IP是Docker网桥分配的，所以将不同Kubernetes Node的Docker网桥配置成不同的IP网段即可。

• Node上的Pod/容器原生能通信，但是Node之间的Pod/容器如何通信的，这就需要对Docker进行增强，在容器集群中创建一个覆盖网络（Overlay Network），联通各个节点，目前可以通过第三方网络插件来创建覆盖网络，比如Flannel和Open vSwitch等等。

Flannel由CoreOS团队设计开发的一个覆盖网络工具，Flannel 通过在集群中创建一个覆盖网络，为主机设定一个子网，通过隧道协议封装容器之间的通信报文，实现容器的跨主机通信。Flannel将会运行在所有的Node之上，Flannel实现的网络结构如图所示：

代理层

Kubernetes中的Service就是在Pod之间起到服务代理的作用，对外表现为一个单一访问接口，将请求转发给Pod，Service的网络转发是Kubernetes实现服务编排的关键一环。

Service都会生成一个虚拟IP，称为Service-IP， Kuberenetes Porxy组件负责实现Service-IP路由和转发，在容器覆盖网络之上又实现了虚拟转发网络。

Kubernetes Porxy实现了以下功能：

• 转发访问Service的Service-IP的请求到Endpoints（即Pod-IP）。

• 监控Service和Endpoints的变化，实时刷新转发规则。

• 负载均衡能力。

Kubernetes Porxy是一种分布式L3代理转发， 默认是基于Iptables实现，这从设计上很值得借鉴，但是性能部分有待验证。

Kubernetes中的Ingress提供了一个统一的对外代理入口配置，比如HTTP的访问配置，然后通过实现Ingress-Controller，Ingress-Controller的实现可以用Nginx、LVS等等，以Nginx来说，就Ingress-Controller监控Kubernetes API，生成Nginx配置，然后加载生效，而Nginx跟Pod的通信，可以走Service，但是考虑到Kubernetes Porxy的性能问题，建议直接和Pod通信。下面就是一个实现图：

整体来看的一个网络模型如下：

关于：中科研拓

深圳市中科研拓科技有限公司专注提供软件+硬件结合系统解决方案定制开发服务，其中包括：软件外包、软件开发、软件定制、硬件开发、硬件定制、智能硬件开发、物联网项目等开发外包服务，通过IT技术实现创造客户和社会的价值，成为优秀的软件公司，通过客户需求导向、开放式创新、卓越运营管理等战略的实施，全面打造公司的核心竞争力。优秀软件外包公司、软件开发公司，联系电话400-0316-532，邮箱sales@zhongkerd.com，网址www.zhongkerd.com