7部署rancher步骤_DevOps平台Rancher试用笔记

(封面图来自Rancher官网，https://rancher.com/)

本篇文章是从我自己的博客上搬过来的，实际创作于2018年底，删改了部分过时的内容。之前我抱着试一试的态度用了Rancher，发现它的优势不仅是能方便的创建并管理维护多个集群, 更在于它降低了开发测试运维人员的"心智成本"。虽然发现了一些小问题，但总体来说开源免费的Rancher用起来还是蛮香的。

Rancher的背景和定位

Kubernetes从Borg的原型发展到如今成为"云原生操作系统", 不仅因为其对计算资源的抽象和容器编排的标准化带来的变革, 也离不开周边繁荣的生态系统, Rancher就是其中之一。

Kubenertes解决了集群的容器编排, 统一了资源管理接口, 但没有提供整个运维链的闭环解决方案。Rancher的目的就是提供一整套大而全的解决方案. 不仅囊括集群资源的管理, 还集成日志/监控/预警, 2.x版本又加入了持续交付能力。

而且这一套解决方案不需要对Kubernetes有非常深的了解, 极大的降低了学习成本。另外Rancher公司一边提供开源的软件, 一边提供付费的服务。

Rancher平台试用经历

（由于Rancher版本迭代比较快，这篇文章中的截图与当前最新版本略微有些差异）

首先一行命令把Rancher跑起来：

// 真正使用时不能这么跑，起码要加个数据目录挂载，防止数据丢失
sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher

然后打开浏览器就可以创建一个集群了（见下图）, 我在本机VM中运行, 所以选择了Custom。输入完集群的基础配置之后, Rancher会提供另一条docker命令, 拿到节点上运行, 初始化过程是这样的:

• 每个执行的节点上, 创建一个叫rancher-agent的容器；
• 这个容器会继续创建rke-tools的容器, 然后用它来初始化容器的宿主机各个组件, 比如kubelet, kube-proxy, api-server等等 - 在rancher上会同步显示每个步骤的信息, 整个过程无需干预, 网络不是太差的话, 坐等10分钟集群就出来了。

Rancher接管集群的方式非常多样, 下图的上半部分是用于整合导入现有的Kubernetes集群, 下半部分是用于接管集群的初始化工作, 直接部署出来一套集群, 这样出来的Control Plane组件都是基于hypekube完全运行在docker中的（Rancher公司的另一个产品RancherOS也是这个思路, 整个操作系统全部容器化了）。

平台从上而下分为多个层级, 每个层级的管理的粒度从粗到细, 一目了然：

• Global 级别下管理各个集群整体配置, 全局设置, 用户和角色等 ；
• Cluster 级别下管理节点及节点调度, 项目, 命名空间, 用户及权限, 存储, 单集群级别的监控预警/通知, kubectl接口等；
• Project 级别主要功能是管理单个项目下各个命名空间的Kubernetes资源对象和项目成员, 包括运维管理最核心的功能。PS: Rancher创建了Project的概念管理多个相关的Kubernetes Namespace，这个设计非常实用。

下图是一个Global级别管理Role的例子：

这是Cluster级别管理的概况

这是Cluster级别管理预警的例子, 预警条件和各种类型通知已经非常灵活了, 另外Cluster级别统一管理PV/StorageClass, 符合运维的实际场景:

这是Project级别的工作负载情况, 有很多方便用户的细节设计：

对于每种Workload有方便的功能入口, 比如redeploy, rollback, scale, Endpoint链接, Yaml编辑查看, shell到容器内部执行命令等。每个Workload, 也就是真正会产生Pod的资源, 展开都会有圆点和方块图标, 每个圆点代表一个container容器, Pod只有一个container的不会显示方块, 此时一个圆点也就是一个Pod, 对于有多个容器的Pod, 比如Init container或带有sidecar的, 会显示方块, 每个方块是一个Pod, hover上去有便捷的入口。

另外，Rancher支持可视化的应用部署。在Project级别新建一个Deploy, 直接表单配置很直观, 不懂Kubenetes也可以玩。通过表单很方便的设置探针, 资源限制, Node Selector等, 而无需了解Kubernetes的语法结构 （个人感觉这就是Rancher的商业模式, 把功能做的很方便, 用户形成依赖之后不懂原生的kubernetes了, 然后出问题得找他们付费咨询）

Pipeline功能, 以及其他Resource管理入口，话不多说，上图

查看Pod日志, 以及完整的Yaml, 比Dashboard多了一些细节功能, 比如导出：

除了截图的这些功能, 还有一些重要的功能：

• 右上角用户可以管理kubectl登陆的Key和token ；
• Resource下管理的主要是相对变化较少的部署资源, 比如ConfigMap/Secret, 此外还有Pod/Depoloyment级别的预警配置, 以及日志集成等, 资源管理还有证书的管理, 能很方便的做SSL Ingress, SSL Offloading等；
• LoadBalancing 直观的展示的当前的Ingress配置, 是对服务的统一入口管理；
• Service Discovery 是内部的服务列表, 包括集群内部分配的DNS以及固定的ClusterIP等。

用Rancher部署基础设施组件

Rancher也有Helm的集成，Helm 是Kubernetes上管理应用的“包管理器”，为每个要部署的应用声明为一个Chart, 通过模板引擎渲染隔离了动态配置和静态编排结构, 并且可以统一管理发布以及版本控制, 非常方便。

Rancher平台Catalog的功能就是对Helm的集成和进一步开发, Global级别下点击Catalogs打开Helm Stable仓库可以获取到更多的Helm Chart，也可以添加自定义的Helm仓库。然后，在项目级别的Catalog App里, 可以可视化地Launch很多第三方Chart, 分分钟部署好集群基础设施。

虽然Catalog极其方便, 但我觉得重要的基础设施还是自行维护或者用第三方云服务商提供的现成的服务, 因为基础组件的稳定性和运维要求更高, 要么就吃透, 要么就不要自己维护。用Rancher Launch一个Redis还好, 但是Launch一个EFK/ELK日志系统，没有一定背景知识不一定可以完全理解，部署容易维护难, 出了问题就一脸懵逼了。

总结

总体来说Rancher用起来还是很方便的，尤其适合给不熟悉Kubernetes的开发团队使用，运维团队应该使用Rancher就见仁见智了，个人认为运维团队在吃透Kubernetes的情况下可以适当使用以提升效率，而在Kubernetes可视化平台中Rancher肯定是Top 3的。如果对命令行有特殊情结一定要用的话，推荐运维使用K9S，好用到爆。搭建Kubernetes集群除了使用Rancher、KubeAdm、kubeasz，Rancher也开发了另一个轻量级的工具: K3S，不扯远了。

之前试用Rancher的过程中也发现了一些小坑（不完全是Rancher的）, 相关心得在这里分享一下：

• Rancher本身比较耗资源, 运行时占用>1G memory. 最好单独部署, 或运行容器时限制cpu和内存, 防止影响宿主机；
• 如果用Rancher创建集群, Ingress Controller默认会帮我们创建好, 但Ingress Controller初始配置不一定是想要的(比如默认80端口且创建好后无法修改), 建议Yaml自行维护Ingress Controller, 具体的Ingress配置可以在Rancher的UI中配, 很方便；
• Workload里面StatefulSet的Scale按钮扩容没有提示, 一按就会修改StatefulSet开始调度, 慎点, StatefulSet一般都是像Redis, MySQL这种应用, 的权限控制应该要更严一点；
• PV的信息最好加上Node Affinity, PVC加上Label Selector等, 防止PVC申请到错误的PV；
• Rancher使用目前没遇到大的问题, 小问题比如Catalog App状态更新的时候有延迟等；
• 需要防止Pod调度导致其他Pod饿死的情况, 比如像ElasticSearch启动时非常占资源, 节点调度和资源限制策略需要注意, 比如用LimitRange控制单个资源, ResourceQuota控制整个namespace。

最后，来贴个用Rancher部署的Kubernetes集群以及各个常用组件的全家福吧。