Tekton 入门指南：云原生 CI/CD 利器

一、Tekton 是什么

Tekton 是一个开源的云原生 CI/CD（持续集成/持续交付）框架，使用 Go 语言开发，专为 Kubernetes 环境设计。它允许开发者通过声明式 YAML 文件在 Kubernetes 集群中定义和执行流水线，从而完成代码构建、测试、镜像打包和部署等任务。

历史背景

Tekton 的前身是 Knative 的子项目 build-pipeline，最初目的是为 Knative 的 build 模块增加流水线功能。后来它独立出来，定位为通用的 CI/CD 工具。

2026 年 3 月，Tekton 正式从 CD Foundation（CDF）转入 CNCF（云原生计算基金会），成为 CNCF 的孵化项目$TRAE_REF。这标志着 Tekton 与 Kubernetes、Knative、Argo 等项目站到了同一阵营，是其发展历程中的重要里程碑。

为什么需要 Tekton

传统的 CI/CD 工具（如 Jenkins、GitLab CI）虽然也支持在 Kubernetes 上运行，但它们本质上是将 K8s 作为"扩展"来使用，并非原生设计。Kubernetes 作为新一代基础设施，迫切需要一套"生于 K8s、长于 K8s"的 CI/CD 方案。Tekton 基于 Kubernetes CRD（自定义资源）+ Controller 模式实现，所有流水线任务都以 Pod 形式运行，天然具备弹性伸缩、资源隔离、跨集群部署等能力。

二、Tekton 的六大优势

可移植：跨平台、跨语言、跨部署环境。Tekton 定义的流水线可以在任何 Kubernetes 集群上运行，不受具体环境限制。

可定制：Tekton 的每个实体（Task、Pipeline）都是完全可定制的。平台工程师可以定义细粒度的构建模块，供开发团队在不同场景下灵活组合使用。

可复用：一旦定义好 Task 或 Pipeline，组织内任何人都可以直接引用，无需重复造轮子。这使得构建复杂流水线的效率大幅提升。

可扩展：Tekton Catalog 是社区驱动的 Task 仓库，包含数百个经过验证的预制组件（Maven 构建、Docker 镜像打包、Helm 部署等），开箱即用。

标准化：Tekton 作为 Kubernetes 扩展安装和运行，使用成熟的 K8s 资源模型。流水线定义采用声明式 YAML，天然支持版本控制和 GitOps 工作流。

可伸缩：增加工作负载只需向集群添加节点即可，Tekton 随集群自动扩展，无需重新定义资源分配或修改流水线配置。

三、Tekton 组件概览

Tekton 由多个子项目组成，各司其职：

四、核心概念详解

理解 Tekton 的关键在于掌握五个核心概念，它们形成了一套分层清晰的流水线建模语言。

4.1 Task —— 最小执行单元

Task 是 Tekton 中最小的可复用单元，定义了一组有序的 Step。每个 Step 对应一个容器中执行的命令，例如代码拉取、编译构建、镜像打包、应用部署等。Tekton 会为每个 Step 启动一个独立的 Container。

Task 本身只是"模板"，不包含具体执行上下文。它强调无状态和幂等性——只要输入一致，输出就确定。

4.2 TaskRun —— Task 的实例化

TaskRun 是 Task 的一次具体执行。它绑定实际的输入参数（如 Git 仓库地址、镜像标签）、超时策略、重试逻辑等，并驱动底层控制器创建专属 Pod 来运行 Task 中的 Step。

一个 TaskRun 对应一个 Pod，每个 Step 对应 Pod 中的一个 Container。

4.3 Pipeline —— 编排多个 Task

Pipeline 是按照有向无环图（DAG）顺序排列的 Task 集合。它定义了多个 Task 之间的依赖关系（通过 runAfter 字段控制执行顺序），支持参数传递、并行执行、条件分支（when 表达式）等。

Pipeline 同样是"模板"，不直接执行。

4.4 PipelineRun —— Pipeline 的实例化

PipelineRun 是 Pipeline 的一次执行入口。它注入运行时参数，并承载完整的执行上下文：触发来源、超时设置、ServiceAccount 权限、日志路径等。每次执行都会在集群中创建一条可追踪的 PipelineRun 记录。

4.5 使用场景区分

• Task：适用于较简单的工作负载，比如运行单元测试、代码 lint 检查、构建缓存等。Task 在单个 Pod 中执行。
• Pipeline：适用于复杂工作负载，比如静态分析 + 测试 + 构建 + 部署的完整流程。

4.6 层级关系一张图

PipelineRun (执行入口)
  └── Pipeline (模板：定义 Task 的有序集合)
        ├── Task A (模板：定义一组 Step)
        │     ├── Step 1 → Container
        │     └── Step 2 → Container
        ├── Task B (模板)
        │     └── Step 1 → Container
        └── Task C (模板)
              ├── Step 1 → Container
              └── Step 2 → Container

