DockOne微信分享(一三零):探究PaaS网络模型设计


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

【3 天烧脑式容器存储网络训练营 | 深圳站】本次培训以容器存储和网络为主题,包括:Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage机制、容器网络实现原理和模型、Docker网络实现、网络插件、Calico、Contiv Netplugin、开源企业级镜像仓库Harbor原理及实现等。

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直接通信。
QQ截图20170712141024.png

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

Pod内部容器通信

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

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

Pod的启动方式类似于:
$ docker run -p 80:80 --name network-container -d <network-container-image>
$ docker run --net container:network-container -d <image>

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

Pod间通信

Kubernetes网络模型是一个扁平化网络平面,在这个网络平面内,Pod作为一个网络单元同Kubernetes Node的网络处于同一层级。
QQ截图20170712141318.png

在这个网络拓扑中满足以下条件:
  • 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实现的网络结构如图所示:
QQ截图20170712141425.png

代理层

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通信。下面就是一个实现图:
QQ截图20170712141523.png

整体来看的一个网络模型如下:
QQ截图20170712141604.png

Q&A

Q:有这么多虚拟网络,覆盖网络,会不会有网络延迟?

A:网络虚拟会带来性能损耗,比如Flannel需要将报文封装到UDP包中传输,这中间的封包解包就会带来损耗。所以网络虚拟化的部分,软件的实现还有待优化,其实更好的方式是硬件支持,比如现在提的很多的SDN网络。
Q:Pod为什么要有个网络容器?

A: 一方面这是解耦,通过网络容器来负责网络配置,这样对于业务容器来说稳定性会更高,比如在多个业务容器中,某一个业务容器断了,这样就不会导致网络中断。
Q:Calico默认全网是打通的,怎么做基于网段之间的隔离?

A:目前来说要做网段隔离,可能偏向安全性比较高的场景,我们目前是做私有云场景,对隔离的要求没那么高。所以如果要做隔离的话,可以参考OpenStack的OVS方案。
Q:在某些应用场景下,Pod的IP需要固定,而不是重启之后IP可能会变化,请问如何满足这种场景的需求?

A:Pod的IP需要固定的话,一种方式是修改Docker的代码,据我所知腾讯有实现过。另外的方案就是做L3的代理,给Pod一个浮动IP,有点像OpenStack的实现。
Q:Ingress的流量默认是先走Service然后到Pod,还是直接到Pod?

A:取决你的实现,官方的实现是先走Sevice再到Pod,我们是直接到Pod。
Q:Ingress-Controller实现除了使用LVS和Nginx外,能否采用商用负载设备来实现?实现是否取决于和Kubernetes API的对接?

A:可以,只要有接口都可以实现,通过实现Ingress-Controller,比如对接F5的硬件设备,只要F5支持相关的API。
Q:代理入口上有哪些方法解决单点失效的问题呢?

A:这个比较传统了,软件实现就Keepalived之类的。
Q:Igress-Cntroller比较好的库都有哪些,分别基于Nginx Haproxy LVS的?

A:GitHub有蛮多实现的,其实还是比较简单的,像go语言的话,直接套用官方提供的demo即可,其他语言可以对接Kubernetes的API实现。
Q:这么多层的网络,多层转发后网络性能怎么样?有没有办法实现高速数据转发解决方案?

A:代理层,虚拟层都会有损耗,这个就是要考虑管理成本和性能的权衡了。如何要实现高性能的话,就是要往SDN网络研究,通过硬件层的支持来实现虚。
以上内容根据2017年07月11日晚微信群分享内容整理。分享人吴龙辉,网宿科技云计算架构师,负责设计开发PaaS平台,《Kubernetes实战》作者。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesa,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

0 个评论

要回复文章请先登录注册