告别 GitOps 翻车！7 招让 ArgoCD 稳如老狗

希望能给正在或即将上 GitOps 的兄弟们一些参考。七步法让 ArgoCD 更稳、更隔离、更可控之前的文章介绍了 ArgoCD 的基本用法但生产环境光会配还不够还得配得好。这次我们不讲概念直接上实战要点看看怎么让 ArgoCD 这个“GitOps 内核”跑得更稳。第一步别让它“饿死”也别让它“暴走”——资源限制要设好ArgoCD 本身也是个 Pod会消耗集群的 CPU 和内存。如果不设资源限制它可能会吃掉一个节点的所有资源影响集群上其他的业务 Pod。特别是在大规模集群或多集群模式下ArgoCD 的application-controller和repo-server的负载会比较高(我的 application-controller 一个 pod 16G 内存)资源限制和请求一定要配。我自己的经验是# argocd-cm.yaml 或者 Operator 的 spec server: resources: requests: cpu: 250m memory: 512Mi limits: cpu: 500m memory: 1Gi controller: resources: requests: cpu: 500m memory: 1Gi limits: cpu: 1 memory: 2Gi repoServer: resources: requests: cpu: 250m memory: 512Mi limits: cpu: 500m memory: 1Gi这个配置要根据你的集群规模和应用数量来调整但记住一个原则请求给足限制给够。第二步别跟原始 YAML 死磕——Helm 或 Kustomize 任选其一ArgoCD 本身不强制你用 Helm 还是 Kustomize但强烈建议不要直接管理原始的 YAML。直接维护原始 YAML 的缺点重复代码多特别是对于多环境dev/staging/prod的情况。容易出错一个环境改漏了DR 的时候就抓瞎了。更新维护困难版本管理复杂。推荐策略首选 Helm如果你是标准的应用发布有 Chart 仓库团队熟悉 Helm那就用 Helm。ArgoCD 对 Helm 的支持非常原生可以自动渲染 Chart。次选 Kustomize如果你更习惯 Kubernetes 原生的方式或者项目结构比较复杂比如有大量 overlayKustomize 也是个好选择。我个人更倾向于 Helm因为它的模板化能力更强而且生态更丰富比如 ArtifactHub 上有一堆现成的 Chart。但如果你做的是平台层面的配置如 CRD、OperatorKustomize 会更合适一些。第三步源代码和清单分开——权责分明安全第一这是一个很容易被忽略的点。很多人直接把应用代码和 ArgoCD 的Application清单放在同一个 Git 仓库里。这样做有什么问题生命周期不同应用代码每天都在变但 ArgoCD 的清单可能几周才改一次。把它们混在一起版本管理会很混乱。权限不清开发同学有代码仓库的写权限但他们不应该有修改Application资源的权限这可能会导致他们跳过审批直接上线。安全风险如果开发同学的仓库被黑攻击者可以借机修改 ArgoCD 的配置比如指向一个恶意的镜像仓库。最佳实践源代码Source Repo应用本身的代码仓库如 Java、Go 项目开发团队维护。清单库Manifest Repo存放 ArgoCD 的Application、AppProject、以及 Helm Chart 或 Kustomize 的 overlay 文件。由平台/SRE 团队维护严格控制写权限。第四步最大程度隔离——应用实例和平台实例分开这是 Red Hat 官方推荐的一个实践我认为是多租户场景下的核心要点。想象一下一个团队的应用Application资源被误删了导致整个 ArgoCD 的application-controller需要重新同步这个过程可能会影响到其他所有团队的应用部署。解决方案为不同的团队创建独立的 ArgoCD 实例。(当然, 也可以根据实际情况, 一个共享 ArgoCD 实例, 但是进行严格的 RBAC 权限限制.)apiVersion: v1 kind: Namespace metadata: name: team-a-gitops --- apiVersion: argoproj.io/v1alpha1 kind: ArgoCD metadata: name: team-a namespace: team-a-gitops spec: # 为 team-a 配置独立的 repo server, controller, dex server 等 server: route: enabled: true hostname: argocd-team-a.example.com repo: # 限制 team-a 只能访问哪些仓库 ...上面是 openshift 下基于 argocd operator 的yaml. 通常我们要创建多个实例, 直接使用 helm chart 来部署多个实例即可.注意这听起来有些重但在企业级场景下非常值得。每个实例都是自治的一个团队的“瞎搞”不会影响集群的配置或别人的应用。第五步警惕声明式配置的“隐形陷阱”ArgoCD 靠声明式配置Application、AppProjectCRD来管理。但这里有个坑期望状态 ≠ 实际状态。比如你配了一个Application希望它创建三个Deployment。但如果你在 Git 仓库里删了一个Deployment的 YAML 段ArgoCD 会把它删掉。但如果有人在集群里手动kubectl edit改了某个字段ArgoCD 会把它拉回 Git 里的状态。那问题在哪配置漂移的源头不止一个除了 Git 仓库还有 ArgoCD 本身的 Web UI 和 CLI 可以直接修改。如果有人比如我自己有手误用 UI 手动改了syncPolicy而忘记提交 Git那这个期望状态和 Git 仓库就不一致了。Application本身也会漂移想象一下你通过 Web UI 修改了Application的某个参数比如targetRevision指向不同的分支这个修改是不会自动同步回 Git 的。我的建议All-in Git所有对 ArgoCD 配置的修改必须从 Git 仓库发起。Web UI 只用来查看状态和手动触发同步。用argocd app diff检查在 CI/CD 流程中可以加一步脚本来运行argocd app diff跟 Git 仓库对比确保没有意外的配置漂移。监控 ArgoCD 自身用 Prometheus 监控 ArgoCD 的指标比如argocd_app_info如果某个Application的状态变成了OutOfSync就触发告警。或者用 ArgoCD 的 notifications-controller 来发送告警通知。第六步多人协作时AppProject 是黄金搭档权限管理在多团队场景下是必选项。AppProject就是干这个的。apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: team-b-project namespace: argocd spec: sourceRepos: - https://gitlab.example.com/team-b/* # 只能从 team-b 的仓库拉 destinations: - namespace: team-b-* # 只能部署到 team-b 相关的命名空间 server: https://kubernetes.default.svc clusterResourceWhitelist: - group: * kind: * namespaceResourceWhitelist: - group: * kind: *AppProject可以严格控制谁sourceRepos能拉什么代码哪里destinations能部署能创建什么资源clusterResourceWhitelist/namespaceResourceWhitelist说实话这是 GitOps 多租户的基石少了它后面的隔离全是空谈。第七步不要迷信“最佳实践”最后想吐槽一句。网上有很多现成的“ArgoCD 最佳实践”模板但这玩意儿不能直接套用。Red Hat 的专家也说了要根据你的组织结构和 YAML 管理工具来调整。如果你们团队结构扁平项目简单一个 ArgoCD 实例 Helm/Kustomize 就够用了。如果你们是平台团队服务多个业务单元那必须上多实例 AppProject 严格的权限控制。如果你们还在用原始 YAML别急着上 Kustomize先评估一下切换成本。声明本文所有实践建议都来自我个人的生产实践和 Red Hat 官方推荐不要无脑抄要理解背后的原理。总结ArgoCD 是一个很牛的工具但用好它不光是要会配更是要对 GitOps 的设计原则有深入理解。资源限制防止一台机器被吃掉。工具选择Helm 或 Kustomize别自己手写 YAML。仓库分离源代码和清单库分开。