基于kubernetes 平台的持续集成解决方案研究

梁岸川 上汽通用五菱汽车股份有限公司 凌以静 上汽通用五菱汽车股份有限公司

引言

当前云计算在软件公司中获得了极大的普及。市场上已经有多个云服务巨头：亚马逊云服务(AWS)，微软azure，阿里云和谷歌云。与此同时，中型企业也开始进入这个市场。所有这些吸引力都源于云计算带来的好处。例如，云中的后端服务允许公司不构建自己的基础设施，而且安全性和备份也由云提供商负责。此外，kubernetes 可扩展的开源平台在当今得到了广泛的应用，它提供了创建自己的平台解决方案的可能性，这些平台解决方案可以执行容器化的应用程序。

应用程序的开发包括不同的阶段：设计、编码、测试、构建、发布等等。主要目标是满足客户的需求。为了实现这一目标，公司应该尽可能频繁地迭代、发布产品。目的是为了更快地部署新功能和修复BUG。持续集成实践有助于实现这些需求。

本文的目标是研究持续集成持续部署的最佳实践，并构建一个自动化流水线。关键价值在于实现所有阶段的流程自动化。

首先会回顾本课题项目研究的理论背景和技术背景，包括微服务、K8S，CICD 等。

最后将介绍具体持续集成的实现方法。要实现最终目标，需要通过多个实施步骤。

1 理论背景

1.1 微服务

应用程序市场正在不断增长。最终用户希望获得更优质的服务，包括具有丰富的功能，现代化、可感知的设计和全天候可用性。为了满足这些需求，软件公司需要尽可能频繁地推出更新，更快速地迭代产品。

微服务架构包含多个松耦合的小组件。每个模块都只执行自己的任务，并独立于其他模块。模块之间通过 REST API 接口进行通信。微服务架构可以加快测试和部署速度。

1.1.1 微服务的特性

为了更好地理解微服务架构风格，需要回顾几个特征。

代码库

特定微服务组件的代码量相对较小，其功能应该仅限于完成特定的任务。在这种情况下，团队中的新加入的开发人员更容易读懂代码逻辑以及贡献新的代码。此外，使用更小的模块构建和运行应用程序的开发效率要快得多。

在传统单体架构中，即使是很小的变化也需要构建整个项目。这可能会导致应用程序有很少的发行版本，却有大量的更改。在微服务开发中，鼓励更快更频繁地发布。独立部署服务时，更容易跟踪故障，如果出现问题，则回滚到之前的稳定版本不会花费太多时间。

可扩展性

通常，为了扩展大型单体应用程序的高可用或负载均衡节点，则需要完整地部署整个系统。如果只是某些功能需要更多实例资源，同样需要完整地部署多套系统，因此，扩展此类应用需要大量资源，很明显，复制大型单体应用系统的效率并不高。相比之下，每个微服务可以具有不同数量的副本，这将提高应用程序的性能和资源的利用率。

1.1.2 微服务的挑战

与单体应用相比，微服务架构具有许多优点，易于部署，扩展，修复等等。尽管如此，微服务架构还是存在一些挑战。每个微服务组件都是一个独立的模块，它与其它独立组件打包在一起工作，因此，处理服务之间的通信变得复杂。需要为微服务间的API 接口编写良好的文档，管理这些接口的工作成为重中之重。

测试

与单体架构相比，测试小型独立组件更容易。然而，总体上测试系统变得更具挑战性。需进行大量的集成测试，以验证系统是否正常工作。此外，还需要更多资源来测试系统。在这种情况下，设计良好的pipline 是必须的。

代码

微服务架构允许开发人员为他们需要实现的模块选择不同的技术，框架和库。在特定模块上工作的团队的规模可能相对较小，因此如果一个成员离开公司，另一个团队的开发人员必须学习新的工具才能接手这个模块的工作。

安全

模块可以被其它服务重用。模块化使黑客有更多的入口点可以渗透到系统中。在处理用户数据时，安全性是必须要考虑的，应该投入大量精力来处理微服务架构中的安全风险。

1.2 Kubernetes

需要了解容器才能更好地掌握kubernetes。以前，应用程序部署在主机系统上，这会导致应用程序配置，生命周期和主机操作系统之间有较高的耦合度。

容器是打包应用程序和在不同环境中部署应用程序的方法。如何管理、扩展和恢复这些资源仍然是一个问题。Kubernetes 的出现是为了解决这些问题。

Kubernetes 源于谷歌内部的Borg 系统，提供了面向应用的容器集群部署和管理系统。Kubernetes 的目标旨在消除编排物理/虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。

Kubernetes 用户可以通过编写yaml 或者json 格式的配置文件，通过直接请求Kubernetes API 创建应用，该配置文件中包含了用户想要应用程序保持的状态，就算整个Kubernetes 集群中的个别主机发生异常，都会保持用户所期望的应用程序的状态，这一切都由kubernetes 自动完成。

Kubernetes 集群是一组计算节点组成的一个资源集合。它由两种类型的节点组成：主节点和从节点。Master 是管理节点，负责集群资源的调度、扩展、终止以及更新应用程序。从节点负责运行应用程序。图1 展示了kubernetes 集群。

图1.Kubernetes 集群架构

每个工作节点都有kubelet 组件，它负责与管理节点进行通讯。此外，从节点需要这些组件来创建、运行和删除容器应用程序。它可以是docker、rkt 或LXD。Master 节点的API 是集群的入口。可以使用Deployment 在kubernetes 集群中部署容器化应用程序。在kubernetes 中，Deployment 配置描述了如何更新和创建应用程序。当创建Deployment 时，kubernetes 会生成Pod，它是一种抽象概念，用于表示应用程序的一个实例以及与之相关的一组资源集合，通常包含一个或多个容器。当创建Pod时，它驻留在某个节点上，直到它被终止。如果Pod 所在的节点发生故障，则Kubernetes 集群会自动在另外一个健康节点生成同样配置的Pod，这个新的Pod 对外提供与原Pod一模一样的功能，对外部用户来说，他们并不需要关心这些Pod 所支撑的服务运行在哪个节点之上。

图2.kubernetes 集群中Pod 和Service 的关系示例[3]

kubernetes集群的主要优势是可以轻松实现对Pod扩容和缩容。通过更改Pod 的副本数量可以轻松实现。当Master 节点扩展应用程序时，它会自动选择在其中一个拥有足够多资源的节点中创建Pod 副本。运行一个Pod 的多个副本需要相应的机制来分配流量。这由与该应用程序关联的Service 负责，Servcie 内部实现了负载均衡[图2]。

2 持续集成的实践

2.1 CI 和CD （持续集成和持续交付）

市场的高度竞争迫使企业分配大量的人力和计算资源来实现CI、CD。这些实践为软件开发带来了很多好处。从频繁的发布开始。这改善了用户体验，因为新功能交付得更快。

持续集成是一种软件开发实践，开发人员通常在日常工作中提交代码。每次集成都由自动测试系统进行检查，以便在早期阶段捕获问题。

持续交付是持续集成过程的延伸，它提供了一种可持续的产品发布方式。这意味着不仅测试过程、构建过程应该是自动化的，发布过程也应该是自动化的。为了开始开发这个过程，需要有稳定可靠的持续集成。这个过程有一个将产品部署到生产的手动步骤，但是部署应该是自动化的。持续交付的好处是你可以频繁地进行小版本发布，在快速地交付小功能的同时也可以更快地修复bug。

常用的CI 工具有Jenkins、Travis 、Circle 等等，本文将介绍基于Jenkins 的CI 方法。Jenkins 是一个开源的、提供友好操作界面的持续集成(CI)工具，起源于Hudson（商业产品），主要用于持续、自动地构建、测试软件项目，监控外部任务的运行。

2.2 持续集成的实践

在上一章中，我们回顾了微服务、k8s 等关键技术背景，微服务应用架构在当下非常流行，有着易于部署、扩展、修复等诸多优点，以docker 为代表的容器技术成为微服务架构应用的交付标准，而Kubernetes 又是当今容器编排技术的事实标准，将应用部署在云供应商提供的基础设施所构建的Kubernetes 集群中，可同时获得k8s以及云计算带来的诸多好处，又可以避免被云供应商绑定。

Kubernetes 细化的应用程序的分解粒度，同时将服务发现、配置管理、负载均衡和健康检查等作为基础设施的功能，简化了应用程序的开发。而且Kubernetes 这种声明式配置尤其适合CI/CD 流程。图1 展示了基于Kubernetes 和jenkins 的CI 过程。

图3.基于 Kubernetes 和Jenkins 的CI 流程图

应用构建和发布流程：

1.开发者向Gitlab 提交代码，代码中包含构建镜像所需的Dockerfile，以及微服务应用所对应的服务类型、服务名称、资源数量、实例个数。

2.代码提交到远程Git 仓库之后，通过webhook 触发Jenkins自动构建。

3.Jenkins 的CI 流水线自动编译代码并打包成docker 镜像推送到Harbor 镜像仓库

4.Jenkins 的CI 流水线中包括了自定义脚本，根据我们已准备好的kubernetes 的YAML 模板，将其中的变量替换成用户输入的选项

5.生成微服务应用的kubernetes yaml 配置文件

6.更新Ingress 的配置，根据新部署的应用的名称，在ingress的配置文件中增加一条路由信息

7.Jenkins 调用kubernetes 的API，部署应用。

以上的构建均在开发者提交Gitlab 之后全自动完成。

3 总结

持续集成的目的，就是让应用产品可以更快速地迭代，以适应不断变化的业务需求。持续集成的关键不是集成，而是持续。所谓持续，就需要自动化。代码的每次合并都会触发持续集成服务器进行自动构建，这个过程包括了编译、单元测试、集成、集成测试、质量分析、性能测试等步骤。在本文中，我们介绍了当今热门的微服务架构以及容器编排工具Kubernetes，并且展示了基于Jenkins 和Kubernetes 的持续集成方案。