趋势科技基于 Docker 和 Kubernetes 的持续部署实践

使用 Docker 可实现对环境和资源的隔离，但是与此同时也需要一套容器集群管理系统对分散的容器进行整体性的应用部署、维护和扩展等。Google 基于自身多年的大规模容器管理经验，推出开源的 Kubernetes 是目前流行的容器编排系统之一。此外，Docker 还改变了软件开发方式，成为了持续部署的一个重要选择。

趋势科技采用的是Docker＋Kubernetes＋Jenkins 的技术方案实现CI/CD，团队的开发、测试和生产环境的部署工作都Docker 下进行。该方案实现PB 级数据处理，帮助了新业务的技术方案落地。InfoQ 对趋势科技的资深研发工程师孙青进行了相关的采访，另外，孙青将会在 CNUTCon 全球容器技术大会上分享题为《我在 Kubernetes 实践中踩过的坑》的演讲。

受访嘉宾

孙青，趋势科技中国研发中心资深工程师，6 年研发经验，致力于大型分布式系统的设计开发，目前专注于 Docker 和 Kubernetes 在持续集成以及持续部署中的最佳实践。

InfoQ： 能否介绍下趋势科技的业务和团队规模情况？与此对应，你们技术的需求是怎样的？

孙青：趋势科技业务范围涉及终端与移动安全、服务器安全、网络安全、虚拟化安全和云安全等。安全服务是由全球的 5 大研发中心共 1200 多名业界安全专家负责。我所在部门提供趋势全球移动安全响应和研究，主要负责各类移动平台相关的威胁分析、应急响应以及漏洞挖掘等业务工作和相应系统研发工作；目前团队有五十多人。

团队目前开发技术栈是：Python + MySQL + MongoDB + Redis + ELK + Hadoop。技术上需求主要有两个，海量数据的处理和新技术方案的快速落地。移动安全作为新兴的安全领域，近些年来得以快速崛起：要处理的样本信息迅速从 GB 级别激增至 PB 级。同时为适应各种业务，配套的新技术方案也源源不断从预演阶段快速迭代至生产环境。在满足业务增长需要的情况下，如何能合理有效的利用和管理资源是首要问题。具体来说，在资源共享和有效隔离的情况下，如何实现海量数据的分布式存储、索引以及快速分析查询。

InfoQ： 您说过公司因“业务特殊性”遇到了痛点，能否介绍一下？在解决痛点的过程中，技术方案的改进历程是怎样的？

孙青：因为处理样本的模块较多，出于系统机器资源考虑，不能为各个业务提供独立的环境；所以在部署上经常出现环境和资源冲突或资源浪费的问题。初期由于样本量小，分析模块都是单独部署，使用的是 SaltStack + supervisord 来管理。

随着存储量的激增，首先，机器数量越来越多；其次，分析模块也越来越多。由于各个模块对资源的需求都不一样，为了不浪费机器资源，我们开始混合部署。混合部署之后，又面临着资源冲突以及环境冲突的问题。公司运维花了大量时间去解决这些问题，这造成了很大的困扰。Docker 发布后，经过一段时间的调研，我们决定基于 Docker 开展部署，最终形成了现在的方案。

InfoQ：可否介绍下现在的持续集成和持续部署方案？

孙青：目前方案是 GitLab + Jenkins + Docker + Kubernetes。

方案的工作流程如下：首先，开发人员提交代码代码提交；随后，GitLab 会自动触发 Jenkins job，Jenkins job 会构建相应的镜像，放在一个 Kubernetes 的 Pod 里面；接下来，Kubernetes 的 Pod 会把模块需要的其他依赖都包含在其内部（比如 MySQL、Redis、MongoDB 等），运行 robot 测试用例，测试用例的结果最后会反馈到 Jenkins 中；所有测试通过之后，GitLab 把代码 Merge 到 Master 分支，然后触发部署，构建生产环境所需的 Docker 镜像并上传到镜像仓库。最后，生产环境的 Kubernetes 拉取最新的镜像做更新。

