本文作者：爱数技术研究院 系统架构师 陆远

在爱数技术发展历程中，云原生技术在2015年左右就开始进入了爱数的视野。只是那会，还没有提“云原生”这个词。

在2015年的时候，我跟公司另一位同事参与一个活动，听到了Docker，了解到了容器技术。回来之后，就开始预研和试用Docker。

从2016年开始，我所在的AnyBackup团队已经在关注Docker技术的发展，最初是期望在持续集成这块使用容器技术，来降低环境的依赖和管理复杂度。

同年，公司考虑到业务发展，组建了一条新的产品线， AnyRobot产品线，期望帮助用户实现智能运维。

从一开始AnyRobot就是基于容器技术构建起来的。这个过程大致分为三个阶段：

1. 基于容器化快速上线；
2. 基于Mesos实现集群化资源统一调度；
3. 切换到Kubernetes。

下面我来分享一下AnyRobot在2016-2019的容器化实践历程，主要是前两个阶段，包括遇到和解决的问题和得到的启发。

第一阶段：基于容器化快速上线

第一阶段遇到的问题：产品依赖多种开源组件，有基于Java的、有基于Ruby的还有基于Python的，这些开发、测试、生产环境管理难；初期人员少，需要快速验证和上线产品。

为了解决这些问题，在2016年左右我们引入了Docker，使用容器技术的隔离能力降低了应用运行时带来的碰撞和冲突，屏蔽部署环境差异性、单个主机混合部署多种环境。

通过Dockerfile版本化环境，通过Docker的镜像和镜像仓库技术，降低了环境依赖和简化了程序分发，同时屏蔽了研发各流程中的环境差异，保证了开发、测试、构建到生产部署环境的一致性。

通过Jenkins Pipeline持续集成流水线快速完成组件的打包和发布，所有配置版本化和统一管理，无需单独人员维护，降低了构建维护成本。

基于这些，初期3、4个人的团队，大约花了一个月，从对于容器技术和Docker的预研、对于日志分析领域的开源技术栈的预研，到使用开源技术栈快速包装出了第一个产品化的一体机版本。在这个过程中，通过容器技术，大大简化了环境依赖和环境管理，提升了开发效率，快速地验证了整体业务。

在产品初期的几个版本，服务基于主机网络来进行通信。这么做比较简单，但是很快遇到了网络冲突的问题。某个服务需要启动多个副本来做能力扩展的时候，会出现网络冲突，无法在同一节点扩展。随后我们将容器的网络模式从主机模式切换到网桥模式，利用容器的网络命名空间降低了网络碰撞问题，简化网络复杂度，同时增强了同一服务的扩展能力。

另外一个问题是网络流量控制。由于初期的理解，docker的网络管理与防火墙无法共存，导致无法使用防火墙实现服务器网络流量控制。我们在对docker网络通信原理的研究后，利用相同的原理，在此基础上扩展了网络控制能力，实现了类似防火墙的网络流量控制。

同时还解决了一些其他问题。在cpu和内存资源上，我们利用cgroup技术对容器资源进行了初步的限制。基于单物理节点提供Elasticsearch集群，提升了系统资源利用率、降低Full GC的卡顿时间，提升了性能。

到了2017年初，由于考虑到 AnyRobot 业务能力的扩展，业务规模化下的性能、可用性等能力的支撑，我们开始着手从单机形态迈向分布式集群。

第二阶段：基于Mesos实现集群化资源统一调度

从单机到集群，我们首先需要解决的是容器在集群上的编排，以及集群节点管理、节点资源管理等问题。当时评估了几个容器资源编排产品，Docker Swarm、Mesos和Kubernetes。

评估维度包括架构特点、隔离机制、资源调度机制、网络模式、高可用、扩展方式、健康检测、故障转移、服务发现、负载均衡、集群规模、文档、社区活跃度、用户案例等方面。

当时考虑到Kubernetes还不够成熟，网络和存储方案不完善,另一方面觉得Mesos已经经过长期和大规模的验证，相对较成熟，而且两级调度能够更好的扩展调度策略，最后选型采用了Mesos + Marathon，Mesos提供容器底层资源平台的抽象，同时还能集成其他框架，做为容器编排的底层平台；Marathon提供容器平台的操作能力和容器/任务的可观测性，作为容器编排平台的操控入口和可视化页面。

2017年到2018年，AnyRobot在实践Mesos和Marathon的过程中，解决了不少问题。

在网络上从单节点到多节点，首先带来的是节点的通信配置问题，首先容器需要实现跨节点的通信能力，其次是不同节点上容器通信配置的传递问题。为此我们研究了mesos-dns和marathon-proxy框架，同时也利用之前积累的docker网络技术和计算机路由技术，实现了跨节点通信的问题，通过统一容器通信配置和搭建dns服务器进一步优化了节点通信的配置同步问题。

这些在后来的Kubernetes生态，有kube-proxy、core-dns和service来支持。

通过利用mesos的资源定义能力和AnyRobot集群管理系统的进一步研发和优化，将存储定义与应用部署分离，明确了环境管理人员职责和部署人员职责，同时将集群资源进行抽象化供上层应用使用。

并且考虑了在私有云环境下可能存在的机器性能不足问题，因此通过Mesos资源定义，对机器资源进行一定策略的伪放大，实现资源超卖。

在实践过程中还发现，由于marathon自身的可观测能力仅限于容器任务状态，且不够深入，无法满足分布式应用平台运维的需要。因此我们引入了Prometheus和Grafana等实现对集群节点、基础平台的指标的监控。并且由于AnyRobot自身的业务能力，能够完成对平台日志的采集和提供良好的分析能力。

在这个过程中，Kubernetes不断快速迭代，加上CNCF和社区的完善，2019年在容器编排领域，竞争格局基本尘埃落定，Kubernetes成为容器编排领域的事实标准，成为云原生的底座。2019年也被称为云原生技术普及的元年。mesos、marathon此时已经处于半停止维护阶段，mesos自身的各种漏洞，mesos社区发展缓慢。在这个过程中，我们也关注到这个变化，规划AnyRobot 从 Mesos+Marathon 逐渐切换到 Kubernetes。