rancher 和 kubernetes 有什么区别？

总体来说，rancher 和 k8s 都是用来作为容器的调度与编排系统。但是rancher不仅能够管理应用容器，更重的一点是能够管理k8s集群，rancher2.x 底层基于k8s调度引擎，通过rancher 的封装，用户可以在不熟悉k8s概念的情况下轻松的通过rancher 来部署容器到k8s集群当中。

为了实现上述功能，rancher自身提供了一套完整的用于管理k8s的组件，包括rancher api server，cluster controller，cluster agent，node agent 等等。组件相互协调使得rancher 能够掌控每个k8s集群，从而将多集群的管理和使用整合在统一的rancher 平台中。rancher 增强了一下k8s的功能，并提供了面向用户友好的使用方式。

多集群管理

用户可以通过很多种方式搭建一个k8s集群，可以是在本地机器上手动搭建，可以在公有云厂商的服务器上手动搭建，也可以直接使用公有云厂商的k8s集群成服务。rancher能够将所有部署在不同地点，通过不同方式搭建的k8s集群统一管理起来。rancher通过不同的插件和驱动适配了不同场景的k8s集群。对于用户而言，他们无需关系底层k8s的实现细节，统一通过rancher UI 或者 rancher API 就可以在不同的k8s集群里部署应用。

权限管理

在k8s中，权限管理同创使用RBAC的模式，即用户或应用通过使用证书 或 serviceaccount 来表明身份，k8s通过检查对应的role，clusterrole来确定方位者是否有对应的权限。但是所有的权限管理都仅仅限定在k8s内部，无法与第三方的认证管理系统集成。另一方面，每一个集群都是独立的一套权限管理，在用户有很多集群的场景中，没有办法统一的规划多集群的权限管理。不过，k8s在设计之初就已经很明确的表示k8s将不会提供自己的账号管理，这一点应该由外部组件自己实现。

rancher通过 auth proxy组件在k8s之外提供了统一的权限管理中心。Auth Proxy 可以与第三方认证系统结合。一般情况下，用户通过rancher提供的 kubeconfig 认证文件访问 rancher 的author proxy。 Auth Proxy 经过鉴权后将用户的请求设置对应的请求头，最后通过其他组件将请求转发到真正的 k8s api server。因此，对于用户的开发团队而言，可以直接通过现有的团队权限管理系统来对所有的k8s的权限进行管理。但用户对集群的访问的延时可能因为代理这一步而上升。

应用部署

k8s通过提供大量的API实现了强大的容器编排功能。但是对于上层的应用开发者而言，掌握大量的概念并不容易，而且有很多对于开发并不关心的字段。在k8s中部署应用，通常会通过编写yaml并执行kubectl create -f来实现。这种基于命令行的使用方式并不友好，而且不易于修改，而且yaml文件的编写要求用户掌握每一个字段的合法值，这对于上层用户有很大的学习成本。但一旦掌握了k8s原生的API，用户就可以实现更多定制化的部署需求。

Rancher提供了统一的UI界面来部署应用，功能比k8s官方的UI更强大。了解k8s的用户在使用Rancher部署应用时就会发现的所有选项都可以在k8s的API中找到一一对应的字段。但Rancher对每个选项有更友好易懂的描述，更切合上层开发的概念，因此用户即使不懂k8s也能够轻松部署应用。以Deployment为例，Rancher将应用部署时所需的配置进行了分类，划分为应用调度、健康检查、升级策略等模块，使得配置更简单。Rancher更多的面向的是与k8s无关的应用的部署场景，对于与那些与k8s紧密结合的应用，它们所需的一些k8s资源并不能完全在Rancher中统一管理。比如部署自己开发的k8s operator所需的webhook配置，RBAC相关配置都需要用户自行导入yaml来实现部署。

Rancher也提供了应用商店的模式，用户可以在商店中浏览并一键部署所需的应用。

集群运维

对于直接使用k8s原生系统的用户，机器运维复杂且费时。集群升级和集群备份都需要人工介入执行多条命令。比如k8s自身升级需要用户了解组件升级的相互依赖，etcd升级需要用户了解etcd升级策略，并且做好相关备份以防备数据丢失，节点上线需要人工安装组件，执行命令。

基于rancher的RKE构建的集群能够自行解决集群升级，集群备份的一些痛点，并提供了完善的回滚机制，减轻了运维的工作量。节点的上下线在rancher中变得十分简单，通常只需要运行docker容器完成了一系列自动化部署。

集群监控，日志收集

原生k8s的集群监控，日志都依赖第三方的组件，比如Prometheus,fluentd，用户需要自己开发或部署实现上述功能。rancher同样通过集成这些主流的第三方组件实现了集群的监控报警和日志收集，大幅度简化了部署的流程。和k8s概念的封装一样，rancher也对这些第三方的组件的配置做了封装和优化。

rancher将报警的配置进行语义化的配置，涵盖了系统组件，工作负载，节点等常用资源，用户通过rancher配置报警会比直接编写Prometheus的PromQL语音简单很多，节约学习成本。但也仅限如此而已，更复杂的报警故障无法直接通过rancher配置。

转自：https://blog.csdn.net/wangyiyungw/article/details/105552605