基于Kubernetes的CI/CD实践

标签：CI Kubernetes DevOps CD 构建 镜像

K8s已经成为一线大厂分布式平台的标配技术。你是不是还在惆怅怎么掌握它？来这里，大型互联网公司一线工程师亲授，不来虚的，直接上手实战，3天时间带你搭建K8s平台，快速学会K8s，点击下方图片可了解培训详情，点击下方图片了解详情。

 

本文旨在讲解时速云基于Kubernetes和Docker实现CI/CD的一些解决方案和实践，即如何通过自研流水线模板方式与Jira、GitLab、Sonar、Harbor等第三方DevOps工具集成，自动化地实现从代码到镜像、应用的持续集成、持续交付。以及，在Kubernetes环境下，如何更好地做CI/CD，有什么优势，如何利用这些优势。

面临的DevOps需求

随着客户要求迭代速度的加快，公司的项目管理、交付管理面临了来自公司内外部的巨大挑战。

公司目前需要管理很多客户项目和自身迭代产品项目，产品使用Go、Java、NodeJS等多种技术栈的多个分支的代码项目。而且每周需要交付多个测试版本进行持续验证。同时，还要应对客户现场的紧急版本修复、客户定制版本交付等场景。

解决上述问题的核心就是要提升效率，加快交付速度。

CI/CD规划概览

架构总览

结合Kubernetes的一些基础理念和特性，综合考虑容器PaaS平台、微服务治理平台在DevOps的需求，并融合企业内部已有的CI/CD等工具，自主实现了一套更适合于云原生应用平台的DevOps服务体系。基本的技术架构及实现方式如下图所示：

上图中，代码仓库中的代码会被Job创建在构建节点上的Pod的容器拉取，并执行编译、单元测试、扫描、打包，制作镜像、 Push镜像等操作后，这个Pod就会被销毁。容器日志会被节点的Agent发送到日志服务中心，可以提供容器被销毁后的日志查询。也可以使用CronJob执行定时任务。

该方案具备以下优势：

• 不需要单独部署复杂的高可用CI/CD服务，比如Jenkins集群等，简化了部署管理的复杂度。

• 构建任务均通过镜像进行封装，并在容器中进行，接口更加标准、透明。

• 对构建任务的资源、限额、日志、监控、告警、计费等诸多能力可以直接利用PaaS平台，而无需重复开发，PaaS未来的能力也可以直接为DevOps服务。

• 可以通过容器PaaS，让构建任务具备更高级的调度能力。

• PaaS层对底层资源的弹性伸缩也可以为DevOps服务，对构建资源进行伸缩策略的定义，实现构建资源的弹性。

• 对DevOps平台的管理运维可以同容器PaaS一致，没有额外的学习成本。

• 通过容器、镜像等标准概念，对构建任务进行封装，并快速实现DevOps的构建模版，使得DevOps平台通过自定义模版具备更好的扩展能力。

关键技术

技术要点

这种架构模式下，可以把每一个构建任务通过Pod Spec来进行描述，相关的构建任务能力可以通过以下方式映射到Pod Spec中。

同样道理，结合上层的Job/CronJob，我们就可以控制构建的执行策略，比如构建任务期望的并⾏执⾏的最⼤Pod数量，期望的成功完成的Pod数量，从Job创建到活跃状态的超时时间（默认12⼩时），标记Job为失败前的最⼤重试次数，默认 = 6；以及通过Cron格式的任务计划定义，Job执⾏的并⾏策略，是否暂停后续执⾏，保留运⾏成功/失败的历史Job的数量。

实践举例

这里举两个例子，来说明时速云DevOps平台中每个构建任务的工作原理：

构建Docker镜像，也就是我们经常使用的从代码生成镜像的任务模版，其基本工作方式如下：

每个构建任务都是一个Job，会按照用户传递的信息组装成Job的结构，并由Kubernetes调度并执行，有DevOps Manager管理Job的运行情况。其中使用了InitContainer、Volume、Secret等多种Kubernetes资源。

服务持续部署，平台提供了镜像部署、应用模版部署、Spinnaker、时速云DevOps平台集成、应用包部署、服务状态检查等多种持续部署相关模版，通过灵活组合使用，可以满足几乎所有场景下的持续部署需求。如下图所示的基本工作流程，我们会把不同部署方式封装成对应的镜像，并提供可视化配置界面供用户使用。

同样，我们也提供了忽略某个构建任务的执行，某个构建任务失败时速云DevOps平台继续执行，指定构建节点，自定义构建任务所需资源，当然也支持构建任务使用GPU资源，进行机器学习相关的时速云DevOps平台处理能力。

小结

借助Kubernetes自动编排、自动回收资源的机制，减少了人工干预。结合Kubernetes提供的丰富的资源类型，CI/CD解决方案也有了更多的选项和思路。仿佛Kubernetes是为CI/CD专门定做的。

CI/CD工具及实践

工具及流程概览

我们的DevOps工具链有Jira、Gitlab、时速云DevOps平台、Sonarqube、TestLink、Harbor。

