本文于3月22日晚由张新峰,杭州爱医康架构师技术分享整理而成。本次分享介绍了如何使用负载均衡达到一个对用户友好(稳定无感)、对运维友好(傻瓜高效)、对架构友好(追溯监控)的高可用状态。
搜索微信号RancherLabs,或文末扫码,添加Rancher小助手为好友,可加入官方技术交流群,实时参加下一次分享~前端
咱们今天要说的是一个老生常谈的问题:负载均衡。有点运维经验的人都对这个很了解了,可你的负载均衡有没有完美呢?在微服务大行其道的今天,每一个公司几十上百个服务都很常见,更不用说多条产品线并存的公司了,这么多服务如何在扩缩容的时候实现服务发现和高可用,天天频繁升级更新的时候有没有实现用户无感知?固然每一个人对于完美的定义不一样,咱们今天要说的是指对用户友好(高可用无感)、对运维友好(高效傻瓜)、对架构友好(追溯监控)的完美状态。node
Rancher 1.6
Traefik 1.5.3
dnsmasq
ab
■ 了解Rancher的安装部署和基本使用
■ 了解DNS相关的网络基本常识nginx
目前公司有3大产品线,十多个小产品,再加上用于运营分析的内部服务和开发测试环境的各类系统和服务,有差很少上百个子域名。运维的职责之一就是要保证这么多域名稳定准确地指向相应的服务器或服务。这些服务中大部分是Web服务,还有Spring Cloud微服务。无论是用户经过浏览器访问Web服务,仍是微服务之间的相互调用,稳定性确定是衡量服务的首要指标。尤为是在向DevOps看齐的敏捷型团队,要想在天天频繁发布上线的时候也能保证服务的稳定,就必须使用负载均衡。web
先看看咱们测试环境的一个产品线使用Rancher自带的负载均衡时的效果。docker
若是这个列表看着不是那么眼花缭乱,请看下图: 数据库
目前这个产品线部署了不到50个服务,若是这个界面看着也挺清爽,请再看看每次升级/编辑负载均衡规则的界面吧:后端
是否是完全眼花缭乱了呢,这就是我以前每次维护负载均衡器的痛苦。 这里并非在诋毁Rancher负载均衡的很差,只是这个管理方式在服务较少的时候仍是方便的,服务不少的时候就不是那么方便了。浏览器
若是你想说谁让你把这么多服务放在一个负载均衡的,由于这是咱们探索负载均衡过程当中的其中一个阶段。缓存
咱们最初的作法是每次新增一个Web服务,就先在Rancher中部署好服务,而后在Rancher负载均衡中增长一个规则,最后还要去DNS服务器中新增一个A记录或者CNAME记录,这样用户才能够访问这个新的服务。虽然只有3步,常常有服务变更的时候也很累,还能不能更简便?服务器
后来咱们总结了生产环境不一样服务使用不一样二级域名但主域名都相同的规律,想到把全部有规律的相同分组(好比相同产品线)的域名泛解析到指定主机,只要在Rancher中将LB也调度到那个主机,后续须要在这个分组内新增Web服务就只需2步:
1部署好服务;
2在Rancher负载均衡中新增一个规则将想要的域名指向刚才部署,不须要添加A记录,用户就能够访问服务了。
这样着实方便了一些,可是一段时间后,服务愈来愈多,域名也相应愈来愈多,就遇到了上面管理负载均衡器界面眼花缭乱的困扰。我就在想有没有更简便的方案能够把手动管理负载均衡这一步也省略呢?可否实现每次新增或编辑一个Web服务只须要部署好服务这一步就能够了呢?
后来Traefik进入了个人视野,他能够整合各类KV存储解决方案和容器编排引擎,是实现自动负载均衡的绝佳选择。Traefik还原生支持Rancher的API,能够自发现Rancher上部署的服务。Rancher社区应用商店也提供了Traefik应用模板,按照模板部署Traefik服务之后,全部Web服务只要添加几个标签就能够自动注册到Traefik而且绑定好了制定的域名。再加上前面的经验,只要泛域名解析到了Traefik服务所在的服务器IP,便可实现了仅仅只需一个部署操做,用户就可使用指定域名访问服务了。
实际操做前,必需要有一个搭建好的Rancher 1.6环境,咱们下面只说Rancher的Agent主机须要如下几个服务器用来作实验,网络规划以下:
说明一点: 若是是生产环境或者须要公司外部用户访问内部网站,就须要在你的公网域名所在的DNS中设置相关域名解析,不须要单独部署DNS服务。 在公司内网部署一个独立DNS服务器的好处就是对公司内网用户友好,不用每一个人记住枯燥的IP和端口了。还有一个好处就是能够实现域名拦截,好比公司内网开发测试环境想用一个花钱也搞不到的好域名,仅限内网,嘿嘿。。。
将以上4台主机分别添加到Rancher,主机名没有要求。若是已经在Rancher集群里了,直接编辑主机按照上面网络规划分别添加标签。注意主机已经有的标签不要随意修改或删除,以避免带来未知的问题。
四个节点都添加好的主机界面截图:
若是你公司内部已经有DNS服务器,请在内部DNS上设置相关域名解析,能够略过这一步。若是对网络DNS了解很少,也请慎重操做,很容易引发你的电脑“没法上网”。
先添加一个应用,再添加服务,这里介绍一个自带Web管理界面的轻量级DNS服务器,镜像是:jpillora/dnsmasq,端口映射添加53和5380端口,分别对应容器53/udp和8080/tcp端口。注意53端口不能修改,必须是UDP协议。5380端口是DNS管理控制台,端口能够根据须要设置。以下图:
DNS服务启动好之后,打开DNS管理控制台http://10.0.1.10:5380,进行DNS配置: 最核心的一条泛解析配置address=/.aek.com/10.0.1.10能够把aek.com全部的子域名解析到10.0.1.10这个IP。
配置好的截图以下:
下一步在各个主机和用户电脑上的设置DNS,将主DNS设置为10.0.1.10。固然前提是用户的电脑是能够ping通10.0.1.10这个IP。若是公司有DHCP服务器,将DHCP分配的主DNS设置为10.0.1.10,DHCP管辖下的电脑重启后都会应用这个主DNS了。 Windows设置DNS效果:
Linux修改DNS命令:
sed -i '1 i nameserver 10.0.1.10' /etc/resolv.conf
RancherOS修改DNS命令:
sudo ros c set rancher.network.dns.nameservers [10.0.1.10] sudo reboot
设置好之后,验证DNS是否生效。打开CMD,ping aek.com或者随便这个域名的子域名,看看解析是否都指向咱们的gateway服务器10.0.1.10,以下图:
关于Rancher部署Traefik服务的详细介绍,请查看Rancher官方教程 「Rancher部署Traefik实现微服务的快速发现」,这里只简单说一下。 在社区应用商店找到Traefik并部署,这里咱们演示简单起见只须要修改Http Port端口为80,Https Port若是用到的话就改为443,端口配置界面以下:
为了高可用,一个重要的选项要留意,必定要启用健康检查:
其余选项暂时不须要修改,点击启动按钮启动一个traefik服务。 启动之后发现443端口并无映射出来,估计是这个社区镜像的Bug,若是须要https,就升级一下traefik服务,添加443端口映射便可。
打开网址http://10.0.1.10:8000就能够看到一个清爽的Traefik界面了。管理界面就两个界面,一个Providers显示注册上来的Web服务,咱们尚未部署Web服务,因此如今是空的:
还有一个界面Health显示负载均衡的健康状态,平均响应时间和状态码统计图都在这里。还有一个很是重要的统计信息就是实时HTTP错误列表,每次服务升级发布上线的时候,留意这里有没有突然出现一大堆错误,你的服务架构升级是否稳定,有没有影响用户体验就体如今这里了!
至此,一个DNS服务,一个Traefik服务就部署好了,接下来咱们就看看Traefik的神奇效果。
Rancher的Traefik教程有一个细节须要更正,多是教程里面的traefik版本和最新版本不一样,因此教程里面说的关于域名的配置标签traefik.domain和traefik.alias并很差用。看了Traefik官方文档「Traefik配置Rancher后端」中的说明,通过个人实际验证,在Rancher中实现自动注册Web服务到Traefik须要添加如下3个标签:
好比咱们想要使用域名http://traefik.aek.com直接访...,只须要升级Traefik服务添加以下3个标签:
traefik.enable=true traefik.port=8000 traefik.frontend.rule=Host:traefik.aek.com
这里有个技巧,Rancher设计很人性化的地方,一次性复制下面3个标签,在Rancher服务的标签界面点击“添加标签”之后,直接粘贴,刚才复制的3个标签已经所有填好了,以下图:
Traefik服务升级好之后,刷新Traefik的控制台,Providers里面就会多了一组负载均衡。
这个时候你就能够打开http://traefik.aek.com直接访...。
接下来咱们部署一个Web服务,看看自动注册并使用DNS解析的效果,使用我写的一个方便验证负载均衡后端和服务端的Web镜像zhangsean/hello-web已经发布到Docker Hub,容器内部暴露80端口,不须要添加端口映射,只须要添加如下3个标签,咱们启动2个容器,以便看看有没有负载均衡的效果:
traefik.enable=true traefik.port=80 traefik.frontend.rule=Host:web.aek.com
部署界面截图:
hello-web服务启动成功后,查看traefik控制台,会发现多了一组负载均衡规则:
这时候就能够打开网址 http://web.aek.com 访问刚部署的hello-web服务了。屡次刷新,会看到Server Name在两个容器名之间轮换,说明2个服务后端都在提供服务了。
顺便说一下,不少业务后端服务须要记录客户端真实IP,后端应用经过HTTP请求头 HTTP_X_FORWARDED_FOR 或 HTTP_X_REAL_IP便可获取客户端真实IP,区别是前者可能包含多层代理的IP。 关于获取跨代理的客户端真实IP的详细讲解,请参考:HTTP 请求头中的 X-Forwarded-For,X-Real-IP
咱们如今经过压力测试,验证这种负载均衡的高可用效果。咱们选择老牌压力测试工具ab,容器化的ab镜像是jordi/ab,为了不单次压力测试的不稳定状况,咱们使用Rancher批量发起多组压力测试。
咱们首先测试在服务后端扩缩容的时候,服务的可用状况。 新建一个应用HA-Test,而后添加服务ab-web,镜像指定jordi/ab,不须要映射端口,命令里填写测试命令-n 1000 -c 10 -l http://web.aek.com/使用10并发...。由于页面是活动的因此必定要加-l参数不然会看到不少失败请求,实际上是ab检测到页面返回长度不一致认为请求失败了。自动重启选择“从不(仅启动一次)”,网络类型选择“主机”以便减小容器内部往来对压力测试形成的影响,添加一个标签test_node=true,调度规则也添加主机标签限制必须包含test_node=true,这样保证测试容器只会运行在node3上不会影响后端服务所在主机的性能。
新增ab-web服务:
网络设置:
标签设置:
调度规则:
启动服务之后,进入服务详情,看到服务是Started-Once,等待服务运行并自动中止,ab测试就完成了。查看服务日志便可看到测试结果。
测试结果:
如今想再测试一次,只须要手动启动服务或者给这个服务扩容便可。多运行几回压测,把这几个重要指标放到Excel中进行统计分析就能够知道服务的稳定性和性能了。
以上只是压测的介绍,压测时间才持续时间1秒钟确定不能说明什么,咱们经过调整-n参数来增长服务请求数,让压测持续一段时间,在此期间扩容服务,看看服务稳定性怎样。
选择ab-web服务,将其克隆,在新服务里面把服务名改为ab-web-1w,在命令里面把请求个数参数调整为-n 10000,启动压测服务。等服务进入Running状态后,把hello-web服务扩容到3个后端,确保hello-web扩容的后端启动成功,而且在Traefik控制台确认hello-web后端已经有3个server,这个时候也能够手动刷新 http://web.aek.com 看看Server Name是否出现第三个容器。这时候压测应该还在进行汇总,回到ab-web-1w服务查看日志,等待压测结束。 能够看到没有失败请求,说明扩容期间负载均衡服务很稳定。
咱们再进行来验证服务缩容的时候负载均衡是否稳定,方法同上,将ab-web-1w克隆成ab-web-1w-2,其余参数不须要修改,启动服务,等待压测服务Running,把hello-web服务缩容到2个,在traefik控制台确认hello-web的后端只剩2个,查看压测服务日志,等待压测结束,确认是否有失败请求。 很庆幸,压测结果显示,没有任何失败请求!
再来看看Traefik控制台的健康状态,除了没法请求favicon出现的404错误(Hello-web镜像里面没有放favicon.ico文件),没有其余错误。这也印证了Traefik服务的高可用。
经过以上简单的压测,咱们基本上验证了Traefik在服务扩缩容的过程当中任然可以保持服务的稳定高可用。 再结合DNS泛解析,实现了对用户友好(高可用:升级服务过程当中用户无感知)、对运维友好(部署简单高效操做傻瓜方便)、对架构友好(监控服务升级过程当中有无异常)的简单高可用服务。
固然生产环境要比咱们这个演示环境复杂的多,随机的并发流量,不稳定的网络等等因素也都在影响着负载均衡的高可用。 Traefik还提供了运行状态API,能够整合到监控系统里面实现更稳定持续的监控。Traefik自身也支持HA模式,避免Traefik单点故障。
咱们公司在生产环境用阿里云SLB作流量接入,后面接着Traefik的HA集群作自动域名和服务发现的路由,再后端是各类Web服务,上线运行半年左右,一直很稳定。
以上就是今天的分享,若有不严谨的地方,请多指正!谢谢你们!
Q&A环节
Q1:请问多个服务用了同一个host标签,traefik会怎么选择转到哪一个服务?
A1:服务的容器运行在哪些主机上是Rancher的调度服务所负责的,和Traefik无关。Traefik连接的是服务,这个服务的容器无论在哪些主机上运行都会被链接过来。
补充:咱们目前没有遇到多个服务配置相同域名的状况,相比只会有一个服务生效,改天试一试看。实际应用时还说要避免这种状况吧。
Q2:请问一下这个负载均衡适合哪些环境和应用?
A2:据官方压测结果显示Traefik能够和Nginx相媲美,因此Nginx适合的环境Traefik都适合。目前官方说Traefik只适合HTTP和HTTPS应用,不知道后期会不会支持TCP负载均衡。
Q3:请问大家在生产环境中除了用阿里云slb作流量接入,后面接着Traefik的HA集群,中间是否还用到了nginx作代理,若是有,通常用了多少台呢?
A3:Traefik就至关于Nginx了,并且还比Nginx好用,咱们生产环境就没有用Nginx了。Traefik HA集群用了2台主机,自动适应的主备结构。
Q4:我想问一个跟traefik能访问远程的docker吗?docker API能够配置认证吗?
A4:只要是使用HTTP协议的API均可以使用Traefik代理。
Q5:请问下dnsmasq怎么实现的主备?
A5:咱们目前的DNSmasq只是用在公司内网,因为没有什么压力,因此没有考虑DNSmasq的高可用。生产环境使用的是域名服务商的DNS服务器,这种服务器想必都有高可用吧,好比阿里云的DNS服务器有2个:223.5.5.5和223.6.6.6
Q6:我想问一下,rancher自带的负载均衡除了ui上有些痛点,性能上有什么不足么?
A6:Rancher自带的负载均衡基于haproxy,也是很成熟的负载均衡解决方案,原本不存在性能不好的问题,可是Rancher默认的内部的网络交互上存在性能损耗问题。你们能够根据今天的压测思路,部署一个Rancher自带的负载均衡,用压测看看性能。同时也对比一下把服务直接在主机上暴露端口访问的性能,三者之间对比,性能对比仍是比较明显的。
Q7:请说下Traefik的HA集群怎么部署?
A7:Traefik的HA集群是基于consul后端作存储,启动多台Traefik链接到consul,Traefik会自动选举一个节点做为主节点,其余作备用节点。具体教程请查看官方说明:https://docs.traefik.io/user-...
Q8:有尝试lvs加traefik吗?
A8:咱们目前是把Traefik的HA集群的多台主机都加入到一个阿里云SLB的虚拟服务器组,流量接入阿里云SLB后,自动负载到Traefik的集群,而后再路由到后端服务。目前没有使用LVS。
Q9:traefix在https上部署容易吗?
A9:Traefik部署https应用仍是很方便的,只要添加SSL证书先关配置便可。还有一个颇有吸引力的特性,只要配置了ACME,就能够对SSL证书自动续费。对于想小范围使用免费SSL证书的环境很是友好。
Q10:用了阿里云的slb还须要本身traefik的高可用么?阿里的Slb不是支持健康检查的么,我想的是可不能够利用这个来作高可用?
A10:阿里云SLB是流量接入端,若是在阿里云SLB上配置域名路由不只麻烦(每一个域名都手动添加一条记录),并且只能配置后端到某个服务或者服务器组,这样不利于服务的高效利用呀。因此仍是须要像Traefik这样的自动适配代理来作域名适配转发。为了不traefik这个核心域名路由转发节点的单点故障,因此最好是作traefik的HA集群。固然流量小的状况下,能够先不用HA集群。健康检查是说若是发现某个后端不健康,就把这个后端从负载均衡中移除。若是后端只有一个traefik,万一这个traefik不健康,阿里云SLB不就断了后路了么?因此说至少用两个traefik来作HA,就是避免单点故障。
Q11:请问大家的网络是如何规划的,好比,咱们有DMZ区对外访问,核心区放置Server,不一样应用服务分不一样网段?
A11:咱们阿里云环境是用专有网络的,对外都是使用SLB作接入的。专有网络本身能够设置网段,好比10.8.1.0/24是容器服务器分区,10.8.2.0/24是数据库服务器,在公司路由器上作路由跳转,公司内网指定的电脑才能够直接访问生产服务器。不该应用分不一样网段,便于管理,也便于问题定位,建议作网段划分。
Q12:dns的ttl设置有讲究么?
A12:DNS服务的TTL是指在DNS服务器上缓存时间,设置越小,DNS的变更就能够更快在全网生效,然而运营商的DNS设置TTL都是有限制的,默认600秒,想要设置更短,就要购买高级服务了。
Q13:单个服务支持多个域名吗?服务的label怎么配置呢?
A13:单个服务支持多个域名,多个域名用英文逗号分隔便可。
Q16:目前贵司后端服务发布 有什么灰度发布的方案吗?
A16:目前使用的Rancher的升级机制实现的灰度发布,每一个服务在至少2个容器的状况下,升级发布服务的时候就能够保证服务不中断,由于Rancher会先中止一个容器,立刻启动一个容器,保证这个新容器启动成功,才会中止升级下一个容器。这个策略基本知足了灰度发布的须要。通过简单压力测试,这种服务升级发布过程当中,traefik的前端是没有遇到请求错误的。
微信号:RancherLabs