从Docker到Kubernetes,爱数云原生演进历程
作者: 日期:2021年09月22日 阅:1,526

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

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


相关文章