K8s 应用的网络可观测性： Cilium vs DeepFlow

随着分布式服务架构的流行，特别是微服务等设计理念在现代应用普及开来，应用中的服务变得越来越分散，因此服务之间的通信变得越来越依赖网络，很有必要来谈谈实现微服务可观测性中越来越重要的一环——云原生网络的可观测。K8s 是微服务设计理念能落地的最重要的承载体，本文主要聚焦谈谈 K8s 的网络可观测性，以及其给基础设施/应用等团队能带来的价值。

谈 K8s 网络可观测性之前，先简单了解下 K8s 的网络通信是如何实现的，CNCF 定义了容器网络接口即 CNI，CNI 提供了一种应用容器的插件化网络解决方案，定义对网络容器进行操作和配置的规范，通过插件的形式对 CNI 接口进行实现。实现了 CNI 接口则成为 CNI 插件，常见的 CNI 插件包括 Calico、Cilium、Flannel、Kube-OVN、Terway、Weave Net 等，每种 CNI 插件都有自己的偏重性，使用者可用根据环境限制、功能需求和性能需求等各种方面选择自己所需的 CNI 插件。但是目前针对这种类繁多的 CNI 插件并没有统一的网络可观测手段，对 K8s 网络问题的排障定位的前提是需要学习这众多 CNI 插件的原理，对于 K8s 运维或者微服务开发同学们来说学习成本高，而这么高的学习成本学成之后也只能用来回答「网络是不是瘫痪了」这类二极管问题，孤立的看网络只能看到一个个虚拟网口、虚拟网桥、网络策略，但看不到其中流动的每一个访问路径，每一次应用调用，因此也就无法回答关于访问路径、应用调用等这类细粒度的问题。

目前已经开始有一些 CNI 插件厂商在支持 K8s 网络可观测性了，例如 Cilium 单独起了一个子项目 Hubble 来做分布式网络和安全的可观测性，目前已知的如 Calico，Kube-OVN 等也开始推进网络可观测性能力了；也有纯第三方厂商在做 K8s 网络可观测性，DeepFlow 就实现了一种与 CNI 插件无关的网络可观测性能力。下面将重点介绍下 Hubble 和 DeepFlow 两个组件，看看目前 K8s 网络可观测性的能力。

0x0 Hubble

Hubble 是一个用于云原生工作负载分布式的 K8s 网络和安全观测平台，它构建在 Cilium 和 eBPF 之上，能观测服务的通信行为，也观测网络基础设施的通信行为。

Hubble 的组件架构图，包含 CLI/Server/Metrics/Relay/UI，其中 Server 负责采集网络可观测性数据；Relay 对外提供统一的 API 入口，提供集群可观测能力；CLI 是一个命令行工具；Metrics 负责将指标数据输出给 Prometheus，因此可以在 Grafana 构建 Hubble 指标数据的 Dashboard；UI 这是目前还在 Beta 中，主要展示服务依赖/通信拓扑

架构图

在部署 Cilium 时，需要手动开启 Hubble，根据自身所需数据，按需设置 Hubble 配置

1
2
3
4
5
6
7
8
9

helm install cilium cilium/cilium \
--version 1.13.0    \
--namespace kube-system \   
--set prometheus.enabled=true \   
--set operator.prometheus.enabled=true \   
--set hubble.enabled=true  \
--set hubble.ui.enabled=true \
--set hubble.relay.enabled=true \  
--set hubble.metrics.enableOpenMetrics=true -f cilium.yaml

以下是 Hubble 提供的主要能力，结合 UI 页面与 Grafana 提供的 Dashboard 来展示

服务依赖/通信拓扑，以服务的维度查看通信拓扑

服务依赖/通信拓扑

网络监控/告警，包含网络协议/端口/丢包等指标、流日志详情

网络监控/告警

应用监控，包含 HTTP / DNS 的 RED 指标及调用日志详情

应用监控

安全可观测性，结合网络安全策略与流量，观测流量通过情况

安全可观测性

0x2 DeepFlow

DeepFlow 是一个高度自动化的可观测性平台，基于 AF_PACKET、BPF、eBPF、WASM 等技术，无需依赖 CNI 插件，既能观测 K8s 网络的通信行为进行观测、也能让构建在 K8s 上的云原生应用的无需埋点插码就能具备可观测性。

DeepFlow 由 Agent 和 Server 两个进程组成。每个 K8s 容器节点、虚拟机或物理裸机中运行一个 Agent，负责该服务器上所有应用进程的 AutoMetrics 和 AutoTracing 数据采集。Server 运行在一个 K8s 集群中，提供 Agent 管理、数据标签注入、数据写入、数据查询服务。

架构图

DeepFlow 可以做到 CNI 插件和应用都无感知情况下，一条命令五分钟就能让 K8s 网络和云原生应用的具备可观测性

1

helm upgrade deepflow-agent -n deepflow deepflow/deepflow-agent -f values-custom.yaml

l
DeepFlow 产品可视化，有 UI 界面 和 Grafana Dashboard 两种形式，以下产品功能主要基于 UI 界面形式

全景调用拓扑，包含服务依赖拓扑以及覆盖网络各个节点的网络路径拓扑

服务拓扑

网络路径拓扑

全链路分布式拓扑，面向用户请求的零侵扰分布式追踪，可从代码追踪到系统进程并进一步追踪到网络节点

调用链追踪

网络监控，包含覆盖三四层负载、时延、异常、性能等网络指标、分钟粒度的流日志及包粒度的时序图

网络指标

流日志

时序图

应用监控，包含HTTP(S)、Dubbo、gRPC、ProtobufRPC、SOFARPC、MySQL、PostgreSQL、Redis、Kafka、MQTT、DNS等协议的 RED 指标及调用日志

应用指标

调用日志

0x3 总结

通过分析 Hubble 和 DeepFlow 两款产品，虽然是不同厂商在做，但是对于 K8s 网络可观测性的功能点上其实是有一样的认知，笔者基于两个产品能力以及业界对可观测性数据的定义，总结了 K8s 网络可观测性应该具备的能力如下：

• 全景展示：服务依赖拓扑
• 指标数据：应用指标/网络指标
• 日志数据：应用调用日志/网络流日志/网络时序图
• 追踪数据：应用调用链追踪/网络路径追踪

为了方便大家更好的了解在 K8s 网络可观测性上 Hubble 和 DeepFlow 平台的差异，总结表格如下：

0x4 参考文档

• https://github.com/cilium/hubble
• https://docs.cilium.io/en/stable/overview/intro/
• https://github.com/deepflowio/deepflow
• https://deepflow.io/docs/zh/about/overview/