WEBKT

生产级指南：如何在 Kubernetes 中平滑升级 SkyWalking 并确保数据一致性？

1 0 0 0

在微服务架构中，SkyWalking 作为核心的可观测性平台，其稳定性直接影响到故障排查效率。在 Kubernetes (K8s) 生产环境中升级 SkyWalking，最大的挑战不在于更换镜像版本，而在于存储 Schema 的变更兼容性、大规模 Agent 的连接平滑迁移以及历史数据的完整性。

本文将结合生产实践，分享一套标准化的平滑升级路径。

一、 升级前的核心准备

在执行 kubectl apply 之前，必须完成以下三项对齐：

  1. 版本兼容性矩阵 check：
    • OAP 与 Storage：检查新版本 SkyWalking 是否支持当前 Elasticsearch (ES) 或 BanyanDB 版本。例如，从 8.x 升级到 9.x，对 ES 的索引模板处理逻辑有所变化。
    • OAP 与 Agent：SkyWalking 遵循“大版本向下兼容”原则（如 9.x OAP 支持 8.x Agent），但反之则不行。建议先升级服务端，再分批升级客户端。
  2. 存储层快照：
    • 如果是使用 ES，务必执行 POST /_snapshot/my_backup/snapshot_1 进行全量快照。Schema 变更一旦不可逆，快照是最后的防线。
  3. 配置审计：
    • 对比新旧版本的 application.yml。重点关注环境变量的变化，尤其是关于 TTL（数据保留时间）和索引分片的参数。

二、 核心升级策略：四步走

1. 存储层 Schema 预升级 (Migration Job)

SkyWalking OAP 在启动时会自动检测并升级索引结构。但在 K8s 中，如果直接进行 RollingUpdate，多个新版 Pod 同时尝试 init 存储，可能会引发 ES 索引锁冲突。

推荐做法：使用一个一次性的 Job 来完成 Schema 初始化。

apiVersion: batch/v1
kind: Job
metadata:
  name: skywalking-migrate-job
spec:
  template:
    spec:
      containers:
      - name: oap
        image: apache/skywalking-oap-server:9.x.x # 目标版本
        env:
        - name: SW_STORAGE
          value: elasticsearch
        - name: SW_STORAGE_ES_CLUSTER_NODES
          value: "elasticsearch-logging:9200"
        # 关键配置：仅运行初始化逻辑后退出
        - name: SW_CORE_MODE
          value: init
      restartPolicy: OnFailure

2. OAP 集群的滚动更新

在 Job 执行成功后，修改 OAP 的 Deployment。为了保证平滑，需要调整 strategy 参数：

  • ReadinessProbe：必须配置就绪检查。SkyWalking OAP 启动较慢（涉及指标聚合初始化），如果不配置就绪检查，流量会过早切入导致监控断流。
  • UpdateStrategy：建议 maxSurge: 25%，maxUnavailable: 0。
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
      - name: oap
        image: apache/skywalking-oap-server:9.x.x
        readinessProbe:
          tcpSocket:
            port: 11800
          initialDelaySeconds: 30
          periodSeconds: 10

3. UI 组件升级

UI 组件是无状态的，直接更新镜像即可。由于 UI 与 OAP 之间是通过 GraphQL 通信，通常新版 UI 能很好地适配新版 OAP 的接口。

4. Agent 的分批重启/注入

SkyWalking Agent 通常通过 Java Agent 挂载。在 K8s 中，如果你使用了 SkyWalking Satellite 或 Sidecar 注入，可以通过修改 MutatingAdmissionWebhook 的配置来实现平滑切换。

  • 策略：利用 K8s 的标签选择器，先在开发/测试环境节点上打标测试，验证 Trace 链路是否正常，再逐步通过滚动更新业务 Pod 来完成 Agent 升级。

三、 如何保证数据一致性与零丢失？

  1. 双写入期处理：
    在极端敏感场景下，如果担心新版本 OAP 解析逻辑导致数据异常，可以短时间并行运行两套 OAP 集群（指向同一 ES 存储），通过 Service 权重控制流量。但注意，SkyWalking 的指标聚合是有状态的，这种方式主要用于 Trace 数据的验证。
  2. 监控 OAP 内部队列：
    升级期间，密切观察 ES 的 Rejected Execution 指标。如果新版本 OAP 改变了索引刷新频率，可能会导致存储端压力突增。
  3. 缓冲层介入：
    如果生产环境流量巨大，建议在 Agent 与 OAP 之间引入 Kafka。升级 OAP 时，数据积压在 Kafka 中，待 OAP 升级完成恢复消费，从根本上保证数据不丢失。

四、 常见坑点与排查

  • 索引模板冲突：如果升级后发现没有新数据，检查 ES 索引模板是否被旧模板覆盖。手动删除旧的 sw_* 模板通常能解决问题。
  • gRPC 版本不匹配：极少数情况下，旧版 Agent 使用的 gRPC 协议与新版 OAP 存在兼容性毛刺，表现为 Stream RuntimeException。此时需强制开启 OAP 的旧版本兼容开关。
  • 内存溢出：新版本 OAP 可能会引入更多的分析指标（如 eBPF 模块），升级后需观察 Pod 的 Memory Usage，适时调大 JAVA_OPTS 中的 -Xmx。

总结

K8s 环境下的 SkyWalking 升级，核心在于“解耦初始化与运行”。通过独立的 Init Job 确保存储 Schema 稳定切换，再配合 K8s 自带的滚动更新机制，即可实现用户无感的平滑升级。升级完成后，建议保留 ES 快照 24 小时，直到确认所有核心指标（Service, Instance, Endpoint）的聚合曲线正常。

云原生老兵 KubernetesSkyWalking链路追踪

评论点评