DeepFlow 在腾讯 TKE 内部平台的可观测性实践

赵奇圆 2025-04-27 阅读:

用户案例可观测性 meetup 实录

随着云原生技术的快速发展，越来越多的业务采用微服务架构，并将服务迁移至 Kubernetes（K8s）环境。微服务化虽然提升了单个服务的可维护性和业务开发效率，却同时增加了服务之间的依赖复杂度。一旦出现问题，往往需要耗费精力梳理业务架构来定位故障点。K8s 虽然提供了服务发现等能力，让业务方可更专注于业务逻辑，但这类功能的实现分布在各个节点或者 Pod 之中，一旦出现异常，要花费大量时间摸排问题点。为了解决这一痛点并强化业务可观测性，本文将介绍 DeepFlow 在腾讯 TKE 内部平台上的实践经验。

0x0: TKE 简介

腾讯云容器服务（Tencent Kubernetes Engine, TKE）基于原生 Kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务，覆盖 Serverless、边缘计算、分布式云等多种业务部署场景，业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者，主导开源项目Crane，全面助力客户实现资源优化、成本控制。TKE 内部平台是以 TKE 为底座，服务于腾讯自研业务的容器平台，该平台支持了大量自研业务。

0x1: 云原生场景下可观测性挑战

微服务化引入的挑战：架构复杂且变化快。微服务架构下，服务模块更多，生命周期更短，网络拓扑结构更复杂，传统的静态拓扑图不能准确体现业务网络拓扑。
K8s 化引入的挑战：潜在问题分布广。DNS，Service，NetworkPolicy 等能力实现依赖于节点或 Pod 内核，针对偶发性网络问题，需要在各个链路部署抓包工具，并且依赖业务侧配合复现问题，排障成本非常高。
推动业务改造成本高：业务技术栈差异较大（C++/Go/Python/Java等），推动业务添加日志（Log）、指标（Metrics）和链路追踪（Trace）成本很高（加哪些，怎么加都是挑战），部分遗留系统改造成本更高，风险大，难以全覆盖。

基于上述挑战，我们需要一种包含数据采集，存储和展示的可观测系统，该系统不依赖业务改造，从而实现高效率的故障排查。另外该系统对于业务性能的影响要足够小，资源占用足够少，实现长稳运行，进而支持主动分析上报业务潜在风险。

0x2: 为什么选用 DeepFlow

为实现高性能，零侵入的全栈观测，并适配 C++、Go、Python、Java 等多种技术栈，我们引入了 eBPF 技术。eBPF 是内核层面的扩展能力，它通过在内核中构建支持 eBPF 程序执行的基础框架（包含加载点、校验机制、加载和运行流程等），允许业务方在不修改内核源码的情况下，以更灵活的方式增强系统可观测性，进行性能分析和安全策略的实施（通过 eBPF 程序）。这类似于 K8s 中的 CNI、CSI 等可扩展机制，但 eBPF 作用在操作系统内核层面，并能在众多挂载点上灵活加载。

在调研业界基于 eBPF 的可观测性方案后，我们发现 Cilium/Hubble、Pixie 和 DeepFlow 相对成熟。但 Hubble 强依赖于 Cilium，落地成本较高；Pixie 则缺乏完整的数据采集、存储和展示体系。相比之下，DeepFlow 提供了全面的解决方案（涵盖网络层、应用层指标与流数据、服务拓扑以及调用链跟踪），其采集端采用 Rust 编写，性能表现良好，同时社区活跃，并已有大规模生产环境的成功实践。

0x3: 落地与优化实践

部署架构图

deepflow-server
- 一套 server 纳管多套集群
- CK 数据量只会保留 3 天，指标数据通过 Prometheus Remote Write 能力同步到 VM，保留 14 天

deepflow-server 监控

deepflow-agent
- 普通节点和超级节点性能和采集特性差别较大，采用不同的配置和 daemonset
- 默认部署模式下，apiwatcher 之前是从 agent 中选举出来，这导致 agent 和 apiwatcher 的可用性都无法保证，推动社区针对 agent 支持禁用 k8s apiwatcher，k8s apiwatcher 从 agent 中独立出来，见指引
落地情况
- x00+超级节点Pod
- 单Pod入向QPS 最大200，出向30情况下，采集程序7天内CPU占用最大0.06C，内存占用最大127M

deepflow-agent cpu/内存监控

[图片]deepflow-server 监控

deepflow-server 监控

