从单机到集群：手把手教你用 Kubernetes 和 Zookeeper 搭建高可用 SkyWalking OAP Server

从单机到集群手把手教你用 Kubernetes 和 Zookeeper 搭建高可用 SkyWalking OAP Server在微服务架构盛行的今天分布式系统的监控与追踪变得尤为重要。SkyWalking 作为一款开源的 APM应用性能监控系统凭借其强大的分布式追踪能力和丰富的指标监控功能已经成为众多企业的首选方案。而 OAPObservability Analysis PlatformServer 作为 SkyWalking 的核心组件负责接收、分析和存储来自各个服务实例的监控数据其稳定性和性能直接关系到整个监控系统的可靠性。对于中小规模的系统单实例部署 OAP Server 可能已经足够。但随着业务规模的扩大特别是当日均处理数据量达到百万甚至千万级别时单点部署的瓶颈就会显现处理能力有限、容错性差、扩展困难。这时将 OAP Server 从单机部署升级为集群部署就显得尤为必要。本文将详细介绍如何在 Kubernetes 环境中利用 Zookeeper 作为集群协调器构建一个高可用的 SkyWalking OAP Server 集群。我们将从架构设计开始逐步讲解配置细节、部署策略和优化技巧帮助你在生产环境中搭建一个稳定、可扩展的 APM 监控平台。1. 高可用架构设计在开始部署之前我们需要先理解 SkyWalking OAP Server 集群的工作原理和架构设计。一个典型的 OAP Server 集群由多个节点组成这些节点通过 Zookeeper 进行服务发现和状态同步共同处理来自 Agent 的监控数据。1.1 集群角色划分SkyWalking OAP Server 支持三种不同的角色模式每种角色承担不同的职责Mixed 模式单个节点同时承担数据接收和处理的所有工作适合小型集群或测试环境Receiver 模式专门负责接收 Agent 上报的数据并将数据转发给 Aggregator 节点Aggregator 模式负责数据的聚合分析和存储不直接与 Agent 交互在生产环境中我们通常会采用 Receiver 和 Aggregator 分离的部署方式。这种架构有以下优势水平扩展性可以根据数据量单独扩展 Receiver 或 Aggregator职责分离避免单一节点过载提高系统稳定性资源优化可以根据不同角色的资源需求进行针对性配置1.2 Zookeeper 的作用Zookeeper 在 OAP Server 集群中扮演着关键角色主要提供以下功能服务注册与发现各 OAP Server 节点启动时向 Zookeeper 注册自己集群状态管理维护集群中各节点的状态信息配置共享存储和分发集群级别的配置信息领导者选举在 Aggregator 节点中选举主节点提示Zookeeper 3.5 版本是官方推荐的选择虽然也兼容 3.4.x 版本但建议使用最新稳定版以获得更好的性能和功能支持。1.3 Kubernetes 部署策略在 Kubernetes 中部署 OAP Server 集群时我们需要考虑以下几个关键点考虑因素Deployment 策略StatefulSet 策略节点标识无状态Pod 可随意替换有状态Pod 有固定标识存储需求适合无持久化存储的场景适合需要持久化存储的场景网络标识随机生成固定有序的主机名适用场景Receiver 节点Aggregator 节点对于 OAP Server 集群我们通常采用混合部署策略Receiver 节点使用 Deployment因为它们是无状态的Aggregator 节点使用 StatefulSet因为它们可能需要访问持久化存储2. 环境准备与配置在开始部署之前我们需要准备好相关的基础设施和配置。这包括 Zookeeper 集群的搭建、Kubernetes 环境的准备以及 SkyWalking 相关镜像的获取。2.1 Zookeeper 集群部署Zookeeper 集群的部署可以参考以下配置# zookeeper-cluster.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: zookeeper namespace: skywalking spec: serviceName: zookeeper replicas: 3 selector: matchLabels: app: zookeeper template: metadata: labels: app: zookeeper spec: containers: - name: zookeeper image: zookeeper:3.7.0 ports: - containerPort: 2181 name: client - containerPort: 2888 name: server - containerPort: 3888 name: leader-election env: - name: ZOO_MY_ID valueFrom: fieldRef: fieldPath: metadata.name apiVersion: v1 divisior: 0 - name: ZOO_SERVERS value: server.1zookeeper-0.zookeeper.skywalking.svc.cluster.local:2888:3888;2181 server.2zookeeper-1.zookeeper.skywalking.svc.cluster.local:2888:3888;2181 server.3zookeeper-2.zookeeper.skywalking.svc.cluster.local:2888:3888;2181 volumeMounts: - name: datadir mountPath: /data volumeClaimTemplates: - metadata: name: datadir spec: accessModes: [ ReadWriteOnce ] resources: requests: storage: 10Gi2.2 SkyWalking OAP Server 配置OAP Server 的核心配置集中在 application.yml 文件中我们需要重点关注以下几个部分集群配置设置 Zookeeper 连接信息角色配置定义节点的角色Receiver/Aggregator/Mixed存储配置配置 Elasticsearch 或其他存储后端接收器配置启用或禁用特定的数据接收器以下是一个典型的集群配置示例cluster: selector: ${SW_CLUSTER:zookeeper} zookeeper: nameSpace: ${SW_NAMESPACE:} hostPort: ${SW_CLUSTER_ZK_HOST_PORT:zookeeper.skywalking.svc.cluster.local:2181} baseSleepTimeMs: ${SW_CLUSTER_ZK_SLEEP_TIME:1000} maxRetries: ${SW_CLUSTER_ZK_MAX_RETRIES:3} enableACL: ${SW_ZK_ENABLE_ACL:false}2.3 资源配置建议根据不同的角色OAP Server 的资源需求也有所不同Receiver 节点CPU2-4 核内存4-8GB主要消耗网络和 CPU 资源Aggregator 节点CPU4-8 核内存8-16GB主要消耗 CPU 和内存资源注意实际资源配置应根据数据量和性能需求进行调整建议通过监控观察资源使用情况后再做决定。3. Kubernetes 部署实践有了前面的准备我们现在可以开始在 Kubernetes 上部署 SkyWalking OAP Server 集群了。我们将分别部署 Receiver 和 Aggregator 两种角色的节点。3.1 Receiver 节点部署Receiver 节点使用 Deployment 部署因为它们是无状态的。以下是一个示例配置# oap-receiver-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: skywalking-oap-receiver namespace: skywalking spec: replicas: 3 selector: matchLabels: app: skywalking-oap role: receiver template: metadata: labels: app: skywalking-oap role: receiver spec: containers: - name: oap-server image: apache/skywalking-oap-server:8.9.0 env: - name: SW_CLUSTER value: zookeeper - name: SW_CLUSTER_ZK_HOST_PORT value: zookeeper.skywalking.svc.cluster.local:2181 - name: SW_CORE_ROLE value: Receiver - name: JAVA_OPTS value: -Xms4g -Xmx4g ports: - containerPort: 11800 name: grpc - containerPort: 12800 name: rest volumeMounts: - name: config mountPath: /skywalking/config/application.yml subPath: application.yml volumes: - name: config configMap: name: skywalking-oap-config3.2 Aggregator 节点部署Aggregator 节点建议使用 StatefulSet 部署因为它们可能需要访问持久化存储# oap-aggregator-statefulset.yaml apiVersion: apps/v1 kind: StatefulSet metadata: name: skywalking-oap-aggregator namespace: skywalking spec: serviceName: skywalking-oap-aggregator replicas: 2 selector: matchLabels: app: skywalking-oap role: aggregator template: metadata: labels: app: skywalking-oap role: aggregator spec: containers: - name: oap-server image: apache/skywalking-oap-server:8.9.0 env: - name: SW_CLUSTER value: zookeeper - name: SW_CLUSTER_ZK_HOST_PORT value: zookeeper.skywalking.svc.cluster.local:2181 - name: SW_CORE_ROLE value: Aggregator - name: JAVA_OPTS value: -Xms8g -Xmx8g ports: - containerPort: 11800 name: grpc - containerPort: 12800 name: rest volumeMounts: - name: config mountPath: /skywalking/config/application.yml subPath: application.yml volumes: - name: config configMap: name: skywalking-oap-config3.3 Service 配置为了让 Agent 能够访问 OAP Server 集群我们需要创建相应的 Service# oap-service.yaml apiVersion: v1 kind: Service metadata: name: skywalking-oap namespace: skywalking spec: ports: - name: grpc port: 11800 targetPort: 11800 - name: rest port: 12800 targetPort: 12800 selector: app: skywalking-oap role: receiver提示我们只将 Receiver 节点暴露给外部Aggregator 节点仅用于内部数据处理不直接对外服务。4. 高级配置与优化基础部署完成后我们还需要进行一些高级配置和优化以确保集群能够高效稳定地运行。4.1 存储优化SkyWalking 支持多种存储后端Elasticsearch 是最常用的选择。以下是一些存储优化的建议索引分片策略storage: elasticsearch7: indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:3} indexReplicasNumber: ${SW_STORAGE_ES_INDEX_REPLICAS_NUMBER:1} superDatasetIndexShardsFactor: ${SW_STORAGE_ES_SUPER_DATASET_INDEX_SHARDS_FACTOR:5}批量操作参数bulkActions: ${SW_STORAGE_ES_BULK_ACTIONS:2000} syncBulkActions: ${SW_STORAGE_ES_SYNC_BULK_ACTIONS:50000} flushInterval: ${SW_STORAGE_ES_FLUSH_INTERVAL:15} concurrentRequests: ${SW_STORAGE_ES_CONCURRENT_REQUESTS:4}4.2 性能调优根据数据量和硬件配置可以调整以下参数JVM 参数Receiver 节点-Xms4g -Xmx4g -XX:MetaspaceSize256mAggregator 节点-Xms8g -Xmx8g -XX:MetaspaceSize512m处理线程数core: default: gRPCHandlerThreadPoolSize: ${SW_CORE_GRPC_HANDLER_THREAD_POOL_SIZE:4} gRPCHandlerThreadPoolQueueSize: ${SW_CORE_GRPC_HANDLER_THREAD_POOL_QUEUE_SIZE:10000}4.3 监控与告警为了确保集群健康运行建议设置以下监控指标OAP Server 自身指标节点状态通过 Zookeeper 获取处理延迟错误率资源使用情况CPU 使用率内存使用量网络吞吐量存储后端指标Elasticsearch 索引延迟存储空间使用情况可以通过 SkyWalking 自带的 Prometheus 导出器暴露这些指标然后使用 Prometheus 和 Grafana 进行监控。5. 故障排查与日常维护即使是最稳定的系统也难免会遇到问题因此了解如何排查和解决常见问题非常重要。5.1 常见问题及解决方案节点无法加入集群检查 Zookeeper 连接配置是否正确查看 Zookeeper 日志是否有错误验证网络连通性数据处理延迟高检查 Aggregator 节点资源使用情况调整批量处理参数考虑增加 Aggregator 节点数量存储空间不足优化索引生命周期策略考虑增加 Elasticsearch 节点调整数据保留策略5.2 日志分析OAP Server 的日志是排查问题的重要依据。重点关注以下日志信息启动阶段集群注册是否成功运行阶段错误和警告信息关闭阶段优雅关闭的日志可以通过以下命令查看特定节点的日志kubectl logs -n skywalking pod-name -f5.3 升级与扩展随着业务发展可能需要对集群进行升级或扩展垂直扩展增加单个节点的资源CPU、内存水平扩展增加节点数量版本升级遵循官方升级指南先升级少量节点验证兼容性在实际项目中我们通常会先在一个非生产环境测试升级过程验证无误后再应用到生产环境。