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 网络可观测性的能力。
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 可根据网络安全策略标记流是否丢弃 |