gMpHSpLB/GitOps-Platform-Engineering-ArgoCD

# 项目： ### “GitOps 平台工程：运维生产级 ArgoCD 实例，实现应用生命周期管理、偏差检测与同步策略控制” ## GitOps 的含义 GitOps 是一种运维模型，其中每个系统的期望状态都在 Git 中声明，并且自动化 agent 会持续确保实际状态收敛于期望状态。它不是一个工具——而是一套原则。ArgoCD 是这些原则在 Kubernetes 上的实现。 四项 GitOps 原则 (OpenGitOps 1.0.0)： 1. 声明式：整个系统以声明式进行描述 2. 版本控制且不可变：期望状态的存储方式强制要求不可变性和版本控制 3. 自动拉取：软件 agent 自动拉取期望状态声明 4. 持续协调：软件 agent 持续观察实际系统状态并尝试应用期望状态 ### 期望状态与实际状态 ## ArgoCD 架构 ``` argocd-server → UI and API server. Handles user/CI requests. argocd-repo-server → Clones Git repos, renders Helm/Kustomize manifests. Runs in isolation — no cluster access. argocd-application-controller → The heart of ArgoCD. Watches Applications in etcd. Compares desired (Git) vs actual (cluster). Triggers syncs. argocd-dex-server → OIDC provider for SSO integration. ``` ### ArgoCD 架构图 ## 资源在实践中如何连接：在 Helm + ArgoCD workflow 中 ```console Developer writes code → CI builds image (sha256:abc) → pushed to registry → CI commits "feat: bump image to sha256:abc" to GitOps repo → CI has NO cluster access — its job is done ArgoCD repo-server 检测到新的 commit（watch 事件或 180 秒轮询） → 在新的 HEAD 处克隆 GitOps repo → 运行：helm template myapp ./charts/myapp -f values-prod.yaml → 将渲染后的 YAML 发送到 app-controller → app-controller 对比渲染后的（期望）状态与集群实时（实际）状态 → 发现差异：image tag 发生改变 → 如果已自动化 → ArgoCD 调用 argocd-server → kubectl apply patch → Kubernetes 使用 sha256:abc 滚动部署新的 pod → app-controller 重新获取实时状态 → 已同步 + 健康 → 向 Slack 发送通知 ``` ## sync loop — 每 3 分钟（默认）实际发生的事情： ```console 1. argocd-application-controller reads Application object from etcd (etcd is a distributed, strongly consistent key-value store used to store critical cluster data, especially in Kubernetes. It acts as Kubernetes’ backing store for cluster state, configuration, and metadata.) 2. Sends render request to argocd-repo-server: "Clone this Git URL at this revision, run helm template with these values" 3. argocd-repo-server renders manifests, returns rendered YAML 4. Controller fetches live state from cluster API for all resources in that namespace 5. Controller diffs rendered YAML (desired) vs live state (actual) 6. If diff exists → Application status = OutOfSync 7. If sync policy = automated → Controller calls argocd-server to apply 8. argocd-server calls kubectl apply on the diff 9. Cluster reconciles 10. Controller re-fetches live state → if matches desired → Synced ``` ## 基于 ArgoCD 的 GitOps 工作流图 ## ArgoCD 不会做的事： ``` • It does not replace Helm. It calls Helm's template engine to render manifests. • It does not store application state. The Git repo is the state. • It does not automatically redeploy on image changes (that's an image updater or CI push). • It does not encrypt secrets. That is External Secrets Operator's job. ``` ## ArgoCD 强制执行的 GitOps 契约： ``` • Git is the only source of truth • Any manual kubectl apply or kubectl edit to a managed resource is overwritten on next sync • Deletion from Git means ArgoCD can prune (delete) the resource from the cluster — if pruning is enabled ```

标签：ArgoCD, GitOps, 子域名突变, 平台工程, 持续交付, 网络安全研究