Rancher v1.2基础设施引擎整体架构分析

Rancher Labs官方于12月1日发布了其容器部署与管理平台Rancher的最新版本,Rancher v1.2。Rancher v1.2可以说是一个里程碑版本,只要体会其新版功能,会发现漫长的等待绝对是值得的。

从架构角度看,用两个字来概括就是“解耦”,基础设施引擎的分离,agent节点的服务粒度更细;

从产品角度看,给了用户更多定制的空间,Rancher依然秉持着全部OpenSource的理念;

在开发语言上,之前遗留的通过shell脚本方式的粗糙实现也都基于Golang重写,解耦的新服务也几乎使用Golang开发,agent节点全线基于Golang这也为后续便利地支持ARM埋下伏笔;

在市场选择上,Rancher依然在kubernetes下面投入了大量精力,引入了万众期待的CNI plugin管理机制,坚持要做最好用的Kubernetes发行版。

本文就带着大家从架构角度总览Rancher v1.2版本的特性。

架构总览

在v1.2版本的整体架构图(如下图所示)上,Cattle引擎向下深入演化成了基础设施引擎,这一点上在v1.1时代也早有体现。Cattle更多得作为基础设施的管理工具,可以用它来部署其他服务和编排引擎,当然它本身编排能力还是可以使用的,习惯了stack-service的朋友仍然可以继续使用它,同时rancher scheduler的引入也大大增强了其调度能力。Rancher仍然支持Kubernetes、Mesos、Swarm三大编排引擎,Kubernetes可以支持到较新的v1.4.6版本,由于所有的部署过程的代码都是开放的,用户依然可以自己定制部署版本。值得一提的是,Rancher支持了新版的Swarm Mode也就是Swarmkit引擎,这也意味着Rancher可以在Docker1.12上部署,不小心装错Docker版本的朋友这回可以放心了。

 

20161207094345

 

在存储方面,Rancher引入了Kubernetes社区的flexvol来做存储插件的管理,同时也支持Docker原生的volume plugin机制,并实现了对AWS的EFS&EBS以及标准NFS的支持,先前的Convoy应该会被抛弃,Rancher最终还是选择参与社区标准。在网络方面,除了CNI插件机制的引入,用户还可以使用rancher-net组件提供的vxlan网络替代先前的ipsec网络。在可定制性方面,还体现在Rancher提供了用户可以自定义rancher-lb的机制,如果特殊场景下默认的Haproxy不是很给力时,用户可以自定义使用nginx、openresty或者traefik等等。下面便做一下详细分解。

基础设施引擎

初次安装v1.2版本,会发现多了Infrastructure(如下图所示)的明显标识,默认的Cattle引擎需要安装healthcheck、ipsec、network-services、scheduler等服务。这个是有rancher-catalog来定义的,https://github.com/rancher/rancher-catalog,新分离出来了infra-templates和project-templates:infra-templates就是Rancher定义的各种基础设施服务,包括基础服务和编排引擎;project-templates对应的是Env初始化时默认安装的服务,它可以针对不同的编排引擎进行配置。

 

20161207094352

 

以Cattle引擎为例,可以在project-templates的Cattle目录中找到相应的配置文件,当ENV创建初始化时会创建这里面定义的服务,这样一个机制就可以让我们可以做更深入的定制,让ENV初始化时创建我们需要的服务:

 

20161207094409

 

在Cattle引擎调度方面,Rancher实现了rancher-scheduler,https://github.com/rancher/scheduler。它实现了允许用户按计算资源调度,目前支持memory、cpu的Reservation。其实现原理是,内部有一个resource watcher,通过监听rancher metadata的获取Host的使用资源数据变化,进而得到ENV内所有Host资源汇总信息。与此同时,监听rancher events的scheduler.prioritize、scheduler.reserve、scheduler.release等各种事件,通过排序过滤可用主机后发送回执信息,Rancher Server就有了可以选择的Host列表。如下图所示:

 

20161207094418

 

