企业官网建设流程全解析

SkyWalking Kubernetes 监控全指南：KSM/cAdvisor、Rover 与 Cilium Fetcher 三条观测路径详解

【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking

Kubernetes 已成为云原生应用的基础设施，SkyWalking 作为 APM 系统提供了三条互补的 Kubernetes 监控路径：基于 kube-state-metrics（KSM）与 cAdvisor 的资源指标监控、基于 SkyWalking Rover eBPF Agent 的网络访问日志观测，以及基于 Cilium Hubble API 的流量拓扑分析。本文以 SkyWalking 仓库中的 backend-k8s-monitoring.md 为主干，逐条梳理三条路径的数据流、部署接入步骤、完整指标清单与自定义扩展方式，并结合 OAP 服务端真实的 MAL/OAL 规则文件讲解底层实现，帮助读者在自建 Kubernetes 集群上快速落地一套覆盖"资源、网络、协议"三个维度的可观测方案。

为什么 SkyWalking 需要三种 K8s 监控路径

Kubernetes 是一个开源容器编排系统，用于自动化应用部署、扩缩容与管理，由 Google 最初设计，现由云原生计算基金会（CNCF）维护，目标是"跨主机集群自动化部署、扩缩容和运维应用容器"，可配合 Docker 等容器工具使用。如今 Kubernetes 是云原生应用的基础设施，SkyWalking 提供了以下三种方式监控 Kubernetes 上的部署：

SkyWalking 与 Kubernetes 深度集成，帮助用户理解应用在 Kubernetes 上的运行状态。需要说明的是，文档中提到"Cilium with Hubble 在 v10 计划中"，从当前仓库结构看，cilium-fetcher-plugin 已作为独立的 fetcher 插件存在，可结合 cilium-fetcher-plugin 源码目录 与 fetcher-proto 中的 proto 定义进一步了解实现。

路径一：基于 kube-state-metrics 与 cAdvisor 的资源指标监控

SkyWalking 借助 K8s 的 kube-state-metrics（KSM）与 cAdvisor 采集 Kubernetes 的指标数据，再通过 OpenTelemetry Collector 将指标转发给 OpenTelemetry receiver，最终汇入 Meter System（MAL）。该功能要求授权 OAP Server 访问 K8s 的 API Server，以便 OAP 获取元数据信息。

数据流

1. K8s kube-state-metrics 与 cAdvisor 从 K8s 采集指标数据；
2. OpenTelemetry Collector 通过 Prometheus Receiver 从 kube-state-metrics 与 cAdvisor 拉取指标，再通过 OpenTelemetry gRPC exporter 推送给 SkyWalking OAP Server；
3. SkyWalking OAP Server 访问 K8s API Server 获取元数据信息，并使用 MAL 表达式对指标进行过滤、计算、聚合后入库。

这一数据流与仓库中的配置一一对应：在 otel-rules/k8s/k8s-cluster.yaml 中可以看到入口过滤条件filter: "{ tags -> tags.job_name in [ 'kubernetes-cadvisor', 'kube-state-metrics' ] }"，即只接收 job_name 为kubernetes-cadvisor与kube-state-metrics的指标，这正是 OpenTelemetry Collector 中 Prometheus Receiver 两个抓取任务的 job 名称约定。

部署与接入步骤

1. 部署 kube-state-metrics（参考其官方 Kubernetes Deployment 方式）；
2. cAdvisor 默认已集成在 kubelet 中，无需单独部署；
3. 在 Kubernetes 中部署 OpenTelemetry Collector，并配置 Prometheus Receiver 抓取上述两类指标（抓取目标参考 Prometheus 官方提供的 prometheus-kubernetes 抓取配置示例）；仓库所在的 SkyWalking 生态提供了完整的快速开始示例与推荐版本（可在 skywalking-showcase 项目的deploy/platform/kubernetes/templates/feature-kubernetes-monitor中找到，本仓库不包含该工程）；
4. 配置 SkyWalking 的 OpenTelemetry receiver 以接收上报的指标。

集群监控（Kubernetes Cluster Monitoring）

