Argo CD 的 Application 资源需规范编写以避免 OutOfSync：spec.source.path 指向 Helm/Kustomize 目录而非 Go 源码；Kustomize 中 images 字段须与 CI 推送的镜像 tag 或 digest 一致；禁用硬编码 namespace，改用 spec.destination.namespace 和 automating 策略；确保 probe 配置合理且路径轻量；依赖 argocd-image-updater 实现自动镜像更新；排查同步失败时优先检查 Application 状态字段及 Pod 日志。
Argo CD 的 Application 资源怎么写才不会卡在 OutOfSync
Go 项目用 Argo CD 做 GitOps，最常卡在 OutOfSync 状态——不是部署失败，而是 Argo CD 自己“看不懂”你提交的 YAML。根本原因通常是 Application 定义里没对齐 Go 应用的真实交付形态。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
spec.source.path必须指向 Helm chart 或 Kustomize 目录，不是 Go 源码根目录；Go 编译和镜像构建该由 CI 完成，Argo CD 只管部署已构建好的 manifests - 如果用 Kustomize，确保
kustomization.yaml中的images:字段与 CI 推送的镜像 tag 一致，Argo CD 不会自动替换latest或变量 - 避免在
Application里硬编码namespace；改用spec.destination.namespace+spec.syncPolicy.automated.allowEmpty=false防误删 - 常见错误现象：
ComparisonError: failed to load params—— 多半是 Kustomize 版本不匹配（Argo CD v2.9+ 默认用 kustomize v5，但本地可能还是 v4）
Go 服务的 livenessProbe 和 readinessProbe 怎么设才不被 Argo CD 反复重启
Argo CD 同步时若发现 Pod 长期 CrashLoopBackOff，会不断重试，但问题往往不在 Argo CD，而在 Go HTTP 服务的健康检查配置没适配 GitOps 流程。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- Go 服务启动后需预留缓冲时间再开放 probe 端点，否则 Argo CD 同步触发的首次部署极易因
connection refused导致 probe 失败 - 用
initialDelaySeconds: 10+periodSeconds: 5，别依赖startupProbe（Argo CD v2.8 之前对 startupProbe 支持不稳定） - probe 路径别写成
/healthz这类需额外中间件注册的路由；直接用http.HandleFunc("/ready", ...)，确保最小依赖 - 性能影响：probe 频率太高（如
periodSeconds: 1）会让 Go 服务在低配环境 CPU 尖刺，Argo CD 日志里表现为Failed sync attempt但无具体错误
如何让 Argo CD 自动感知 Go 项目镜像更新（不用手动改 image tag）
手动改 image: myapp:v0.1.2 再提交，违背 GitOps 原则。Argo CD 本身不扫描镜像仓库，必须靠外部机制注入新 tag。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
argocd-image-updater工具，它监听 Docker Registry 的 webhook 或轮询，然后 patchApplication的spec.source.kustomize.images - Go 项目 CI 构建镜像后，必须推送
sha256digest（如myapp@sha256:abc123...），而非仅 tag；digest 才能保证 Argo CD diff 出真实变更 - 别在
kustomization.yaml里用replacements:动态替换 image —— Argo CD 不执行 Kustomize 的 replacements 逻辑，只认images:字段 - 兼容性注意：argocd-image-updater v0.4+ 才支持 Go 模块式项目常用的
ghcr.io和私有 Harbor，旧版会静默跳过
argocd app sync 失败时，怎么快速定位是 Go 代码问题还是 Argo CD 配置问题
同步失败日志里一堆 Kubernetes event 和 Go panic，容易误判。关键看 Argo CD 的 Application 状态字段和底层 Pod 日志来源。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先查
argocd app get <appname>输出里的Status和Health：若Status是Unknown但Health是Missing，说明 Argo CD 根本没生成任何资源 —— 问题在spec.source路径或 Kustomize 解析 - 若
Health是Progressing或Degraded，进对应 namespace 查 Pod：kubectl logs deploy/<my-go-app> -c manager --previous（Go 服务 panic 会在这里，不是 Argo CD 的日志里） - Argo CD 自身报错如
rpc error: code = InvalidArgument desc = application spec is invalid，基本是ApplicationYAML 语法错，比如destination缺了server - 容易被忽略的点：Go 二进制若用
CGO_ENABLED=0编译，但容器 base image 是alpine，可能因缺少/etc/ssl/certs导致 HTTPS 请求失败 —— 这类错误只在 Pod 日志里出现，Argo CD 看不到
