ArgoCD 是用 Go 编写的 Kubernetes GitOps 控制器，部署需正确配置 IRSA 权限、确保 Git 路径已提交、依赖 argocd-image-updater 实现镜像更新同步，并严格遵循 GitOps 原则。

ArgoCD 不是 Go 服务，它不“用 Golang 部署”，而是用 Go 写的、运行在 Kubernetes 上的 GitOps 控制器。你真正要做的，是把 ArgoCD 作为基础设施组件部署进集群，并让它能可靠地同步你用 Go 编写的微服务——这个过程的关键不在语言，而在路径、权限和同步节奏。

ArgoCD 安装失败常见于 EKS/AWS 权限链断裂

不是 Helm 命令写错了，而是 ServiceAccount 没绑定 IAM Role。EKS 上 argocd-server 和 argocd-application-controller 默认用 default SA，但生产必须用 IRSA（IAM Roles for Service Accounts）。

• 先创建 OIDC Provider 并关联 EKS Cluster（aws eks describe-cluster --name xxx --query "cluster.identity.oidc.issuer"）
• 为 argocd namespace 创建 annotated SA：eksctl create iamserviceaccount --name argocd-server --namespace argocd --cluster xxx --attach-policy-arn arn:aws:iam::xxx:policy/ArgoCD-ClusterAdmin --approve
• 安装时显式指定 SA：helm install argocd argo/argo-cd --set server.serviceAccount.name=argocd-server --set controller.serviceAccount.name=argocd-application-controller
• 跳过这步，你会看到 AccessDenied: User: anonymous 或 Unauthorized，但错误只出现在 Application 同步日志里，不是 Helm 输出

Application 资源指向空目录或未提交路径就报 failed to load manifests

spec.source.path 必须是 Git 仓库中**已 git push** 的子目录，且该目录下至少有一个合法 YAML 文件。ArgoCD 不读本地工作区，也不等你 git add 完再拉取。

• 错例：spec.source.path: "manifests/prod" → 但该目录只在你本地，没 git commit -m "add prod manifests" 推送
• 错例：spec.source.path: "." → 根目录下只有 go.mod 和 main.go，没有 Deployment.yaml
• 正确做法：确保 manifests/prod/deployment.yaml 已提交，且能被 kubectl apply -f manifests/prod/ 直接执行
• 验证命令：argocd app get myapp --show-labels 看 status.sync.status；若为 Pending 或 Unknown，先 argocd repo list 确认仓库连通性

Go 应用镜像更新后 Argocd 不自动同步？autoSync 只监听 Git，不监听 Registry

syncPolicy.automated 只响应 Git 仓库的 commit 变更，不会感知 Docker Registry 里新 push 的镜像 tag。想实现“镜像一更新，环境自动升级”，必须引入外部工具。

Software Data Github Interact Developer Helper

帮助用户满足已验证需求：代理用户在Clawhub上对GitHub式工作流有强烈需求，需要实用帮助修复bug、强化设置。

下载

• 用 argocd-image-updater：它轮询 registry（支持 Docker Hub、ECR、GHCR），找到匹配规则的 tag 后，自动 patch Application 的 spec.source.kustomize.images 字段并触发 Git 提交
• Go 项目需配合：Deployment 中不能写死 image: myapp:v1.2.3，改用 Kustomize 变量 images: [{name: myapp, newName: myapp, newTag: v1.2.3}]，否则 updater 找不到可替换位置
• 别指望 CI 脚本直接 kubectl set image —— 这绕过 Git，破坏 GitOps 不可变性，ArgoCD 会立刻把它 sync 回去
• 检查 argocd-image-updater 日志是否出现 no matching applications found：多半是 Application 的 label 没和 updater 的 applicationSelector 对上

本地开发时 argocd app sync 报 PermissionDenied？CLI 绕过了 ArgoCD RBAC

argocd app sync 默认直连 Kubernetes API Server，不走 ArgoCD 自己的鉴权层。你在 UI 里给用户分配了 admin 角色，但 CLI 仍可能失败。

• 正确做法：用 argocd login <host> --sso</host> 或 --grpc-web 模式登录，让请求经由 argocd-server 代理
• 避免用 kubeconfig 直连：CLI 会忽略 ArgoCD 的 RBAC，只看 kubeconfig 里的 ServiceAccount 权限
• 临时调试可加 --insecure，但生产禁用；真正要配的是 argocd-rbac-cm ConfigMap，明确授予 applications, sync 权限
• 一个典型坑：CI 流水线用 argocd app sync 失败，其实是因为流水线用的 SA 没 argoproj.io/applications 的 update 权限，不是网络或证书问题

ArgoCD 的“高透明”不来自 UI 刷新频率，而来自每一步变更都落在 Git 提交里——包括它自己同步失败时生成的 ComparisonError 字段、health.status 的变化、甚至 argocd-image-updater 的 patch commit。最容易被忽略的，是以为 autoSync = 自动一切，其实它只管 Git 这一层，下面的镜像、配置、健康探针，全得靠你按云原生契约去对齐。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！