摘要：官方于月日发布了其容器部署与管理平台的最新版本，。架构总览在版本的整体架构图如下图所示上，引擎向下深入演化成了基础设施引擎，这一点上在时代也早有体现。基础设施引擎初次安装版本，会发现多了如下图所示的明显标识，默认的引擎需要安装等服务。
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版本的朋友这回可以放心了。
在存储方面，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/ra...，新分离出来了infra-templates和project-templates：infra-templates就是Rancher定义的各种基础设施服务，包括基础服务和编排引擎；project-templates对应的是Env初始化时默认安装的服务，它可以针对不同的编排引擎进行配置。
以Cattle引擎为例，可以在project-templates的Cattle目录中找到相应的配置文件，当ENV创建初始化时会创建这里面定义的服务，这样一个机制就可以让我们可以做更深入的定制，让ENV初始化时创建我们需要的服务：
在Cattle引擎调度方面，Rancher实现了rancher-scheduler，https://github.com/rancher/sc...。它实现了允许用户按计算资源调度，目前支持memory、cpu的Reservation。其实现原理是，内部有一个resource watcher，通过监听rancher metadata的获取Host的使用资源数据变化，进而得到ENV内所有Host资源汇总信息。与此同时，监听rancher events的scheduler.prioritize、scheduler.reserve、scheduler.release等各种事件，通过排序过滤可用主机后发送回执信息，Rancher Server就有了可以选择的Host列表。如下图所示：
需要注意的是，rancher-scheduler并没有和rancher-server部署在一起，而是在你添加Host时候部署在agent节点上，当然rancher-scheduler在一个ENV内只会部署一个。
Agent节点服务解耦agent节点一个最大的变化就是，agent-instance容器没有了，它被拆分成多个容器服务，包括rancher-metadata、network-manager、rancher-net、rancher-dns、healthcheck等。
metadata服务是老朋友了，它在每个agent节点上保存了host、stack、service、container等的信息，可以非常方便的在本地调用取得，https://github.com/rancher/ra...，在新的体系中它扮演了重要角色，几乎所有agent节点上的服务均依赖它。在先前的体系中，metadata的answer file的更新是通过事件驱动shell脚本来执行下载，比较简单粗暴。v1.2开始使用监听rancher events方式来reload metadata的answer file，但是answer file还需要到rancher server端下载，总的来说效率还是有一定提升的。
dns在新的体系中仍然承担着服务发现的功能，https://github.com/rancher/ra...。除了拆分成多带带容器之外，它也在效率上做了改进，它与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/et...）会根据metadata数据动态生成hosts文件并写入容器内，这样通过服务名访问时，其实已经在本地转换成了IP，无需经过dns，如下图所示：
rancher-net作出了比较重大的革新，https://github.com/rancher/ra...，除了继续支持原有的ipsec外，还支持了vxlan。这个支持是原生支持，只要内核有vxlan的支持模块就可以。vxlan并不是Cattle的默认网络，使用时可以在infra-catalog中重新选择它来部署，其实现以及部署方式后续会在专门的文章中进行探讨：
network-manager的引入为Rancher v1.2带来了一个重要特性就是CNI插件管理，在之前的版本中很多用户都提到rancher-net本身的网络无法满足业务需求。容器网络之争，无非就是CNM与CNI，Rancher选择站队CNI，这也是为了更好与Kubernetes融合。而CNI的插件很多种，Calico、Weave等之流，每个插件的部署方式都不一样。Rancher为了简化管理提出了network-manager，https://github.com/rancher/pl...，它可以做到兼容主流的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/he...，采用Golang微服务的方式，数据源是metadata。当然healthcheck的最终检查仍然是通过与Haproxy sock通信来查看相应member的健康状态（原理如下图），healthcheck的实现主要是为了将其从agent-instance中解耦出来。
总结Rancher v1.2的新特性非常多，基础设施引擎的变化是一切特性的基础，在这篇开篇之作之后，我们后续会持续为大家带来Kubernetes与Swarmkit的支持、自定义rancher-lb、vxlan的支持、各种CNI插件的集成以及各种存储接入的实践操作指南等等。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/11756.html
摘要：官方于月日发布了其容器部署与管理平台的最新版本，。架构总览在版本的整体架构图如下图所示上，引擎向下深入演化成了基础设施引擎，这一点上在时代也早有体现。基础设施引擎初次安装版本，会发现多了如下图所示的明显标识，默认的引擎需要安装等服务。 Rancher Labs官方于12月1日发布了其容器部署与管理平台Rancher的最新版本，Rancher v1.2。Rancher v1.2可以说是一...
摘要：在之前的版本上，用户时常抱怨的网络只有，没有其他选择。而容器社区的发展是十分迅猛的，各种容器网络插件风起云涌，欲在江湖中一争高下。同样是基于，使用提供的，网络配置信息以方式注入。 在之前的Rancher版本上，用户时常抱怨Rancher的网络只有IPsec，没有其他选择。而容器社区的发展是十分迅猛的，各种容器网络插件风起云涌，欲在江湖中一争高下。Rancher v1.2版本中与时俱进，...
摘要：在之前的版本上，用户时常抱怨的网络只有，没有其他选择。而容器社区的发展是十分迅猛的，各种容器网络插件风起云涌，欲在江湖中一争高下。同样是基于，使用提供的，网络配置信息以方式注入。 在之前的Rancher版本上，用户时常抱怨Rancher的网络只有IPsec，没有其他选择。而容器社区的发展是十分迅猛的，各种容器网络插件风起云涌，欲在江湖中一争高下。Rancher v1.2版本中与时俱进，...
摘要：模版用户可以选择不同的基础设施服务组成模版同时还是有默认的主要模版，用户可以快速创建用户也可以把的项目放到模版中，来管理和部署增强已经大大简化了管理和配置，在多节点部署中和已经被去掉了。请保持关注，和一起走上伟岸光明的容器之路 开篇第一句，先为Rancher v1.2曾经的跳票深深抱歉（鞠躬）。我们补偿的方式，就是在此日、此刻，用新版功能向你证明Rancher v1.2值得你的等待。R...
摘要：组件会给每个分配一个，则替代了的来实现服务发现，在的容器内部依然可以访问服务来获取元数据信息。的需要在中实现一个，目前只有，而则维护了自己的版本在其中提供了。 在Rancher 1.0版本开始，Rancher逐步增加了Kubernetes、Swarm、Mesos等多编排引擎的支持，很多朋友就此产生了疑惑，诸如Cattle引擎和这几个之间到底什么关系？每种引擎是如何支持的？自家的业务环境...
阅读 1416·2021-09-02 19:23
阅读 1517·2021-08-11 11:19
阅读 569·2019-08-30 15:55
阅读 1599·2019-08-30 12:50
阅读 2209·2019-08-30 11:23
阅读 2156·2019-08-29 13:13
阅读 1484·2019-08-28 18:13
阅读 3330·2019-08-26 11:53