五、安装部署实战

5.1 版本兼容性

Tekton 各组件的版本与 Kubernetes 版本有对应关系，安装前务必确认。以下是截至 2026 年 9 月的参考对照：

建议：生产环境优先选择 LTS（Long Term Support）版本，可获得长期的安全补丁和关键 bug 修复。当前最新 LTS 为 v1.15.0，支持至 2027 年 7 月$TRAE_REF。

5.2 安装 Tekton Pipelines

# 下载并部署（以 v1.15.0 LTS 为例）
kubectl apply -f https://infra.tekton.dev/tekton-releases/pipeline/previous/v1.15.0/release.yaml

# 查看 Pod 状态
kubectl get pods --namespace tekton-pipelines --watch

# 当所有 Pod 的 READY 列显示 1/1 时，安装完成

提示：如果集群无法直接拉取 gcr.io 镜像，可以借助 GitHub Action 或 Skopeo 工具将镜像同步到自己的私有仓库或 Docker Hub，然后替换资源清单中的镜像地址。

5.3 安装 Tekton Triggers

# 下载并部署 Triggers（版本需与 Pipelines 匹配）
kubectl apply -f https://infra.tekton.dev/tekton-releases/triggers/previous/v0.27.0/release.yaml
kubectl apply -f https://infra.tekton.dev/tekton-releases/triggers/previous/v0.27.0/interceptors.yaml

# 查看 Pod 状态
kubectl get pods --namespace tekton-pipelines -l app.kubernetes.io/part-of=tekton-triggers

5.4 安装 Tekton Dashboard

# 部署 Dashboard（release-full 版本支持读写操作）
kubectl apply -f https://infra.tekton.dev/tekton-releases/dashboard/previous/v0.50.0/release-full.yaml

# 查看 Pod 状态
kubectl get pods --namespace tekton-pipelines -l app.kubernetes.io/part-of=tekton-dashboard

Dashboard 默认通过 ClusterIP 暴露服务。如需外部访问，可配置 Ingress 或 kubectl port-forward：

# 临时端口转发（适合本地测试）
kubectl port-forward -n tekton-pipelines svc/tekton-dashboard 9097:9097

然后访问 http://localhost:9097 即可打开 Dashboard。

5.5 安装 Tekton CLI

# 下载二进制文件（以 Linux amd64 为例）
CLI_VERSION="0.38.0"
curl -LO https://github.com/tektoncd/cli/releases/download/v${CLI_VERSION}/tkn_${CLI_VERSION}_Linux_x86_64.tar.gz
tar xvzf tkn_${CLI_VERSION}_Linux_x86_64.tar.gz -C /usr/local/bin/ tkn

# 验证安装
tkn version

也可以将 tkn 添加为 kubectl 插件，方便使用：

ln -s /usr/local/bin/tkn /usr/local/bin/kubectl-tkn
kubectl plugin list   # 验证插件是否生效

六、快速上手

安装完成后，可以通过以下资源快速入门：

• 官方快速开始：https://tekton.dev/docs/getting-started/
• GitHub 示例仓库：https://github.com/tektoncd/pipeline/tree/main/examples —— 包含 Task、TaskRun、Pipeline、PipelineRun、挂载卷、结果存储等完整示例
• Tekton Hub：https://hub.tekton.dev —— 浏览和搜索社区贡献的预制 Task，如 git-clone、maven、kaniko、helm-upgrade 等

七、总结

Tekton 的核心价值在于将 CI/CD 流水线变成 Kubernetes 的一等公民。它不是简单的"又一个 CI 工具"，而是一套基于 CRD + Controller 的标准化流水线建模语言。

在实际项目中，Tekton 常与 Argo CD 搭配形成"CI + CD 黄金组合"：Tekton 负责代码构建、测试、镜像打包与安全扫描（CI），Argo CD 负责 GitOps 式的声明同步与自动部署（CD）。两者各司其职，共同构成云原生的完整交付链路。

Argo CD 是 Kubernetes 生态中最流行的 GitOps 持续交付工具。本文介绍它的核心概念、与 Jenkins 的差异，并手把手演示部署一个 Nginx 服务。

一、什么是 Argo CD？

Argo CD 是一个声明式的 GitOps 持续交付工具，用于 Kubernetes 集群。它通过持续监控 Git 仓库中的 Kubernetes 资源配置文件，将这些配置自动应用到指定的集群中，确保集群的实际状态与仓库中的期望状态保持一致。

Argo CD 支持各种 Kubernetes 清单格式：Kustomize、Helm Charts、Ksonnet、YAML 和 JSON，让你通过 Git 仓库就能管理和部署 Kubernetes 资源。