K8s 集群监控提供整个集群及各节点的状态与资源监控。映射关系为：K8s 集群作为 OAP 中的 Service，K8s 节点作为 OAP 中的 Instance，归属Layer: K8S。在 k8s-cluster.yaml 中，expSuffix: tag({tags -> tags.cluster = 'k8s-cluster::' + tags.cluster}).service(['cluster'], Layer.K8S)正体现了这一映射。

集群级支持的指标（数据源均为 K8s kube-state-metrics）：

这些指标在 k8s-cluster.yaml 中均有对应的 MAL 表达式定义。例如：

metricsRules: - name: cpu_cores exp: (kube_node_status_capacity * 1000).tagEqual('resource' , 'cpu').sum(['cluster']) - name: node_status exp: kube_node_status_condition.valueEqual(1).tagMatch('status' , 'true|unknown').sum(['cluster' , 'node' ,'condition']) - name: service_pod_status exp: kube_pod_status_phase.retagByK8sMeta('service' , K8sRetagType.Pod2Service , 'pod' , 'namespace').tagNotEqual('service' , '').valueEqual(1).sum(['cluster' , 'service' , 'phase'])

可以看到 CPU 核心数被乘以 1000 转换为毫核（m）单位；retagByK8sMeta是 MAL 中面向 K8s 的特殊函数，它借助 OAP 从 API Server 获取的元数据，将 Pod 维度标签重写为 Service 维度标签（K8sRetagType.Pod2Service），这正是 OAP 需要访问 K8s API Server 的原因。

节点级支持的指标（CPU/内存/存储资源类来自 KSM，用量类来自 cAdvisor）：

对应实现在 k8s-node.yaml 中，其expSuffix为instance(['cluster'] , ['node'], Layer.K8S)，即节点映射为 OAP Instance。其中 CPU 用量表达式(container_cpu_usage_seconds_total * 1000).tagEqual('id' , '/').sum(['cluster' , 'node']).irate()通过id == '/'精确锁定根容器（cgroup 根，代表整机视角）来聚合节点整体用量，网络收发则对container_network_receive_bytes_total/container_network_transmit_bytes_total做irate()求瞬时速率。

服务监控（Kubernetes Service Monitoring）

K8s Service 监控提供对 Service 状态与资源的可观测性。映射关系为：K8s Service 作为 OAP 中的 Service，归属Layer: K8S_SERVICE，对应 k8s-service.yaml 中的expSuffix: service(['cluster' , 'service'], '::', Layer.K8S_SERVICE)。

Service 级支持的指标：

Service 级指标同样大量依赖retagByK8sMeta('service' , K8sRetagType.Pod2Service , 'pod' , 'namespace')完成 Pod → Service 的维度转换，例如 CPU 用量表达式：

- name: pod_cpu_usage exp: (container_cpu_usage_seconds_total * 1000).tagNotEqual('container' , '').tagNotEqual('pod' , '').retagByK8sMeta('service' , K8sRetagType.Pod2Service , 'pod' , 'namespace').tagNotEqual('service' , '').sum(['cluster' , 'service' , 'pod']).irate()

另外仓库中还存在一份 k8s-instance.yaml，可一并阅读以了解实例维度的规则结构。

自定义监控（Customizations）

该路径支持自定义指标、表达式与仪表盘面板：

• 指标定义与表达式规则位于/config/otel-rules/k8s/k8s-cluster.yaml、/config/otel-rules/k8s/k8s-node.yaml、/config/otel-rules/k8s/k8s-service.yaml（即仓库中的 otel-rules/k8s/ 目录），可直接修改或新增规则后重启 OAP 生效；
• K8s Cluster 与 K8s Service 的仪表盘面板配置随 SkyWalking Horizon UI 包（apache/skywalking-horizon-ui）一同发布，OAP 后端不再托管 UI 仪表盘 JSON。

路径二：基于 SkyWalking Rover（eBPF）的网络访问日志观测

SkyWalking Rover 是 SkyWalking 原生的 eBPF Agent，用于从 Kubernetes 集群采集访问日志，并交给 OAL 系统 进行指标与实体分析。得益于 eBPF 的能力，Rover 还能对 C++、Rust、Golang 等语言编写的运行中服务进行 profiling。

数据流

