生产环境 DevOps 实战 | 第 1 天：为什么选择 Tekton + Argo CD + Harbor 三件套——生产级 DevOps 技术选型

第 1/60 天

引言

在云原生时代，企业的 DevOps 能力几乎等于工程效率本身。然而大多数团队的 CI/CD 基建仍然停留在「Jenkins 加一堆 Shell 脚本」的阶段：流水线写在 XML 或自由风格 Job 里，构建产物散落在各台机器上，发布靠运维手工 kubectl apply，出了问题谁也不敢回滚。当业务规模上来之后，这种模式会带来三个致命痛点：

1. 环境不一致：构建、测试、部署跑在不同环境，行为不可复现；
2. 权限失控：Jenkins 账户能登录几乎所有服务器，安全审计形同虚设；
3. 发布不可控：没有制品追溯、没有灰度手段、没有一键回滚，上线靠胆量。

本系列文章将给出一个经过生产验证的答案：Tekton（CI）+ Harbor（制品仓库）+ Argo CD（CD） 三件套，构建从代码提交到生产上线的全链路云原生 DevOps 平台。第 1 天我们先回答最核心的问题——为什么是这三件套，而不是别的？

核心概念

一条流水线的三个职责

任何 CI/CD 系统，本质上都在解决三个问题：把代码变成制品（CI）、把制品存好并管好（Registry）、把制品安全地发布到目标环境（CD）。三件套正好一一对应：

为什么是 Tekton 而不是 Jenkins？

Jenkins 统治 CI 十几年，但它不是为 Kubernetes 设计的。Tekton 则完全不同：它把流水线建模为 Kubernetes CRD（Task、Pipeline、PipelineRun），流水线就是 kubectl apply 的对象，天然支持声明式管理、版本化、多租户隔离。

为什么是 Harbor 而不是 Docker Registry？

Docker Registry 只是一个存储层；生产环境还需要漏洞扫描、镜像签名、复制容灾、Robot Account、配额管理、审计日志——这些都是 Harbor 的内置能力。Harbor 是 CNCF 毕业项目，中文文档完善，国内落地最多。

为什么是 Argo CD 而不是 Spinnaker / Flux？

Argo CD 是 GitOps 事实标准（CNCF 毕业项目）。与 Flux 相比，Argo CD 的 UI、多集群（ApplicationSet）、渐进式发布（Argo Rollouts）生态更完整；与 Spinnaker 相比，Argo CD 的声明式模型简单一个数量级，不需要维护一整套自己的基础设施。

实战步骤

下面我们用可执行的示例，把三件套的「最小可运行形态」跑通，直观感受这套技术栈的用法。

步骤 1：确认环境基线

三件套全部运行在 Kubernetes 之上，先确认集群与工具版本：

# 确认集群版本（建议 1.26+）
kubectl version --short
kubectl get nodes -o wide

# 确认 Helm 与命令行工具
helm version --short
kubectl kustomize version 2>/dev/null || echo "kubectl 内置 kustomize 可用"

# 需要安装的工具清单（后续文章逐个展开）
# tkn        -> Tekton CLI
# argocd     -> Argo CD CLI
# harborctl  -> 或直接用 curl + Harbor REST API

步骤 2：创建一个最小 Tekton Pipeline

Tekton 中，Task 是原子步骤单元，Pipeline 编排多个 Task。下面这个最小示例：先 clone 代码，再输出提交信息——它是后续一切复杂流水线的骨架：

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: git-clone
spec:
  workspaces:
    - name: source
  steps:
    - name: clone
      image: alpine/git:latest
      script: |
        git clone $(params.repo-url) $(workspaces.source.path)/app
---
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: show-commit
spec:
  workspaces:
    - name: source
  steps:
    - name: log
      image: alpine/git:latest
      script: |
        cd $(workspaces.source.path)/app
        git log -1 --oneline
---
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: simple-pipeline
spec:
  workspaces:
    - name: shared-workspace
  tasks:
    - name: fetch
      taskRef:
        name: git-clone
      workspaces:
        - name: source
          workspace: shared-workspace
    - name: inspect
      taskRef:
        name: show-commit
      runAfter: [fetch]
      workspaces:
        - name: source
          workspace: shared-workspace

执行流水线：

