FluxCD 不是开箱即用的黑盒，需明确配置同步内容；Golang项目镜像、配置和健康信号须符合Flux规则，否则同步失败或卡在Ready状态。
FluxCD 不是“装上就能自动同步”的黑盒，它只同步你明确告诉它要同步的东西；Golang 项目本身不参与 Flux 工作流，但它的镜像版本、部署配置和健康信号必须按 Flux 的规则组织，否则同步会卡在 Ready 状态或根本看不到资源。
flux get kustomization 返回空？先确认 kustomize-controller 是否真在运行
常见错误现象是：YAML 已推到 Git 仓库，flux create kustomization 命令也执行成功，但 flux get kustomization 什么也不返回。这不是网络或权限问题，而是控制器没起来。
-
kubectl -n flux-system get pods查看kustomize-controllerPod 是否 Running；如果不存在，说明你用的是精简安装（比如只装了source-controller），得手动补上：flux install --components=source-controller,kustomize-controller,notification-controller - CRD
kustomizations.kustomize.toolkit.fluxcd.io必须存在，否则flux create实际没注册资源类型——kubectl get crd | grep kustomize验证 - Flux v2 默认启用所有控制器，但如果你用
flux bootstrap时加了--components参数却漏掉kustomize-controller，它就不会监听你写的Kustomization资源
Kustomization.spec.path 必须指向含 YAML 的子目录，不能写成 . 或 /
Flux 不会递归扫描整个 Git 仓库，它只拉取 spec.path 指定路径下的文件。Go 项目常把 manifests 放在 deploy/production/ 或 infrastructure/base/ 下，路径写错就等于没配置。
- 正确写法：
spec.path: ./deploy/staging（注意开头的./，相对仓库根目录） - 错误写法：
spec.path: "."或spec.path: ""—— Flux 会静默跳过，不报错也不同步 - 如果用 Kustomize，确保该路径下有
kustomization.yaml，且它能成功kustomize build出 Deployment/Service 等资源；Flux 内部调用的就是这个命令 - 路径里不能有未提交的本地修改；Flux 只读 Git commit，不是工作区
Go 服务镜像更新失败？检查 images 字段是否被 Flux “看见”
Flux 的 image-automation-controller 只能替换两类位置的镜像字段：Kustomize 的 images: 块、Helm 的 values.yaml 中模板变量。硬编码在 Deployment YAML 里的 image: my-go-app:v1.2.0 它完全无视。
立即学习“go语言免费学习笔记（深入）”；
- 必须把 Go 镜像抽出来：
kustomization.yaml中加images:块，例如：images: - name: ghcr.io/myorg/my-go-app newTag: v1.2.0
- CI 构建完镜像后，要触发
image-automation-controller提交更新：确保ImageUpdateAutomation资源的spec.gitRepository指向存放kustomization.yaml的仓库，且spec.commit.template非空（如"{{.Revision}} update image"） - Go 的 tag 若含
+（如v1.2.0+g8a3b4c），默认 semver 正则^v?(\d+\.\d+\.\d+)$不匹配——改spec.policy.semver.range为^v?(\d+\.\d+\.\d+\+?[a-z0-9]*)$，或换用glob策略
Flux 报 Ready，但 Go 服务 503？健康检查没对齐
Flux 的 Ready 状态只表示 Kubernetes 资源已创建成功（Deployment 已 rollout、Pod 处于 Running），不代表 Go HTTP 服务已真正就绪。一个启动慢的 http.Server 可能还在加载配置或连接数据库，但 readiness probe 已开始探测。
- Go 服务的
readinessProbe不要设太短：initialDelaySeconds: 15+periodSeconds: 10是较安全起点 - probe endpoint（如
/healthz）必须真实反映服务状态：不能只 return 200，要检查 DB 连接、缓存初始化等关键依赖 - Flux 不管 probe 结果，但 ArgoCD 或监控系统会；若你用
flux reconcile kustomization强制同步，它不会等 probe 成功才标记 Ready - 生产环境建议加
startupProbe，避免 readiness/liveness 在启动期误杀进程
Flux 同步逻辑极简，但它对 Git 结构、YAML 组织和 Go 服务可观测性要求很具体；最容易被忽略的是控制器缺失和镜像字段位置——这两点不解决，后面所有自动化都只是假象。
