Kubernetes 中的 CI/CD

CI/CD 概念



CI/CD 其实早在很多年前就已经诞生了，主要是为了将频繁的变更测试、构建、交付和部署等进行自动化，减少手工操作。

• CI 持续集成主要是在代码更改时自动分支合并、构建并执行一系列的测试（包括单元测试、集成测试、端到端测试等），确保这些变更不会破坏原来的应用。

• CD 持续交付和部署则是 CI 测试通过之后把构建结果存档、发布到预布环境和生产环境、最后再进行验收测试的过程。



CI/CD 是 DevOps 的基础，CI/CD 侧重于软件开发过程中的自动化，而 Devops 则是侧重于文化构建，旨在减少开发、运维、QA之间的沟通鸿沟，促进快速可靠发布的同时还保证产品质量。



CI/CD 一系列流程通常会组成一个流水线，docker和Kubernetes则可以简化这些流水线中的很多流程，比如Docker容器可以很容易把有冲突的环境隔离开来，而Kubernetes则更进一步简化整个流水线的构建、执行和维护工作。

CI/CD 工具的选择

根据 CNCF 2019 年的调查报告，Jenkins 和 Gitlab 是当之无愧的 CI/CD 工具之首。当然，除此之外，还有很多其他的工具，比如 Spinnaker、Argo、Jenkins X、CircleCI、Github Actions 等等。



这些工具可以分为两类：



• 传统的 CI/CD 工具，典型的是 Jenkins 和 Gitlab，功能强大，配置灵活，使用场景没有限制。

• Kubernetes native 工具，典型的是 Jenkins X 和 Argo，专为 Kubernetes 场景构建，跟 Kubernetes 生态紧密集成，但缺少灵活性。



其实，现在很多所谓的云原生实际上会以 Kubernetes 原生的方式落地，把 Kubernetes 变成整个基础设施的基础。从这个角度来说，我觉得使用 Kubernetes native 的工具实际上是更好的选择，不仅省去了跟 Kubernetes 集成的配置，还可以很容易跟社区内其他的工具打通。

私有fork



大家在实践云原生技术的时候可能或多或少都需要做一些改动，这些改动可能暂时无法提交到社区。这时候可能就需要把代码从社区克隆到公司内部，选择性的和社区保持同步了。



这种差异实际上促进了很多公司把一些比较通用的特性推到社区里面，方便自己后续同步的同时，也让整个社区在这些新特性中受益。



当然，这些差异也带来了很多的问题，比如公司内部的研发工具包括流水线工具和社区很可能不一致了。这时候如果把社区的流水线全部搬进来会遇到水土不服的问题；而按照内部工具适配，又需要很大的工作量，并且还需要把握好跟社区的差异。



从 CI/CD 的角度来看，实际上并不需要把社区的所有东西都搬进来，只要根据自己的需要把必要的部分引入就可以了（比如端到端的测试和性能测试等）。这些东西一般可以通过很简单的命令集成到现有的流水线中。

本地开发



CI/CD通常需要执行一系列的任务，时间会比较长。并且发生问题时，一般也很难在线排查。所以，对于本地应用的开发阶段，通常并不会直接去用 CI/CD 流水线，而只需要能在开发环境中构建、部署和调试就可以了。



Kubernetes 开源社区有三个工具可以简化这个过程：Skaffold、Tilt 和 Draft。这些工具都支持自动化本地镜像构建、推送镜像并部署新的应用到Kubernetes集群中，如下图所示，就是 Skaffold 的工作原理（图片来自 skaffold.dev）：



这三者之间，Tilt的功能最为丰富，既有 UI 支持，还可以管理多个微服务，使用起来也稍微有些麻烦，需要编写 Tiltfile 文件描述应用程序。



Skaffold和Draft的功能特性基本相同，但Draft已经很长时间都不维护了，所以这二者 Skaffold 是个不错的选择。

以上整理自同名知识星球“漫谈云原生”的上周话题讨论，本周话题为基于Kubernetes的多云/混合云策略，欢迎有兴趣的同学加入参与。