kubectl apply -f simple-pipeline.yaml
kubectl create -f - <<'EOF'
apiVersion: tekton.dev/v1
kind: PipelineRun
metadata:
  name: simple-pipeline-run-1
spec:
  pipelineRef:
    name: simple-pipeline
  workspaces:
    - name: shared-workspace
      emptyDir: {}
EOF

# 观察执行状态
tkn pipelinerun logs simple-pipeline-run-1 -f

步骤 3：在 Harbor 中准备项目与 Robot Account

Harbor 中，项目（Project） 是镜像隔离的最小单位，Robot Account 是给机器/流水线用的最小权限凭证（比管理员密码安全得多）：

# 先通过 API 创建项目 dev-app（public=false 即私有项目）
curl -u admin:CHANGE_ME -k -X POST 
  "https://harbor.example.com/api/v2.0/projects" 
  -H "Content-Type: application/json" 
  -d '{
    "project_name": "dev-app",
    "metadata": {
      "public": "false",
      "auto_scan": "true",
      "prevent_vul": "true"
    }
  }'

# 创建只读 robot account，供 Tekton 推送镜像使用（实际应赋予 push 权限）
curl -u admin:CHANGE_ME -k -X POST 
  "https://harbor.example.com/api/v2.0/projects/dev-app/robots" 
  -H "Content-Type: application/json" 
  -d '{
    "name": "tekton-ci",
    "duration": -1,
    "level": "project",
    "permissions": [{
      "access": [{"resource": "repository", "action": "push"},
                 {"resource": "repository", "action": "pull"}],
      "kind": "project",
      "namespace": "dev-app"
    }]
  }'

注意：duration: -1 表示永不过期，生产环境建议按证书轮换周期设置有效期，并在密钥管理系统中轮换（第 21 天会专门讲 Robot Account 实战）。

步骤 4：创建 Argo CD Application 把集群托管给 Git

Argo CD 的核心思想：Git 仓库是集群状态的唯一事实来源（single source of truth）。下面这个 Application 告诉 Argo CD：app-of-apps/manifests 目录下的 YAML 就是 dev 环境应有的状态，集群漂移了自动拉回来：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: dev-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/dev-app-config.git
    targetRevision: main
    path: manifests
  destination:
    server: https://kubernetes.default.svc
    namespace: dev
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

argocd app create dev-app 
  --repo https://github.com/your-org/dev-app-config.git 
  --path manifests 
  --dest-server https://kubernetes.default.svc 
  --dest-namespace dev 
  --sync-policy automated --auto-prune --self-heal

步骤 5：用 Python 脚本做技术选型的「可量化评估」

选型不能只靠感觉。下面这个脚本把候选方案的评分维度量化，可以作为团队决策的可复现依据：

#!/usr/bin/env python3
"""CI/CD 技术选型评分工具：基于加权评分模型"""
import json

CRITERIA = {
    "Kubernetes 原生": 0.25,
    "社区活跃度":     0.20,
    "落地成本":       0.20,
    "安全合规能力":   0.20,
    "可扩展性":       0.15,
}

CANDIDATES = {
    "Jenkins + 自建Registry + 脚本发布": {"Kubernetes 原生": 2, "社区活跃度": 5,
        "落地成本": 4, "安全合规能力": 2, "可扩展性": 3},
    "GitLab CI + Registry + AutoDevOps": {"Kubernetes 原生": 3, "社区活跃度": 5,
        "落地成本": 4, "安全合规能力": 4, "可扩展性": 3},
    "Tekton + Harbor + Argo CD":         {"Kubernetes 原生": 5, "社区活跃度": 5,
        "落地成本": 3, "安全合规能力": 5, "可扩展性": 5},
}

def score(name: str, scores: dict) -> float:
    return round(sum(CRITERIA[k] * scores[k] for k in CRITERIA), 2)

ranking = sorted(
    ((score(n, s), n) for n, s in CANDIDATES.items()),
    reverse=True,
)
for s, n in ranking:
    print(f"{s:5.2f}  {n}")
print("n推荐方案:", ranking[0][1])

常见问题

1. 我们已经用了 Jenkins，为什么要迁移？

如果 Jenkins 仅承担构建且规模不大，不必为了换而换。但当出现以下信号时，就该考虑 Tekton：流水线定义要版本化管理、多团队需要资源隔离、构建环境标准化困难、Jenkins 频繁挂掉或插件冲突。迁移不是「推翻重来」，可以先用 Tekton 承担新项目，逐步替换（第 54 天会专门讲 Jenkins → Tekton 迁移路径）。