• Jira：项目管理；

• Gitlab：代码托管、在线Review；

• 时速云DevOps平台：基于Kubernetes的代码拉取，编译，代码扫描，单元测试，打包，构建镜像、持续部署，审批，邮件；

• Sonarqube：代码静态扫描；

• TestLink：测试管理；

• Harbor：镜像托管，镜像安全扫描。

流程如下：

实践说明

需求/缺陷管理

需求和缺陷管理我们使用功能强大的Jira工具，以两周一迭代方式进行敏捷式开发。

代码Review/Merge

聊天工具集成GitLab，PR提交后Reviewer及时看到提交信息，进行Review和Merge。

GitLab触发自动化构建

时速云DevOps平台自动生成GitLab项目的webhook，当GitLab有事件发生，把事件信息发送到时速云DevOps平台，时速云DevOps平台根据条件触发自动执行构建。

时速云DevOps平台

流程简介：

时速云DevOps平台基于Kubernetes和Docker运行具体任务，由Kubernetes调度、执行完后销毁。每一个任务模板最终生成Kubernetes的Job，Job会生成Pod运行任务, 并管理生命周期。

每个任务模板镜像都有为自身任务的最小化工具。比如Maven任务镜像只有Maven客户端命令工具，容器被Job生成时，会通过进入点运行Maven命令，运行结束后将结束容器。代码扫描任务会有sonar-scanner客户端工具，Docker构建任务可以运行Docker build命令构建镜像和Push镜像到Harbor。

镜像推送到Harbor后会使用平台持续部署任务模板更新服务。

持续部署成功后服务会被升级到最新版本。

任务模板：

时速云 DevOps 平台的任务模板是为执行任务的镜像和数据集合。

sonar扫描任务为例，sonar扫描任务执行就是容器化运行sonar-scanner。

下图为sonar扫描任务的Dockerfile，就是把代码和sonar扫描配置文件拷贝到指定目录，运行sonar-scanner命令。

执行结果以Rest API方式发送到平台，平台记录执行结果，并根据设置执行下一步任务或失败退出。

集成测试

测试有测试用例，测试用例有测试结果，如果测试结果与期待结果不符，同步到Jira，再执行编码的步骤，形成一个闭环。

测试用例和测试版本的测试结果使用TestLink工具管理。

集成测试是人工测试和基于Selenium的Python脚本的自动化测试共同完成。

Harbor同步

测试人员进行测试通过以后，使用Harbor镜像同步功能，同步到运维环境Harbor。

Harbor镜像更新后通过触发设置触发执行部署任务

Harbor的common/config/registry/config.yml设置notification属性为时速云DevOps平台webhook地址和认证方式，时速云DevOps平台可以根据payload信息触发执行CI/CD。

部署运维服务

时速云DevOps平台被触发执行后，与上面部署一样会根据新的镜像更新部署新的服务。

自动标记Jira

集成测试结束以后，通过Jira API，把GitLab中的大括号里相应的Jira issue为关闭状态，添加部署版本说明。

保障代码和最终交付产物的源头一致性

如下图，在代码构建时把代码的版本信息一同写入镜像可以做到最终交付产物和代码源头的一致性比较。

1.   git rev-parse --short HEAD > .gitversion
2.   git log --pretty=oneline HEAD...$PREVIOUS_COMMIT_ID > .gitdiff

CI/CD流程总结

1. Jira、Gitlab、TestLink、Harbor等工具的集成、Kubernetes特性和各组件的灵活使用、自动化构建流程使得CI/CD流程缩短了交付时间。而且从代码到最终交付产物的可验证性，需求到代码和Bug到代码的可追溯性，提高了效率。

2. 对于公司服务器的计算资源也使得因Kubernetes的机制发挥到优先资源下灵活应用，让各个团队避免了因为计算资源不够等待资源的情况。

3. Kubernetes的良好机制，使得公司有限服务器资源下灵活应用，让各个团队避免了因为计算资源不够等待资源的情况。

4. 时速云DevOps平台任务模板容易扩张、可以快速集成其他第三方工具，也为管理、测试、研发团队快速提供需要的工具集成。

5. 时速云DevOps平台任务模板的最小化，节省了资源，节省了费用。

6. 对部分开源项目的修改和贡献也提高了工作的效率。比如修改Harbor的用户账户体系和验证方式与平台一致，减少了用户在交付中镜像账号的额外管理。修改TestLink源码，实现一键创建Jira Bug ，自动使Jira项目管理与测试管理工具互相追踪，方便查看与管理。

当然我们的CI/CD流程还有很多不足，比如缺少ChatOps等更方便的功能、对已有流程复盘并优化、还需要集成更多CI/CD工具等。

未来规划

1. 随着Kubernetes 的版本升级，提供了更多的功能，这些功能是否能让我们的 CI/CD 更灵活。比如Node、Pod 的亲和性设置，部署容器启动先后顺序设置等。

2. 提供ChatOps功能，通过集成提供API的聊天工具。