怎么适配超级节点 Pod？

TKE 超级节点是一种 Serverless 容器服务，可以视其为一台超大规格的 CVM。当 Pod 被调度到超级节点上时，每个 Pod 都独占一台子机，从而实现 Pod 间的完全隔离。这种架构为业务带来了极高的稳定性和安全性。许多腾讯自研业务（如腾讯会议等）都运行在超级节点上。

TKE 超级节点

内存占用挑战和目标：在超级节点场景中，每个 Pod 都独占一台子机，因此每一个 Pod 内必须注入一个 deepflow-agent。内存作为不可压缩资源，一旦占用过高，不仅影响业务稳定性，还会在大规模部署中产生较高成本。我们的目标是将 deepflow-agent 内存占用控制在 100M 以内。
- 初始情况：使用默认配置启用 deepflow-agent 后，内存占用约为 260M。通过 pprof 分析发现，cBPF 模块为主要内存消耗来源，而 eBPF 模块占用较小。为此，我们在初期决定只开启 eBPF 功能，以满足应用层指标、流日志（HTTP/DNS/GRPC等）及链路拓扑观察的需求。
- 阶段一：优化 agent 内存（从 260M 降至 60M）：尽管关闭了 cBPF，agent 仍然会申请额外内存，我们向社区反馈后，社区迅速优化并合入对应 MR，将 deepflow-agent 内存降低到 60M。
- 阶段二：优化 eBPF map 内存（从 80M 降至 35M）：此时 agent 本身的内存虽已降低，但整体仍比部署前多消耗了约 140M，其中 80M 来自 eBPF Map，我们与社区讨论后采取两项措施：
  - 关闭部分无关功能（on-cpu-profile和off-cpu-profile）
  - 针对超级节点只需关注单Pod的特点，缩小 map 的配置项（如 max-trace-entries），社区很快完善了配置范围，使 eBPF Map 内存占用降至约 35M。最终，deepflow-agent 总占用从 340M 压缩至约 100M，对应讨论。
内存熔断机制：为防止内存紧张时 deepflow-agent 与业务容器争抢资源，我们启用了内存熔断机制。当系统可用内存低于 10% 时，agent 会进入静默模式。最初的判断基于 free 内存，部分业务因 buff/cache 占用过多而产生误判。我们推动社区支持了基于 available 内存判断，从而减少误告。
- Agent 完整配置

max_millicpus: 500
max_memory: 256
system_load_circuit_breaker_threshold: 2
system_load_circuit_breaker_recover: 1.8
sys_free_memory_limit: 10
sys_free_memory_metric: available
tap_interface_regex: ^notexit
vtap_flow_1s_enabled: 1
l7_log_collect_nps_threshold: 20000
external_agent_http_proxy_enabled: 0
l4_log_ignore_tap_sides: [4,9,10,17,18,25,26,33,34]
l7_log_ignore_tap_sides: [4,9,10,17,18,25,26,33,34]
static_config:
  afpacket-blocks-enabled: true
  afpacket-blocks: 8
  flow:
    flow-count-limit: 16384
    others-timeout: 2s
    established-timeout: 10s
    closing-rst-timeout: 2s
  flow-queue-size: 16384
  quadruple-queue-size: 16384
  collector-sender-queue-size: 16384
  flow-sender-queue-size: 16384
  l7-protocol-enabled: [HTTP,HTTP2,MySQL,DNS]
  l7-protocol-advanced-features:
    obfuscate-enabled-protocols: [HTTP,HTTP2,MySQL]
  ebpf:
    perf-pages-count: 32
    ring-size: 8192
    max-trace-entries: 30000
    io-event-collect-mode: 0
    on-cpu-profile:
      disabled: true
    off-cpu-profile:
      disabled: true
  ebpf-collector-queue-size: 4096

通过上述优化和机制调整，我们成功降低了 deepflow-agent 在超级节点场景下的内存占用和资源竞争风险，提升了系统的整体稳定性与成本效益。

怎么支持 StatefulSetPlus？

StatefulSetPlus 是 TKE 内部用于管理有状态服务的 Workload，广泛应用于腾讯的自研业务中。相比于原生StatefulSet，StatefulSetPlus 具备以下特性：

支持自动以及手动的分批灰度发布能力
支持 Pod 原地升级
对接了 TKE 网络插件，支持 Pod 固定 IP
单个 StatefulSetPlus 实例可管理上万个 Pod

