📚 课程目录第1章 GitOps核心理念

1. GitOps 核心理念：声明式配置、不可变基础设施、Git 作为单一事实来源

GitOps 是一种以 Git 仓库为运维与交付中心的现代化运维模式。其核心在于将运维与部署的“期望状态”全部声明在 Git 中，并通过自动化机制持续将实际环境向该期望状态收敛。理解 GitOps 的三个核心理念，是掌握后续发布窗口与分支晋级机制的基础。

1.1 三大核心理念概览

理念	核心含义	对发布流水线的价值
声明式配置	描述系统“应该是什么状态”，而非“如何达到该状态”。	发布内容即代码，可审计、可回滚、可复现。
不可变基础设施	部署单元（容器、虚拟机）一旦创建，不再原地修改；更新时直接替换。	消除配置漂移，确保发布窗口内环境一致性。
Git 作为单一事实来源	所有环境（开发、预发、生产）的期望状态均以 Git 仓库中的声明为准。	分支晋级、回滚、审批均基于 Git 提交历史，形成完整审计链。

实践要点： 在 GitOps 模式下，任何手动修改线上环境的行为都应被视为“事故”。所有变更必须通过 Git 提交触发，再由 Operator 或 CI/CD 系统自动同步。

1.2 声明式配置 vs. 指令式配置

声明式配置是 GitOps 的基石。以下对比可帮助理解其差异：

维度	指令式配置	声明式配置
操作方式	执行一系列命令（如 `kubectl run`、`kubectl scale`）	提交一份 YAML 描述文件（如 `Deployment`、`Service`）
状态管理	系统状态由命令执行顺序决定，易产生漂移	系统持续向 Git 中的期望状态收敛，自动修复漂移
回滚方式	需逆向执行命令或手动恢复	直接 revert Git 提交，Operator 自动同步旧状态
审计能力	依赖操作日志，难以追溯完整变更链	每次变更对应一次 Git commit，天然具备完整审计链

# 指令式示例：手动创建并暴露应用
kubectl create deployment my-app --image=my-app:v1
kubectl expose deployment my-app --port=80 --type=LoadBalancer

# 声明式示例：提交 YAML 到 Git，Operator 自动同步
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v1
        ports:
        - containerPort: 80

1.3 不可变基础设施：消除“配置漂移”

在传统运维中，服务器运行时间越长，手动补丁、临时修改、依赖升级导致的“配置漂移”越严重。不可变基础设施要求：

每次部署创建全新实例：发布新版本时，直接基于新镜像启动新 Pod/VM，旧实例被销毁。
禁止运行时修改：不允许 SSH 进入容器修改配置、安装包或打补丁。
版本与镜像强绑定：每个部署版本对应一个不可变的容器镜像或虚拟机镜像。

  发布窗口中的意义： 在分支晋级回归检查阶段，不可变基础设施确保“测试环境验证通过的镜像”与“生产环境即将运行的镜像”完全一致，杜绝“在我机器上是好的”这类问题。

1.4 Git 作为单一事实来源：分支晋级的基础

Git 仓库中存储了所有环境的期望状态声明文件。发布流水线中的“分支晋级”本质上是将某个 Git 分支（如 release/v1.2）的声明合并到代表更高环境的分支（如 production）。

1.5 三者协同：发布流水线的信任链

在 GitOps 发布流水线中，三个理念形成闭环：

声明式配置 将发布内容标准化为 YAML/JSON 文件，存储在 Git 中。
不可变基础设施 确保每次发布使用全新的、与声明完全一致的运行环境。
Git 作为单一事实来源 提供分支晋级、审批、回滚的完整审计轨迹。

常见误区： 有些团队虽然使用了 Git 仓库，但仍然允许运维人员通过 kubectl edit 或控制台直接修改线上资源。这种做法破坏了“Git 作为单一事实来源”的原则，导致 Git 中的声明与实际环境不一致，回归检查失去意义。