需要注意的是,rancher-scheduler并没有和rancher-server部署在一起,而是在你添加Host时候部署在agent节点上,当然rancher-scheduler在一个ENV内只会部署一个。

Agent节点服务解耦

agent节点一个最大的变化就是,agent-instance容器没有了,它被拆分成多个容器服务,包括rancher-metadata、network-manager、rancher-net、rancher-dns、healthcheck等。

 

20161207094424

 

metadata服务是老朋友了,它在每个agent节点上保存了host、stack、service、container等的信息,可以非常方便的在本地调用取得,https://github.com/rancher/rancher-metadata,在新的体系中它扮演了重要角色,几乎所有agent节点上的服务均依赖它。在先前的体系中,metadata的answer file的更新是通过事件驱动shell脚本来执行下载,比较简单粗暴。v1.2开始使用监听rancher events方式来reload metadata的answer file,但是answer file还需要到rancher server端下载,总的来说效率还是有一定提升的。

dns在新的体系中仍然承担着服务发现的功能,https://github.com/rancher/rancher-dns。除了拆分成单独容器之外,它也在效率上做了改进,它与rancher-metadata容器共享网络,以metadata的结果生成dns的answer file。与之前的架构相比,省去了dns answer file下载的过程。需要注意的是,rancher-dns的TTL默认是600秒,如果出于各种原因觉得dns作为服务发现不是很可靠,那么可以使用etc-host-updater和rancher-metadata的组合,etc-host-updater(https://github.com/rancher/etc-host-updater)会根据metadata数据动态生成hosts文件并写入容器内,这样通过服务名访问时,其实已经在本地转换成了IP,无需经过dns,如下图所示:

 

20161207094431

 

rancher-net作出了比较重大的革新,https://github.com/rancher/rancher-net,除了继续支持原有的ipsec外,还支持了vxlan。这个支持是原生支持,只要内核有vxlan的支持模块就可以。vxlan并不是Cattle的默认网络,使用时可以在infra-catalog中重新选择它来部署,其实现以及部署方式后续会在专门的文章中进行探讨:

 

20161207094437

 

network-manager的引入为Rancher v1.2带来了一个重要特性就是CNI插件管理,在之前的版本中很多用户都提到rancher-net本身的网络无法满足业务需求。容器网络之争,无非就是CNM与CNI,Rancher选择站队CNI,这也是为了更好与Kubernetes融合。而CNI的插件很多种,Calico、Weave等之流,每个插件的部署方式都不一样。Rancher为了简化管理提出了network-manager,https://github.com/rancher/plugin-manager,它可以做到兼容主流的CNI插件,它实际上定义了一个部署框架,让CNI插件在框架内部署。network-manager是以容器方式部署,由于每种插件在初始化时可能需要暴露端口或加入一些NAT规则,所以network-manager能够动态设置不同插件的初始化规则,它的做法是以metadata作为 host port和host nat规则的数据源,然后获取数据后生成相应的Iptables规则加入的Host中。而对于真正的CNI插件,需要在network-manager容器内/opt/cni目录下部署对应cni插件的执行程序(calico/weave),/etc/cni目录下部署cni插件的配置,这两个目录映射了docker卷rancher-cni-driver,也就是Host上的/var/lib/docker/volumes/rancher-cni-driver目录下。

关于healthcheck,先前是通过agent-instance镜像实现,里面内置了Haproxy,事件驱动shell脚本来下载healchcheck配置并reload。新的架构中,Rancher实现了单独的healthcheck,https://github.com/rancher/healthcheck,采用Golang微服务的方式,数据源是metadata。当然healthcheck的最终检查仍然是通过与Haproxy sock通信来查看相应member的健康状态(原理如下图),healthcheck的实现主要是为了将其从agent-instance中解耦出来。

 

20161207094444

 

总结

Rancher v1.2的新特性非常多,基础设施引擎的变化是一切特性的基础,在这篇开篇之作之后,我们后续会持续为大家带来KubernetesSwarmkit的支持、自定义rancher-lb、vxlan的支持、各种CNI插件的集成以及各种存储接入的实践操作指南等等。

分享到:更多 ()