Kubernetes APM 选型：SkyWalking vs Pinpoint vs Elastic APM

场景与目标

在稳定跑业务的同时，想看清每个请求的链路和慢点在哪里。这篇文章一边说清楚 SkyWalking / Pinpoint / Elastic APM 的差异，一边手把手带你在 K8s 里拉起一套 SkyWalking，用最少的步骤让应用产生日志和指标，最后确认 UI 里能看到 Trace。

方案对比（一句话概括）

方案	优点	注意点	适合谁
SkyWalking	Java/Envoy/OTel 都能接，UI 清晰，支持 Service Mesh	OAP 依赖 ES/其他存储，注意资源	想要“一套打通大部分语言和 Mesh”的团队
Pinpoint	Java/Php 探针成熟，拓扑/调用栈直观	语言覆盖面相对窄，探针版本要跟紧	JVM/Php 业务为主的团队
Elastic APM	和 ELK 打通，日志 + APM 一站式	ES 开销大，Agent 需按语言配置	已经用 ELK，想顺手接 APM 的团队

这里选 SkyWalking 落地示例，原因很直接：兼容多语言和 Istio，社区活跃，部署脚本也成熟。

在 K8s 部署 SkyWalking（Helm）

准备命名空间和 Helm 源：

kubectl create namespace observability --dry-run=client -o yaml | kubectl apply -f -
helm repo add skywalking https://apache.jfrog.io/artifactory/skywalking-helm
helm repo update

安装 SkyWalking（使用内置 Elasticsearch 单节点，先跑通）：

helm upgrade --install skywalking skywalking/skywalking \
  --namespace observability \
  --set elasticsearch.replicas=1 \
  --set elasticsearch.minimumMasterNodes=1 \
  --set ui.service.type=ClusterIP \
  --set oap.env.SW_OTEL_RECEIVER_ENABLED=true \
  --set oap.env.SW_TELEMETRY=none
kubectl -n observability wait --for=condition=Available deploy -l app=skywalking --timeout=300s

生产请将 ES/存储独立出来，或改用 ClickHouse 支持，避免单点。

查看服务入口：

kubectl -n observability get svc skywalking-oap skywalking-ui

skywalking-oap 暴露 gRPC/HTTP(OTLP/Zipkin) 端口。
skywalking-ui 提供 Web 界面，默认 8080。

接入应用（Java 和 Istio）

Java 应用注入 Agent

在 Deployment 中给容器挂上 SkyWalking Java Agent（示例基于官方镜像）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-java
  namespace: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-java
  template:
    metadata:
      labels:
        app: demo-java
    spec:
      containers:
      - name: app
        image: your/java-app:latest
        env:
        - name: SW_AGENT_NAME
          value: demo-java
        - name: SW_AGENT_COLLECTOR_BACKEND_SERVICES
          value: skywalking-oap.observability.svc.cluster.local:11800
        - name: JAVA_TOOL_OPTIONS
          value: "-javaagent:/skywalking/agent/skywalking-agent.jar"
        volumeMounts:
        - name: skywalking-agent
          mountPath: /skywalking/agent
      volumes:
      - name: skywalking-agent
        emptyDir: {}
      initContainers:
      - name: agent-init
        image: apache/skywalking-java-agent:9.2.0
        command: ['sh', '-c', 'cp -R /skywalking/agent/* /skywalking-agent']
        volumeMounts:
        - name: skywalking-agent
          mountPath: /skywalking-agent

轻量做法：也可将 Agent bake 进镜像；关键是 SW_AGENT_COLLECTOR_BACKEND_SERVICES 指向 OAP 的 11800 端口。

Istio Sidecar 集成（Envoy 直接上报）

在 Istio meshConfig 中配置 Zipkin 到 SkyWalking OAP（OAP 兼容 Zipkin）即可：

meshConfig:
  enableTracing: true
  defaultConfig:
    tracing:
      sampling: 50.0
      zipkin:
        address: skywalking-oap.observability.svc.cluster.local:9411

滚动更新 Sidecar，网格流量会自动上报。

验证结果

转发 UI 端口：

kubectl -n observability port-forward svc/skywalking-ui 8080:8080

浏览器打开 http://localhost:8080，进入 “Trace” 或 “Topology” 查看 demo-java/Istio 服务是否出现。

手动触发流量：

kubectl -n demo exec deploy/demo-java -- curl -s http://<your-service>/health

刷新 UI，确认有新 Trace 记录，跨度名称与调用链正确。

排障清单

Agent 无法上报：检查容器能否解析 skywalking-oap，端口 11800 是否可达；查看应用日志中是否有 SkyWalking 连接错误。
Trace 采样太低：提升 sampling 或在 Java 端设置 SW_AGENT_SAMPLE=-1（全采样，验证用）。
UI 无数据但 OAP 正常：查看 skywalking-oap Pod 日志，确认存储后端是否报错（ES/ClickHouse 连接）。
Istio 未上报：确认 meshConfig 已分发，或检查 Sidecar 是否启用了 Zipkin 配置。

生产落地要点

把 OAP 存储换成外部 ES/ClickHouse，并开启持久化；OAP/ES 分开水平扩容。
给 Agent/OAP/ES 配置资源限制与 HPA；高并发环境建议单独部署 OTel Collector 进行缓冲和出口控制。
统一 service.name/env/version 标签，便于在 UI 里按环境、版本过滤。
将 Helm values 纳入 GitOps 仓库，上线前用 helm template + kubectl apply --server-dry-run 校验。
为 UI/OAP 加 RBAC/Ingress 访问控制，避免随便被访问。

总结

选型上，SkyWalking 覆盖面广、上手快；Pinpoint 适合 JVM/Php；Elastic APM 则和 ELK 一体化。文中的步骤能让你在集群里 10 分钟跑起 SkyWalking，给应用挂上探针，并在 UI 里看到真实链路。剩下的就是按业务量级加固存储、扩容 Collector，慢慢把追踪纳入日常值班和故障定位流程里。

场景与目标​

方案对比（一句话概括）​

在 K8s 部署 SkyWalking（Helm）​

接入应用（Java 和 Istio）​

Java 应用注入 Agent​

Istio Sidecar 集成（Envoy 直接上报）​

验证结果​

排障清单​

生产落地要点​

总结​