二、Argo CD 的好处

• 声明式管理：只需在 Git 仓库中定义好应用的期望状态，Argo CD 自动将集群实际状态与之同步，减少人为错误，配置管理更清晰、可审计
• GitOps 工作流：Git 仓库作为唯一真理来源（Source of Truth），每次部署或更新都通过提交代码和合并请求触发，保证自动化与审核跟踪
• 持续同步和自愈：持续监控集群资源状态，检测到偏离期望状态时自动纠正
• 多集群支持：一套 Argo CD 管理多个 Kubernetes 集群，跨集群部署更轻松
• 细粒度访问控制：支持基于角色的访问控制（RBAC）以及 SSO 集成，精确控制项目和应用权限

三、Argo CD 与 Jenkins 对比

四、实战：使用 Argo CD 部署一个 Nginx 服务

1、安装 Argo CD

在 Kubernetes 集群中安装 Argo CD：

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

安装完成后，查看 Argo CD API Server 的服务信息：

kubectl get svc -n argocd

2、访问 Argo CD Web 界面

通过 port-forward 暴露 Web 界面：

kubectl port-forward svc/argocd-server -n argocd 8080:443

浏览器访问 https://localhost:8080，默认用户名为 admin，初始密码用以下命令获取：

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

3、创建 Git 仓库并推送配置

在 GitHub（或其他 Git 服务）新建仓库，将以下内容保存为 nginx-deployment.yaml 并推送：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

4、定义 Argo CD 应用

创建 argo-nginx-app.yaml：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: '<YOUR_GIT_REPOSITORY_URL>'   # 替换为你的 Git 仓库地址
    targetRevision: HEAD
    path: '<YOUR_APP_PATH>'                # 替换为 yaml 文件所在目录
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

prune: true 表示仓库中删除的资源会同步从集群清理；selfHeal: true 表示集群被手动改动后会自动恢复成 Git 中的期望状态。

5、应用 YAML 文件

kubectl apply -f argo-nginx-app.yaml

6、验证部署

回到 Argo CD Web 界面，可以看到名为 nginx-app 的应用，状态为 Synced 即部署成功。

也可以在集群中验证 Nginx 是否正常运行：

kubectl get pods -l app=nginx
kubectl get svc nginx-service

五、总结

Argo CD 通过 GitOps 工作流，让 Kubernetes 的应用部署和配置管理更透明、可追溯、可自愈。与 Jenkins 等传统 CI/CD 工具相比，它更专注于 Kubernetes 环境的持续交付，尤其适合微服务和容器化应用；而 Jenkins 则在通用 CI 场景（编译、测试、打包）中依然不可替代——两者配合使用（Jenkins 管 CI，Argo CD 管 CD）是目前的主流实践。

一、Argo CD简介

• 主要是为k8s而生，遵循声明式GitOps理念的持续部署CD工具，自带一个简单的dashboard页面，支持多种配置管理/模版工具（eg：kustomize、helm、kscnnet、jsconnet、plain-yaml）
• argo被称k8s控制器，它持续监控正在运行的应用程序并将当前的实时状态与所需的目标状态（例如git仓库中的配置）进行比较，在git仓库更改时自动同步和部署应用程序

二、架构图

1.API Server：
argocd的api入口，提供了外部接口以便用户或外部工具与argocd进行交互。api server同时也是webui的后台服务

2.Repository Server：
负责与git仓库交互。它从仓库中拉取应用定义，并将这些定义转化为k8s清单文件。会缓存从git仓库中获取的文件

3.Controller：
核心控制器，持续监控k8s集群的当前状态与期望状态（定义在给i他仓库中）之间的差异。controller负责将集群的状态与git中的期望状态保持一致

4.Application Controller：
负责处理用户定义的ArgoCD Application资源。它会检查git仓库中的定义，并确保这些定义与k8s集群中的应用状态保持同步

5.Redis Server：
用于缓存数据和提升系统性能，尤其在处理大量应用和频繁同步操作时很重要

6.Web UI：
提供一个友好的图形化界面，用户可以通过webui查看应用状态，同步状态以及进行手动操作

三、ArgoCD的工作原理

Argo CD的核心理念是GitOps，即以git仓库作为单一的真理源，通过自动化的方式将仓库中的应用配置同步到k8s
1、定义应用：用户在git仓库中定义应用的k8s资源清单，并将这些清单文件提交到git仓库
2、创建Argocd application：在argocd创建一个application资源，资源描述了应用在git仓库中的位置，以及在kubernetes集群中部署的位置
3、同步状态监控：Argocd controller持续监控git仓库中的配置，并于当前集群状态进行对比。每次检测到git仓库中的应用配置发生变化时，controller会自动更新集群中的资源，保持与git仓库的一致性
4、自动同步与手动同步：一种是检测到git仓库有变化，argocd会自动更新k8s集群的资源
5、回滚功能：如果应用更新导致问题，一键回滚

