使用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进行一些改造。