rancher 1.6 实践指南-1

前言：
话说认识rancher应该是14年，当时我还在某人寿公司，为了在vmware上自动化部署应用环境而大搞ansible。后来我跳槽到新东方搞容器云，这才正儿八经的研究rancher的落地方案。rancher是个轻量级方案，可探索的东西很多，很多组件需要自己实施补全。除了在项目中自己反复实践和摸索外，也受到rancher社区成员实践讨论或者技术分享的启发，因此我也总结一片日志，把一期项目彻底总结沉淀一下。一是来源于社区再回馈社区，看看是否对大家有启发，二是准备卸下之前的工作成果，整理着装继续上路。 转载请注明出处：jiangjiang.space

以下摘自rancher.com:

Rancher是一个开源的企业级容器管理平台。通过Rancher，企业再也不必自己使用一系列的开源软件去从头搭建容器服务平台。Rancher提供了在生产环境中使用的管理Docker和Kubernetes的全栈化容器部署与管理平台。

rancher提供如下功能：

• 基础设施编排
• 容器编排与调度
• 应用商店
• 企业级权限管理

官方的架构说明图

从图中看rancher是一个中介，下层他为你管理跑容器用的主机（Iaas层对接），比如在阿里云或者vmware上创建的主机， 中间帮你对接各种编排引擎，比如cattle或k8s， 上层帮你打包应用，比如用rancher catalog或者helm，左手帮你做用户接入和权限控制，右手帮你整合现有的运维工具，比如cicd，镜像仓库和监控等。

我胡乱解读一下rancher的定位。Rancher的定位给大家的印象比较模糊。之前经历了多个版本的迭代，改变也比较大。 听说早期rancher的版本就是给k8s做安装部署和UI的。具体历史我也不是太了解，随着docker的快速成长，当时业界的方向还没有现在这么清晰，在那个独特的环境下，rancher 同时支持k8s 、swarm和mesos，加上自己发展的cattle。确实给外界一个模糊的印象。在我看来其实这模糊的印象恰恰给出了rancher的准确定位—— rancher就是管理容器平台的平台。你可以简单理解rancher就是一个带ui，带虚机管理和权限控制等诸多功能的kubadmin 。不知道这么说是不是有助于理解？ （是不是更糊涂了？ 笑~）
下面说的rancher都是指的是rancher的cattle引擎。

下面所有Rancher的表述代表着Rancher 1.6 ，编排引擎为cattle ，请避免不必要的误会。

我之前在公司内部和外部都谈过这个话题，从纯技术角度考虑，确实有更多的高大上方案要优于rancher，技术选型上技术最优只是选择方案的因素之一，一个项目是否能成功落地还需要考虑：项目资源、项目的时间、团队人员情况和团队文化等等。 rancher的架构小巧，实现简单，生态直接建立在docker和docker compose之上，学习成本非常低。 实施快，容易定制。 特别适合有以下情况的团队：

• 时间紧任务急，想要快速构建一套容器云平台
• 人员不多，人员复用情况高，无专职运维，开发人员自己搞
• 团队build能力强，需求二次开发框架。

总结一下大概就是这样：

1. rancher项目100%开源，可选的商业支持。
2. 提供丰富的api，组件插件化，可供用户自行定制选择。
3. 学习成本低，直接沿用了docker生态，非常好上手。
4. 内置容器网络方案，NFS共享存储，CI/CD工具，应用商店框架（rancher catalog），公有/私有云对接，LDAP对接方案。能节省你很多的方案选择和摸索时间。

也说说劣势，或者说什么情况下不适用rancher

1. 生产级别的有状态应用，rancher有很多办法来支持有状态应用，不过难度有点高。因此还是跑无状态应用轻松一些。
2. 对共享存储有较高写要求的用户，目前共享存储支持最好的是NFS，比较适合作为读存储。目前我还没发现非常满意的写存储方案。
3. 动手能力弱，对开源业态和方案不甚了解的用户。前面提到过，rancher落地到你的组织中需要很多磨合，需要自己琢磨方案（购买其官方支持的除外）。

• 深度定制的用户自服务平台
• 无状态业务和动态伸缩
• 作为平台服务的后台支撑平台
• 容器管理UI

解释一下：

• 第一条：rancher最常用的场景，所谓轻量级paas就是灵活好定制。rancher的方案很松散，比如日志方案，比如镜像仓库，其实都是社区现有的方案攒起来的。用户自己对接起来的自由度就大一些，功能好裁剪。用户以rancher作为后台，功能和动作都在后台，前台来做环境的隔离、计费、权限等等。也可以集成rancher api到现有的平台中（比如已有的管理后台）。 这也是rancher最大的价值所在，试想一下如果对接openshift等重型paas平台，那需要多少工作量？ 侵入性有多大，是否要为了接入对方而改变目前的流程和习惯？
• 第二条：rancher的动态伸缩还是很好集成的，可以应用直接调用webhook，一个shell脚本或者zabbix的action都能帮你做动态伸缩。
• 第三条：我见到群里有同学用rancher管理他们所有的ipfs，rancher对他来说就是ipfs这个对内对外服务平台的后台管理和支撑平台。同样的思路，你可以用rancher做为XXX as a service的基础后台。
• 第四条：rancher用熟了以后会发现，与其手动管理一个个docker，还不如直接用rancher管起来。能轻松不少。

