SkyWalking 基于 Cilium Hubble 的 Kubernetes 无侵入监控：Cilium Fetcher 架构、配置与指标详解

SkyWalking 基于 Cilium Hubble 的 Kubernetes 无侵入监控Cilium Fetcher 架构、配置与指标详解【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking本文围绕 Apache SkyWalking 的 Cilium Fetcher 模块系统讲解如何借助 Cilium Hubble 的 Peers / Observe gRPC API实现 Kubernetes 集群内服务间流量的无侵入采集、实体识别与指标生成。读完本文你将掌握 Cilium Fetcher 的完整数据流、application.yml 配置与 TLS 启用方法、排除规则写法、L4/L7 指标口径以及 OAP 集群下的采集负载均衡原理。Cilium FetcherSkyWalking 的 Kubernetes 网络观测入口SkyWalking 对 Kubernetes 的监控并非依赖传统的 Agent 埋点而是通过Cilium Fetcher模块从 Cilium Hubble 的 Observe API 拉取集群内服务间的流量数据再借助 OALObservability Analysis Language系统完成指标与实体分析。该模块位于oap-server/server-fetcher-plugin/cilium-fetcher-plugin是一条典型的「流量拉取 → 实体识别 → OAL 指标生成」链路拉取层CiliumNodeManager负责发现集群内所有 Hubble 节点并建立 gRPC 连接解析层CiliumFlowListener消费 Flow 数据将其转换为 SkyWalking 的 Service / Instance / Endpoint / Relation 实体并送入SourceReceiver分析层CiliumOALDefine加载oal/cilium.oal脚本cilium.oal由 OAL 引擎聚合出各类指标。关于 OAL 语法与 Scope 定义可参考 OAL 系统说明 与 Scope 声明文档。数据流概览Cilium Fetcher 的整体数据流可概括为一条单向管道Cilium Hubble 节点集群内 │ Peers API发现 Hubble 节点列表Notify 流式推送 ▼ CiliumNodeManagerOAP 内 │ Observe APIGetFlows 流式拉取 Flow 数据 ▼ CiliumFlowListenerOAP 内 │ 分析源/目的 Endpoint构建实体Service、Instance、Endpoint、Relation ▼ SourceReceiver → OAL 引擎cilium.oal ▼ SkyWalking 指标L4 / L7写入存储即SkyWalking 通过 gRPC API 拉取 Cilium 节点与可观测数据分析生成实体再使用 OAL 生成指标。这一设计使 OAP 无需在每个 Pod 内部署任何 Sidecar 或 Agent即可获得服务间通信的完整视图。前置 API 要求Cilium Fetcher 依赖 Hubble 暴露的两个 gRPC APIPeers API监听集群中的 Hubble 节点。OAP 通过该 API 获知集群内有哪些 Hubble 节点并与它们通信以获取 Observe 数据。对应io.cilium.api.peer.PeerGrpc在 CiliumNodeManager 中通过PeerBlockingStub调用notify()订阅节点变更通知PEER_ADDED/PEER_UPDATED/PEER_DELETED。Observe API从 Hubble 节点拉取 Flow 数据。对应io.cilium.api.observer.ObserverGrpc在 CiliumFlowListener 中通过getFlows()发起GetFlowsRequest设置since当前时间、followtrue即从当前时刻起持续跟随新流量。从源码看OAP 对 Flow 的响应类型做了三类处理见CiliumFlowListener的flows.forEachRemainingFLOW正常的流量记录进入handleFlow处理LOST_EVENTSHubble 节点发生事件丢失仅记录 warn 日志NODE_STATUS节点状态信息仅记录 debug 日志。环境准备启用 Hubble在使用 Cilium Fetcher 之前需要先在 Kubernetes 集群中启用 Cilium Hubble 的可观测能力确保 Hubble 组件对外提供 Peers 与 Observe 两个 API。请参照 Cilium 官方 Hubble Setup 文档完成以下事项概览安装/升级 Cilium 并启用 Hubble Relay、Hubble UI 等组件确认hubble-peerService 在kube-system命名空间下可访问默认地址为hubble-peer.kube-system.svc.cluster.local:80若集群启用了 Hubble 的 TLS 证书则需要同步调整 OAP 侧的 TLS 配置见下文「启用 TLS 加密连接」一节。启用 Cilium Fetcher 模块Cilium Fetcher 是 OAP 的一个可选模块需要通过配置显式激活在 YAML 中将selector设为default或通过系统环境变量设置SW_CILIUM_FETCHERdefault。完整配置块如下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}在仓库的默认配置 application.yml 中该模块的实际默认值为selector: ${SW_CILIUM_FETCHER:-}默认不启用因此部署时必须显式设置SW_CILIUM_FETCHERdefault或修改 YAML 后才会启动。各配置项与对应环境变量的含义如下配置项环境变量默认值说明peerHostSW_CILIUM_FETCHER_PEER_HOSThubble-peer.kube-system.svc.cluster.localHubble peer 组件的主机名peerPortSW_CILIUM_FETCHER_PEER_PORT80Hubble peer 组件的端口fetchFailureRetrySecondSW_CILIUM_FETCHER_FETCH_FAILURE_RETRY_SECOND10拉取 Flow 失败后的重试间隔秒sslConnectionSW_CILIUM_FETCHER_SSL_CONNECTIONfalse是否启用 TLS 连接sslPrivateKeyFileSW_CILIUM_FETCHER_PRIVATE_KEY_FILE_PATH空私钥文件路径sslCertChainFileSW_CILIUM_FETCHER_CERT_CHAIN_FILE_PATH空证书链文件路径sslCaFileSW_CILIUM_FETCHER_CA_FILE_PATH空CA 证书文件路径convertClientAsServerTrafficSW_CILIUM_FETCHER_CONVERT_CLIENT_AS_SERVER_TRAFFICtrue是否将客户端流量折算为服务端视角统计这些配置项与 CiliumFetcherConfig 中的字段一一对应由模块框架自动注入。关键参数的行为细节fetchFailureRetrySecond当某个 Hubble 节点连接中断或getFlows抛异常时CiliumFlowListener 会休眠该秒数后自动重连并重新拉取CiliumNodeManager 监听节点变更失败时也会用同样的间隔重试。convertClientAsServerTraffic默认true表示将客户端侧的流量统一折算到服务端视角统计。开启后CiliumFlowListener 会把 Flow 的流量方向做一次翻转INGRESS ↔ EGRESS并且把所有指标的detectPoint固定为DetectPoint.SERVER同时忽略原本判定为服务端的重复流量见shouldIgnoreFlow中的对应分支。启用 TLS 加密连接如果 Hubble 开启了 TLS 证书参考 Cilium 官方 Hubble 配置中关于 TLS certificates 的说明需要同步更新以下配置peerPort通常应更新为443sslConnection设置为truesslPrivateKeyFile私钥文件的路径sslCertChainFile证书链文件的路径sslCaFileCA 文件的路径。对应的环境变量方式为SW_CILIUM_FETCHER_SSL_CONNECTIONtrue、SW_CILIUM_FETCHER_PRIVATE_KEY_FILE_PATH...、SW_CILIUM_FETCHER_CERT_CHAIN_FILE_PATH...、SW_CILIUM_FETCHER_CA_FILE_PATH...。这些证书参数最终由GrpcStubBuilder在构建PeerBlockingStub与ObserverBlockingStub时使用。Cilium 规则配置除模块本身外还需要配置两个 Cilium 规则文件位于 OAP 运行目录的cilium-rules/下仓库中的默认样例在 oap-server/server-starter/src/main/resources/cilium-rules/cilium-rules/exclude.yaml配置哪些 Endpoint 应被排除在监控之外不加入拓扑图、不生成指标详见下一节「排除规则Exclude Rules」。cilium-rules/metadata-service-mapping.yaml配置服务名与 Endpoint 的映射关系用于把 Cilium 的 Endpoint 元数据映射为 SkyWalking 的服务/实例命名。从 CiliumFetcherProvider 的源码可以看到两个文件的默认路径protected String excludeRulesFile cilium-rules/exclude.yaml; protected String fieldMappingFile cilium-rules/metadata-service-mapping.yaml;模块启动时start()方法会先通过FieldsHelper.forClass(ServiceMetadata.class).init(fieldMappingFile)加载字段映射再通过ExcludeRules.loadRules(excludeRulesFile)加载排除规则最后才启动节点管理器和流量监听器任一规则文件加载失败都会抛出ModuleStartException阻止启动。服务元数据解析机制ServiceMetadata 负责把 Hubble 的Endpoint含 Labels、Workloads、Namespace、PodName转换为 SkyWalking 的serviceName与serviceInstanceName。其中metadata-service-mapping.yaml决定了如何从 Endpoint 的 Labels 中选取字段拼装服务名Labels 中带k8s:前缀的键会被自动去除前缀后同样写入元数据便于映射规则直接引用短键名。排除规则Exclude Rules排除规则用于指定哪些 Cilium Endpoint 不应被加入拓扑图也不参与指标及其他数据的生成。配置示例namespaces: # 定义哪些命名空间的流量应被排除 - kube-system labels: # 定义哪些 Endpoint 标签的流量应被排除只要匹配任一标签组即被排除 - k8s:io.cilium.k8s.namespace.labels.istio-injection: enabled # 每条规则为 key-value 对key 为标签键value 为标签值 k8s:security.istio.io/tlsMode: istio默认行为默认情况下kube-system命名空间的所有流量以及由 Istio 网格管理的流量都会被排除仓库默认样例 exclude.yaml 与上述配置一致。匹配语义重要只有当流量的源和目的 Endpoint 同时命中排除规则时该流量才会被排除只要有一侧不命中流量仍会被统计。从 ExcludeRules 的源码可进一步确认判定逻辑namespacesendpoint.getNamespace()命中列表即排除labels对 Endpoint 的标签列表逐条比对一个标签组内的所有 key-value 全部匹配才算命中Labels.isMatch中matchCount labelMap.size()才返回 true。生成的实体Generated EntitiesSkyWalking 从 Cilium 拉取 Flow 后会分析源与目的 Endpoint解析出以下对应实体Service服务Service Instance服务实例Service Endpoint服务端点Service Relation服务间关系Service Instance Relation服务实例间关系Service Endpoint Relation服务端点间关系在实现层面CiliumFlowListener 会为每条 Flow 构建对应的CiliumService、CiliumServiceRelation、CiliumServiceInstance、CiliumServiceInstanceRelation、CiliumEndpoint、CiliumEndpointRelation六类指标源对象L7 流量还会生成 Endpoint 与 EndpointRelationL3/L4 流量只生成前四类统一以Layer.CILIUM_SERVICE作为归属层并写入SourceReceiver。其中关系类实体还会通过parseComponentId标注组件 IDTCP110、HTTP49、DNS159、Kafka27供拓扑图展示组件类型。在进入实体构建前handleFlow会先做一次过滤shouldIgnoreFlow剔除以下流量缺少源或目的 Endpoint 的 Flow源/目的 Endpoint 无 PodName 或 NamespaceID 0且元数据缺失的 Flowverdict 不是FORWARDED/DROPPED的 Flow流量方向未知的 Flow类型不是 L3/L4 或 L7 的 Flow启用convertClientAsServerTraffic后被判定为服务端重复的流量源与目的 Endpoint 同时命中排除规则的流量。指标生成Generate Metrics针对上述每一类实体都可以分析出 L4 与 L7 协议层的指标。L4 指标记录每个服务与其他服务读写数据包的指标指标名单位说明Read Package CPMCount每分钟从其他服务读取的数据包总数Write Package CPMCount每分钟向其他服务写入的数据包总数Drop Package CPMCount每分钟丢弃来自其他服务的数据包总数Drop Package Reason CountLabeled Count每分钟按丢弃原因标签统计的读取数据包数对应到 OAL 脚本cilium.oalL4 指标基于verdict forwarded/verdict dropped、type tcp与direction ingress/egress过滤后使用cpm()/labelCount(dropReason)聚合cilium_service_l4_read_pkg_cpm from(CiliumService.*).filter(verdict forwarded).filter(type tcp).filter(direction ingress).cpm(); cilium_service_l4_write_pkg_cpm from(CiliumService.*).filter(verdict forwarded).filter(type tcp).filter(direction egress).cpm(); cilium_service_l4_read_pkg_drop_cpm from(CiliumService.*).filter(verdict dropped).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);L7 协议指标基于每条传输数据的分析提取 7 层网络协议信息。注意默认情况下 Cilium 只上报 L4 指标。如需 L7 指标必须在每个服务的 CiliumNetworkPolicy 中显式开启详见 Cilium 官方安全策略文档。只有detectPoint SERVER的 L7 流量会计入服务端指标见 OAL 脚本中各处filter(detectPoint DetectPoint.SERVER)。HTTP指标名单位说明CPMCount每分钟 HTTP 请求调用次数DurationNanosecondsHTTP 响应的总耗时Success CPMCount每分钟 HTTP 成功响应status 500次数Status 1/2/3/4/5xxCount按 1xx/2xx/3xx/4xx/5xx 分组的 HTTP 响应状态码计数在 CiliumFlowListener 中HTTP 指标仅处理响应 Flowhttp.getCode() 0的请求被忽略端点名由HTTP 方法 URL 路径http.getMethod() : url.getPath()构成并记录 URL、状态码、协议与请求方法成功判定为http.code 500。DNS指标名单位说明CPMCount每分钟 DNS 请求调用次数DurationNanosecondsDNS 响应的总耗时Success CPMCount每分钟 DNS 成功响应code 0次数Error CountLabel Count带错误描述标签的 DNS 响应错误计数DNS 指标只统计响应 Flowflow.getL7().getType() RESPONSE成功判定为dns.getRcode() 0端点名形如DNS/qtype如DNS/A同时记录域名、查询类型、rcode 及对应的人类可读错误串映射表见 DNSCodes。Kafka指标名单位说明CPMCount每分钟 Kafka 请求调用次数DurationNanosecondsKafka 响应的总耗时Success CPMCount每分钟 Kafka 成功响应errorCode 0次数Error CountLabel Count带错误描述标签的 Kafka 响应错误计数Kafka 指标同样只统计响应 Flow成功判定为kafka.getErrorCode() 0端点名形如Kafka/topic/apiKey并记录 errorCode 及其可读错误名映射表见 KafkaCodes、API 版本、关联 ID 与主题名。值得注意的是cilium.oal 中 L4 / L7 指标并非只为 Service 生成而是对 Service、ServiceInstance、Endpoint 以及它们的 Relation 六类 Scope 各有一套完整定义如cilium_service_*、cilium_service_instance_*、cilium_endpoint_*、cilium_service_relation_*、cilium_service_instance_relation_*因此同一份流量数据可以支撑拓扑、实例列表、端点明细与调用链关系等多维度的查询视图。OAP 集群下的采集负载均衡Cilium Fetcher 模块依赖 Cluster 模块。当模块启动时每个 OAP 节点都会通过 Peers API 获取集群中所有 CiliumHubble节点的信息OAP 集群中所有节点RemoteInstance的信息。然后按以下策略分配采集任务核心逻辑见 CiliumNodeManager#buildShouldUsingNodes平均分配把所有 Cilium 节点平均分给每个 OAP 节点不重复采集保证同一个 Cilium 节点不会被多个 OAP 节点同时监控动态感知通过实现ClusterWatcher监听集群节点变化onClusterNodesChanged并每 10 秒定时刷新一次远端节点列表refreshRemoteNodes节点增删时自动重建「本节点应使用的 Cilium 节点」集合只对变化部分触发关闭/新建连接reBuildUsingNodes中的Create/Close/Unchanged三种动作。由此OAP 集群横向扩容时采集压力会随节点数自动分摊某个 Hubble 节点或 OAP 节点宕机后其余节点也会自动接管其采集任务避免单点与重复采集。该模块的节点分配行为有单元测试覆盖见 CiliumNodeManagerTest。自定义扩展自定义指标与 OAL 规则你可以自定义自己的指标与仪表盘面板。指标的定义与表达式规则位于/config/oal/cilium.oal发行包路径即仓库中的 oal/cilium.oal。修改该文件后OAP 启动时会由 CiliumOALDefine 加载并编译为指标聚合逻辑。Cilium 相关 Scope 的字段如verdict、type、direction、dropReason、http.code、dns.rcodeString、kafka.errorCodeString、success、duration等以Cilium前缀声明详见 Scope 声明文档可据此编写符合语法的自定义 OAL 表达式。自定义仪表盘Cilium 的仪表盘面板配置随 SkyWalking Horizon UI 发布包apache/skywalking-horizon-ui提供OAP 后端不再托管 UI 仪表盘 JSON。需要自定义面板时请在 Horizon UI 侧完成配置而不是修改 OAP 的配置文件。小结通过 Cilium FetcherSkyWalking 得以在 Kubernetes 环境实现「零埋点」的服务网络观测由 Hubble 提供底层流量数据OAP 负责实体识别、OAL 指标聚合与集群级负载均衡最终在 UI 上呈现服务拓扑、实例关系以及 HTTP / DNS / Kafka 等 L7 协议维度的健康指标。部署时的关键动作可归纳为三点一是确认 Hubble 的 Peers / Observe API 可用按需启用 TLS二是在 application.yml 中通过SW_CILIUM_FETCHERdefault激活模块并核对peerHost/peerPort三是按需调整cilium-rules/exclude.yaml与metadata-service-mapping.yaml两个规则文件把不需要纳入观测的命名空间与流量精准排除。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考