随着分布式服务架构的流行，特别是微服务等设计理念在现代应用普及开来，应用中的服务变得越来越分散，因此服务之间的通信变得越来越依赖网络，很有必要来谈谈实现微服务可观测性中越来越重要的一环——云原生网络的可观测。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 网络可观测性的能力。
01
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 配置
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 指标及调用日志详情
安全可观测性，结合网络安全策略与流量，观测流量通过情况
02
DeepFlow
DeepFlow 是一个高度自动化的可观测性平台，基于 AF_PACKET、BPF、eBPF、WASM 等技术，无需依赖 CNI 插件，既能观测 K8s 网络的通信行为进行观测、也能让构建在 K8s 上的云原生应用的无需埋点插码就能具备可观测性。
DeepFlow 由 Agent 和 Server 两个进程组成。每个 K8s 容器节点、虚拟机或物理裸机中运行一个 Agent，负责该服务器上所有应用进程的 AutoMetrics 和 AutoTracing 数据采集。Server 运行在一个 K8s 集群中，提供 Agent 管理、数据标签注入、数据写入、数据查询服务。
DeepFlow 可以做到 CNI 插件和应用都无感知情况下，一条命令五分钟就能让 K8s 网络和云原生应用的具备可观测性
helm upgrade deepflow-agent -n deepflow deepflow/deepflow-agent -f values-custom.yaml
DeepFlow 产品可视化，有 UI 界面 和 Grafana Dashboard 两种形式，以下产品功能主要基于 UI 界面形式
全景调用拓扑，包含服务依赖拓扑以及覆盖网络各个节点的网络路径拓扑
全链路分布式拓扑，面向用户请求的零侵扰分布式追踪，可从代码追踪到系统进程并进一步追踪到网络节点
网络监控，包含覆盖三四层负载、时延、异常、性能等网络指标、分钟粒度的流日志及包粒度的时序图
应用监控，包含HTTP(S)、Dubbo、gRPC、ProtobufRPC、SOFARPC、MySQL、PostgreSQL、Redis、Kafka、MQTT、DNS等协议的 RED 指标及调用日志
03
总结
通过分析 Hubble 和 DeepFlow 两款产品，虽然是不同厂商在做，但是对于 K8s 网络可观测性的功能点上其实是有一样的认知，笔者基于两个产品能力以及业界对可观测性数据的定义，总结了 K8s 网络可观测性应该具备的能力如下：
全景展示：服务依赖拓扑 指标数据：应用指标/网络指标 日志数据：应用调用日志/网络流日志/网络时序图 追踪数据：应用调用链追踪/网络路径追踪
为了方便大家更好的了解在 K8s 网络可观测性上 Hubble 和 DeepFlow 平台的差异，总结表格如下：
| 软件架构 | Hubble | DeepFlow |
|---|---|---|
| CNI依赖 | 完全依赖 Cilium | 无 |
| eBPF依赖 | 完全依赖 eBPF | 仅 AutoTracing、SSL 解密依赖 |
| 后端存储 | 使用 Prometheus 存储指标数据，不存储拓扑和日志数据 | 基于 ClickHouse 有完整的存储解决方案 |
| 数据标签 | 不支持自定义标签、开销大 | 支持 K8s 资源/K8s label 标签、开销低 |
| 产品能力 | Hubble | DeepFlow | 说明 |
|---|---|---|---|
| 服务拓扑 | 有 | 有 | Hubble 仅支持 service 维度；DeepFlow 可支持按任意 Tag 聚合为拓扑 |
| 应用指标 | 有 | 有 | Hubble 支持 HTTP/DNS/Kafka协议；DeepFlow 支持十余种协议，且正在支持 WASM 插件解析私有协议 |
| 应用调用日志 | 无 | 有 | 查看详细的调用信息 |
| 应用调用链追踪 | 无 | 有（仅企业版） | 更好的和应用结合，快速确定问题发生在应用、系统还是网络 |
| 网络指标 | 有 | 有 | Hubble 只有流量/包量统计；DeepFlow 指标量更丰富，还涉及时延、异常、性能的指标 |
| 网络路径拓扑 | 无 | 有 | 可快速知道问题发生的网络位置 |
| 网络流日志 | 有 | 有 | Hubble 可根据网络安全策略标记流是否丢弃；DeepFlow 可给流增加更多的标签和指标 |
| 网络时序图 | 无 | 有（仅企业版） | 可更加深入分析包的交互 |
| 网络安全 | 有 | 无 | Hubble 可根据网络安全策略标记流是否丢弃 |
04
参考文档
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/
