关于运维:K8s-应用的网络可观测性-Cilium-VS-DeepFlow

34次阅读

共计 2765 个字符，预计需要花费 7 分钟才能阅读完成。

随着分布式服务架构的风行，特地是微服务等设计理念在古代利用遍及开来，利用中的服务变得越来越扩散，因而服务之间的通信变得越来越依赖网络，很有必要来谈谈实现微服务可观测性中越来越重要的一环——云原生网络的可观测。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 网络可观测性的能力。

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 指标及调用日志详情

利用监控

平安可观测性，联合网络安全策略与流量，观测流量通过状况

平安可观测性

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 指标及调用日志

利用指标

调用日志

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

全景展现：服务依赖拓扑指标数据：利用指标 / 网络指标日志数据：利用调用日志 / 网络流日志 / 网络时序图追踪数据：利用调用链追踪 / 网络门路追踪
为了不便大家更好的理解在 K8s 网络可观测性上 Hubble 和 DeepFlow 平台的差别，总结表格如下：

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

正文完