DockOne微信分享(一三四):国内某大型酒店管理集团基于Kubernetes的实践


【编者的话】随着业务的增长,架构变得越来越复杂,服务器和应用数量越来越多,随之应用的管理,配置的管理,后期的运维都受到了极大的挑战。之前通过人工进行服务器配置,后期运维通过监控平台发现故障,人工恢复的模式已经无法适应业务的需求。我们借助Docker+Kubernetes打造的新的容器云平台,将之前90%以上需要人工维护部分的工作变成了自动化,一切变得so easy。

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览;持续集成系统介绍;客户端与服务端的 CI/CD 实践;开发流程中引入 CI、CD;Gitlab 和 CI、CD 工具;Gitlab CI、Drone 的使用以及实践经验分享等。

公司5年前已经开始了敏捷方法的实践,并打造DevOps的文化,应用架构也完成了SOA的转型,但是由于业务的增长,系统越来越庞大,大家发现敏捷越来越不敏捷,DevOps的实现愈发困难。

在2015年经历了几次大的项目上线后,大家意识解决这些问题的严重性,在2015年底,我们开始相关调研,正值Kubernetes发布,我们发现Docker+Kubernetes可以很好的解决我们面临的一些问题,2016年初我们开始基于Docker+Kubernetes的私有容器云的建设,当年10月完成所有应用容器化改造,并全部稳定运行在Docker+Kubernetes平台。升级后我们的运维效率得到了成倍的提升。

先介绍一下重构前的架构:
图片1.png

重构后的架构:
图片2.png

另外我们使用了ThoughtWorks推荐的一个方法,把我们的我们的应用环境设计成4个环境,分别是QA、UAT、Green、Blue其中QA环境是用于开发人员使用的测试环境另外考虑应用联调的需要,我们提供了一套便于各开发小组联调的UAT环境(数据非真实数据)。

绿、蓝环境均是生产环境,连接同一套数据库,但是除了数据库之外,所有的应用以及相关依赖均是独立的,蓝绿环境的配置,一解决了发布中线上环境的问题,我们的发布流程是:
图片3.png

这样设计的一个作用是为了实现任何时间可以进行发布任务,后面会详细讲。另一个作用蓝绿环境是一个互备的环境。

以下罗列了一下Docker+Kubernetes解决了我们具体的哪些痛点,我找了几个分解一下。

痛点 1

系统缺乏弹性

在面临大的项目时我们需要增加大量资源对现有应用系统进行升级,传统的方式费时费力,需要一台一台服务器部署,还需要调整整个CI/CD的脚本,调整Load balance。整个系统搭建完,再进行调整还会导致大量的人力成本,考虑到调整起来代价比较大,所以我们一般会按照可能的承受的最高负载配置资源。这样也导致了资源的利用率降低。另外还有脏环境的问题,环境配置文件的管理等问题。

当然考虑到以上的原因,为了降低管理成本,我们对服务器,应用运行环境做了一些标准。例如规定了Java运行环境是什么,JDK是什么,我们基于这样的规范做了虚拟机的模板,以降低管理成本。这样也带来了一些新的问题,对开发而言,一定程度上限制了对新技术的使用。

Docker+Kubernetes如何解决了这些问题

Docker的特性,用完即销毁,解决了脏环境的问题。

在Kubernetes上应用容器是基于同一个镜像生成,扩容简单,面临大项目上线时候只要Kubernetes集群资源充裕,应用扩副本可在很短时间内完成,无需对持续部署脚本做任何调整。除了提高效率外,在资源利用率上,我们可以做一些动态的调度,例如在闲时减少副本的数量,闲置资源可用于大数据计算,深度学习无实时要求的应用。

另外Docker技术的使用,应用程序的Runtime变成应用的一部分,集群节点都是标准的,至于平台上跑什么样的Docker已经对环境不会造成管理上的影响,所以我们的平台可以同时支持各种Web运行环境,中间件。对于开发而言,这部分不再受到限制。

痛点 2

敏捷体系下,大量迭代,带来大量的发布,原流程和工具阻碍了测试和版本上线的速度。

如何解决大量发布,而不影响线上业务? 很多公司考虑发布过程中对业务的影响一般会采用两套方法:
  1. 在系统访问低谷发布,例如在凌晨。
  2. 采用滚动发布的方法,节点逐个进行代码更新。但是前提是代码要做到向前兼容,因为请求会同时落到新老节点上。


我们为了解决这个问题,我们的生产环境则分为蓝绿环境,资源配比1比0.5 ,我们发布时可以先发绿,完成后将其切换到线上,再发蓝,蓝发布完成后再重新将蓝切换上线。这样可以确保在一天的任何时间进行发布。

技术方面,由于应用数量较多,而且有4个环境,导致应用直接互访的配置文件管理异常的麻烦,上千个配置导致及其容易出错。我们利用了Kubernetes的一些特性。我们为每个环境都建立了一个集群,并且应用在每个集群的service名称均一样,并且分区名称一致。

这样应用abc在qa集群内可以使用abc这个服务名进行调用,在UAT集群也是使用这个服务名,但是集群之间其实是隔离的。这样的设计,使得这部分配置变成了免维护的配置。极大降低了配置管理的工作量。
图片4.png

痛点 3

服务稳定需要大量人工保障

原平台下应用的稳定,我们是监控加人工干预,后期我们做过一些尝试,使用Zabbix监控配合一些服务重启脚本来实现应用故障后自动恢复,但是实现过程还是比较麻烦。

新的平台

我们利用了Kubernetes的liveness和readiness两个健康检查的探针技术解决了服务故障后的自动恢复。

在应用的yaml文件内可加入以下内容:
图片5.png

其中path部分就是应用的健康检查url。平台会根据预先设定时间,检查应用的url是否可访问,一般liveness的检查时间会略长于readiness,如果失败会触发readiness探针,外部请求将不会落在故障pod上,另外会触发liveness探针,系统会自动kill掉故障pod,并自动新拉起一个pod,由于这样的一个机制,整个服务实现了自动恢复。

这两个探针也支持端口检测,或者run一个脚本看是否返回特定值,当然我们觉得端口的方式不够准确,之前遇到过很多次端口是通的,但是应用已经挂掉的情况。所以我们使用了心跳url的方式,另外注意,心跳url的制作,要确保这个url不要依赖其他的服务。

Kubernetes平台很好的解决了我们的这些痛点,整体的效率得到了成倍的提高。服务可用性得到了极大的提升,并且原来投入在保障服务稳定性部分的人力降低到之前的5%。

参考文档:https://kubernetes.io/docs/tas ... obes/

另外关于分享两个容器化过程中的小经验。

1、如果使用Jenkins实现CI /CD,由于每次build出来的版本避免与之前的有冲突。可以使用Jenkins的流水线编号变量作为镜像的tag号,这样你的镜像的tag和pipline号可以一一对应,对于管理和排错提供方便。
图片6.png


2、关于配置文件,之前一直有一个说法,就是一个镜像可以实现在多个环境里运行。当时我们选择Docker也是看中了能解决配置文件的问题。

但是整个的实践中还是遇到了不少问题,例如有方案是,镜像是同一个,配置通过变量传进去;有的配置文件放在共享磁盘里;还有最新的ConfigMap方案。后来我们用了很久的时间想明白的这件事情,如果不同的环境配置通过变量的方式传进去,其实没有解决配置管理的问题,只是配置管理的地方从原来的配置文件变成了变量管理。换汤不换药,而且变量管理其实会更加麻烦,不如配置文件来的直接了当。所以这是个伪命题。

共享目录的方案,所有Docker同时挂在一个放置配置文件的目录,这样的方式,节点一多这个目录会成为一个性能瓶颈,另外这个挂载目录一旦出问题。所有的应用均会出现故障。这是在系统架构上不是一个好的设计。反而造成了应用和NFS服务强耦合。所以我们建议的方式是,将配置文件与项目的war包jar分离开,通过jenkins实现使用不同环境的配置文件编译不同的镜像。

另外配置文件可以与您的代码放在一起放在SVN或者Git上,修改个文本文件肯定比修改Jenkins上某个task的变量配置容易的多,而且还有版本管理。

Q&A

Q:容器的日志怎么管理呢?不同应用的日志怎么管理?

A:我们在容器化之前已经开始使用ELK的解决方案,所以我们整个容器化平台的改造中也整合了ELK的方案。
我们平台上的日志收集采用了2个方案:
  1. Docker启动的时候mount一个共享存储,日志都写在这个共享存储里,然后配置Logstach采集,最后吐到ES里,用kibana展示,缺点是挂共享存储,性能略差。优点是日志可以根据应用来分到不同的ELK上,并且日志做归档比较容易,我们有场景要查一年前的日志。
  2. 我们在Kubernetes节点上安装fluentd组件,采集Kubernetes node上的日志,应用部分只需要在log4j的配置里将日志输出打到标准输出上系统即可采集,缺点是这个集群的日志会全部聚合到一套ELK上。优点是应用几乎无需做什么改造。
Q:容器中需要持久化的数据怎么处理?

A:原则上我们不建议在容器化平台上的应用有持久化数据 ,如果互联网应用的背景,应用无状态化设计对于应用有横向扩展需求是更加适合的,应用在上容器云平台前要完成这部分改造。但是我们的确有做过数据持久化的研究,当时主要考虑ES集群会有持久化数据,我们的方案是Kubernetes+GlusterFS的方案。但是由于ES集群本身很稳定,也不会有发布,容器化意义并不大,所以暂时我们这部分仍保留在VM上。
Q:请教下,如果开发机在本地,如何连到测试环境(联调环境)上去,你们的网络如何打通?

