企业官网建设流程全解析

Cilium 可观测性实战：部署 Prometheus 与 Grafana 并开启 Cilium/Hubble 指标

【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium

本文基于 Cilium 官方文档 Running Prometheus & Grafana 展开，完整覆盖“用一份示例清单部署 Prometheus + Grafana、通过 Helm 值开启 Cilium/Hubble/Operator 三类指标、为 Operator 指标端点配置 TLS、port-forward 访问看板，以及读懂各内置仪表盘”的全流程。读完后你可以复制本文中的命令直接搭建一套能自动抓取 Cilium 与 Hubble 指标的监控栈，并理解每个开关背后的默认端口与底层配置。

示例部署包含什么

Cilium 仓库内置了一份把 Prometheus 和 Grafana 合并到单一 Kubernetes 部署中的示例清单 monitoring-example.yaml。它由仓库中的 Chart 渲染而来，默认安装包含两部分：

• Grafana：可视化看板，预载 Cilium Dashboard；
• Prometheus：时间序列数据库兼监控系统，自动抓取 Cilium 与 Hubble 的指标。

官方文档同时提到，可以在 KubeCon + CloudNativeCon 的演讲《Effortless Open Source Observability with Cilium, Prometheus and Grafana》中看到三者协同工作的演示。

清单渲染出的资源

应用这份清单的命令与输出如下：

$ kubectl apply -f examples/kubernetes/addons/prometheus/monitoring-example.yaml namespace/cilium-monitoring created serviceaccount/prometheus-k8s created configmap/grafana-config created configmap/grafana-cilium-dashboard created configmap/grafana-cilium-operator-dashboard created configmap/grafana-hubble-dashboard created configmap/prometheus created clusterrole.rbac.authorization.k8s.io/prometheus unchanged clusterrolebinding.rbac.authorization.k8s.io/prometheus unchanged service/grafana created service/prometheus created deployment.apps/grafana created deployment.apps/prometheus created

对照 monitoring-example.yaml 的源文件，可以确认每个资源的用途：

Prometheus 抓取配置解析

Prometheus 的抓取行为定义在 prometheus.yaml。核心是全局 10 秒的抓取/超时/评估间隔，以及四个抓取任务：

global: scrape_interval: 10s scrape_timeout: 10s evaluation_interval: 10s scrape_configs: - job_name: 'kubernetes-endpoints' kubernetes_sd_configs: - role: endpoints relabel_configs: - source_labels: [__meta_kubernetes_pod_label_k8s_app] action: keep regex: cilium - source_labels: [__meta_kubernetes_service_annotation_prometheus_io_scrape] action: keep regex: true # ...（scheme/path 重写、地址端口替换、labelmap 等） - job_name: 'kubernetes-pods' # 抓取带 prometheus.io/scrape 注解的 Pod - job_name: 'kubernetes-services' # 抓取带 prometheus.io/probe 注解的 Service - job_name: 'kubernetes-cadvisor' # 经 API Server 代理抓取节点 cAdvisor 指标

关键点：kubernetes-endpoints任务通过两条 relabel 规则过滤目标——保留k8s_app=cilium标签的 Pod 所属 Endpoint，同时要求 Service 带有prometheus.io/scrape=true注解。也就是说，只要 Cilium Helm chart 按后文开启指标并打上相应注解，这份 Prometheus 就能自动发现并抓取 Cilium 与 Hubble 的指标端点，无需额外配置。

Grafana 数据源与仪表盘装载

grafana-config 目录下的文件说明了 Grafana 的装配方式：

• prometheus-datasource.yaml 以 provisioning 方式声明名为prometheus的数据源，url: http://prometheus:9090（同命名空间内 Service 域名），并允许编辑；
• config.yaml将仪表盘 provider 指向/configmap/dashboards/目录，对应三份挂载的仪表盘 JSON：cilium-dashboard.json、cilium-operator-dashboard.json、hubble-dashboard.json，以及按工作负载聚合 L7 HTTP 指标的 hubble-l7-http-metrics-by-workload.json。

