Kubernetes 的集成税：当 Prometheus 搭不上 Cilium 的指标列车

预计阅读时间：8 分钟

凌晨两点，Grafana 面板一片空白——不是服务挂了，不是网络断了，Hubble 的 DNS 可视化和 TCP 流量追踪一切正常。唯独 Cilium 的网络指标在 Prometheus 里消失了。这不是 bug，是集成出了问题。

这类"明明组件都在跑，数据就是串不起来"的场景，在 Kubernetes 生产环境中反复上演。每引入一个新组件，你以为获得的是功能，实际付出的却是调试、对齐、补漏的隐性成本——这就是集成税。

指标消失的三个常见嫌疑

Cilium 的 Prometheus 指标突然消失，排查路径通常落在三个环节：

1. 指标端口没暴露或被 ServiceMonitor 遗漏

Cilium 默认在端口 9982 暴露 Prometheus 指标，Hubble 则在 9985。如果 ServiceMonitor 只匹配了其中一个，或者 label selector 对不上，Prometheus 根本不会去抓取。

2. NetworkPolicy 或 Cilium 自身的 eBPF 规则阻断了抓取流量

讽刺的是，Cilium 管的网络策略可能恰好挡住了 Prometheus 访问 Cilium Agent 的指标端口。这在严格的安全策略集群里并不罕见。

3. 指标路径或格式变更未同步到 Grafana 仪表盘

Cilium 版本升级后指标名或 label 结构发生变化，旧仪表盘的 PromQL 查询自然返回空值。Hubble 不受影响，因为它走的是自己的 UI 和 API，不依赖同一套指标管道。

实战排查：从空白面板到数据回流

下面给出一个可直接在集群中运行的排查流程。假设你用的是 Prometheus Operator（ServiceMonitor 方式）+ Cilium 1.14+。

第一步：确认 Cilium Agent 是否在吐指标

# 找到任意一个 Cilium Agent Pod
CILIUM_POD=$(kubectl get pods -n kube-system -l k8s-app=cilium -o jsonpath='{.items[0].metadata.name}')

# 直接 curl 指标端点
kubectl exec -n kube-system $CILIUM_POD -- curl -s http://localhost:9982/metrics | head -20

如果返回一堆 cilium_ 开头的指标行，说明 Agent 端没问题，瓶颈在 Prometheus 抓取配置。如果返回空或连接拒绝，检查 Cilium Helm values 中 prometheus.enabled 是否为 true。

第二步：检查 ServiceMonitor 是否匹配

# 查看集群中所有 ServiceMonitor
kubectl get servicemonitors -n kube-system -o yaml | grep -A5 "cilium"

# 更直接：看 Prometheus 是否发现了这个 target
# 访问 Prometheus UI 的 /targets 页面，或用 API 查询
kubectl port-forward -n monitoring svc/prometheus-operated 9090:9090 &
curl -s http://localhost:9090/api/v1/targets | python3 -m json.tool | grep -i cilium

如果 targets 里找不到 Cilium，大概率是 ServiceMonitor 的 selector 和 Cilium Service 的 label 对不上。下面是一个修正后的完整 ServiceMonitor 示例：

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: cilium-agent
  namespace: kube-system
  labels:
    release: prometheus   # 必须匹配 Prometheus Operator 的 serviceMonitorSelector
spec:
  selector:
    matchLabels:
      k8s-app: cilium     # 必须匹配 Cilium Service 的 label
  namespaceSelector:
    matchNames:
      - kube-system
  endpoints:
    - port: metrics       # Cilium Service 中指标端口的 name 字段
      path: /metrics
      interval: 30s
      honorLabels: true   # 保留 Cilium 自身的 namespace/pod label，避免被 Prometheus 覆盖

关键细节：honorLabels: true 在 Cilium 场景中很重要。Cilium 指标自带 source_namespace、destination_namespace 等 label，如果 Prometheus 用自己的 namespace label 覆盖了它们，网络拓扑查询就会全部失效。

第三步：确认网络策略没有拦截抓取流量

# 查看是否有 NetworkPolicy 影响 kube-system 内的流量
kubectl get networkpolicies -n kube-system

# 如果有策略，检查是否放行了 Prometheus namespace 到 9982 端口的流量
# 临时验证：从 Prometheus Pod 直接 curl
PROM_POD=$(kubectl get pods -n monitoring -l app=prometheus -o jsonpath='{.items[0].metadata.name}')
kubectl exec -n monitoring $PROM_POD -- curl -s http://cilium-agent.kube-system:9982/metrics | head -5

如果 curl 失败但第一步成功，说明网络策略挡了跨 namespace 访问。需要补一条放行规则：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-prometheus-to-cilium
  namespace: kube-system
spec:
  podSelector:
    matchLabels:
      k8s-app: cilium
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring   # monitoring namespace 必须有这个 label
      ports:
        - port: 9982
          protocol: TCP
        - port: 9985
          protocol: TCP

别忘了给 monitoring namespace 打上 label：

kubectl label namespace monitoring name=monitoring --overwrite

集成税的账单不止于指标

Cilium + Prometheus 的指标断裂只是集成税的一个切面。更广的账单包括：

版本耦合：Cilium 1.14 改了指标名，Grafana 仪表盘就得同步更新。Helm values、ServiceMonitor、NetworkPolicy、Dashboard JSON——四份配置必须一起动。
调试链路断裂：Hubble UI 能看到流量，但 Grafana 看不到指标。两个系统各自"正常"，却无法交叉验证。出了问题，你先怀疑的不是组件，而是它们之间的胶水。
隐性依赖：你以为部署了 Cilium 就有了网络可观测性，实际上还需要正确配置 ServiceMonitor、NetworkPolicy 放行、Grafana dashboard 导入、Prometheus resource 预留——每一环都是额外劳动。

上线前的集成检查清单

在把 Cilium（或任何新组件）推进生产之前，跑一遍这个清单可以避免凌晨两点的空白面板：

## Kubernetes 组件集成检查清单

1. [ ] 指标端点可达：从 Prometheus Pod curl 目标组件的 /metrics
2. [ ] ServiceMonitor label 双向对齐：selector 匹配 Service，Prometheus 的 serviceMonitorSelector 匹配 ServiceMonitor
3. [ ] honorLabels 按需开启：组件自带拓扑 label 时必须设为 true
4. [ ] NetworkPolicy 放行抓取流量：从监控 namespace 到目标端口
5. [ ] PromQL 查询验证：在 Prometheus UI 手动跑关键查询，确认有数据返回
6. [ ] Grafana dashboard 版本对齐：dashboard JSON 中的指标名与当前组件版本一致
7. [ ] 抓取间隔与资源预留：组件指标量大时，检查 Prometheus 的 scrape interval 和存储容量
8. [ ] 升级回滚测试：模拟组件版本回退，确认旧 dashboard 仍能渲染（或提前准备版本分支）

集成税不会消失，但可以提前缴纳。在部署阶段多花一小时对齐 label 和策略，比在生产事故中花一整夜排查空白面板划算得多。