四、ArgoCD自动拉取更新的机制

argocd通过持续监控git仓库的变更来实现自动拉取和更新机制
工作机制

• 定时轮询：Argocd controller会定期轮询指定的git仓库，以检查是否有新的提交。默认周期3min
• webhook触发：支持通过Git仓库的webhook来触发同步操作。当仓库中发生提交或合并请求时，gitlab、github等平台可以通过webhook通知argocd进行同步
• 状态对比：每次拉取到最新的git仓库状态后，argocde会与当前集群中应用状态进行比对，如果发现差异，argocd会自动执行同步操作，确保集群与git仓库的配置一致

阅读剩余部分

官方网址健康检查

问题描述：当公司内网创建的监控zabbix或者promethues，当网络断掉的时候会使监控服务采集不到数据，或者直接掉线，即使配置可告警功能但是仍然不会发送，这个时候无法及时知道故障的发生对生产环境有影响
解决方案：
1、添加healthchecks，设置zabbix5-10分钟，触发一次心跳，告诉healthchecks我还活着，当检测不到zabix数据则出发告警机制
2、将监控放在云平台上，公网环境跟内网环境不搭边

创建注册Healthchecks

1. 打开网址
2. 点击右上角的sign up/log in
3. 填写你的邮箱
4. 去邮箱收信
5. 步骤如下

w

6. 会出现以下页面

【仍需要修改】

7. 最终配置

8. 飞书创建bot
   拿到webhook的url
9. 加飞书webhook

zabbix配置

10. vm添加心跳cron

Git 常用命令速查

日常开发 Git 操作速查手册，持续更新。

1、克隆

git clone <远程仓库地址>

2、切换分支

git checkout <分支名>

3、数据拉取到本地仓库（不自动合并）

git fetch

4、拉取到本地仓库并自动合并

git pull

5、合并

git merge <分支名>

6、查看分支

git branch

7、查看远程所有分支

git branch -r

8、查看本地和远程的所有分支

git branch -a

9、新建分支

git branch develop

10、从当前分支拷贝并切换到新分支

git checkout -b develop

11、将本地新的分支推送至远程

git push origin develop

12、暂存

git stash

13、恢复暂存区

git stash pop

14、删除本地分支

git branch -d <分支名字>

15、删除远程分支

git push origin --delete <分支名字>

16、查看远程仓库详情（含远程已删除的分支信息）

git remote show origin

17、清理远程已删除的本地追踪分支（强制删除）

git remote prune origin

18、查看代码修改状态

git status

19、提交到暂存区

git add <file>

20、提交暂存区文件

git commit -m "提交说明"

21、分支推送到远程

git push
# 或指定分支
git push origin <本地分支名>

22、合并代码

（1）先切换到要合并到的目标分支

git checkout <目标分支名>

（2）合并源分支（--no-ff 保留分支历史）

git merge --no-ff <源分支名>

（3）合并完成推送远程

git push

23、重新同步原分支

git rebase <分支名>

24、rebase 同步场景

场景：从 develop 拉取了 feature-200 分支，开发完想合并回 develop 时，发现 develop 已被别人提交了新代码。

（1）切换到 develop 分支

git checkout develop

（2）同步 develop 分支最新代码

git pull

（3）切换回 feature-200 分支

git checkout feature-200

（4）重新同步 develop

git rebase develop

（5）强制推送

git push -f

⚠️ 注意：-f 强制推送会覆盖远程历史，仅在自己负责的分支上使用。

25、查看 / 更换用户名邮箱

（1）查看当前的

git config user.name
git config user.email

（2）查看全局的

git config --global user.name
git config --global user.email

（3）更换局部的

git config user.name "<name>"
git config user.email "<email>"

（4）更换全局的

git config --global user.name "<name>"
git config --global user.email "<email>"

（5）使用已有的凭证

git config credential.helper store

在 Jenkins 中 shell 脚本用 git tag 新建标签推送至远程时有用。

26、查看远程仓库地址

git remote -v

27、创建 git 仓库

mkdir <directory>
cd <directory>
git init
touch a.txt
git add a.txt
git commit -m "first commit"
git remote add origin <远程服务器地址>.git
git push -u origin master

28、合并多个 commit（squash）

场景：从 develop 拉取了 feature-100 分支并提交了 2 个 commit，合并回 develop 前，为便于审核查阅，将 2 个 commit 合并为 1 个。

（1）交互式 rebase，合并最近 N 个提交

git rebase -i HEAD~<提交节点数量>

（2）多次操作导致本地与远程分支不一致时，强制推送

git push -f