InfoQ：为什么选择 Docker 作为新的技术方案？又为什么选择 Kubernetes？

孙青：刚才提到过，选定 Docker 作为持续集成和持续部署方案是经过调研的结果。因为，发现 Docker 的理念正是我们所需要的，尤其是对环境、资源的隔离。从目前使用的效果来看，也确实达到了引入它的目的。

在决定要使用 Docker 之后，团队研究发现必须要同时使用一套容器集群管理系统。团队认为 Mesos 更适合作为 DCOS 的一部分，对于我们的业务有点“杀鸡用牛刀”的感觉。当时，Docker Compose 和 Swarm 刚刚发布，还不太成熟；Kubernetes 关注度很高、社区很活跃，而且 Kubernetes 里面的 Pod、RC、Service 的抽象很符合趋势科技的业务需求：所以最终选择了 Kubernetes。

InfoQ：在这个持续集成和持续部署方案之前，趋势科技是如何实现测试集成和部署环节呢？采用了这个方案之后，带来了哪些收益？

孙青：在使用 Docker 之前，准确地说，公司并没有持续集成和持续部署的方案，当时采用的只是比较传统的测试部署流程：开发人员完成开发并测试之后，首先提交代码到 SCM，然后出 build，build 好之后先在 staging 环境做集成测试，确定没有问题之后再部署到生产环境。

方案采用后，上线频率由原来的两周一次提高到一周两次。因为不再需要解决机器环境冲突的问题，所以该方案也同时大大降低了的运维成本。当然，新技术栈的引入会带来了额外的维护成本，不过这是无法避免的。

InfoQ： 对现阶段的 Kubernetes 使用满意吗？趋势科技对 Kubernetes 做了哪些改造？如何看待 Docker 前不久推出的内置编排工具？

孙青：目前对 Kubernetes 使用状况满意，它满足了公司的业务需求；团队正在将 Kubernetes 稳步落地，各项业务还在迁移的过程中。目前，还没有对 Kubernetes 进行改造；但是后续团队会着手改造工作，现在正在调研 Kubernetes 的 autoscaler。之所以这么做因为 Kubernetes 的开发计划里面，自定义的 autoscaler 目前进度还不明朗，团队会考虑自行研发一个基于 QPS 的 Autoscaler。

个人还没有深入研究 Docker 新推的该项功能。不过我个人认为 Docker 作为目前主流的容器工具，它内置的编排工具势必会非常有竞争力，后续会去研究一下 Docker 的内置编排工具。作为技术使用者，我们希望可以有更多的工具选择。如果业务上有需求，技术上我们也会考虑选用。

InfoQ：在采用 Kubernetes 技术过程中，可否简单讲讲你们遇到的最大的坑？有什么经验可以分享？

孙青：其实最大的问题主要还是网络，趋势科技的网络是基于 Flannel 做的。在使用后不久就遇到了 FLannel 出问题，导致 Node 之间的 Vxlan 不通。当时查这个问题查了很久，后面找到原因看到是因为 Flannel 在 bond 网络下的 OOM 导致的。好在 Flannel 修复的比较及时，并没有对我们的业务造成太大影响。但是 Flannel 的最新发布还是 15 年 11 月，所以猜测其开发进度没有预期的理想。因为我们对网络方面的要求并不高，所以到目前为止没有发现其他重大问题。

因为 Kubernetes 到目前为止被大家诟病最多的还是它的网络解决方案以及网络抽象。对于网络要求较高的服务我建议要多调研，多做一些性能测试。我个人的观点是：如果业务对网络的要求极高，就不推荐用原生的 Kubernetes。如果要用，网络架构不推荐使用 Flannel，可以做其他的选择；此外，需要对 kube-proxy 进行一些改造。

感谢徐川对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。