豹变 | 国内某大型酒店集团 Kubernetes 落地实录
胡忠良 / 国内某大型酒店管理公司运维经理
嘉宾介绍：
负责国内某大型酒店旅游线上业务系统运维。曾多年在全球五百强企业承担技术团队管理工作。51 CTO 讲师，Dockone 社区分享嘉宾，熟悉微软，Linux 知识体系；熟悉互联网技术解决方案，拥抱开源技术。
阅读字数：4167 | 5 分钟
讲师：胡忠良
校对：小百科
点击文末【阅读原文】，获取【讲课视频】。对话框回复【资料下载】获取本文 PPT。
大家好，今天和大家分享一下我所在酒店管理公司在整个私有容器云建设经验。
新老平台介绍和对比
老平台：简介
我所在的酒店集团，旗下有超过 8000 家酒店，80 多万间客房，集团在 2015 年、2016 年大体推广线上业务，整个线上预定平台相关系统超过 600 多个应用，超过 3000 台虚拟机，超过 400 名的技术人员进行平台开发和维护。
老平台：瓶颈
2015 年开始，线上业务开始激增，我们系统也面临扩容压力，线上压力成百倍的增长，随之而来是业务的稳定性、开发和运维，需要在整个系统扩容的过程中以及日常的运维过程中，包括发布等等方面投入大量的人力维护整个公司的整套系统正常运行。2015 年底，我们认为之前那套基础架构以及管理方式已经无法跟上业务发展，所以 2015 年开始研究新的平台。
在 2016 年初，在才云的协助下完成了对整个系统基础架构的重构，底层也是使用了 Docker+Kubernetes 的技术。10 月底完成了所有应用进行容器化改造，并迁移到 Kubernetes 的平台上，完成后从 CI/CD 开始到运维、到线上故障的处理，整个效率得到了非常大的提高，之前运维团队需要花大量人力处理线上故障。比如说一个应用死掉了需要通过人工进行处理、或者通过监控平台出发。完成整个基础架构改造以后这部分工作量至少下降 90% 以上。
新老平台：架构对比
这张图是改造之前的应用架构，最外层是 LoadBalance，请求以后根据 LoadBalance 请求策略，根据不同的 IP+ 端口，到后端的节点上，当时在一个机器上安装三个实例，分别是三个不同的端口，提供不同的服务，当你的应用多了整个管理非常复杂，LoadBalance 的应用配置、CI/CD 也是通过 Jenkins 实现的，通过 Jenkins 触发对应的发布脚本，把编译完成的 jar 包推到对应的目录，Jenkins 脚本也特别复杂。
改造前：应用架构图
由于整个应用配置特别复杂，我们通过一个 Excel 表管理应用，有不同的服务、名称，在哪一台虚拟机上，端口分别是什么，这张表非常庞大，这只是截取了其中一部分，还需要人工维护。
改造前：通过庞大的 Excel 表管理应用
新平台：架构
这是架构改造完成以后，比较明显的区别就是 CI/CD，Jenkins 是处理一个 CI。CD 完全交付给 Kubernetes 处理，Jenkins 只是完成了 Docker 镜像的打包送到 Kubernetes，线上到底多少个副本，包括整个路由分配都是 Kubernetes 实现，LoadBalance 配置也比以前简单很多，原来 LoadBalance 特别复杂，每个应用会落到不同的节点和端口，现在 LoadBalance 只需要写几条，对应的请求落到 Kubernetes 上的提供访问服务的几个 NODE 上就可以了，我会把这几个 NODE 调度成不跑任何的应用容器，大家可以看到 Kubernetes 一层已经实现了自动化。
改造后：应用架构图
我司私有云平台重构用到一些开源软件，代码仓库还是 Gitlab 和 svn，核心的是 Docker 和 Kubernetes，持续集成还是使用了 Jenkins。我个人认为这是目前最好的持续集成的工具，普罗米修斯和 Grafana 实现了容器监控，最后三个是 Elk，是一套开源日志的解决方案，中间也使用了才云的技术以及开源工具，才云把这部分代码已经贡献到了上游。
遇到痛点
我们当时遇到了一些痛点：
第一，系统架构缺乏弹性；
第二，工具或者流程阻碍了测试与版本的上线速度；
第三，发布后的系统无法快速查错；
第四，服务稳定需要大量人工保障。
解决方案
系统架构缺乏弹性
第一，之前虚拟机上直接装应用系统占用率低，由于调度代价大，所以整个系统，包括整套架构，我会按照整个平台可能受到的最大负载部署我的服务，当我的线上压力低也不会把这些服务给撤了，因为整个部署起来太麻烦了。
第二，系统部署时间长，装系统，部署应用，更改配置，调整 CD/CD 的脚本其实还是挺麻烦的，代价也挺大，遇到业务扩容、系统上线，需要花费大量的资源和时间。
第三，之前我的服务器节点都是一台一台 VM，有时候遇到这台服务器出问题可能会改一些东西，时间久了会产生脏环境问题，今天改了这个东西会成为下次服务器故障的原因。
第四，为了解决上述问题，所以我们会制定标准的服务器标准，以减少配置量。原来我们使用的是统一的 Weblogic 集群应用池，对开发而言，开发语言受到限制，只能使用中间件服务器支持的语言，JRE 版本也受到限制，之前只能在 1.6 版本下进行开发。
基于容器集群环境，都是按照进程方式在跑，资源使用相对可以节省，其实还要看你跑什么应用，如果跑大量 JAVA 应用也没有省很多，但是相对来说可以节省一部分资源。
Docker 集群其实是用完就销毁，所以脏环境的问题也都没有了，整个配置管理会比之前容易很多，之前有几百个文档积累每一个应用到底是如何搭建的，都要通过一个一个 Word 文档记录，其实很花时间，用 Docker 以后就基本上知道这个环境到底做了什么东西。
整个容器的环境可以支持快速扩容，当业务要上线的时候可以根据业务需求快速扩容，对整个资源使用率业务可以分高峰、低峰，在高峰的时候提高线上应用的副本，到了晚上一些闲的时候把这部分资源释放出来，把副本资源释放给 BI、深度学习等等一些应用使用，这样可以提高整体资源的使用率，因为调度成本非常低。上了容器以后对开发来说应用的 Runtime 可以看成应用的一部分，只看要把环境打包到 Docker 镜像里在我的平台上都可以跑，所以这里没有任何限制。
这是才云平台的 UI，可以看到整个副本的调整都通过 UI 来调整，调整完副本应用完以后几分钟整个线上的副本数就和你设定的调整到所设定的对应副本数。
靠右边这张图可以有一个自动的弹性扩展，可以设定 CPU 大概达到 80% 的时候可以自动扩容，除了基于 CPU 的弹性伸缩还支持根据 QPS 应用并发请求数来进行扩展。
工具或流程阻碍了测试与版本的上线速度
这部分包含工具和流程，整个在改造的时候对这两部分都进行了调整。整个 CI/CD 部分进行优化，可以实现每个应用单独的进行发布，在基础和工具上我们发现之前整个 CI/CD 中配置管理是很麻烦的问题，环节比较多，配置管理配错了导致的故障很多。
我们有四个环境：开发环境、UAT 环境、蓝环境、绿环境(可以把绿环境理解成预生产)，中间的配置和服务调用的地址，如果你经常去改的话配错的几率还挺高的，所以我们给不同环境的建立了独立的 Cluster，应用调用使用 ServiceName ，我们确保每个集群的应用服务名是统一的。这样从 qa 到 uat 环境到蓝环境、绿环境，配置都是一样的，写的地址都是一样的，但运行在不同集群中访问的服务也是不一样的，这样配置量减少了 60%、70%，由于整个配置量减少，这部分出错的几率也降低了很多。
有的时候我们这边会有一些项目，代码可能会有一个开发分支，而且这个开发分支上的功能要开发很久，就有环境被占用的问题。按照之前的做法会安排相关的同事帮助他们搭建一套新的测试环境，看看整个环境的复杂程度可能要几天，长的话一两个礼拜。整个应用容器化以后，建测试环境就特别快。比如三个应用加上一套 ES，半个小时可以建立一套测试环境。
持续集成还是使用 Jenkins，我们没有跟风使用别的东西，我们没有做容器化之前就使用 Jenkins，容器化的过程中也调研了一下 Jenkins 和其他产品的对比，我们发现 Jenkins 对 Docker、Kubernetes 不错，有很丰富的插件，所以我们还是继续使用了 Jenkins。
发布后的系统无法快速查错
当你的应用节点多了以后定位问题是很费劲的，之前应用实力少，可能就一两个，当你的应用四五十个节点的时候，整个定位问题就很麻烦，要做日志的聚合，在容器化之前我们已经使用了 Elk 的解决方案，所以在整个容器化过程当中我们希望这套方案一直使用下去。
才云平台在给 Kubernetes 做二次开发的时候其实就支持这样一个功能，Log4J 打到标注输出上即可，在 Elk 里可查看任何一个应用日志，当然你也可以在每个容器中挂盘，把相关的日志写到网络存储盘，通过 Log4J 采集也可以，对于一些没有做日志改造的或者本身就有一些开发部门对容器化本来就有一些疑问的，对于他们来说我们不希望他们做一些特别多的改造配合做这个事情，我们希望这个东西可以快速上，并且可以看到效果。主要在应用里把 Log4J 把日志打到标准输出上。
这是 Elk 的界面，可以根据关键字的查询，已经把所有的日志聚合在一块了。
服务稳定需要大量人工保障
这是我们运维团队非常关注的点，很长时间我们同事忙得不可开交，处理一些这个服务不可用，那个服务出问题，需要人工处理应用恢复的事情。
其实 Liveness 和 Readiness 我们也使用了，而且这个功能的使用对于我们的运维自动化以及日常运维提供了非常大的帮助。
旁边是 liveness 和 Readiness 这两个配置，最早监控服务是通过端口，运维同事会看这个服务是起来，还是没有起来，其实这种方法不太准确，有的时候端口起来了应用觉得完全没有起来，我们在容器化期间要求开发同事为每个应用提供一个页面，整个 Kubernetes 之间有机制，每过几秒钟调用这样一个接口。
我们这个比较简单，就是写了一个接口，只要能够正常返回 200 就可以，这个代价比较低，因为我们在很短时间内要完成这么多的应用的容器化，我们也希望将来可以和当当网一样，把整个页面做更好的完善。
总 结
整套都是开源产品；
开放性和兼容性比较好；
服务的自动修复；
可快速、可弹性部署；
降低运维成本。由于大部分会有一些运维方面、配置方面的工作完全由 Kubernetes 接管，所以整个人员的成本可以降低。
经验分享
对于中间的整个容器化过程中也遇到了一些问题，也对应用进行了一些改造，有几个建议：
第一，建议无状态化的应用上容器，如果有比较多的持久化数据，其实可能要考虑一下是否需要上，因为我们做容器化其实是为了解决频繁变更配置特别麻烦的工作，希望通过整个平台解决掉，像一些持久化数据的服务例如 ES，Redis 本身没有频繁变更，其实整个架构是很稳定的，我也不会经常对它进行扩展，这个点大家可以考虑一下。
第二，Session 保持 Kubernetes 支持，但是这部分功能比较弱，如果有 Session 保持的要求我们建议你把这部分放在外面独立的 redis 里。
第三，写一个正确的健康检查 URL。
我的演讲到这里，谢谢大家！
Q & A
Q：关于健康检查地址是固定的还是什么？
A：不同应用是不同的，但是每个应用是固定的。（见下图）这个可以看到 17.22461.1，后面是 -30211，那个集群里任何一个 NODE 的地址和服务端口号，后面那一串肯定是固定的。
Q：我想问一下如果完全采用 Kubernetes ConfigMap 这个东西，配置量是不是很大？
A：我们当初想要上 Kubernetes 的时候就是为了解决配置问题，之后我们花了一点时间想明白这个事情了，如果你的配置一定要配，要看这个配置在哪里配，我们的配置文件和外包分离的，我们跑的镜像都是对应这个环境的镜像，我们把配置文件放在 SVN 上，他们要修改就在 SVN 改，如果用变量的方式进去，或者是用 ConfigMap 方式，其实更改配置这部分工作还要做，换了一个地方做，就要评估在哪里改方便，我觉得还是用最传统的方式放在 SVN 上改更方便，如果改变量也很复杂，因为你改配置的工作还在做，就看你在哪里改。
Q：你的镜像还是读的是文件？
A：对，外包和配置是分开的，不同环境会有不同环境的配置文件。