从 cilium-dashboard.json 的面板定义看，它直接以 PromQL 查询 Cilium 指标，例如错误率面板使用sum(rate(cilium_errors_warnings_total{...}[1m])) by (pod, level) * 60、CPU 面板使用irate(cilium_process_cpu_seconds_total{...}[1m])的 min/avg/max 曲线、内存面板使用cilium_process_resident_memory_bytes等，印证了仪表盘数据完全依赖后文开启的 Prometheus 指标链路。

为 Cilium、Hubble 与 Operator 开启指标

文档明确指出：Cilium（cilium-agent）、Hubble、Cilium Operator 默认不暴露指标；开启后分别会在这些组件运行的节点上打开端口9962、9965、9963。三者可以相互独立地通过如下 Helm 值开启：

• prometheus.enabled=true：为cilium-agent开启指标；
• operator.prometheus.enabled=true：为cilium-operator开启指标；
• hubble.metrics.enabled：启用指定的 Hubble 指标列表；Hubble 指标生效的前提是先启用 Hubble 本体（hubble.enabled=true）。

对照当前仓库 install/kubernetes/cilium/values.yaml 的默认值，可以更精确地理解每个开关的落点：

注意两点：

1. 从当前仓库 values.yaml 的默认值看，operator.prometheus.enabled已经默认为true，而文档叙述的是三类组件“默认不暴露”的通用语义；实际部署时以你所用 chart 版本的 values 为准。
2. hubble.metrics.enabled为空（~）时 Hubble 指标完全禁用，必须显式给出要采集的指标名列表才生效。

此外，hubble.metrics.enableOpenMetrics控制是否以 OpenMetrics 格式导出 Hubble 指标（默认false，见 values.yaml#L1501-L1502）。开启它可以获得更好的数据模型（如 Exemplars 关联 Trace 语义），这也是官方示例安装命令中显式设置它的原因。

各指标的完整清单与含义可参考仓库内的 指标配置指南。

一键开启全部指标的 Helm 安装命令

按文档中的安装指令，在 kube-system 命名空间部署 Cilium 并同时开启全部指标：

helm install cilium cilium/cilium \ --namespace kube-system \ --set prometheus.enabled=true \ --set operator.prometheus.enabled=true \ --set hubble.enabled=true \ --set hubble.metrics.enableOpenMetrics=true \ --set 'hubble.metrics.enabled={dns,drop,tcp,flow,port-distribution,icmp,httpV2:exemplars=true;labelsContext=source_ip\,source_namespace\,source_workload\,destination_ip\,destination_namespace\,destination_workload\,traffic_direction}'

其中hubble.metrics.enabled启用了七类 Hubble 指标：

• dns、drop、tcp、flow、icmp：DNS 查询、丢包、TCP、流、ICMP 事件指标；
• port-distribution：目的端口分布指标（注意：该指标默认禁用，必须像上面这样显式加入列表）；
• httpV2:exemplars=true;labelsContext=source_ip\,...,traffic_direction：HTTP v2 指标并启用 Exemplars，同时把 8 个上下文标签（源/目的 IP、命名空间、工作负载、流量方向）附加到指标上——这正是按工作负载切分 L7 流量面板的基础，对应的聚合视图即 hubble-l7-http-metrics-by-workload.json 仪表盘。

--set选项可以与任何官方安装指南中的 Helm 命令组合使用。

为 Operator 的 Prometheus 端点配置 TLS

如果你希望 cilium-operator 的指标端点（9963 端口）走 TLS，需要分两步。

第一步：创建包含tls.crt与tls.key的 Secret（示例）：

kubectl -n kube-system create secret generic operator-prometheus-tls \ --from-file=tls.crt=./server.crt \ --from-file=tls.key=./server.key

第二步：在 Helm 命令中添加以下参数：

--set operator.prometheus.tls.enabled=true # 为 Operator Prometheus 开启 TLS --set operator.prometheus.tls.server.existingSecret=secret-name # 引用上一步的 Secret 名称

如果要进一步启用 mTLS，需要在上一步的 Secret 中额外加入ca.crt键，并追加：

