用 client-go Informer 监听 Deployment/DaemonSet 的 image 字段变更，结合 annotations 解析变更来源，拼接完整镜像地址，区分飞书/Slack 消息格式，配置多集群隔离与错误兜底。
怎么让 Go 程序监听 Kubernetes 镜像变更
核心是绕过轮询，用 Watch API 实时捕获 ImageStream（OpenShift）或更通用的 Deployment/DaemonSet 的 image 字段变化。K8s 原生没有“镜像更新事件”，得从工作负载对象的 spec.template.spec.containers[*].image 变化反推。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
client-go的Informer（不是原始Watch），它自动重连、缓存、去重，避免自己处理410 Gone或资源版本错乱 - 监听范围别设太宽：限定
Namespace（比如只看production），否则集群大时 Informer 同步慢、内存涨得快 - 注意
Deployment的revisionHistoryLimit会影响旧 ReplicaSet 清理，但不影响 Watch——只要对象没被删，变更就能捕获 - 别直接比对
image字符串：带 digest 的（如nginx@sha256:abc...）和 tag 的（如nginx:latest）要归一化处理，否则同个镜像换种写法会被当成两次更新
Slack/飞书通知里怎么填对镜像来源和变更详情
光说“xxx Deployment 镜像变了”没用，运维需要立刻知道：谁改的？改前啥样？是不是自动流水线触发的？
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 从
Deployment的annotations里捞线索：CI/CD 工具（如 Argo CD、Jenkins）常写ci.jenkins.io/job-name或argocd.argoproj.io/tracking-id -
image字段值本身不带 registry 地址上下文，得结合metadata.namespace和集群配置的默认 registry（比如harbor.example.com/prod/）拼出完整拉取地址 - 飞书卡片和 Slack Block Kit 渲染逻辑不同：飞书要求
elements是数组且必须有tag字段；Slack 的blocks里type必须小写（"section"不是"Section"），错一个就整个消息发不出 - 别在通知里暴露敏感信息：过滤掉
registry密码、token类 annotation，用正则删掉.*secret.*键名
为什么 Go 机器人跑着跑着就卡住不发消息了
常见不是代码 bug，而是 K8s 客户端连接生命周期没管好，或者通知渠道限流没兜底。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
Informer启动后必须调WaitForCacheSync，否则第一次 List 拿到的可能是空缓存，Watch 就收不到任何事件 - Slack Webhook 超时默认 3 秒，飞书是 5 秒；Go 默认 HTTP client 没设超时，遇到网络抖动会卡死 goroutine。必须显式设
Timeout和MaxIdleConnsPerHost - K8s APIServer 对单 client 的 QPS 有限制（默认 5qps），如果 Informer 监听多个资源类型又没做
ResyncPeriod控制，容易被限流返回429 Too Many Requests，此时要检查rate.Limiter配置 - 日志别只打 “send failed”：一定要把
http.StatusCode、response.Body前 200 字（防泄露）一起记下来，否则飞书返回{"StatusCode":400,"StatusMsg":"invalid msg"}根本没法 debug
如何安全地支持多集群、多通知渠道混用
一个机器人管 3 个集群 + Slack + 飞书，配置稍错就会消息发串、权限错配、甚至误删资源。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个集群用独立的
rest.Config和Clientset，别复用；Config里Host和BearerToken必须一一对应，混用会导致 403 - 渠道配置走环境变量而非硬编码：
SLACK_WEBHOOK_URL_prod、FEISHU_WEBHOOK_URL_staging，启动时按CLUSTER_NAME环境变量动态选 - 飞书要求
timestamp和sign签名，Slack 不需要——别把飞书签名逻辑套到 Slack 上，否则 webhook 400 - 最易忽略的一点：不同集群的命名空间名可能重复（比如都有
default），通知里必须带上集群标识，否则收到消息的人根本分不清是哪个集群的default/nginx更新了
真正的麻烦不在写代码，在配置隔离和错误传播控制。比如飞书 webhook 失败不该导致整个 Informer 停摆，得用带缓冲的 error channel 单独处理。