1. SkyWalking Rover 监控 K8s 集群中的访问日志数据，并发送给 OAP；
2. SkyWalking OAP Server 通过 gRPC 接收来自 Rover 的访问日志，分析生成实体，并使用 OAL 生成指标。

部署与配置

1. 在 Kubernetes 中部署 Rover，并启用其 access log service（流量采集配置）；
2. 通过以下配置启用 OAP 的 eBPF receiver 模块：

receiver-ebpf: selector: ${SW_RECEIVER_EBPF:default} default:

其中selector默认值由环境变量SW_RECEIVER_EBPF控制（默认default），保持默认即可启用。

生成的实体（Generated Entities）

SkyWalking 接收来自 Rover 的访问日志后，分析 Kubernetes 连接信息，解析出以下对应实体：

1. Service（服务）
2. Service Instance（服务实例）
3. Service Endpoint（服务端点）
4. Service Relation（服务间关系）
5. Service Instance Relation（服务实例间关系）
6. Service Endpoint Relation（服务端点间关系）

生成的指标（Generate Metrics）

对上述每个实体，均可分析出连接（connection）、传输（transfer）、协议（protocol）三类指标。

连接指标（Connection Metrics）：记录每个服务与其他服务建立/关闭连接的指标。

传输指标（Transfer Metrics）：记录每个服务向其他服务发起网络请求时，每次 syscall 的基本信息与 L2-L4 层细节。

读连接数据（Read Data from Connection）：

写连接数据（Write Data to Connection）：

协议指标（Protocol）：基于每次传输数据分析，提取 7 层网络协议信息。

HTTP/1.x 或 HTTP/2.x：

上述指标与 oal/ebpf.oal 中的 OAL 定义一一对应，例如连接类指标：

kubernetes_service_connect_cpm = from(K8SService.*).filter(type == "connect").cpm(); kubernetes_service_connect_time = from(K8SService.connect.duration).filter(type == "connect").longAvg(); kubernetes_service_connect_success_cpm = from(K8SService.*).filter(type == "connect").filter(connect.success == true).cpm(); kubernetes_service_read_cpm = from(K8SService.*).filter(type == "read").cpm(); kubernetes_service_write_l2_net_device_avg_send_duration = from(K8SService.write.l2.networkDeviceSendDuration).filter(type == "write").longAvg(); kubernetes_service_http_call_cpm = from(K8SService.*).filter(detectPoint == DetectPoint.SERVER).filter(type == "protocol").filter(protocol.type == "http").cpm().decorator("K8SServiceDecorator");

从 OAL 结构可以看到，Rover 上报的数据以type（connect/accept/close/read/write/protocol）区分事件类别，connect.duration、read.l2.packageCount、write.l3.netFilterCount等字段则体现了 eBPF 在连接建立、协议栈各层处理环节的精细化埋点能力。

自定义监控（Customizations）

该路径同样支持自定义指标与仪表盘面板：

• 指标定义与表达式规则位于/config/oal/ebpf.oal（即 oal/ebpf.oal），其中使用的K8SService等 Scope 的字段定义可参考 Scope 声明文档（Scopes with K8s prefix）；
• K8s 仪表盘面板配置随 SkyWalking Horizon UI 包（apache/skywalking-horizon-ui）一同发布，OAP 后端不再托管 UI 仪表盘 JSON。

路径三：基于 Cilium Fetcher（Hubble）的流量观测

如果集群中安装了 Cilium，SkyWalking 通过 Cilium Fetcher 借助 Cilium Hubble 的 Observe API 采集服务间流量数据。这些数据可用于创建拓扑图，并提供 L4 与 L7 层指标，随后交由 OAL 系统 进行指标与实体分析。

数据流

SkyWalking 通过 gRPC API 获取 Cilium Node 与观测数据，分析生成实体，并使用 OAL 生成指标。

API 依赖

Cilium Fetcher 依赖 Cilium Hubble 提供以下两个 API：

1. Peers API：监听集群中的 hubble 节点，OAP 会与 Hubble 节点通信以获取 Observe 数据；
2. Observe API：从 Hubble 节点获取 Flow 数据。

部署与配置

