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"） - 为
argocdnamespace 创建 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。想实现“镜像一更新，环境自动升级”，必须引入外部工具。
立即学习“go语言免费学习笔记（深入）”；
- 用
argocd-image-updater：它轮询 registry（支持 Docker Hub、ECR、GHCR），找到匹配规则的 tag 后，自动 patchApplication的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-cmConfigMap，明确授予applications, sync权限 - 一个典型坑：CI 流水线用
argocd app sync失败，其实是因为流水线用的 SA 没argoproj.io/applications的update权限，不是网络或证书问题
ArgoCD 的“高透明”不来自 UI 刷新频率，而来自每一步变更都落在 Git 提交里——包括它自己同步失败时生成的 ComparisonError 字段、health.status 的变化、甚至 argocd-image-updater 的 patch commit。最容易被忽略的，是以为 autoSync = 自动一切，其实它只管 Git 这一层，下面的镜像、配置、健康探针，全得靠你按云原生契约去对齐。