A:我们不建议开发使用本地资源进行开发,我们提供整套的QA环境(都在Kubernetes上)。
如果实在要登录到Node上看一些东西,我们有堡垒机。
Q:Docker网络用的什么方案?

A:Flannel,能用,性能不太好,准备迭代掉它。这是坑!大家不要踩。
Q:服务对外暴露是用什么实现的?

A:集群内部访问之前说了,服务名的方式,集群外的访问,Kubernetes每个节点都可以提供服务。但是如果所有请求都落在一个Kubernetes节点上,这个节点就是一个单点。
所以我们提供对外服务时仍然会在node前面加一层loadbalance,LB后面将5-10个Kubernetes的节点作为backend添加上去。另外这部分节点最好不要调度任务在上面跑。
Q:你们的Docker容器在Windows上是怎么解决IP通信的?

A:我们不用Windows的Docker,Docker是进程共享的虚拟化技术,Windows和Linux共享哪门子进程?感觉不太靠谱,所以不用。(比较主观)
微软自己也在搞类似Docker+Kubernetes的架构的一套东西,大家可以关注一下,如果要上Windows的Docker那还是用MS的解决方案比较靠谱。
Q:你们的宿主机、容器、服务的监控告警系统架构是怎样的,能简单介绍下吗?

A:宿主机我们还是用Zabbix,服务的可用性我们也用Zabbix(这是容器化之前就保留下来的)但是只有当所有pod都挂掉才会报警,容器的监控我们是使用Prometheus和Grafana。
Q:四个环境的发布权限你们怎么去合理配置呢?

A:原则上用户登录所有环境都需要通过堡垒机,4个环境的发布,都是通过Jenkins来实现的,所以我们会控制Jenkins上对应的Pipline的权限。(Git->Jenkins->Kubernetes)这一段是自动化的,开发人员能做的就是触发构建任务。
QA环境 ,开发测试环境,我们给到开发进入容器,以及查看日志的权限
UAT、开发人员可以通过ELK查看日志,无其他权限。
生产、开发人员可以通过ELK查看日志,无其他权限。
如有特殊的需求,需要让运维人员操作。
Q:如果有开发人员需要上去看错误日志,假设这种错误日志是需要调试,不会被收集,是只能通过堡垒机去看吗?容器的日志怎么进行存储,如果挂到宿主机目录那好多容器怎么分文件夹呢?

A:我们方案里fluentd可以收集node上几乎所有的日志,另外关于错误调试日志,如果是应用的,那开发人员按照需求调整输出路径就好了,用ELK采集就好了。如果是系统级别的,运维人员就把它作为一个Linux主机查日志拍错就好了。
另外容器的日志,解释起来有些长,你可以参考我之前的帖子《Docker日志那点事》,容器日志的目录和格式都有写到。
Q:用的Overlay网络,那你们用的NodePort暴露的服务,然后外部LB访问NodePort?那你们现在容器一个集群内有多少容器?kube-proxy的性能有做过压力测试吗?

A:回答后面一部分,我们每个环境都是一个集群,例如QA是一个集群,UAT是一个集群,我们一个生产集群目前大概 1000+个容器。
关于压力测试,和kube-proxy的负载问题。提供给集群外的服务接口,我们前面会包一层loadbalance,所以请求进来后后会通过LB平均分配到不同node上的kube-proxy上,这部分可以通过横向扩展来解决压力的问题。
另外我们应用上线前会做压力测试,目前我们没遇到过kube-proxy被压死的情况,多是我们的压力不够(我们使用JMeter,大多时候是JMeter死掉)。
Q:各环境用的是同一个image build用env区分?还是不同build?有比较过或遇到什么坑吗?

A:开始的分享提到了,一个image build用env区分,就是坑。配置文件管理变成了env的管理。所以老老实实每个环境build一个镜像。
Q:各环境的config是怎样和什么时候打到image里的?

A:配置文件一起放在Git上,Jenkins拉完代码再把配置文件拉下来,简单点使用CP命令把对应的配置文件和war或者jar以及Dockerfile放到对应的目录下,进行build就好了。
不同环境作为不同的任务。
左边的任务就是把代码拉下来 配置文件拉下来,右面的任务就是把不同的配置放到不同的目录再进行build。
图片7.png

大家可以参考一下这段脚本:
图片8.png
以上内容根据2017年07月25日晚微信群分享内容整理。分享人胡忠良,20年IT工作经验,曾在全球500强公司担任IT运维经理,现任国内最大酒店管理集团-基础架构中心运维经理,微软认证讲师,数据安全专家,ITIL专家,51CTO讲师,Devops实践者,拥抱开源技术。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesa,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

0 个评论

要回复文章请先登录注册