Rancher系列之--简介

随着微服务架构越来越被广大互联网公司的认可 ，对于服务的管理也成了一个重要的问题。服务越来越多势必来带大量的维护成本，怎么部署？像传统运维一样由运维人员管理这一大堆服务和配置？这一定是下下策，毕竟那么多服务和配置的管理对于对程序本身并不了解的运维工程师来讲每次上线可能是一次对灵魂的拷问：我是谁？我在哪里？我在干什么？

其次，服务和配置很多的情况下，对于运维人员和开发人员来讲对程序之间的调用、具体参数的配置又避免不了大量的沟通和文档的维护，工作量大不说而且还极其容易出错，一旦出错排查起来又十分麻烦。

怎么能减少不必要的沟通和出错的机会呢？这时候以docker为代表的容器化技术和以kubernates（k8s）为事实标准的容器编排平台成为了解决问题的首选。而Rancher以其简单易用、容易上手尤其是对于k8s不那么精通的同学来讲可谓是一剂良药。下面来具体说说到底好在哪里，为我们解决了什么样的问题。

上图来自Rancher的官方文档，简单说就是用来管理kubernates的平台。那对于了解kubernates的同学可能会问了，kubernates有官方的dashboard，有kubectl都可以用来管理，那这个Rancher到底好在哪呢？

请看图：

Rancher UI：

 

 再对比一下kubernates的dashboard

无论在功能上还是易用性上，Rancher UI都要比kubernates dashboard要强很多很多。

再说kubectl，对于小白来说需要大量的学习成本。当然使用熟练之后往往还是kubectl更轻量、快捷一些。

简单的介绍了Rancher之后相信大家对它已经有了一个初步的认识，下面我们再来了解一下它的架构设计。看看Rancher如何与Docker和Kubernetes进行交互的。

官方架构图

一、用户在Rancher UI上的所有操作都会直接与Rancher API Server通讯，它负责认证授权，项目（Rancher特有的概念）管理等。

二、Cluster Controler（集群控制器）和Cluster agent（集群代理）实现管理Kubernetes集群所需的业务逻辑

三、etcd负责存储Rancher Server的配置信息

四、Auth Proxy转发所有Kubernetes API调用并集成了身份验证服务（通过rancher部署的k8s，如果需要通过kubecl管理集群，默认情况kubectl是与Auth Proxy通讯的而不是与k8s的Kubernates API Server直接通讯，但是也可以配置成绕过Rancher直接与k8s集群通讯，这个功能在什么场景会使用会在后面的安装片介绍）

如上所示，Rancher通过代理的方式对kubernates进行管理，在此之上还提供了对外部用户的认证授权，项目管理，集群中节点的标识，统计信息，节点信息和运行状况。还集成里日志管理，集群监控，甚至是流水线功能，极大的方便了用户对平台的管理。

说在最后：Rancher最大的好处就是快捷的部署k8s集群和通过UI几乎零学习成本的集群维护，对开发和运维人员来说更友好一些。尤其是对于团队使用来说，能够更容易被接受和推广下去。