什么是 Kubernetes CI/CD 管道？

我的粉丝们，新的一年祝愿你：兔年大吉大利，兔年顺顺利利，兔年快快乐乐，兔气十足十足，兔年富富满堂，兔年财源广进，兔年步步高升，兔年梦想成真！

关注留言点赞，带你了解最流行的软件开发知识与最新科技行业趋势。

Kubernetes CI/CD 管道不同于传统的 CI/CD 管道。主要区别在于容器化过程。

自从组织开始从构建单体应用程序迁移到微服务以来，容器化技术一直在兴起。随着应用程序在成百上千个容器化环境中运行，管理和编排这些容器的有效工具变得至关重要。

Kubernetes (K8s) 是 Google 的一种开源容器编排工具，因其改进公司部署流程的功能而广受欢迎。Kubernetes 凭借其高灵活性和可扩展性的特性，已经成为领先的容器编排工具，到 2022 年，超过 60% 的公司已经采用了 Kubernetes。

随着越来越多的公司采用容器化技术和 Kubernetes 集群进行部署，实施 CI/CD 管道以自动化方式交付 Kubernetes 变得有意义。因此，在本文中，我们将介绍以下内容：

什么是 CI/CD 流水线？为什么要为 Kubernetes 使用 CI/CD？Kubernetes 应用程序交付的各个阶段。使用开源 Devtron 平台自动化 CI/CD 过程。什么是 CI/CD 管道？

持续集成和持续部署 (CI/CD) 管道代表一种自动工作流，它持续集成软件开发人员开发的代码，并将它们部署到目标环境中，减少人工干预。

在 CI/CD 管道之前，开发人员手动获取代码，将其构建到应用程序中，然后将其部署到测试服务器中。然后，在获得测试人员的批准后，开发人员会将他们的代码扔掉，以便 Ops 团队将代码部署到生产环境中。当部署频率为几个月一次时，这个想法在某种程度上适用于单体应用程序。

但随着微服务的出现，开发人员开始更快地构建更小的用例并频繁部署它们。在代码提交后手动处理应用程序的过程是重复的、令人沮丧的并且容易出错。

这是敏捷方法论和 DevOps 原则以 CI/CD 为核心蓬勃发展的时候。这个想法是更快、更频繁地构建增量更改并将其交付到生产中。CI/CD 管道使整个过程自动化，高质量的代码快速高效地投入生产。

CI/CD 流水线的两个主要阶段1. 持续集成或 CI 管道

这个阶段的中心思想是每当开发人员开发新软件时自动构建软件。如果每天都有开发，那么应该有一种机制来每天构建和测试它。这有时被称为构建管道。经过多次测试后，最终的应用程序或工件将被推送到存储库。

2. 持续部署或 CD 流水线

持续部署阶段是指从存储库中拉取工件并频繁且安全地部署它。CD 管道用于将应用程序自动部署到测试、暂存和生产环境中，减少人工干预。

注意：人们在提到持续部署时可以互换使用的另一个术语是持续交付，但它们并不相同。根据 David Farley 和 Jez Humble 的书持续交付：通过构建、测试和部署自动化进行可靠的软件发布，它是将所有类型的更改发布到生产中的过程，包括新功能、配置更改、错误修复和实验，或以可持续的方式 安全、快速地交到用户手中。

持续交付包括整个软件交付过程，即持续规划、构建、测试和向市场发布软件。假设持续集成和持续部署是它的两个部分。

现在，让我们讨论一下为什么要为 Kubernetes 应用程序使用 CI/CD 管道。

为 Kubernetes 使用 CI/CD 管道的好处

通过为 Kubernetes 使用 CI/CD 管道，人们可以获得几个重要的好处：

可靠且成本更低的部署

部署在 Kubernetes 上的 CI/CD 管道有助于软件的受控发布，因为 DevOps 工程师可以设置分阶段发布，例如蓝绿和金丝雀部署。这有助于在发布期间实现零停机时间，并降低一次性向所有用户发布应用程序的风险。使用 CI/CD 管道自动化整个 SDLC（软件开发生命周期）有助于通过削减与发布过程相关的许多固定成本来降低成本。

