1. OpenShift GitOps持续交付工程导论
在云原生交付体系中，应用能否稳定、可追溯、可回滚地到达集群，往往比“能否构建出镜像”更决定工程效率。OpenShift GitOps 正是围绕这一目标构建的持续交付方案：它把 Git 仓库作为期望状态的唯一来源，由集群内的控制器持续把实际状态拉齐到 Git 中声明的状态。理解这套机制，是后续所有章节的基础。
课程目标与学习路径
本课程面向已经具备容器与 Kubernetes 基础、希望把交付流程工程化的开发者与运维人员。学完后应能独立完成以下任务：在 OpenShift 集群上启用 GitOps 能力；用 Argo CD 管理应用与环境；用 ApplicationSet 批量生成多环境应用；用 Kustomize 与 Helm 组织可复用配置；用同步策略、健康检查与回滚机制保障发布安全；并把 GitOps 接入 CI 流水线，形成“构建在 CI、部署在 GitOps”的分工。课程强调可复现，因此会给出真实可用的 YAML 片段、目录结构与判断依据，而不是停留在概念介绍。
GitOps 的四条核心原则
GitOps 不是某个工具的名字，而是一组约束交付方式的工程原则。业界通常归纳为四条：
- 声明式描述：系统期望状态以声明式配置表达，而不是用脚本逐步执行命令。Kubernetes 的 YAML 天然满足这一点。
- 版本化且不可变：所有期望状态存放在 Git 中，每次变更都是一次提交，历史可追溯、可审计、可回滚。
- 自动拉取：集群内的代理主动从 Git 拉取期望状态，而不是由外部系统推送。拉取模式让集群凭据不必暴露给 CI。
- 持续调和：控制器不断比较期望状态与实际状态，发现偏差就修正，使集群具备自愈能力。
这四条原则带来一个关键推论：Git 提交即发布意图。谁合并了 PR、合并了什么内容、何时生效，全部有据可查。相比传统“登录集群执行 kubectl apply”，GitOps 把变更入口收敛到代码评审流程中。
OpenShift GitOps 的组件架构
OpenShift GitOps 是 Red Hat 对 Argo CD 的集成发行版，通过 Operator 方式安装和管理。其核心组件与数据流如下：
图中①到④构成一个闭环：Repo Server 拉取并渲染清单，Application Controller 将渲染结果应用到集群，随后回读实际状态与期望状态比对，一旦发现偏差就触发修正。这个循环默认每三分钟执行一次，也可通过 webhook 在 Git 推送时立即触发。
持续交付价值与典型场景
把上述机制放到真实交付中，价值体现在三处。第一是环境一致性：开发、测试、生产使用同一套清单模板，仅通过 overlay 覆盖副本数、资源配额与镜像标签，避免“测试能跑、生产报错”。第二是可回滚性：发布失败时，回退一次 Git 提交即可让集群回到上一个已知良好状态，回滚时间从“重新构建再部署”缩短到一次同步。第三是权限收敛：CI 系统只需 Git 写权限，集群凭据由 Argo CD 持有，减少了凭据扩散面。
一个典型的多环境目录可以这样组织：
gitops-repo/
├── apps/
│ └── web/
│ ├── base/
│ │ ├── deployment.yaml
│ │ ├── service.yaml
│ │ └── kustomization.yaml
│ └── overlays/
│ ├── dev/
│ │ ├── kustomization.yaml
│ │ └── patch-replicas.yaml
│ └── prod/
│ ├── kustomization.yaml
│ └── patch-replicas.yaml
└── argocd/
├── app-dev.yaml
└── app-prod.yaml
其中 base 存放与环境无关的通用清单，overlays/dev 与 overlays/prod 分别覆盖差异。对应的 Argo CD Application 只需指向不同路径：
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: web-prod
namespace: openshift-gitops
spec:
project: default
source:
repoURL: https://git.example.com/team/gitops-repo.git
targetRevision: main
path: apps/web/overlays/prod
destination:
server: https://kubernetes.default.svc
namespace: web-prod
syncPolicy:
automated:
prune: true
selfHeal: true
这里 prune: true 表示 Git 中删除的资源会同步从集群删除，selfHeal: true 表示集群中被手工改动的资源会被自动纠正回 Git 声明状态。两者是 GitOps 自愈能力的直接开关，但也意味着任何绕过 Git 的手工修改都会被覆盖，团队需要就此达成共识。