1. 参照 Hubble 官方部署文档完成 Hubble 的安装，使其提供上述 API；
2. 激活 Cilium receiver 模块：在 YAML 中设置selector=default，或通过系统环境变量设置SW_CILIUM_FETCHER=default：

cilium-fetcher: selector: ${SW_CILIUM_FETCHER:default} default: # Host name and port of Hubble peer component peerHost: ${SW_CILIUM_FETCHER_PEER_HOST:hubble-peer.kube-system.svc.cluster.local} peerPort: ${SW_CILIUM_FETCHER_PEER_PORT:80} fetchFailureRetrySecond: ${SW_CILIUM_FETCHER_FETCH_FAILURE_RETRY_SECOND:10} sslConnection: ${SW_CILIUM_FETCHER_SSL_CONNECTION:false} sslPrivateKeyFile: ${SW_CILIUM_FETCHER_PRIVATE_KEY_FILE_PATH:} sslCertChainFile: ${SW_CILIUM_FETCHER_CERT_CHAIN_FILE_PATH:} sslCaFile: ${SW_CILIUM_FETCHER_CA_FILE_PATH:} convertClientAsServerTraffic: ${SW_CILIUM_FETCHER_CONVERT_CLIENT_AS_SERVER_TRAFFIC:true}

各配置项说明如下：

3. 若启用了 Hubble 的 TLS 证书，需更新以下配置：

   • peerPort：通常应更新为443；
   • sslConnection：设置为true；
   • sslPrivateKeyFile：私钥文件路径；
   • sslCertChainFile：证书链文件路径；
   • sslCaFile：CA 文件路径。

4. 配置 cilium 规则：

   • cilium-rules/exclude.yaml：配置应从监控中排除的 endpoint，详见下文"排除规则"；
   • cilium-rules/metadata-service-mapping.yaml：配置服务名称与 endpoint 的映射。

排除规则（Exclude Rules）

Cilium 规则中的 exclude 配置用于指定哪些 Cilium Endpoint 不会被加入拓扑图，也不会生成指标与其他数据。

namespaces: # 定义来自哪些命名空间的流量应被排除 - kube-system labels: # 定义匹配哪些 endpoint 标签的流量应被排除，只要匹配任一标签即被排除 - k8s:io.cilium.k8s.namespace.labels.istio-injection: "enabled" # 每个标签是一个键值对，key 为标签键，value 为标签值 k8s:security.istio.io/tlsMode: istio

默认情况下，来自kube-system命名空间以及由 istio mesh 管控的流量都会被排除。仓库中的 cilium-rules/exclude.yaml 即为上述默认配置的实际落地文件。

注意：只有源端和目的端同时匹配排除规则的 endpoint 才会被排除；否则流量仍会计入。

另外，cilium-rules/metadata-service-mapping.yaml 定义了服务名与实例名的生成规则：

serviceName: ${LABELS."service.istio.io/canonical-name",LABELS."app.kubernetes.io/name",LABELS.component,LABELS.app,LABELS.k8s-app,SERVICE}.${NAMESPACE} serviceInstanceName: ${NAME}

即服务名按service.istio.io/canonical-name→app.kubernetes.io/name→component→app→k8s-app→ 原生 SERVICE 名的优先级依次取第一个存在的标签值，并拼上命名空间后缀；实例名取NAME。

生成的实体（Generated Entities）

SkyWalking 从 Cilium 获取 Flow 数据，分析源端与目的端 endpoint，解析出以下实体：

1. Service（服务）
2. Service Instance（服务实例）
3. Service Endpoint（服务端点）
4. Service Relation（服务间关系）
5. Service Instance Relation（服务实例间关系）
6. Service Endpoint Relation（服务端点间关系）

生成的指标（Generate Metrics）

对上述每个实体，可分析出 L4 与 L7 协议指标。

L4 指标：记录每个服务与其他服务读写数据包的指标。

对应实现可在 oal/cilium.oal 中看到，例如：

cilium_service_l4_read_pkg_cpm = from(CiliumService.*).filter(verdict == "forwarded").filter(type == "tcp").filter(direction == "ingress").cpm(); cilium_service_l4_write_pkg_drop_cpm = from(CiliumService.*).filter(verdict == "dropped").filter(type == "tcp").filter(direction == "egress").cpm(); cilium_service_l4_drop_reason_count = from(CiliumService.*).filter(verdict == "dropped").filter(type == "tcp").labelCount(dropReason);

