在云原生领域中,Kubernetes 累积了大量用例。它能够在云中部署应用容器、安排批处理 job、处理工作负载以及执行逐步升级。Kubernetes 使用高效的编排算法来处理这些操作,即便是大规模集群这些算法依旧表现良好。
此外,Kubernetes 主要用例之一是运行持续集成或持续交付(CI/CD)流水线。也就是说,我们部署一个 CI/CD 容器的唯一实例,该实例将监控代码版本控制系统。所以,每当我们推送到该仓库时,该容器都会运行流水线步骤。其最终目标是达到一个“true or false”的状态。True 即在集成阶段 commit 通过了各种测试,False 即未通过测试。
除了以上描述的 CI 流水线之外,在 CI 测试通过之后,另一个流水线可以接管余下的过程,以处理发布过程的 CD 部分。在这一阶段,流水线将尝试将应用程序容器交付到生产中。
需要明白的是,这些操作是按需运行或者是由各种行为(如代码 check-in、测试触发器、流程中上一步的结果等)自动触发的。因此我们需要一种机制来增加单个节点以运行那些流水线的步骤,并在不需要它们时将其淘汰。这种管理不可变基础架构的方法有助于我们节省资源并降低成本。
当然,最关键的机制就是 Kubernetes,它具有声明式的结构和可定制性,因此可以让你在任何场景下高效地调度 job、节点以及 pod。
本文包括 3 个部分:第一部分我们将探讨目前在 Kubernetes 上运行最受欢迎的 CI/CD 平台。
接着我们将会看两个用例:第一个例子中,我们将简单地在 Kubernetes 上安装 Jenkins 以及对其进行配置以让我们可以在 Kubernetes 上使用这个流行的开源工具来运行我们的 CI 流水线;第二个例子中,我们将把这个 Jenkins 部署提高到一个新的水平。我们将会提供一些在 Kubernetes 中扩展 CI/CD 流水线的 tips 和建议。
最后,我们将会讨论在 Kubernetes 上大规模运行 CI/CD 的最合理的方法和实践。
本文的目标是让你彻底了解 Kubernetes 处理这些工作负载的效率。
适用于 Kubernetes 的 CI/CD 平台
Kubernetes 是一个运行 CI/CD 的理想平台,因为它拥有许多特性使得在上面运行 CI/CD 更为简单。那么,到底有多少 CI/CD 的平台可以在 Kubernetes 上运行呢?可以这么说,只要它们能够被打包为一个容器,Kubernetes 都能够运行它们。以下是几个最为流行的 CI/CD 平台:
Jenkins :Jenkins 是最为流行也最为稳定的 CI/CD 平台。在世界范围内有数以千计的企业都在使用它,因为它拥有强大的生态和可扩展性。如果你打算要在 Kubernetes 上使用它,非常建议你安装它的官方插件。JenkinsX 是专门为云原生领域设计的 Jenkins 版本。它与 Kubernetes 更加兼容,并且提供了更好的集成功能,如 GitOps、自动 CI/CD 和预览环境。
Spinnaker :Spinnaker 是一个可扩展的多云部署的 CD 平台,得到了 Netflix 的支持。使用相关的 Helm Chart 即可安装它。
Drone :这是有多种功能的通用云原生 CD 平台。可以使用关联的 Runner 在 Kubernetes 中运行它。
GoCD :Thoughtworks 的另一个 CI/CD 平台,提供了适用于云原生部署的各种工作流程和功能。它可以在 Kubernetes 中作为 Helm Chart 运行。
此外,还有一些与 Kubernetes 紧密合作的云服务,并提供诸如 CircleCI 和 Travis 的 CI/CD 流水线。如果你不打算托管 CI/CD 平台,那么这些也十分有用。
现在,我们来看看如何在 Kubernetes 集群上安装 Jenkins。
如何在 Kubernetes 上安装 Jenkins
首先,我们需要安装 Helm,它是 Kubernetes 的软件包管理器:
同样,我们还需要安装 Tiller,以让 Helm 正常运行:
完成这些步骤之后,我们需要运行检查命令,以查看 deployment 的配置值:
仔细检查配置值并在需要的时候进行更改。然后安装 Chart:
安装过程中会有一些关于下一步操作的说明:
注意:
行以下命令获取”admin“用户的密码:
在相同的 shell 中获取 Jenkins URL 以访问这些命令:
遵循这些步骤,它们将在http://127.0.0.1:8080启动代理服务器。
到那里输入你的用户名和密码。你将会拥有自己的 Jenkins 服务器:
不过,请记住,还有许多配置选项尚未修改,你可以访问 chart 文档以了解更多信息:
https://github.com/helm/charts/tree/master/stable/jenkins
在默认情况下,服务器会安装好最基本的插件,如 Git 和 Kubernetes-Jenkins,我们可以根据自己的需要安装其他插件。
总而言之,使用 Helm 安装 Jenkins 十分轻松。
使用 K8S 扩展 CI/CD Jenkins 流水线
既然我们已经大致了解 CI/CD 如何在 Kubernetes 上运行的,那么我们来看一个在 Kubernetes 中部署高度可扩展的 Jenkins 部署的示例用例。人们通常用它(进行了少量修改)来处理基础结构的 CI/CD,开始吧!
使用 Jenkins 固定发行版
虽然官方 Jenkins 镜像很适合入门,但它需要的配置超出了我们的期望。许多用户会选择一个固定的发行版,如 my-bloody-jenkins(https://github.com/odavid/my-bloody-jenkins),它提供了一个较为完整的预安装插件以及配置选项。在可用的插件中,我们使用 saml 插件、SonarQubeRunner、Maven 和 Gradle。
它能够使用以下命令通过 Helm Chart 安装:
我们选择使用以下 Dockerfile 部署自定义镜像:
其中 plugins.txt 文件是我们要预安装到镜像中的其他插件列表:
然后,只要 dockerfile 发生更改,我们就使用此通用 Jenkinsfile 来构建 master:
我们所使用的专用集群由 AWS 中的一些大中型实例组成,用于 Jenkins jobs。接下来,我们进入下一个部分。
使用专用的 Jenkins Slaves 和标签(label)
为了扩展我们的一些 Jenkins slaves,我们使用 Pod 模板并将标签分配给特定的 agent。因此在我们的 Jenkinsfiles 中,我们可以为 jobs 引用它们。例如,我们有一些需要构建安卓应用程序的 agent。因此,我们引用以下标签:
并且将使用特定于安卓的 pod 模板。我们使用这一 Dockerfile,例如:
我们还使用了 Jenkinsfile,该文件与上一个文件类似,用于构建 master。每当我们对 Dockerfile 进行更改时,agent 都会重建镜像。这为我们的 CI/CD 基础架构提供了极大的灵活性。
使用自动伸缩
尽管我们为 deployment 分配了特定数量的节点,但我们还可以通过启用 cluster autoscaling,来完成更多的事情。这意味着在工作负载增加和峰值的情况下,我们可以增加额外的节点来处理 job。目前,如果我们有固定数量的节点,那么我们只能处理固定数量的 job。基于以下事实,我们可以进行粗略地估计:每个 slave 通常分配 500ms CPU 和 256MB 内存,并且设置一个很高的并发。这根本不现实。
举个例子,当你的版本被大幅削减并且需要部署大量微服务时,可能会发生上述情况。然后,大量的 job 堆积在流水线,造成严重的延误。
在这种情况下,我们可以增加该阶段的节点数。例如,我们可以添加额外的 VM 实例,然后在过程结束时将其删除。
我们可以在命令行中使用自动伸缩选项来配置“Vertical”或“集群”自动伸缩选项。但是,此方法需要仔细计划和配置,因为有时会发生以下情况:
越来越多的 job 达到平稳阶段
Autoscaler 增加新的节点,但是需要 10 分钟来进行部署和分配
旧的 job 已经完成任务,新的 job 将填补空白,进而减少了对新节点的需求
新节点可用,但需要 X 分钟保持稳定且未利用,X 由–scale-down-unneeded-time 标志定义
同样的事情每天发生很多次
在这种情况下,最好是根据我们的特定需求进行配置,或者只是增加当天的节点数,并在流程结束后将其还原。所有这些都与寻找最佳方法来利用所有资源并使成本最小化有关。
在任何情况下,我们都应该有一个可伸缩且易于使用的 Jenkins 集群。对于每个 job,都会创建一个 pod 来运行特定的流水线,并在完成后将其销毁。
大规模使用 K8s 进行 CI / CD 的最佳实践
现在我们已经了解了 Kubernetes 有哪些 CI/CD 平台以及如何在你的集群上安装一个平台。接下来,我们将讨论一些大规模运行它们的方法。
首先,选择 Kubernetes 发行版是我们需要考虑的最关键因素之一。找到最合适的解决方案才能够进行下一步。
其次,选择合适的 Docker 镜像仓库和应用程序包管理器同样重要。我们需要寻找可以按需快速检索的安全可靠的镜像管理。至于软件包管理器,Helm 是一个不错的选择,因为它可以发现、共享和使用为 Kubernetes 构建的软件。
第三,使用现代集成流程,如 GitOps 和 ChatOps,在易用性和可预测性方面提供了显著优势。将 Git 用作单一数据源,使我们可以运行“通过拉取请求进行操作”,从而简化了对基础架构和应用程序的部署控制。使用诸如企业微信或钉钉之类的团队协作工作来触发 CI/CD 流水线的自动化任务,有助于我们消除重复劳动并简化集成。
总体而言,如果我们想更深入地了解,你可以自定义或开发自己的 K8S Operator,与 K8S API 配合更紧密。使用自定义 operator 的好处很多,因为它们可以建立更好的自动化体验。
最后,我们可以说 Kubernetes 和 CI/CD 平台是天合之作。如果你刚刚入门 Kubernetes 生态系统,那么你可以尝试集成一个 CI/CD 流水线。这是了解 Kubernetes 内部运作方式的好方法,关键是要留出机动空间,方便将来容易更改。
评论