这里开始进入正题，记录rancher的部署架构和需要注意的细节。

简单的rancher部署方案大体是这样的：

你只需要按照文档很快就能搭建一套出来，这里需要注意的是
1.如果是虚机部署，切记不要dhcp
2.如果是拷贝虚机的方式，最好在部署docker后，部署rancher前拷贝。（或做成虚机模板）

大家也可能会发现这个方案存在很多问题，比如server只有一个，数据库只有一个。
节点连接写死 server 的 IP（当然也可以用域名解耦）等等。

下面介绍我的部署架构， 我只是在上面简单方案的基础上增加高可用和负载均衡即可，将所有单点都变成负载均衡的，或者至少是HA方式。

架构图如下：

1. ranher server 部署多台，开启rancher server ha 模式
2. rancher 数据库采用maxscale中间件和多台mariadb，减少数据库故障对rancher 的影响，缩短库切换时间
3. 在server和client中间增加4/7层转发作为负载均衡。我们知道当rancher node不断的增加会对后台server造成很大的压力，在s/c中间增加负载均衡就使得两遍的扩展都变得轻松。

下面就逐个介绍一下各个组件的配置，从宿主机开始，直到应用如何对外发布到公网。

毋庸置疑推荐选择ubuntu 1604，4.x内核支持overlayfs2，使用起来会轻松好多。
centos在国内使用广泛，已有一整套的配置、监控、运维体系，出于管理成本考虑，选择centos也没关系。我用的也是centos. 下面所有的设置介绍都是基于centos7.4的。

首先请先卸载centos自己默认安装的docker，以避免不必要的麻烦。

ubuntu1604就不用考虑使用dm了，直接上overlayfs2即可。
如果你是centos7.4 ，也可以直接使用overlayfs2。
但是下面的介绍重点是DeviceMapper，我参考了openshift和docker EE，他们都用的DM，因此我也选择DM作为容器存储。 DM实际就是跳过了文件系统层，直接在磁盘上划薄逻辑卷（lvm thin volume）作为容器的存储。性能还不错，所谓薄卷的意思就是超卖，大概意思就是承诺给10个容器分别配置10G磁盘，但是实际自己拥有的磁盘要远小于100G，可能只有小几十个G。这么做主要是考虑容器自身存储不算大，有个几百兆就算不小了，加上应用也就1g或者2g大，因此如果按照10G或者20G一个容器来分配磁盘还是挺浪费的。另外容器的生命周期短，磁盘全部用满的机会较少。因此超卖是个节省资源的做法。

顺便说一下，rancher有时容器创建不出来也是因为磁盘满，一般多是之前积累下的镜像占用了空间。这里还是多给一些磁盘，同时注意定期清理镜像。

都是DeviceMapper方式，还分为direct-LVM 和 loop-LVM，这里是个坑。红帽系列系统中的docker默认开启的是 loop-lvm，其实是一个文件假装成一个磁盘放在文件系统中，再通过device mapper 做成卷挂载，性能和可扩展性可想而知。因此一定要将loop-lvm改为direct-lvm。

改dircet-lvm有两种方法，手动或者自动，如果是新装系统就自动就行了。
配置方法如下：

/etc/docker/daemon.json 中加入：
{
  "storage-driver": "devicemapper",
  "storage-opts": [
    "dm.directlvm_device=/dev/xdf",
    "dm.thinp_percent=95",
    "dm.thinp_metapercent=1",
    "dm.thinp_autoextend_threshold=80",
    "dm.thinp_autoextend_percent=20",
    "dm.directlvm_device_force=false"
  ]
}
# 转载请注明出处：jiangjiang.space 

docker的默认bridge docker0 的子网是从172.17.0.0/16 开始的. 需要注意的是172.17可能已经存在与物理网络之上，这就造成启动了docker的机器和172.17网段就失联了。原因是外面172.17网段发来的包，被docker路由到docker0上去了， 因此所有的包都有去无回，两遍自然也无法通信。

解决办法：
规划组织内的子网，留一段子网专门给docker使用。

{
   "bip": "172.xxx.0.1/xx",
}

docker默认从docker hub 拉取镜像。 docker hub距离较远，中途有又众所周知的一些情况干扰。因此需要配置国内镜像源加速。

这里使用docker中国官方源

解决办法：

 "registry-mirrors": [
            "https://registry.docker-cn.com"
   ],

常见的内核参数优化，最大文件打开数，swappiness 等等
sysclt 配置

/etc/sysctl.conf
net.core.somaxconn = 65535
fs.file-max = 655360
vm.swappiness = 1

ulimit nofile

/etc/security/limits.conf
*  soft    nofile  102536
*  hard    nofile  102536

这里要说明一下是MountFlags参数。
前面我也说了一下，我这里设置mount flags 为 private，主要是为了避免容器存储卷因为被其他进程打开而出现关闭上
请参考我之前的一片笔记。这里设置要看情况，比如你如果想完全避免容器删除不掉的情况发生，那么需要设置为private 。
但是如果需要挂载glusterfs，后面我会提到，则需要修改为share。

/usr/lib/systemd/system/docker.service
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity
MountFlags=private    # 解决容器删除不掉的问题，可能会影响bind host目录到容器里面
#MountFlags=shared