2. 三件套必须一起用吗？

不是。三者可以独立替换：Tekton 推镜像到任何 Registry，Argo CD 也可以从 Docker Hub 拉镜像。但组合使用收益最大——因为它们的授权模型（Robot Account）、API 风格（声明式 YAML）、可观测性（Prometheus 指标）天然互补，集成成本最低。

3. 小团队 / 单机环境用这套是不是过度设计？

如果只是个人项目或演示环境，minikube + Tekton + Harbor + Argo CD 依然能跑，但管理成本确实偏高——此时建议用 Docker Compose 或一体化工具（如 Gitea + Drone / Gitea Actions）。三件套的价值在「多人协作、多环境、合规审计」的场景才完全体现。

4. 学习成本高吗？

有 K8s 基础的话，曲线并不陡：Tekton 的核心就是「把流水线当 YAML 写」，Argo CD 的核心是「kubectl apply 换成 git push」，Harbor 则是「Docker Registry 加了个更好的 UI 和安全层」。本系列 60 天就是按这个路径从入门到生产排的，跟着走即可。

5. 和 GitHub Actions / GitLab CI 冲突吗？

不冲突。SaaS CI 跑在别人机器上，自建三件套跑在自己集群里。混合模式很常见：GitHub Actions 做 PR 检查（轻量），Tekton 做主流水线（生产构建），第 55 天会讲混合 CI 的过渡方案。真正的红线是：生产发布必须走受控的 GitOps 通道，不能一边 Argo CD 管集群、一边有人偷偷 kubectl 改资源。

总结

• 选型逻辑：CI/CD 的本质是「代码 → 制品 → 环境」三段式，Tekton、Harbor、Argo CD 正好一一对应，且全部是 CNCF 生态的 Kubernetes 原生方案。
• 组合优势：声明式 YAML 贯穿始终，流水线、仓库策略、应用状态全部可版本化、可审计、可回滚；权限模型（Namespace / Robot Account / Project）天然支持多团队隔离。
• 上手路径：先跑通最小 PipelineRun + Harbor 项目 + Argo CD Application，再逐步叠加镜像签名、扫描、灰度、多集群等高阶能力。
• 本系列预告：接下来 59 天，我们会从架构蓝图（第 2~7 天）、Tekton 深入（第 8~14 天）、Harbor 实战（第 15~21 天）、Argo CD 深入（第 22~28 天），一路走到生产落地、安全加固、踩坑记录和生态扩展，最终交付一份可以直接抄的完整路线图。

下期预告

第 2 天：CI/CD 工具链全景对比——Jenkins、GitLab CI、Tekton、Argo CD、Harbor 怎么选

明天我们将把技术选型这件事做透：主流 CI 工具（Jenkins / GitLab CI / GitHub Actions / Tekton）、CD 工具（Argo CD / Flux / Spinnaker / Jenkins X）、制品仓库（Docker Registry / Harbor / Nexus / Artifactory）放在同一张评分表里逐项对比，并给出不同规模团队的选型建议。

📚 系列目录（持续更新中）

• 第 1 天：为什么选择 Tekton + Argo CD + Harbor 三件套——生产级 DevOps 技术选型 ← 本篇
• 第 2 天：CI/CD 工具链全景对比：Jenkins、GitLab CI、Tekton、Argo CD、Harbor 怎么选 🔜
• 第 3 天：生产环境 DevOps 架构设计：从代码提交到上线的全链路蓝图 🔜
• 第 4 天：Tekton 核心概念入门：Task、Pipeline、PipelineRun、Step 详解 🔜
• 第 5 天：Argo CD 核心概念入门：Application、Project、Sync 策略详解 🔜
• 第 6 天：Harbor 核心概念入门：Registry、Project、Robot Account 详解 🔜
• 第 7 天：三件套集成总览：Tekton 构建 → Harbor 存储 → Argo CD 部署的端到端流程 🔜
• 第 8~60 天：Tekton CI 深入、镜像与 Harbor、Argo CD 深入、三件套集成实战、GitOps 进阶、生产实践与运维、生态与扩展、高级主题与展望 🔜