更快的发布

通过实施 CI/CD 工作流，过去需要数周和数月才能完成的发布周期已显着缩短至数天。事实上，一些组织甚至一天部署多次。开发人员和运维团队可以作为一个团队与 CI/CD 管道一起工作，并快速解决发布过程中的瓶颈，包括用于延迟发布的返工。借助自动化工作流程，团队可以频繁快速地发布应用程序而不会精疲力尽。

优质产品

实施 CI/CD 管道的主要好处之一是它有助于在整个 SDLC 中持续集成测试。如果不满足某些条件，您可以将管道配置为停止进入下一阶段，例如，如果工件未通过功能或安全扫描测试，则部署管道失败。因此，可以及早发现问题，并且在生产环境中出现错误的可能性很小。这确保了质量从一开始就融入产品本身，最终用户得到更好的产品。

图 C：实施 CI/CD 管道的好处

图 C 说明了实施 CI/CD 管道的好处。

现在，让我们更深入地了解 Kubernetes 应用程序交付的各个阶段，这些阶段可以成为 CI/CD 管道的一部分。

Kubernetes 应用交付的阶段

以下是 Kubernetes 应用程序交付的 CI/CD 管道中涉及的不同阶段，以及开发人员和 DevOps 团队在每个阶段使用的工具。

图 D：Kubernetes 应用程序交付的阶段。

图 D 表示 Kubernetes 应用交付的各个阶段。

代码

过程： 编码是开发人员为应用程序编写代码的阶段。一旦编写了新代码，它们就会被推送到远程存储库的中央存储中，其中存储了应用程序代码和配置。它是开发人员之间的共享存储库，他们不断地将代码更改集成到存储库中，大部分是每天。代码存储库中的这些更改会触发 CI 管道。

工具： GitHub、GitLab、BitBucket

建造

过程： 一旦在应用程序代码存储库中进行了更改，它就会被打包到一个称为工件的可执行文件中。这允许在部署文件之前灵活地移动文件。打包应用程序和创建工件的过程称为构建。然后将构建的工件制作成将部署在 Kubernetes 集群上的容器镜像。

工具： Maven、Gradle、Jenkins、Dockerfile、Buildpacks

测试

流程： 一旦容器镜像构建完成，DevOps 团队将确保其经过单元测试、集成测试和冒烟测试等多项功能测试。单元测试确保小块代码（单元），如功能，正常工作。集成测试寻找不同的代码组件，如不同的模块，如何作为一个整体保持在一起。最后，冒烟测试检查构建是否足够稳定以继续进行。

功能测试完成后，将有另一个子阶段用于测试和验证安全漏洞。DevSecOps 将执行两种类型的安全测试，即静态应用程序安全测试（SAST）和动态应用程序安全测试（DAST），以检测诸如包含易受攻击包的容器镜像等问题。

通过所有功能和安全测试后，镜像将存储在容器镜像存储库中。

工具： JUnit、Selenium、Claire、SonarQube

以上所有步骤构成了 CI 或构建管道。

部署

过程： 在部署阶段，容器镜像从注册中心拉取并部署到在测试、预生产或生产环境中运行的 Kubernetes 集群中。将映像部署到生产中也称为发布，然后应用程序可供最终用户使用。

与基于 VM 的单体应用程序不同，部署是 Kubernetes 最具挑战性的部分，原因如下：

开发人员和 DevOps 工程师必须处理许多 Kubernetes 资源才能成功部署。 由于部署方式多种多样，例如使用声明性清单文件和 HELM 图表，企业很少按照标准化方式部署其应用程序。每天多次部署大型分布式系统确实是一项令人沮丧的工作。

工具： Kubectl、Helm Charts

对于感兴趣的用户，我们将展示将 NGINX 映像部署到 K8s 的简单过程中涉及的步骤。（随意跳过工作示例。）

在 Kubernetes 集群中部署 Nginx（工作示例）

在部署之前，您必须在 K8s 中创建资源文件，以便您的应用程序在容器中运行。并且有很多资源，比如Deployments、ReplicaSets、StatefulSet、Daemonset、Services、Configmap，还有很多自定义资源。

我们将研究如何使用最少的资源或清单文件部署到 Kubernetes：部署和服务。Deployment 工作负载资源提供声明性更新并描述所需状态，例如 pod 的复制和缩放。Kubernetes 中的服务使用 Pod 的 IP 地址将流量负载均衡到 Pod 副本。

为了对此进行测试，您应该有一个在服务器上运行的 K8s 集群，或者使用 Minikube 或 Kubeadm 在本地运行。现在，让我们将 Nginx 部署到 Kubernetes 集群。

Nginx 的部署 YAML——让我们给它命名nginx-deployment.yaml——看起来像这样：

apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 10 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80

Deployment 文件指定容器镜像（即 nginx），声明所需的 Pod 数量 (10)，并将容器端口设置为 80。

现在，使用名称创建一个服务文件nginx-service.yaml并粘贴以下代码：

apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - name: http port: 80 targetPort: 80 type: ClusterIP

配置清单文件后，使用以下命令部署它们：

# kubectl apply -f nginx-deployment.yaml # kubectl apply -f nginx-service.yaml

该代码将部署 Nginx 服务器并使其可从集群外部访问。您可以通过运行以下命令来查看 Pod：

# kubectl get pods

此外，您可以运行以下命令并获取服务的 IP 地址以从浏览器访问 Ngnix。

# kubectl get svc

如果您已经注意到，在部署应用程序时需要执行多个步骤和配置。想象一下 DevOps 团队每天要将多个应用程序部署到多个集群中的苦差事。

监控、健康检查和故障排除

过程： 部署后，监控 K8s 集群中新 Pod 的健康状况非常重要。Ops 团队可以手动登录集群，并使用诸如 kubectl get pods 或 kubectl describe deployment 之类的命令来确定集群或命名空间中新部署的 Pod 的健康状况。此外，运营团队可以使用监控和日志记录工具来了解 pod 和集群的性能和行为。

为了排除故障和发现问题，成熟的 Kubernetes 用户将使用 Probes 等高级机制。探测分为三种：用于确保应用程序正在运行的活动探测、用于确保应用程序已准备好接受流量的就绪探测以及用于确保在 Pod 上运行的应用程序或服务已完全启动的启动探测。尽管有许多命令和方法，但由于集群内的许多组件（节点、pod、控制器、安全和部署对象等）的可见性不佳，开发人员或运维团队很难排除故障并检测到错误。 ).

工具： AppDynamics、Dynatrace、Prometheus、Splunk、kubectl

渐进式交付和回滚

过程： 人们使用蓝绿和金丝雀等高级部署策略逐步推出他们的应用程序，避免降低客户体验。这也称为渐进式交付。这个想法是允许一小部分流量流向新部署的 pod，并执行质量和性能回归。如果新部署的应用程序是健康的，那么 DevOps 团队将逐步前滚它。但是，如果出现性能或质量问题，Ops 或 SRE 团队会立即将应用程序回滚到其旧版本，以确保发布过程为零停机时间。

工具： Kubectl、Kayenta等

反馈和通知

过程： 反馈是任何 CI/CD 过程的核心，因为每个人都应该知道软件交付和部署过程中发生了什么。确保有效反馈的最佳方法是衡量 CI/CD 流程的有效性并实时通知所有利益相关者。如果出现故障，它可以帮助 DevOps 和 SRE 在服务管理工具中快速创建事件以进一步解决问题。

例如，项目经理和企业主可能有兴趣了解新功能是否已成功推向市场。同样，DevOps 想知道新部署、集群和 pod 的状态，而 SRE 想了解部署到生产环境中的新应用程序的健康状况和性能。

工具： Slack、Discord、MS Teams、JIRA 和 ServiceNow

注意：所有阶段——监控、渐进式交付以及反馈和通知——都属于持续部署。

如果您是拥有数十个或数百个基于 Kubernetes 的微服务的大型或中型企业，那么您需要使用管道序列化您的交付 (CI/CD) 流程。