通过将近1个季度的努力，基本上完成了内网开发、测试以及生产环境（借助公有云容器引擎服务）关键服务容器化工作。 在这个过程中，本来是把已经验证过的技术和方案进行落地，只是执行上的问题。但是研发大爷在使用过程中又提出了许多新的需求，见招拆招之后，发现还是有些许收获，因此整理成文，本文介绍rancher server的应用。
一、什么是rancher？
Rancher是一个开源的企业级容器管理平台，通过使用rancher，可以快速的构建出kubernetes环境并对其进行可视化管理。 Rancher由以下四个部分组成：
1、基础设施编排
Rancher可以使用任何公有云或者私有云的Linux主机资源。对计算资源进行整合和统一调度使用2、容器编排与调度
Rancher包含了当前全部主流的编排调度引擎，同一个用户可以创建Swarm或者Kubernetes集群。并且可以使用原生的Swarm或者Kubernetes工具管理集群。3、应用商店
Rancher的用户可以在应用商店里一键部署由多个容器组成的应用，例如容器的日志集中收集应用套件。4、企业级权限管理
Rancher支持灵活的插件式的用户认证。支持Active Directory，LDAP， Github等 认证方式。 Rancher支持在环境级别的基于角色的访问控制 (RBAC)，可以通过角色来配置某个用户或者用户组对开发环境或者生产环境的访问权限。更多信息请移步官网：https://rancher.com/
二、为什么要用rancher？
每个人选择用rancher的原因可能各不一样，这里列出rancher能解决的一些实际问题。
1、降低kubernetes集群的部署门槛
我们通常使用kubeadm或者二进制方式部署kubernetes集群，如果你想拥有一个kubernetes学习环境，通过使用rancher，只需要按照向导在主机上运行指定的命令，然后等待片刻，就可以得到一个kubernetes环境，大大降低了集群的入门门槛。2、统一管理各个环境的kubernetes集群
当有开发环境、测试环境、正式环境甚至更多的kubernetes集群的时候，如何集中管理这些集群资源是个问题。rancher提供了很好的解决方案，支持各大公有云的云容器和自建kubernetes的纳管工作。
简单来说，kubernetes实现了各个主机上docker资源的统一管理，rancher在kubernetes之上，实现了对kubernetes的集中管理。3、替换kubernetes原生的dashboard
原生的dashboard虽然可以通过rbac来控制用户的访问权限，但在实际的配置中还是太繁琐了，尤其是用户数多，且每个用户的权限又要求设置的不一样的时候。Rancher通过项目和namespace挂钩，对用户授权各个项目的权限来有效简化了配置。其次原生的dashboard的shell web窗口是不支持黏贴的，这个在内网开发和测试环境被无数的吐槽。Rancher提供了完美的解决方案。
三、使用rancher纳管k8s集群
Rancher server本身就是一个docker 容器，可以运行在kubernetes集群外部。当然如果你有需求的话，也可以部署在集群内。
# yum -y install docker
# docker run -d -p 80:80 -p 443:443 --name rancher-server \
-v /root/star_59iedu_com.pem:/etc/rancher/ssl/cert.pem \
-v /root/star_59iedu_com.key:/etc/rancher/ssl/key.pem \
-v /var/lib/rancher:/var/lib/rancher \
--restart=unless-stopped rancher/rancher
设置初始密码和访问url地址
添加集群，选择导入方式纳管已存在的k8s集群
在k8s master节点上创建对应的资源，完成纳管。
这里经常遇到的问题是DNS解析问题，建议在dns后台将对应的记录添加好，避免出现纳管失败的情况。
四、rancher使用
纳管完成后可以看到k8s集群的资源情况
创建全局用户
通过创建project和namespace挂钩
点击集群中的“成员”设置全局用户对所有项目的权限，类似组的概念
点击项目“编辑”设置全局用户对项目的权限
终端使用
点击“集群”，可以运行kubectl工具
通过点击项目的工作负载“执行命令行”，可以运行一个shell终端，终端支持黏贴。
后记：
来自程序猿的若干需求：
1、我使用rancher的初衷是为了解决shell终端黏贴的问题，在内网开发和测试环境，码农们出于固定思维，喜欢登陆到容器内部瞧瞧看看，美其名曰debug。2、适配完终端黏贴的问题之后，码农提出了新的需求，他们在终端里面捣鼓半天，需要把结果文件下载到本地，然后希望通过sz命令下载下来，或者通过rz命令能上传一些class文件进去编辑，这个是任何web终端工具都解决不了的问题，因为lrzsz不能适配web终端。解决方案是把文件保留到PVC里面，通过共享存储来解决这种无聊的需求。
3、紧接着，无聊的程序猿又要求能在pod里面远程debug，还是固定思维。原来tomcat非容器编排部署的是/home/tomcat/bin/catalina.sh jpda start 方式启动，默认会启动一个8000的端口，程序猿们就可以在IDE工具上进行断点debug。目前我们开发、测试和生产环境用的jdk、tomcat等基础镜像是同一个，程序猿们又不想修改maven上相关的配置，从运维上看，也不想维护多个基础镜像，那么如何解决这个问题呢？同一个基础镜像，相同的代码包，如何适配多个环境呢？且看下回分解。
来源：51CTO
作者：ylw6006
链接：https://blog.51cto.com/ylw6006/2367448?source=dra