可见 L4 指标通过verdict（forwarded/dropped）、type（tcp）与direction（ingress/egress）过滤 Flow 数据得出，丢包原因通过labelCount(dropReason)按标签统计。

协议指标（Protocol）：基于每次传输数据分析，提取 7 层网络协议信息。

注意：默认情况下 Cilium 只上报 L4 指标。如果需要 L7 指标，必须在每个服务的 CiliumNetworkPolicy 中显式声明（详见 Cilium 官方安全策略文档）。

HTTP：

DNS：

Kafka：

在 oal/cilium.oal 中，协议指标覆盖了 Service、ServiceInstance、Endpoint、ServiceRelation、ServiceInstanceRelation 五类实体的 HTTP / DNS / Kafka 定义，例如：

cilium_service_protocol_http_call_cpm = from(CiliumService.*).filter(verdict == "forwarded").filter(type == "http").filter(detectPoint == DetectPoint.SERVER).cpm(); cilium_service_protocol_http_status_5xx_cpm = from(CiliumService.*).filter(verdict == "forwarded").filter(type == "http").filter(detectPoint == DetectPoint.SERVER).filter(http.code >= 500).filter(http.code < 600).cpm(); cilium_service_protocol_dns_error_count = from(CiliumService.*).filter(verdict == "forwarded").filter(type == "dns").filter(detectPoint == DetectPoint.SERVER).filter(success == false).labelCount(dns.rcodeString); cilium_service_protocol_kafka_call_success_count = from(CiliumService.*).filter(verdict == "forwarded").filter(type == "kafka").filter(detectPoint == DetectPoint.SERVER).filter(success == true).cpm();

Cilium Fetcher 与 OAP 集群的负载均衡

Cilium Fetcher 模块依赖 Cluster 模块：当 Cilium Fetcher 模块启动时，会通过每个 OAP 节点上的 Peers API 获取 OAP 集群中所有 Cilium 节点与节点信息。

在此基础上，它会把采集到的 Cilium 节点平均分配到每个 OAP 节点上，并保证单个 Cilium 节点不会被多个 OAP 节点重复监控，从而在 OAP 集群部署时实现采集任务的负载均衡与去重。

自定义监控（Customizations）

该路径同样支持自定义指标与仪表盘面板：

• 指标定义与表达式规则位于/config/oal/cilium.oal（即 oal/cilium.oal），其中使用的CiliumService等 Scope 的字段定义可参考 Scope 声明文档（Scopes with Cilium prefix）；
• Cilium 仪表盘面板配置随 SkyWalking Horizon UI 包（apache/skywalking-horizon-ui）一同发布，OAP 后端不再托管 UI 仪表盘 JSON。

三条路径的选型建议

三条监控路径从仓库的 backend-k8s-monitoring.md 出发、互不冲突且维度互补：

• 需要集群资源大盘与容量规划：选择KSM + cAdvisor路径。它数据链路轻（依赖 OpenTelemetry Collector 转发）、指标覆盖面广（集群/节点/服务三级的 CPU、内存、存储、状态），适合作为 K8s 集群的"体检报告"，也是接入成本最低的一条路径；
• 需要拓扑感知、网络性能分析与无侵入 profiling：选择Rover（eBPF）路径。它对应用语言无侵入，可观测到 syscall 级、协议栈各层的读写细节，并能对 C++/Rust/Golang 等服务做 profiling；
• 集群已采用 Cilium 作为 CNI：优先选择Cilium Fetcher路径。直接复用 Cilium Hubble 的观测能力获取 Flow 数据，天然支持 L4/L7（HTTP/DNS/Kafka）指标与拓扑图，且在 OAP 集群模式下自带负载均衡能力。

三条路径生成的实体均落在 SkyWalking 标准的 Service / Instance / Endpoint / Relation 模型上，因此可以统一在 SkyWalking UI（Horizon UI）中查看拓扑与指标，并与 SkyWalking 其他观测数据（Trace、Log、Meter）形成完整的可观测闭环。

【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking