瀚云平台基于Kubernetes实现高效CI/CD流水线

Posted 2021-04-16 瀚云研发中心

前言

Preface

容器推出以来，以其资源独立、隔离、环境的一致性、轻量化等等优异的特点赢得众多公司和开发者的青睐。

在容器大发展的基础上，kubernetes的诞生又让容器技术得到了巨大发展，并获得了来自各个行业和各个领域的鼎力支持——从大企业到初创公司，从研发到各类IT人员等等。

本文仅重点阐述瀚云平台是如何基于kubernetes等一系列开源技术实现自己的CI/CD流水线。

持续集成/持续发布

CI/CD整体架构

高效可靠的CI/CD流水线是互联网或者软件公司实现快速交付的基础。

在微服务架构十分流行的形势下，服务也变得越来越细化，更新越来越频繁，这使得CI/CD也就越发重要。

因为，它让公司能够按照一致的、可重复操作的方式，完全自动化地完成代码的搭建、测试和部署。

one

 持 续 集 成

Continuous Integration

持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。 

Two

持 续 发 布

Continuous Deploymen

持续发布是在持续集成的基础上，自动化的把应用模块部署到开发，测试、生产环境上的过程。

瀚  云

CI/CD整体架构

代 码

工 作 流

公司内部有一套基于gitlab flow定制化的代码工作流，并以分支为特性，保证多个团队，多个开发人员同步进行开发。

所有的模块用Tag封闭代码版本并提交测试，测试通过后以Tag版本号进行发布，项目发布后合并到master。

瀚 云CI/CD

开源工具集介绍

Jenkins X

Jenkins X是Kubernetes原生的CI/CD解决方案，用于云原生应用的快速开发和部署。

Jenkins X是想最大限度的利用Jenkins能力来实现基于Kubernetes生态系统原始的CI/CD平台。

它的核心价值是简化整个云原生应用的开发，部署，运行过程。

在jenkins任务中，首先会根据参数自动通过模板代码生成 Dockerfile 和 chart 文件， 传入的参数有

其中 KUBERNETES_CPU 和KUBERNETES_MEMORY 是用于限制 pod 调用 CPU 和限制内存的。同时还用于kubernetes 集群的调度和分配，将参数作为参考，调度到有剩余资源的 Node 上。

deployment.yaml

其中 limits 表示资源限额，即限制应用容器使用的资源，requests 表示资源调度，即 kubernetes 集群根据这个参数将决定将这个应用分配到有剩余资源的 Node上 。requests 是按照 limits 以一个比例 （小于接近于1）写入的。

Nexus

Nexus可以 作为 Nodejs 和 Java 程序的本地依赖仓库，既可以将公司开发的依赖包发布到上面，还可以将中心仓库的依赖包下载下来缓存。从而可以在应用构建的过程中大幅度减少拉取依赖包所用的时间。

 maven

maven用于java程序打包构建，通过 maven plugins 在 target 文件夹中将生成

- jar包
- lib文件夹，放入依赖的 jar包
- config 文件夹 ，放入配置文件

然后将这些东西 COPY 到镜像当中

skafflod

Skaffold 是谷歌开源的简化本地 Kubernetes 应用开发的工具。

它将构建镜像、推送镜像以及部署 Kubernetes 服务等流程自动化，可以方便地对 Kubernetes 应用进行持续开发。

简单来说就是通过 skaffold.yaml 将 Dockerfile 生成镜像，然后 push 到镜像仓库中。

Harbor

Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器。

harbor在docker distribution的基础上增加了一些安全、访问控制、管理、镜像安全扫描等功能，以满足企业对于镜像仓库的需求。

chartmuseum

chartmuseum是一个放置 helm chart 的文件仓库，提供了一系列 Restful API 接口，包含上传和下载chart文件，提供查询接口。

charts文件结构

Helm

Helm 是用于管理 Kubernetes 资源对象的工具，类似 APT，YUM 和 HOMEBREW，它通过将 Kubernetes 的资源对象打包成 Chart 的形式，完成复杂应用的部署和版本控制，是目前业界流行的解决方案。

Monocular

Monocular是一个开源软件，用于管理kubernetes上以Helm Charts形式创建的服务，可以通过它的web页面来安装helm Charts。 

瀚  云

CI/CD流程

 步  骤

Steps

1. 开发者基于分支开发代码，并启动 pipeline 将代码发布到开发环境中。

2. 将代码构建后生成镜像，并push到镜像仓库，镜像tag 根据当前时间生成时间戳。同时通过模板代码生成项目chart，将 chart 推送到 chart museum 中，以时间戳区分版本。

3. 通过helm ，将应用的chart（二进制包）部署项目到开发环境中，用 ingress 暴露服务。

4. 提交测试，在git上打上 *-TEST 形式的 tag，提交到测试流程。

5. 测试环节，在docker仓库中提取镜像。在chart museum 中提取开发的 chart ，修改chart （主要是 profile 、namespace、启动命令）。提交新的 chart 。然后测试人员通过 SonarQube analysis 分析代码。

6. 通过 helm ，将测试提交的 chart 部署项目到测试环境中，以 ingress 暴露服务。测试人员、测试bug。

7. 测试不通过，打回代码；测试通过，在git上修改成 *-RELEASE  形式的 tag ，同时 delpoy 到 maven 仓库 maven-releases ，固定版本。提交到生产流程。

8. 发布生产环节，在docker仓库中提取镜像。在chart museum 提取开发的 chart  ，修改chart （主要是启动个数， profile 、namespace、启动命令。）提交新的 chart 作为备份。

9. 滚动发布到生产环境。

 滚 动 发 布

kubernets Deployment 具有滚动更新机制

maxSurge:  滚动升级时会先启动15% 应用容器（pod数量），向上取整，默认为 25%。

maxUnavailable: 滚动升级时允许的最大Unavailable的pod个数，向上取整，默认为 25%。

滚动发布的流程是会先产生15% 的新版本 pod，当 running 状态后，删除 15% 的旧版本 pod ，直到所有旧版本的 pod 替换为 新版本 pod。

探 针

kubernets Deployment 的状态检测机制

livenessProbe: kubernetes认为该pod是存活的,不存活则需要重启

readinessProbe: kubernetes认为该pod是启动成功的

path: 探针URL 路径，使用的是 /health

port: 端口

periodSeconds: 每隔多少秒检测一次

successThreshold: 默认1

timeoutSeconds: 超时时间，超过时间就会自动重启

结尾

Ending

持续集成/持续发布对于版本高速迭代的公司而言是非常重要的，传统的Jenkins虽然也可以实现kubernetes上的CI/CD，但是无疑是非常笨重和不优雅的。

瀚云系统通过Jenkins X在配合定制化的流程，非常好的契合了现有的开发流程和部署方式，并且优雅的将各种开源软件组合到了一起。

当然这个CI/CD 还有需要完善的地方，后续会努力让这个系统更加完善。