3. 与更多的DevOps工具集成，包括GitInspector等。

4. 对开源工具的优化，以及对开源社区的贡献。比如TestLink等还有很多缺陷，集成时会遇到需要解决的问题等。

5. 持续增强DevOps前期项目管理、产品管理的功能模块，例如立项管理、路线图、需求管理、版本管理、发布物、产品运营、里程碑、迭代计划、测试管理等功能方向，有助于奠定项目/产品的基石。

6. 持续增强DevOps后期度量与优化功能模块，例如质量、效率、进度、APM、问题库、自愈等功能方向，帮助项目/产品后期更好的运营。

Q&A

Q：请问一下小白入门Kubernetes，有啥快速入门的资料可以看？

A：现在Kubernetes相关的资料、书籍已经很多了，如果愿意读英文，推荐直接看官方文档，讲的还是比较清楚的，有助于全面了解 Kubernetes：https://kubernetes.io/docs/home/

Q：请问在什么情况下删掉容器，镜像也自动删除，而且在容器运行的状态下，镜像能被删除，这时候运行的容器依赖的镜像名变成了uuid，比如原来镜像名是Redis现在是Redis这个镜像的ID。

A：没碰到容器运行情况下，镜像被删除的情况，目前理解应该是镜像名被新的镜像占用了，然后容器原来使用的镜像就成了ID了吧。

Q：生产环境下Kubernetes的负载均衡高可用是如何解决的呢？

A：私有云环境下可以用NodePort，Ingress等模式，有条件的可以结合 F5；IaaS、公有云环境下可以结合对应平台的LB。

Q：中小企业传统架构下，有必要上Kubernetes吗？应该从哪些方面来进行考虑。

A：传统架构下，可以从应用开发的架构、模式以及规模方面考虑。

Q：如何管理使用过程中用到的GitLab Token？安全问题？

A：平台加密保存到数据库，使用时解密使用。

Q：如何兼容Helm部署，单独部署等多种部署模式对Kubernetes集群中同一个同名资源比如deployment的操作？如何解决冲突？

A：单独CD会基于对已有deployment进行配置、镜像更新等相关操作；Helm模版部署会先进行冲突检测。

Q：采用Operator的方式去实现DevOps，会对Kubernetes API server带来负担吗？

A：目前Kubernetes之上的扩展都是推荐CRD+controller的Operator方式，只要设计、实现合理，是没有太大负担的。

Q：如何管理迭代构建镜像比如Java多版本，Node多版本等？

A：相同镜像名称，使用时间戳等方式管理也是一种方案。

Q：为什么要自己做CI的功能呢，gitlab-ci.yml方式可以和代码一起保存，而且更加通用。如果可以解析gitlab-ci或者其他CI配置文件是不是更好？

A：完全可以使用GitLab ，或者Jenkins等已有CI工具去完成。我们考虑的是更多的集成方案，1. 比如有新的工具，我们可以方便集成，不用等待第三方插件或者对方提供工具。2. 安装部署简单，如果安装/添加插件过程中需要重启导致其他用户无法使用等。

Q：每次提交代码就触发Code review后才合并，这种开发效率不会低吗？如A开发好提交，B也在写代码，需要停下来帮A review代码？

A: 是的，每次提交都要Code review后才合并，效率是一方面，健壮性也是一方面。

Q：基于Kubernetes的冷启动时间过长的问题怎么解决呢？比如触发了一个任务，这个时候要去拉相关的镜像，然后执行CI脚本，这个时间比较长。有没有考虑比如说预热几个Job在那里？

A：会把常用构建镜像进行load，用户自己的镜像，第一次构建会慢一些，后续就比较快了，当然如果比较大的镜像，比如机器学习的，可以提前缓存提速。

Q：如何管理基于版本同环境相关的部署所需要的变量？

A：可以考虑挂载ConfigMap、Secret。

Q：衡量自动回滚的标准是什么？Pod没有成功启动？自动化测试没过？

A：对，比如Pod一定时间内没有都Ready，或者短时间内重启次数过多，或者在微服务框架下相邻服务调用失败率增加等，都可以作为一些验证的标准，或者自己定义常见的异常标准。

Q：目前Kubernetes的版本使用是？目前升级的频率是？

A：目前我们使用的版本是v1.18.x，升级频率跟产品版本迭代同步进行，会跟进社区最新fixpack版本。

Kubernetes入门与进阶实战培训

Kubernetes入门与进阶实战培训将于2020年9月18日在上海开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：Docker基础、容器技术、Docker镜像、数据共享与持久化、Docker实践、Kubernetes基础、Pod基础与进阶、常用对象操作、服务发现、Helm、Kubernetes核心组件原理分析、Kubernetes服务质量保证、调度详解与应用场景、网络、基于Kubernetes的CI/CD、基于Kubernetes的配置管理等。点击下方图片或者阅读原文链接查看详情。

 

 

标签：CI,Kubernetes,DevOps,CD,构建,镜像
From： https://www.cnblogs.com/data159/p/17239544.html