如何通过HTTP接口展示Kubernetes集群已部署服务的镜像标签

你提到的S3、Redis存储方案都存在部署流程耦合、数据一致性难保障的问题，完全不需要引入这类额外存储，最稳妥的实现是直接基于Kubernetes原生能力做，零冗余数据源，数据和集群实际运行状态完全一致。

推荐方案：基于K8s API Informer机制实现（无额外依赖） #

核心逻辑是直接把K8s APIServer作为唯一数据源，不需要修改任何现有CI/CD部署流程：

• 给暴露/api/metadata接口的服务绑定一个最小权限的ServiceAccount，通过RBAC仅授予对Deployment/StatefulSet/DaemonSet、ReplicaSet、Pod资源的list、watch权限，禁止授予写权限
• 服务启动时初始化对应语言的官方K8s客户端（Go/Python/Java/JS均有成熟官方维护版本），启动Informer监听机制，和APIServer建立长连接实时接收资源变更事件，在本地内存维护一份缓存映射：key为服务名，value为对应服务当前最新就绪版本使用的完整镜像地址
• 处理接口请求时直接读取本地内存缓存返回即可，不需要每次请求查APIServer
• 缓存更新逻辑注意过滤无效数据：只统计处于Running状态、就绪检查通过的Pod所属的最新修订版本工作负载，自动忽略旧版本ReplicaSet、启动失败、未就绪的Pod对应的镜像，避免返回旧版本数据

最小权限RBAC配置参考：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: service-image-reader
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets", "daemonsets", "replicasets"]
  verbs: ["list", "watch"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["list", "watch"]
---
# 绑定到你部署metadata服务的ServiceAccount即可
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: service-image-reader-binding
subjects:
- kind: ServiceAccount
  name: <你的metadata服务使用的SA名>
  namespace: <服务所在命名空间>
roleRef:
  kind: ClusterRole
  name: service-image-reader
  apiGroup: rbac.authorization.k8s.io

方案优势 #

• 数据一致性100%可靠：返回的镜像标签完全对应集群里实际正在运行的服务版本，不会出现部署失败、回滚时外部存储数据和实际状态不一致的问题
• 实时性达标：工作负载滚动更新完成、新Pod就绪后，Informer会在毫秒级收到事件更新本地缓存，接口返回内容同步变更
• 性能开销极低：接口读本地内存，响应延迟在毫秒级，Informer的list+watch机制对APIServer的压力极小，哪怕集群有上千个工作负载也不会有性能问题
• 维护成本为0：不需要在部署流水线里加任何额外的写入逻辑，也不需要维护S3、Redis这类额外组件的可用性

轻量替代方案（不想写代码可选） #

如果不想自己开发服务逻辑，可以用现成组件快速搭建：

• 在集群内部署kube-state-metrics组件，它本身已经会缓存所有工作负载的镜像信息，你可以在前面加一个极薄的代理层，把kube-state-metrics暴露的指标格式转换成你需要的JSON格式返回即可
• 也可以给metadata服务加一个sidecar容器，用kubectl proxy暴露APIServer的只读接口，代理层定期（间隔1-2秒即可）拉取工作负载列表解析镜像信息做缓存，性能和可靠性略低于Informer方案，但胜在实现快，不需要集成K8s客户端。

不推荐你之前构思的S3、Redis方案：这类方案属于在集群外维护一份运行状态的冗余副本，必须在部署流水线的每个分支（正常部署、回滚、部署失败终止）都正确处理存储写入逻辑，只要有一个分支没覆盖到，就会出现数据不准的问题，长期维护成本极高。

内容的提问来源于stack exchange，提问作者Mo Xue