📚 课程目录第1章 GitOps理念概述

1. GitOps 理念概述

1.1 GitOps 的定义

GitOps 是一种以 Git 仓库作为单一事实来源（Single Source of Truth）的云原生运维模式。它将整个系统的期望状态声明式地存储在 Git 仓库中，并通过自动化机制持续确保实际运行环境与仓库中定义的期望状态保持一致。

  核心思想：Git 仓库不仅是代码的版本控制工具，更是整个基础设施和应用程序配置的权威来源。任何对环境的变更都必须通过修改 Git 仓库中的声明式配置来触发。

1.2 GitOps 核心原则

GitOps 建立在三大核心原则之上，这些原则共同构成了其与传统运维模式的根本区别：

原则	描述	关键实践
声明式	系统期望状态以声明式配置文件描述，而非命令式脚本	使用 Kubernetes YAML、Helm Chart、Kustomize 等声明式工具
版本控制	所有声明式配置存储在 Git 仓库中，具备完整变更历史	分支策略、Pull Request 审查、标签与回滚
自动化	自动化工具持续对比实际状态与期望状态，并自动调和差异	Flux CD、Argo CD 等 GitOps Operator 自动同步

1.3 声明式 vs 命令式

声明式配置是 GitOps 的基石。以下对比展示了声明式与命令式在 Kubernetes 环境中的差异：

维度	命令式（Imperative）	声明式（Declarative）
操作方式	执行具体命令（如 `kubectl run`）	提交配置文件（如 `kubectl apply -f`）
状态管理	状态隐式存在于集群中，难以追踪	状态显式定义在文件中，可审计可复现
变更回滚	需手动执行反向操作	通过 Git revert 即可自动回滚
可重复性	依赖操作者经验和环境上下文	任意环境均可复现相同配置

# 命令式示例：直接创建 Deployment
kubectl create deployment nginx --image=nginx:1.25

# 声明式示例：定义期望状态文件
# 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

1.4 GitOps 自动化工作流

GitOps 的自动化机制通过“观察-比较-调和”的闭环确保环境一致性：

1.5 GitOps 与传统 CI/CD 对比

传统 CI/CD 与 GitOps 在架构理念和运维模式上存在本质差异：

对比维度	传统 CI/CD	GitOps
配置存储	配置分散在 CI 脚本、配置中心、数据库	所有配置统一存储在 Git 仓库
部署触发	CI 工具（Jenkins/GitLab CI）推送至集群	Operator 从 Git 拉取并自动调和
状态一致性	依赖 CI 执行结果，可能因网络/权限导致不一致	持续调和，自动修复漂移
回滚方式	重新执行旧版本 CI 流水线或手动操作	Git revert 提交，Operator 自动回滚
安全模型	CI 工具需要集群凭证，存在安全风险	Operator 使用最小权限，无需外部系统凭证
审计追踪	分散在 CI 日志、聊天记录、邮件	Git 提交历史即为完整审计日志

实践建议：GitOps 并非完全取代 CI/CD，而是重新定义了部署阶段的责任边界。CI 阶段（构建、测试、镜像推送）仍可使用传统 CI 工具；CD 阶段（环境同步、配置管理）则交由 GitOps Operator 接管。

1.6 GitOps 的典型适用场景

多环境 Kubernetes 部署：开发、测试、预发布、生产环境通过不同分支或目录管理
基础设施即代码（IaC）：管理 Terraform、Crossplane 等基础设施配置
策略与安全配置：OPA/Gatekeeper 策略、网络策略、RBAC 配置的版本化管理
边缘与多集群管理：统一控制面管理分布在不同区域的集群

注意事项：GitOps 要求团队具备 Git 工作流规范（分支策略、PR 审查、签名提交）。对于需要紧急热修复的场景，需建立完善的审批与回滚机制，避免绕过 Git 直接操作集群。