GitOps：以 Git 为唯一可信源管理基础设施与 Kubernetes

1. 重新定义 GitOps：超越流水线自动化

在云原生运维中，GitOps 常常被简单误解为“在 CI/CD 流水线中执行部署脚本”或“把 YAML 文件放进 Git 仓库”。当代码合并时，由外部 CI 工具（如 GitHub Actions 或 GitLab CI）触发执行 kubectl apply，这属于典型的基于推送（Push-based）的自动化部署，而非严谨意义上的 GitOps。

根据 CNCF OpenGitOps 工作组的定义，GitOps 是建立在四大核心原则之上的现代化运维模式：

1. 声明式系统描述（Declarative Descriptions）：基础设施资源、网络拓扑、应用部署、安全策略与配额均采用声明式清单进行定义。
2. 版本化且不可变的状态存储（Versioned & Immutable State）：Git 作为唯一的单一可信源（Single Source of Truth, SSOT），所有状态声明具有版本控制、不可篡改性与加密审计追踪。
3. 自动化拉取与状态收敛（Automated State Pull）：运行在集群内部的调和代理（In-cluster reconciliation agent）自动轮询或监听变更，以最小权限将声明拉取并应用至本地，无需外部暴露管理员凭证。
4. 持续状态调和与漂移检测（Continuous Reconciliation & Drift Detection）：代理保持连续的闭环控制，持续比对集群实际运行状态（Actual State）与 Git 中的期望状态（Desired State），主动发现并自愈带外手动修改。

+-------------------------------------------------------------------------+
|                                开发者工作空间                             |
|  git commit -m "feat: scale catalog replicas" && git push               |
+-----------------------------------+-------------------------------------+
                                    |
                                    v
+-------------------------------------------------------------------------+
|                         Git 仓库（单一可信源 SSOT）                        |
|  - manifests/base/catalog.yaml                                          |
|  - overlays/production/kustomization.yaml                              |
+-----------------------------------+-------------------------------------+
                                    |
          调和循环（集群内部）          | Git Poll / Webhook (拉取模式 Pull)
          In-Cluster Agent          v
+-------------------------------------------------------------------------+
|                  Kubernetes 集群 Ingress / 控制平面                       |
|                                                                         |
|  +---------------------+         比对          +---------------------+  |
|  |   GitOps 控制器      | --------------------> | 集群实际运行状态      |  |
|  |  (Argo CD / Flux)   | <-------------------- | (Kube API)          |  |
|  +---------------------+        漂移检测        +---------------------+  |
|             |                                             ^             |
|             +-------- 自动同步 / 自动修复 (Self-Heal) -------+             |
+-------------------------------------------------------------------------+

核心架构对比：推模式（Push） vs. 拉模式（Pull）

• 推模式：外部 CI 系统必须长期存储生产集群的高权限凭证（kubeconfig）。一旦 CI 平台遭遇供应链攻击，整个集群将完全失守；且若管理员在生产环境中执行 kubectl edit，CI 无法察觉配置漂移。
• 拉模式：凭证永不流出集群，集群内控制器以只读权限拉取 Git 仓库。任何未授权的生产手动变更都会被立即检测并被 Git 期望状态强制覆盖。

2. 基于 Kustomize 的多环境声明管理

使用 Base 与 Overlay 结构能够消除多环境配置的模板膨胀与复制粘贴风险：

# apps/ecommerce-service/overlays/production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ../../base

namespace: ecommerce-production

images:
  - name: ghcr.io/ladestack/ecommerce-service
    newTag: v2.14.0

patches:
  - target:
      kind: Deployment
      name: ecommerce-service
    patch: |-
      - op: replace
        path: /spec/replicas
        value: 12

3. Argo CD 与 Flux CD 架构选型

• Argo CD：提供功能强大的可视化 Web 控制台、完善的企业级 SSO/RBAC 支持，极度适合作为面向业务研发团队的自服务 PaaS 平台。
• Flux CD：遵循 Unix 哲学的高内聚微控制器架构，纯声明式无默认前端，深度契合边缘计算集群及基础设施底层管理。

4. 密钥管理与生产回滚考量

• 密钥安全：严禁将明文 Secret 存入代码库。推荐采用 Sealed Secrets（本地公钥加密提交）或 External Secrets Operator（与 Vault、云密钥管理服务集成动态下发）。
• 回滚边界：Git 回滚代码并不能自动逆转具有破坏性的数据库结构变更，必须配合“扩展-收缩（Expand-Contract）”无损数据库迁移模式以保障业务高可用。