Apache SkyWalking OAP 高级部署理解 Mixed / Receiver / Aggregator 三种角色与 Kubernetes 集群拆分实践【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking导读在集群环境下SkyWalking 的 OAPObservability Analysis Platform服务器节点之间通过内部通信完成分布式聚合。默认情况下所有节点都以Mixed混合模式运行即每个节点同时承担数据接收、两级聚合、持久化与告警的全部职责。但当集群规模扩大、或安全策略与网络策略要求对数据入口和计算存储进行物理隔离时你需要为节点指定明确角色。本文以 advanced-deployment.md 为主线结合oap-server源码与默认配置完整讲解 Mixed、Receiver、Aggregator 三种角色的职责边界、配置方法与 Kubernetes 环境下的拆分部署要点帮助你按需设计 OAP 集群拓扑。角色总览OAP 节点的三种运行模式原文档明确在集群模式下所有 OAP 节点默认以 Mixed 模式运行。可用于 OAP 的角色有三种角色说明Mixed默认同时承担 Receiver 与 Aggregator 的全部职责Receiver仅负责数据入口与 L1 聚合并将结果转发给其他节点Aggregator仅负责接收其他节点数据、执行 L2 聚合、持久化与告警这三种角色并非独立模块而是由 OAP 核心模块的同一份配置项控制。从源码看角色定义位于 CoreModuleConfig.java 中的Role枚举Mixed、Receiver、Aggregator三个取值其中Mixed是默认值Role.fromName(String name)使用大小写不敏感匹配解析配置字符串未知取值一律回退为Mixed。因此配置时写receiver或RECEIVER均可但拼写错误不会报错只会悄悄退回 Mixed 模式——部署时需要特别留意。Mixed默认的完整职责节点默认情况下OAP 节点是一个功能完整的处理单元原文档列出的职责包括接收Agent 上报的链路Trace或指标MetricsL1 聚合对接收到的数据进行第一轮聚合内部通信发送/接收与集群内其他 OAP 节点交换数据参与分布式聚合L2 聚合执行第二轮聚合产出最终的指标结果持久化Persistence将聚合结果写入存储后端告警Alarm基于聚合结果运行告警规则。在Role枚举的源码注释中Mixed 被明确描述为 Default role. OAP works as theReceiverandAggregator即它同时具备两种专用角色的能力。对于中小规模集群这是最简单也最常用的部署形态所有节点对等无需额外规划职责分工。Receiver专注数据入口的节点当集群需要对「数据接入面」与「计算存储面」做网络隔离时可将部分节点设为 Receiver。原文档给出的职责为接收Agent 上报的链路或指标L1 聚合内部通信发送将聚合结果转发给 Mixed 与 Aggregator 角色节点。关键点在于Receiver只发送、不接收来自其他 OAP 节点的数据也不执行 L2 聚合、不写存储、不跑告警。源码中有两处实现证据可以印证这一行为在 CoreModuleProvider.java 中节点启动时会判断自身角色只有 Mixed 与 Aggregator 才会调用coordinator.registerRemote(...)把自身注册为集群中的远程实例Receiver 角色不注册因此其他节点不会把内部通信数据发送给它。在 OAPNodeChecker.java 的健康检查逻辑中Receiver 角色被单独豁免了「必须能在实例列表中找到自身」的校验——这正对应其「只发送不接收」的定位它无需出现在其他节点的聚合目标列表里。此外Role.Receiver的枚举注释还揭示了一个重要细节对于Record记录类数据如链路 Span它们不需要第二轮分布式聚合因此Receiver 节点会将 Record 直接推入存储而非转发给 Aggregator。换句话说即使集群中有独立的 Aggregator链路明细数据也由 Receiver 直写存储只有指标类数据走「Receiver → Aggregator」的两级聚合链路。这一点在设计存储访问策略时值得注意。Aggregator专注聚合、持久化与告警的节点Aggregator 是数据处理链路的末端节点原文档给出的职责为内部通信接收接收来自 Receiver 与 Mixed 角色 OAP 的数据L2 聚合持久化告警。它不直接面对 Agent不接收外部链路/指标上报也不做 L1 聚合。从Role枚举注释看Aggregator receives data fromMixedandAggregatorOAP nodes, and do 2nd round aggregation. Then save the final result to the storage——它消费的是上游节点完成 L1 聚合后的中间结果。同时如前文所述Aggregator 会像 Mixed 一样注册为集群远程实例见 CoreModuleProvider.java从而被上游节点识别为可发送的目标。如何配置 OAP 角色角色通过 OAP 核心模块的role配置项指定。默认配置位于 application.ymlcore: role: ${SW_CORE_ROLE:Mixed} # Mixed/Receiver/Aggregator即支持两种配置方式环境变量设置SW_CORE_ROLEMixed|Receiver|Aggregator例如SW_CORE_ROLEReceiver配置文件直接修改application.yml中core.role的取值。默认值为Mixed即未显式配置时节点以混合模式运行。由于Role.fromName采用忽略大小写的匹配且失败时回退 Mixed见 CoreModuleConfig.java请确保取值严格为三种角色名之一避免因拼写错误导致角色未按预期生效。适用前提这些角色是为「复杂的安全与网络策略部署需求」而设计的。原文档明确说明只有当你确实需要对集群节点做职责拆分时才应使用该功能对大多数场景默认的 Mixed 模式已足够。Kubernetes 环境下的角色拆分部署原文档指出如果使用 SkyWalking 原生的 Kubernetes 集群协调器并坚持为 OAP 节点指定明确角色则每种角色需要两个独立的 Deployment——一个用于 Receiver OAP另一个用于 Aggregator OAP以便为不同职责的系统环境配置如资源配额、网络策略、存储访问权限做分离。具体做法是为 Aggregator 角色设置labelSelector标签选择器让集群协调器按标签选出正确的 OAP Deployment 作为聚合目标。Kubernetes 集群协调器的关键配置原生 Kubernetes 集群协调器的配置位于 application.ymlcluster: selector: ${SW_CLUSTER:standalone} kubernetes: namespace: ${SW_CLUSTER_K8S_NAMESPACE:default} labelSelector: ${SW_CLUSTER_K8S_LABEL:appcollector,releaseskywalking} uidEnvName: ${SW_CLUSTER_K8S_UID:SKYWALKING_COLLECTOR_UID}namespaceOAP Pod 所在的 Kubernetes 命名空间默认defaultlabelSelector必填项用于从集群中挑选参与 OAP 集群的 Pod默认值为appcollector,releaseskywalkinguidEnvName读取 Pod UID 的环境变量名用于节点在集群中识别自身默认SKYWALKING_COLLECTOR_UID。其中labelSelector的解析逻辑可以在 KubernetesCoordinator.java 中看到它以逗号分隔多组keyvalue键值对逐组解析为标签映射交给 Kubernetes 的 EndpointGroup 过滤 Pod 列表。因此要按角色拆分就应该让 Receiver 与 Aggregator 两个 Deployment 挂载不同的标签并分别为其设置对应的labelSelector。拆分部署的推荐拓扑结合原文档建议与KubernetesCoordinator的标签解析机制推荐的部署形态如下Receiver Deployment挂标签如rolereceiver其 Pod 暴露 gRPC 端口供 Agent 上报不注册为远程聚合目标Aggregator Deployment挂标签如roleaggregator并配置SW_CLUSTER_K8S_LABELroleaggregator使集群协调器只发现 Aggregator 的 Pod两类 Deployment 可部署在同一命名空间但通过标签与 labelSelector 在逻辑上隔离成两个不同的 OAP 集群视图。需要特别说明的是由于labelSelector是集群协调器挑选全部参与节点的依据拆分后 Receiver 与 Aggregator 实际会各自维护一套「集群成员列表」视图。从KubernetesCoordinator.start()的实现KubernetesCoordinator.java可见每个 OAP 节点通过 labelSelector 发现端点并构造RemoteInstance列表。因此两个 Deployment 的 labelSelector 必须分别精确匹配各自角色的 Pod 标签避免互相把对方纳入集群成员造成数据转发与健康检查异常。健康检查视角下的角色差异角色差异在集群健康检查逻辑中也有体现。OAPNodeChecker.isHealth(...)OAPNodeChecker.java对三种角色的检查口径不同Mixed / Aggregator必须能在集群实例列表中找到自身否则判定为不健康Receiver豁免「找到自身」的校验因为它不参与下游节点的聚合目标列表任何角色在集群模式下都禁止出现127.0.0.1、localhost这类非法节点地址单节点部署除外。这意味着拆分部署后Receiver 节点的健康状态判断更宽松而 Aggregator 必须能通过 labelSelector 在集群中发现自身否则会被标记为不健康——排查角色拆分后的集群异常时可以从这个角度入手。总结OAP 集群默认所有节点以Mixed模式运行承担接收、L1/L2 聚合、持久化与告警的全部职责Receiver专注数据入口与 L1 聚合只发送不接收内部数据并将 Record 类数据直写存储Aggregator专注 L2 聚合、持久化与告警不直接面对 Agent通过SW_CORE_ROLE环境变量或core.role配置项即可为节点指定角色在 Kubernetes 上拆分角色时为每种角色创建独立 Deployment并通过cluster.kubernetes.labelSelector默认appcollector,releaseskywalking精确匹配各自角色的 Pod 标签这些角色专为复杂的安全与网络策略部署需求设计常规场景使用默认 Mixed 模式即可。如需进一步了解 Kubernetes 集群协调器的完整配置如权限要求、镜像与启动参数可继续阅读 Kubernetes 集群协调器文档。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sk/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考