课程导入：云原生CI/CD的演进、Tekton与Argo CD的定位、课程学习路径与实战环境准备
在云原生技术体系快速迭代的今天，持续集成与持续交付（CI/CD）已经从“可选工具链”演变为“平台核心能力”。传统以Jenkins、GitLab CI为代表的单体流水线，在Kubernetes成为应用交付标准之后，逐渐暴露出资源利用率低、环境一致性差、发布策略单一等结构性瓶颈。本课程聚焦于云原生领域两个最具代表性的开源项目——Tekton与Argo CD，前者重新定义了“流水线即代码”的执行模型，后者则将GitOps理念落地为声明式交付的行业标准。本章作为课程起点，将系统梳理云原生CI/CD的演进脉络，明确Tekton与Argo CD在技术版图中的分工边界，并给出贯穿全课程的实战环境搭建方案。
一、云原生CI/CD的演进逻辑：从“自动化”到“平台化”
1. 核心原理：CI/CD的本质与云原生带来的范式转移
持续集成（CI）的核心在于频繁地将代码变更合并到主干，并通过自动化构建与测试尽早发现集成问题；持续交付（CD）则进一步确保代码在任何时刻都处于可部署状态，并通过自动化流程将应用发布到目标环境。传统CI/CD工具链以“任务编排”为中心，通过插件或脚本串联构建、测试、部署步骤。然而，当应用架构从单体转向微服务，部署环境从虚拟机转向Kubernetes后，传统工具面临三个根本性挑战：环境一致性（构建环境与运行环境差异导致“在我机器上能跑”）、资源利用效率（常驻的Jenkins Master/Slave造成资源浪费）、发布策略的精细化（蓝绿、金丝雀、A/B测试需要平台级能力支撑）。
云原生CI/CD的范式转移体现在：一切皆声明式——流水线定义、应用部署清单、环境配置全部以代码形式存储在Git仓库中；一切皆容器——构建、测试、部署步骤运行在Kubernetes Pod中，环境完全隔离且可复现；一切皆可观测——通过Kubernetes原生的日志、指标、事件机制，CI/CD过程本身也成为可监控的一等公民。
2. 判断方法：如何评估现有CI/CD系统的云原生成熟度
评估一个CI/CD系统是否真正“云原生”，可以从以下五个维度进行判断：
| 评估维度 | 传统CI/CD特征 | 云原生CI/CD特征 |
|---|---|---|
| 执行环境 | 固定虚拟机/物理机，环境易漂移 | 按需创建Pod，环境与生产一致 |
| 配置管理 | Web界面配置，难以版本化 | YAML/代码定义，Git版本管理 |
| 扩展性 | 垂直扩展为主，受限于单机 | 水平扩展，K8s自动调度 |
| 发布策略 | 脚本实现，难以标准化 | 平台原生支持蓝绿、金丝雀、渐进式交付 |
| 多集群支持 | 需额外插件，配置复杂 | 天然支持多集群、多环境管理 |
如果现有系统在上述维度中超过三项不满足，则说明需要向云原生CI/CD架构演进。值得注意的是，演进并非全盘推翻，而是可以采用“绞杀者模式”——将新项目或新服务逐步迁移到Tekton+Argo CD流水线，同时保留旧系统运行存量任务。
3. 案例拆解：一个典型微服务项目的CI/CD痛点与转型路径
以某电商平台订单服务为例，该团队最初使用Jenkins构建单体应用，部署到虚拟机。随着业务拆分为30多个微服务，团队面临以下具体问题：
- 构建排队严重：Jenkins Master资源有限，高峰期构建任务排队超过30分钟。
- 环境不一致：开发环境使用Docker Compose，测试环境使用虚拟机，生产环境使用K8s，导致“测试通过、生产失败”频发。
- 发布效率低：每次发布需要运维手动执行脚本，平均耗时45分钟，且无法快速回滚。
团队决定分三步转型：第一步，将构建流程迁移到Tekton，利用Kubernetes的Pod并发能力，构建排队时间从30分钟降至2分钟以内；第二步，将部署流程迁移到Argo CD，通过GitOps实现应用声明式管理，发布操作从手动脚本变为Git提交触发自动同步；第三步，引入Argo Rollouts实现金丝雀发布，将发布风险降低80%。整个转型周期约6周，期间新旧系统并行运行，逐步切换流量。
4. 常见误区与总结复盘
在云原生CI/CD演进过程中，团队常陷入以下误区：
- 误区一：认为“容器化=云原生”。将Jenkins直接打包成容器运行，只是改变了部署方式，并未解决架构层面的问题。
- 误区二：过度追求“全自动”。在灰度策略、审批流程尚未完善时，盲目取消人工审批环节，可能导致生产事故。
- 误区三：忽视安全与合规。云原生CI/CD的配置即代码特性，要求对Git仓库权限、Secret管理、镜像签名有更严格的控制。
总结复盘：云原生CI/CD的演进本质上是将CI/CD从“工具链”提升为“平台能力”。Tekton负责解决“如何高效、可靠地构建和测试”，Argo CD负责解决“如何安全、可控地发布和回滚”。两者互补，共同构成云原生应用交付的完整闭环。
二、Tekton与Argo CD的定位：CI与CD的职责边界
1. 核心原理：Tekton的流水线模型与Argo CD的GitOps模型
Tekton是Linux基金会旗下的开源项目，它提供了一组Kubernetes自定义资源定义（CRD），包括Task（任务）、Pipeline（流水线）、PipelineRun（流水线运行）、TaskRun（任务运行）等。Tekton的核心设计理念是“流水线即代码”——用户通过YAML声明流水线的步骤、参数、工作区，Tekton Controller负责将流水线实例化为Pod并调度执行。每个Step运行在独立的容器中，步骤之间通过工作区（Workspace）共享数据，支持并行执行和条件判断。
Argo CD则是CNCF旗下的GitOps持续交付工具，其核心模型是“声明式部署”——用户将应用期望状态（Deployment、Service、ConfigMap等K8s清单）存储在Git仓库中，Argo CD持续监控Git仓库与集群实际状态的差异，并通过自动或手动同步使集群状态收敛到期望状态。Argo CD还提供Application CRD、AppProject CRD用于多租户管理，以及Sync策略（自动/手动）、Hook机制（PreSync、Sync、PostSync）用于精细化控制部署流程。
2. 判断方法：何时选择Tekton，何时选择Argo CD
在实际项目中，团队需要根据需求场景选择合适的工具，甚至组合使用。以下判断清单可供参考：
| 需求场景 | 推荐工具 | 理由 |
|---|---|---|
| 需要自定义构建步骤、并行执行、缓存机制 | Tekton | Task/Pipeline模型灵活，支持复杂CI逻辑 |
| 需要将应用部署到多个K8s集群 | Argo CD | 多集群管理是Argo CD的核心能力 |
| 需要实现GitOps工作流，以Git为唯一事实源 | Argo CD | GitOps模型天然支持声明式同步与审计 |
| 需要执行数据库迁移、K8s资源校验等部署前/后任务 | Argo CD + Argo Rollouts | Hook机制与渐进式交付支持复杂发布策略 |
| 已有Jenkins/GitLab CI，希望逐步迁移 | Tekton（CI部分） | Tekton可独立使用，降低迁移风险 |
3. 实战场景：Tekton与Argo CD的典型协作链路
一个标准的云原生CI/CD协作链路如下：
- 开发人员推送代码到Git仓库（如GitLab或GitHub）。
- Webhook触发Tekton PipelineRun，执行以下步骤：拉取代码 → 单元测试 → 构建容器镜像 → 推送到镜像仓库 → 更新Git仓库中的部署清单（镜像Tag）。
- Argo CD检测到Git仓库中部署清单的变更（镜像Tag更新），根据同步策略（自动或手动）将新版本应用到目标K8s集群。
- Argo CD通过Kubernetes健康检查（Readiness Probe、自定义Hook）确认应用状态，若异常则自动回滚到上一个稳定版本。
这种协作模式的优势在于：CI阶段与CD阶段通过Git仓库解耦，开发人员无需关心部署细节；运维人员通过Argo CD的UI或CLI即可查看所有应用的状态和同步历史。
4. 常见误区与总结复盘
关于Tekton与Argo CD的定位，常见误区包括：
- 误区一：用Tekton做CD。Tekton虽然可以执行kubectl apply命令，但它缺乏GitOps所需的“状态持续对比”和“自动修复”能力，不适合作为CD主引擎。
- 误区二：用Argo CD做CI。Argo CD不擅长执行复杂的构建和测试逻辑，其核心是部署而非构建。
- 误区三：认为两者只能二选一。实际上，Tekton与Argo CD是互补关系，组合使用才能发挥最大价值。
总结复盘：Tekton与Argo CD的定位差异源于它们解决的核心问题不同。Tekton解决“如何高效构建”，Argo CD解决“如何安全发布”。理解这一边界，有助于团队在设计流水线时做出合理的架构决策。
三、课程学习路径与实战环境准备
1. 核心原理：课程设计的“三阶段”学习模型
本课程共30章，按照“基础→进阶→实战”三阶段设计。第一阶段（第1-8章）聚焦Tekton与Argo CD的核心概念、安装部署、基本操作；第二阶段（第9-20章）深入高级特性，包括Tekton的缓存、条件执行、参数化，Argo CD的AppProject、多集群管理、Sync策略、Hook机制；第三阶段（第21-30章）通过完整项目案例，将CI/CD与DevOps实践（监控、告警、安全扫描、成本优化）结合，帮助学员构建生产级交付平台。
学习路径建议：每章学习后，完成对应的动手实验；每三章结束后，进行一次综合练习，将前几章的知识串联起来。例如，第5章学习Tekton的Workspace后，可以尝试将第3章的构建任务与第4章的测试任务通过Workspace共享数据。
2. 操作流程：实战环境搭建步骤
为了顺利完成课程实验，建议准备以下环境：
| 资源类型 | 规格要求 | 用途 |
|---|---|---|
| Kubernetes集群 | v1.26+，至少4核CPU、8GB内存 | 运行Tekton与Argo CD |
| 镜像仓库 | Harbor或Docker Hub | 存储构建产物 |
| Git仓库 | GitLab或GitHub | 存放代码与部署清单 |
| 命令行工具 | kubectl、tkn、argocd | 操作K8s与工具 |
推荐使用kind或k3s在本地搭建轻量级K8s集群，以降低资源门槛。安装Tekton与Argo CD的简化命令如下：
# 安装Tekton Pipelines
kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml
# 安装Tekton CLI（tkn）
brew install tektoncd-cli
# 安装Argo CD
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# 安装Argo CD CLI
brew install argocdkubectl get pods -n tekton-pipelines 和 kubectl get pods -n argocd，确认所有Pod处于Running状态。Argo CD默认密码存储在名为 argocd-initial-admin-secret 的Secret中，可通过 kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d 获取。
3. 案例拆解：一个最小化的端到端CI/CD实验
为了帮助学员快速建立整体认知，我们设计一个最小化实验：使用Tekton构建一个Go语言应用镜像，然后通过Argo CD将其部署到K8s集群。实验步骤如下：
- 在Git仓库中创建应用代码和Dockerfile。
- 编写Tekton Pipeline，包含两个Task：
build-image（构建并推送镜像）和update-git（更新部署清单中的镜像Tag）。 - 创建PipelineRun，触发流水线执行。
- 在Argo CD中创建Application，指向部署清单所在的Git仓库路径。
- 设置同步策略为“自动”，观察Argo CD自动部署新版本。
该实验虽然简单，但涵盖了CI/CD的核心链路。学员可以在此基础上扩展，例如增加单元测试、安全扫描、金丝雀发布等步骤。
kaniko 或 buildah 作为构建工具，它们无需Docker Daemon即可在容器内构建镜像。本课程后续章节将详细介绍kaniko的配置方法。
4. 常见误区与总结复盘
在环境准备阶段，学员常遇到以下问题：
- 误区一：使用过旧的K8s版本。Tekton与Argo CD的新特性依赖K8s API的演进，建议使用v1.26及以上版本。
- 误区二：忽略RBAC配置。Tekton和Argo CD需要创建ServiceAccount并绑定相应权限，否则会出现权限不足的错误。
- 误区三：网络问题导致镜像拉取失败。在国内环境，建议配置镜像加速器或使用代理。