作者 | Lyre 爱数技术研究院-系统架构师

在爱数技术发展历程中，云原生技术在 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。