然而，DeepFlow 默认并不识别 StatefulSetPlus。当 DeepFlow 运行在超级节点上时，由于无法正确识别这些 Pod 所属的控制器类型，导致 Pod 无法完成注册。为了解决这一兼容性问题，我们向 DeepFlow 社区提交了一个 MR 已合入 v6.6，并在 agent 组配置中加入 StatefulSetPlus 资源的识别。由于 DeepFlow 对于 CRD 的支持机制较为完善，我们只需：

定义 StatefulSetPlus 对应的 CRD 信息
为相应的 CRD 增加 watch 能力

MR 修改文件

Agent 组配置中加入 StatefulSetPlus 资源的识别：

static_config:
  kubernetes-resources:
  - name: namespaces
  - name: nodes
  - name: pods
  - name: replicationcontrollers
  - name: services
  - name: daemonsets
  - name: deployments
  - name: replicasets
  - name: statefulsets
  - name: ingresses
  - group: platform.stke
    name: statefulsets
    version: v1alpha1

0x4: 案例分享

DNS 异常业务影响评估

在某一可用区进行断电演习时，由于 CoreDNS 为单可用区部署，可能导致整个集群的 DNS 服务异常。此时，需要明确管控面服务的影响范围。然而，在未部署 DeepFlow 的情况下，面临以下主要挑战：

人工梳理工作繁琐：在部署 DeepFlow 之前，需要人工逐一梳理所有管控面服务的 Pod，并与各服务负责人协调确认其访问的 DNS 端点。这一过程不仅耗时，还容易出错。
潜在遗漏风险：即使通过抓包等方式反复确认 Pod 是否通过第三方库调用 DNS，依然可能存在遗漏，导致部分 DNS 访问未被准确识别和管理。
重复的工作流程：每当上线新服务时，都需要重新执行上述复杂的梳理和确认流程，进一步增加了运维工作量和复杂性。

DeepFlow 分析过程如下：

链路拓扑可视化：部署 DeepFlow 后，链路拓扑图能够直观地展示哪些 Pod 在访问 DNS，极大地简化了排查和管理流程。

拓扑链路可视化

DNS 访问详情一目了然：DeepFlow 还可以具体展示 Pod 访问的 DNS 端点，包括：DNS 请求的 QPS、响应时延、错误率。通过这些关键指标，运维人员能够快速评估 DNS 服务的性能和稳定性。

DNS 访问详情一目了然

快速定界偶发访问异常问题

某内部客户反馈，在服务高峰期核心业务系统出现偶发性请求超时或失败的问题，问题持续时间约 1 小时，对业务稳定性和用户体验造成了较大影响。经过初步排查，发现问题与 DNS 解析异常有关，需进一步明确具体原因并制定解决方案。

DNS 解析异常

在缺乏 DeepFlow 部署的环境中，故障排查依赖于传统的手动全链路抓包分析，需要从客户端逐层追踪至 Pod、容器、宿主机直至 DNS 服务，并且由于缺乏历史数据回溯能力，还必须等待问题复现才能采集有效数据，整个过程需要多团队协同作业，导致排查效率极其低下且 MTTR 居高不下。

分析过程对比

部署 DeepFlow 后，借助其自动化流量可视化和日志分析能力，排查效率显著提升，具体流程如下：

调用日志快速定位 DNS 异常请求：根据客户反馈的异常业务请求，通过 DeepFlow 的 DNS 流日志功能按异常 DNS 域名快速搜索流日志，直接获取异常时间段的 DNS 请求流量数据。流日志显示异常链路，明确问题所在。

调用日志

流日志精准缩小问题链路：根据流日志分析，发现客户端 Pod 和客户端节点已成功发送 DNS 请求，但 CoreDNS Pod 并未收到请求。问题链路缩小至 CoreDNS 母机 -> CoreDNS Pod 节点 -> CoreDNS Pod 路段。

定位异常点

进一步分析问题根因：检查CoreDNS 母机和 CoreDNS Pod 节点的监控数据，发现内核参数配置存在问题，迅速定位根因。

借助 DeepFlow，从排查到定位问题仅耗时半小时，大幅提升了效率。

0x5: 未来展望

启用 cBPF 功能，实现对网络三层/四层协议指标监控及流量日志采集能力
采用差异化启用策略，并与 DeepFlow 团队协作推进 cBPF 内存占用优化工作
完成与内部告警平台集成，实现基于智能分析的潜在风险主动上报机制