1. GitOps 核心理念：声明式配置、不可变基础设施、Git 作为单一事实来源
GitOps 是一套以 Git 仓库为运维中心的持续交付与基础设施管理范式。其核心由三大支柱构成：声明式配置、不可变基础设施、Git 作为单一事实来源。理解这三者之间的协同关系，是构建可靠 GitOps 流水线的第一步。
1.1 三大核心理念对比
| 核心理念 | 定义 | 关键特征 | 反模式 |
|---|---|---|---|
| 声明式配置 | 用户描述系统的期望状态（What），而非执行步骤（How）。 | 幂等性、可重复、版本化 | 命令式脚本、手动 kubectl apply |
| 不可变基础设施 | 基础设施组件在部署后不被修改，替换而非修补。 | 一致性、可追溯、快速回滚 | SSH 登录修改、配置漂移 |
| Git 单一事实来源 | Git 仓库是集群期望状态的唯一权威存储与变更入口。 | 审计日志、协作基础、自动同步 | 直接操作集群、多源配置 |
1.2 核心理念关系图
下图展示了三大理念如何形成闭环：声明式配置定义期望状态，不可变基础设施保证状态一致性，Git 仓库作为两者之间的持久化锚点与变更驱动源。
1.3 声明式配置详解
声明式配置是 GitOps 的语言基础。团队只需在 Git 中维护一组描述系统最终状态的文件（如 Kubernetes Deployment、Service、ConfigMap），控制器负责将集群实际状态收敛至期望状态。
关键优势：
- 幂等性：同一份配置多次应用，结果始终一致。
- 可审查：所有变更通过 Pull Request 进行代码审查。
- 可回滚：回退到上一个 Git commit 即可恢复集群状态。
# 声明式配置示例：nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.25
ports:
- containerPort: 801.4 不可变基础设施
不可变基础设施要求：一旦部署，组件不再被修改。若需变更，则通过 Git 提交新配置，控制器销毁旧实例并创建新实例。这彻底消除了配置漂移和雪花服务器问题。
| 对比维度 | 可变基础设施 | 不可变基础设施 |
|---|---|---|
| 变更方式 | SSH 登录、手动修改 | 替换整个实例 |
| 一致性 | 随时间退化 | 始终与 Git 一致 |
| 回滚速度 | 慢（需逆向操作） | 快（直接切换镜像版本） |
| 审计能力 | 弱（依赖操作日志） | 强（Git 历史即审计日志） |
1.5 Git 作为单一事实来源
在 GitOps 模型中，Git 仓库不仅是代码存储，更是集群状态的权威数据库。所有对基础设施和应用的变更，都必须通过 Git 提交来驱动。控制器持续对比 Git 中的期望状态与集群实际状态，自动纠正偏差。
实践要点：
- 每个环境（dev/staging/prod）应有独立的 Git 分支或目录。
- 禁止直接通过 kubectl 或云控制台修改集群资源。
- 所有变更必须经过 Pull Request 流程，确保可追溯。
1.6 多团队协作中的理念落地
当多个团队共享同一 GitOps 流水线时，三大理念提供了协作基础：
- 声明式配置：每个团队维护自己的配置目录，通过清晰的目录结构避免冲突。
- 不可变基础设施：团队 A 的回滚不会影响团队 B 的服务，因为每个部署单元都是独立的不可变实例。
- Git 单一事实来源：所有团队的变更历史集中存储在 Git 中，便于跨团队审计和问题排查。
常见误区： 部分团队将 Git 仅当作“备份仓库”，仍然通过 CI 脚本直接修改集群。这违背了 GitOps 的核心理念——Git 必须是变更的唯一入口，而非事后记录。