GitOps声明式发布模型项目部署与灰度发布 - 第2节

声明式模型基础：声明式配置与命令式配置的区别

在 GitOps 和 Kubernetes 生态中，声明式（Declarative）与命令式（Imperative）是两种截然不同的运维与交付范式。理解二者的区别，是掌握声明式发布模型的前提。

核心概念对比

维度 命令式配置 声明式配置
操作方式 执行具体指令（create / delete / scale） 描述期望状态（apply / sync）
状态管理 手动跟踪当前状态，逐步操作 系统自动调和，持续趋近期望状态
可重复性 依赖操作顺序，易产生漂移 幂等执行，多次 apply 结果一致
审计能力 操作日志分散，难以追溯 配置即代码，版本化存储
故障恢复 需人工介入，重新执行命令 自动检测偏差并修复
典型工具 kubectl run / create / delete kubectl apply / kustomize / helm
关键认知：命令式关注"怎么做"，声明式关注"要什么"。GitOps 强制要求所有环境配置以声明式 YAML 形式存储在 Git 仓库中，集群持续从仓库拉取并调和。

命令式配置的典型场景与痛点

  • 临时调试：快速创建 Pod 测试连通性，kubectl run test --image=nginx
  • 紧急扩缩：kubectl scale deployment web --replicas=5
  • 直接修改：kubectl edit deployment web 手动修改运行中的资源

这些操作虽然快捷，但存在明显缺陷：操作不可追溯、环境状态与代码仓库脱节、多人协作时容易产生配置漂移。

声明式配置的幂等性与调和循环

声明式配置的核心机制是调和循环（Reconciliation Loop）。用户提交期望状态文件后，控制器持续对比当前状态与期望状态，自动执行差异操作。

# 声明式配置示例：期望运行 3 个副本的 Nginx
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
# 应用声明式配置（幂等执行）
kubectl apply -f deployment.yaml
实践建议：在 GitOps 工作流中，禁止直接使用 kubectl run 或 kubectl create 创建生产资源。所有变更必须通过 Git 提交 → CI 验证 → 自动 apply 的管道完成。

声明式API的概念

声明式 API 是 Kubernetes 和 GitOps 的底层设计哲学。它定义了一种面向意图的接口契约：用户提交资源对象的期望状态（Spec），系统通过控制器持续将其调整为实际状态（Status）。

声明式 API 的核心特征

  • 资源对象化：一切基础设施和应用配置都抽象为 API 资源（Pod、Service、Deployment、Ingress 等）
  • Spec / Status 分离：用户只填写 spec（期望），系统自动更新 status（实际）
  • 控制器模式：每个资源类型对应一个控制器，持续执行调和循环
  • 最终一致性：允许中间状态存在，系统保证最终达到期望状态

声明式 API 的工作流程

  1. 用户编写 YAML 文件，定义资源的期望状态（Spec）
  2. 通过 kubectl apply 或 GitOps 工具提交到 API Server
  3. API Server 验证并存储到 etcd
  4. 对应控制器（Controller）通过 Watch 机制感知变化
  5. 控制器执行调和逻辑，创建/更新/删除底层资源
  6. 控制器将实际状态回写到资源的 Status 字段
常见误解：声明式 API 不等于"写 YAML"。真正的声明式要求系统具备自动调和能力，而非仅仅将配置保存为文件。如果修改 YAML 后仍需手动执行命令才能生效，那仍然是命令式。

Kubernetes中的声明式模型

Kubernetes 本身就是声明式模型的典型实现。整个系统围绕期望状态驱动构建，从 Pod 调度到服务发现，从自动扩缩到滚动更新，全部遵循声明式 API 设计。

Kubernetes 声明式模型架构

Kubernetes 声明式模型架构 用户 / 开发者 期望状态 YAML API Server etcd 存储 控制器 (Controller) 调和循环 实际状态 调和循环说明 1. 控制器 Watch 期望状态 2. 对比当前实际状态 3. 执行差异操作（创建/更新/删除） 4. 持续循环，直到一致

声明式模型在 Kubernetes 中的具体体现

Kubernetes 组件 声明式特征 实际作用
Deployment 定义期望副本数、更新策略 自动创建 ReplicaSet，滚动更新 Pod
Service 定义标签选择器、端口映射 自动维护 Endpoint 列表
Ingress 定义域名、路由规则 自动配置反向代理
HPA 定义 CPU/内存阈值 自动扩缩 Pod 副本数
StatefulSet 定义有状态服务拓扑 自动管理 Pod 序号、存储卷

声明式模型带来的核心优势

  • 自愈能力：Pod 崩溃后自动重建，无需人工干预
  • 版本化回滚：Deployment 保留历史版本，支持一键回退
  • 渐进式交付：支持 RollingUpdate、Canary、Blue-Green 等发布策略
  • 多环境一致性：同一套 YAML 可部署到开发、测试、生产环境
  • 审计与合规：所有变更通过 Git 记录，满足合规要求
GitOps 实践要点：在 Kubernetes 声明式模型基础上，GitOps 增加了"Git 仓库作为单一事实来源"的约束。集群中的任何资源变更，都必须通过 Git 提交触发，而非直接操作 API Server。这进一步强化了声明式模型的可靠性和可审计性。

声明式 vs 命令式：实际场景对比

声明式 vs 命令式：扩缩容场景对比 命令式：手动执行 kubectl scale 步骤1：kubectl scale deploy web --replicas=5 步骤2：手动检查 Pod 是否启动 步骤3：如果 Pod 崩溃，再次手动创建 结果：操作不可追溯，易产生漂移 声明式：修改 YAML 并 apply 步骤1：修改 deployment.yaml replicas: 5 步骤2：git commit + git push 步骤3：GitOps 自动 apply，控制器自动调和 结果：版本化、可审计、自愈
迁移建议：从命令式迁移到声明式时，可以先从 Deployment 和 Service 开始，逐步将 ConfigMap、Secret、Ingress 等资源纳入 Git 管理。初期可以使用 kubectl apply --prune 清理未被 Git 管理的资源，确保集群状态与仓库完全一致。
← 上一章 📖 返回目录 下一章 →