在 Kubernetes 环境中运行服务时，您经常会遇到一些神秘的情况，例如“配置明明都正确，为什么这个 Pod 无法与那个 Pod 通信？🤔”。即使翻遍日志或执行 `describe` 命令，原因也常常不明确。
解决这些令人沮丧的网络问题的侦探正是 Cilium Hubble。Hubble 利用 eBPF 技术，赋予我们一种神奇的能力，可以透明地洞察 Kubernetes 集群内部的所有通信。
在本文中，我们将深入探讨 Hubble 的工作原理及其内部结构。只要您正确理解这个架构，今后在面对网络问题时就不会再手足无措了！
Hubble 复仇者联盟：三位核心玩家 🦸♂️
Hubble 并非独自工作。它就像一个复仇者联盟团队，由三个具有明确职责的核心组件有机协作。
(来源: Cilium.io)
1. Hubble Agent (🕵️ 现场特工)
- 部署形式: DaemonSet (集群中每个节点一个！)
- 任务: 实时监控和收集每个节点上发生的所有网络活动的前线特工。
Agent 如何知晓一切？秘密就在于 eBPF。
- 数据检测 🔍: Cilium 利用 eBPF 深入内核，秘密监视所有网络数据包（L3/L4 信息、L7 HTTP 请求、DNS 查询等）。
- 记录到缓冲区 ✍️: 检测到的事件信息被逐一存储在 eBPF Perf Ring Buffer 中，这是内核与用户空间之间的高速通道。
- 数据处理 🍳: 部署在每个节点上的 Hubble Agent 从该缓冲区中取出数据。然后，它不仅仅是原始数据，还会附加 Pod 名称或标签等 Kubernetes 信息，将其重构为有意义的信息（Flow 对象），例如“谁与谁通信，以及是否根据策略被允许或阻止”。
- 开放本地服务器 📡: 最后，Agent 准备通过其本地 gRPC 服务器提供处理后的数据。也就是说，所有节点都在流式传输各自的实时通信记录。
> 核心要点: Agent 是所有数据收集的起点，并以 DaemonSet 形式部署，覆盖所有节点。
2. Hubble Relay (📡 中央控制站)
- 部署形式: Deployment (集群中通常只有一个！)
- 任务: 充当中央控制站，收集并整理所有分散的现场特工（Agent）的报告，并将其传递给最终用户。
如果集群中有数百个节点，我们是否需要逐一连接数百个 Agent 才能查看通信信息？🤯 光是想想就觉得可怕。Relay 正是解决了这个问题。
- 发现特工 🗺️: Relay 通过 Kubernetes API 自动发现集群中的所有 Hubble Agent。
- 汇总报告 📊: 它连接到所有已发现 Agent 的 gRPC 服务器，实时吸取每个节点流式传输的数据并将其合并为一个。
- 提供单一接口 🚪: 然后，通过其自身的 gRPC 服务器，将整个集群的聚合通信数据作为一个单一接口提供。
> 核心要点: Relay 是一个重要的组件，它集中聚合分布式数据，让用户可以在一个地方查看整个集群的情况。
3. Hubble UI & CLI (💻 指挥中心)
- 部署形式: UI (Deployment & Service), CLI (本地安装)
- 任务: 一个接口，允许我们直观地查看 Relay 提供的数据并发出命令。
- Hubble UI (可视化仪表板) ✨:
- 通过 Web 浏览器访问，它提供了一个 服务映射 (Service Map)，让您可以一目了然地查看集群中的所有服务和通信流。
- 如果某个 Pod 的通信被阻止了怎么办？它会在服务映射上显示为红线，只需点击几下，您就可以详细了解被阻止的原因（Policy denied）。这大大缩短了调试时间！
- Hubble CLI (终端命令) ⌨️:
- 您可以使用 `hubble observe` 等命令在终端中以文本形式查看实时通信流。
- 强大的过滤功能，例如 `–verdict DROPPED`（仅查看被阻止的通信）和 `–to-port 80`（仅查看发往 80 端口的通信），让您可以精确地筛选所需信息，这对于自动化脚本等也非常有用。
> 核心要点: UI 和 CLI 连接到 Hubble Relay，作为最终的网关，以我们易于理解的形式展示复杂的网络数据。
数据是如何呈现在我们眼前的？🗺️
让我们追踪一个网络数据包，看看它是如何呈现在我们眼前的。
- [内核] 📦 Pod A 向 Pod B 发送数据包。
- [eBPF] 🕵️♂️ 嵌入内核的 Cilium eBPF 程序拦截数据包，并记录源/目标信息、策略违规状态等。
- [Perf Buffer] 📝 此信息存储在内核的 eBPF Perf Ring Buffer 中。
- [Hubble Agent] 👨💻 节点上的 Hubble Agent 从缓冲区中检索数据，并添加 Kubernetes 信息以创建有意义的 Flow 数据。
- [Hubble Relay] 📡 Relay 从集群中的所有 Agent 收集 Flow 数据并进行整合。
- [Hubble UI/CLI] 🖥️ 当用户打开 UI 或执行 CLI 命令时，它会连接到 Relay，接收集成数据，并将其精美地显示在屏幕上。
理解这个流程，您就可以清楚地描绘出 Hubble 的每个部分为何必要以及它们如何协同工作。
那么，了解这些有什么好处？（核心总结）💡
理解 Hubble 架构不仅仅是积累知识，它能显著提升您的实际问题解决能力。
- Agent 是 DaemonSet vs Relay 是 Deployment: 现在您可以解释为什么它们以这种方式部署了。数据需要从所有节点收集（DaemonSet），而聚合只需在中心进行一次（Deployment）。
- 数据源是 eBPF Perf Ring Buffer: Hubble 显示的所有信息的根源是内核级别的 eBPF。这就是 Hubble 数据高度可靠的原因。
- Relay 存在的原因: 可扩展性和单一访问点！多亏了 Relay，即使在拥有数千个节点的大规模集群中，您也可以高效地监控整体情况。
- 通过 Hubble 可以了解什么:
- 简单的 IP、端口信息 (L3/L4)
- HTTP 路径、Kafka 主题等应用层信息 (L7)
- DNS 查询信息
- 最重要的是: 网络策略裁决结果 (ALLOWED / DROPPED) 👈 解决问题的决定性线索！
现在，当 Kubernetes 中出现网络问题时，不要再依赖猜测了。打开 Hubble，追踪数据流，成为一个基于明确证据解决问题的专家吧！
发表回复