--set operator.prometheus.tls.server.mtls.enabled=true # 使用 Secret 中的 ca.crt 校验客户端证书

这些选项在 values.yaml#L3478-L3488 中有完整定义：operator.prometheus.tls.enabled默认false，server.existingSecret默认为空字符串，server.mtls.enabled默认false且注释说明“该选项在 TLS 禁用时无效”——即必须先开 TLS，mTLS 才有意义。

访问 Grafana 与 Prometheus

监控栈部署在cilium-monitoring命名空间，两个服务通过kubectl port-forward暴露到本地：

Grafana（3000 端口）：

kubectl -n cilium-monitoring port-forward service/grafana --address 0.0.0.0 --address :: 3000:3000

然后浏览器访问 http://localhost:3000。

Prometheus（9090 端口）：

kubectl -n cilium-monitoring port-forward service/prometheus --address 0.0.0.0 --address :: 9090:9090

然后浏览器访问 http://localhost:9090。

两个命令都带--address 0.0.0.0 --address ::，意味着端口转发同时绑定 IPv4 与 IPv6 所有地址，集群内其他机器也可以经由转发节点访问（示例清单中 Grafana 还默认开启了匿名 Admin 访问，见 grafana.ini 中[auth.anonymous] enabled = true，生产环境应自行收紧）。

读懂内置仪表盘：各面板对应什么指标

文档的 Examples 一节按主题展示了各仪表盘的实际截图，覆盖两大类看板：

Cilium 仪表盘（cilium-dashboard）

这些面板的 PromQL 全部基于cilium_*前缀的指标（如前文cilium_errors_warnings_total、cilium_process_cpu_seconds_total），因此必须先开启prometheus.enabled=true才有数据。

Hubble 仪表盘（hubble-dashboard）

再次强调port-distribution指标默认禁用：如果 Hubble Networking 面板中端口分布无数据，先检查hubble.metrics.enabled列表里是否包含它。

接入已有 Prometheus 体系：ServiceMonitor 与 dashboards

示例部署适合快速验证；若集群已有基于 prometheus-operator 的监控系统，values.yaml 中各组件的prometheus.serviceMonitor提供了标准接入方式（以 cilium-agent 为例，values.yaml#L2696-L2729）：

prometheus: metricsService: false # 是否创建指标 Service enabled: false port: 9962 serviceMonitor: enabled: false # 需集群中已存在 prometheus-operator 的 ServiceMonitor CRD labels: {} annotations: {} interval: "10s" # 抓取间隔 scrapeTimeout: ~ relabelings: - sourceLabels: [__meta_kubernetes_pod_node_name] targetLabel: node action: replace replacement: ${1} metricRelabelings: ~ trustCRDsExist: false # true 时 Helm 跳过 CRD 存在性检查

operator.prometheus与hubble.metrics下也有同构的serviceMonitor配置块，且默认都带__meta_kubernetes_pod_node_name -> node的 relabeling，方便按节点维度聚合。注意serviceMonitor.enabled需要 prometheus-operator 的monitoring.coreos.comCRD 已安装，否则 Helm 会在安装前检查失败（可用trustCRDsExist=true跳过检查）。

除 ServiceMonitor 外，prometheus.metrics（values.yaml#L2730-L2745）支持用+metric_foo/-metric_bar语法在默认指标列表上增删指标；prometheus.controllerGroupMetrics默认启用了write-cni-file、sync-host-ips、sync-lb-maps-with-k8s-services三个 controller 组指标。如果你的 Grafana 是自建的，dashboards.enabled=true（values.yaml#L2746-L2757）会给 Cilium 仪表盘加grafana_dashboard标签，供 Grafana Helm chart 的 sidecar 自动导入。

小结

整条链路可以概括为：Helm chart 按开关在节点上开启9962/9965/9963三个指标端口 → Prometheus 通过 kubernetes SD 与 relabel 规则自动发现并每 10 秒抓取一次 → Grafana 以 provisioning 数据源查询 Prometheus，并加载 Cilium/Operator/Hubble 仪表盘，最终呈现从 agent 资源、网络与策略，到 Hubble 七层流量的完整可观测视图。

【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium