Cilium 和 Hubble 简介

本文将为你简要介绍 Cilium 和 Hubble。

什么是 Cilium？

Cilium 是开源软件，用于透明地保护使用 Docker 和 Kubernetes 等 Linux 容器管理平台部署的应用服务之间的网络连接。

Cilium 的基础是一种新的 Linux 内核技术，称为 eBPF，它使强大的安全可视性和控制逻辑动态插入 Linux 本身。由于 eBPF 在 Linux 内核内运行，Cilium 安全策略的应用和更新无需对应用程序代码或容器配置进行任何改动。

什么是 Hubble？

Hubble 是一个完全分布式的网络和安全可观测性平台。它建立在 Cilium 和 eBPF 之上，以完全透明的方式实现对服务的通信行为以及网络基础设施的深度可视性。

通过建立在 Cilium 之上，Hubble 可以利用 eBPF 实现可视性。依靠 eBPF，所有的可视性都是可编程的，并允许采用一种动态的方法，最大限度地减少开销，同时按照用户的要求提供深入和详细的可视性。Hubble 的创建和专门设计是为了最好地利用这些新的 eBPF 力量。

Hubble 可以回答诸如以下问题。

服务依赖和拓扑图

• 哪些服务在相互通信？频率如何？服务依赖关系图是什么样子的？
• 正在进行哪些 HTTP 调用？服务正在生产或消费哪些 Kafka 主题？

网络监控和警报

• 是否有任何网络通信失败？为什么会出现通信失败？是 DNS 的问题吗？是应用还是网络问题？通讯是在四层（TCP）还是七层（HTTP）中断的？
• 在过去 5 分钟内，哪些服务遇到了 DNS 解析问题？哪些服务最近经历了 TCP 连接中断或连接超时？未回复的 TCP SYN 请求的比率是多少？

应用监控

• 某一服务或所有集群中的 5xx 或 4xx HTTP 响应代码的比率是多少？
• 在我的集群中，HTTP 请求和响应之间的 95% 和 99% 的延迟是什么？哪些服务的性能最差？两个服务之间的延时是多少？

安全观察性

• 哪些服务由于网络策略而被阻止连接？哪些服务被从集群外访问过？哪些服务解析了一个特定的 DNS 名称？

为什么使用 Cilium 和 Hubble？

现代数据中心应用程序的开发已经转向面向服务的体系结构（SOA），通常称为微服务，其中大型应用程序被分成小型独立服务，这些服务使用 HTTP 等轻量级协议通过 API 相互通信。微服务应用程序往往是高度动态的，作为持续交付的一部分部署的滚动更新期间单个容器启动或销毁，应用程序扩展 / 缩小以适应负载变化。

这种向高度动态的微服务的转变过程，给确保微服务之间的连接方面提出了挑战和机遇。传统的 Linux 网络安全方法（例如 iptables）过滤 IP 地址和 TCP/UDP 端口，但 IP 地址经常在动态微服务环境中流失。容器的高度不稳定的生命周期导致这些方法难以与应用程序并排扩展，因为负载均衡表和访问控制列表要不断更新，可能增长成包含数十万条规则。出于安全目的，协议端口（例如，用于 HTTP 流量的 TCP 端口 80）不能再用于区分应用流量，因为该端口用于跨服务的各种消息。

另一个挑战是提供准确的可视性，因为传统系统使用 IP 地址作为主要识别工具，其在微服务架构中的寿命被大大缩短，可能才仅仅几秒钟。

利用 Linux eBPF，Cilium 保留了透明地插入安全可视性 + 强制执行的能力，但这种方式基于服务 /pod/ 容器标识（与传统系统中的 IP 地址识别相反），并且可以根据应用层进行过滤（例如 HTTP）。因此，通过将安全性与寻址分离，Cilium 不仅可以在高度动态的环境中应用安全策略，而且除了提供传统的三层和四层分割之外，还可以通过在 HTTP 层运行来提供更强的安全隔离。

eBPF 的使用使得 Cilium 能够以高度可扩展的方式实现以上功能，即使对于大规模环境也不例外。

功能概述

以下是关于 Cilium 可以提供的功能的概述。

透明的保护 API

能够保护现代应用程序协议，如 REST/HTTP、gRPC 和 Kafka。传统防火墙在三层和四层运行，在特定端口上运行的协议要么完全受信任，要么完全被阻止。Cilium 提供了过滤各个应用程序协议请求的功能，例如：

• 允许所有带有方法 GET 和路径 /public/.* 的 HTTP 请求。拒绝所有其他请求。
• 允许 service1 在 Kafka topic1 主题上生产，service2 消费 topic1。拒绝所有其他 Kafka 消息。
• 要求 HTTP 标头 X-Token: [0-9]+ 出现在所有 REST 调用中。

详情请参考 七层协议。

基于身份来保护服务间通信

现代分布式应用程序依赖于诸如容器之类的技术来促进敏捷性并按需扩展。这将导致在短时间内启动大量应用容器。典型的容器防火墙通过过滤源 IP 地址和目标端口来保护工作负载。这就要求不论在集群中的哪个位置启动容器时都要操作所有服务器上的防火墙。

为了避免受到规模限制，Cilium 为共享相同安全策略的应用程序容器组分配安全标识。然后，该标识与应用程序容器发出的所有网络数据包相关联，从而允许验证接收节点处的身份。使用键值存储执行安全身份管理。

安全访问外部服务

基于标签的安全性是集群内部访问控制的首选工具。为了保护对外部服务的访问，支持入口（ingress）和出口（egress）的传统基于 CIDR 的安全策略。这允许限制对应用程序容器的访问以及对特定 IP 范围的访问。

简单网络

一个简单的扁平三层网络能够跨越多个集群连接所有应用程序容器。使用主机范围分配器可以简化 IP 分配。这意味着每个主机可以在主机之间没有任何协调的情况下分配 IP。

支持以下多节点网络模型：

• Overlay：基于封装的虚拟网络产生所有主机。目前 VXLAN 和 Geneve 已经完成，但可以启用 Linux 支持的所有封装格式。

  何时使用此模式：此模式具有最小的基础架构和集成要求。它几乎适用于任何网络基础架构，唯一的要求是主机之间可以通过 IP 连接。

• 本机路由：使用 Linux 主机的常规路由表。网络必须能够路由应用程序容器的 IP 地址。

  何时使用此模式：此模式适用于高级用户，需要了解底层网络基础结构。此模式适用于：

  • 本地 IPv6 网络
  • 与云网络路由器配合使用
  • 如果你已经在运行路由守护进程

负载均衡

Cilium 为应用容器之间的流量和外部服务实现了分布式负载均衡，能够完全取代 kube-proxy 等组件。负载均衡是在 eBPF 中使用高效的 hashtables 实现的，允许几乎无限规模扩展。

对于南北向的负载均衡，Cilium 的 eBPF 实现了最大的性能优化，可以连接到 XDP（eXpress Data Path），并支持直接服务器返回（DSR）以及 Maglev 一致的散列，如果负载均衡操作不在源主机上执行的话。

对于东西向类型的负载均衡，Cilium 在 Linux 内核的套接字层（如在 TCP 连接时）执行有效的服务到后端转换，这样就可以避免在较低层的每包 NAT 操作开销。

带宽管理

Cilium 通过高效的基于 EDT（Earlist Departure Time，最早离开时间）的速率限制来实现带宽管理，eBPF 适用于从节点流出的容器的流量。与传统的方法相比，如在 CNI 插件中使用的 HTB（Hierarchy Token Bucket，分层令牌桶）或 TBF（Token Bucket Filter，令牌桶过滤器），这可以大大减少应用的传输尾部延迟，并避免在多队列网卡下锁定。

监控和故障排除

可视性和故障排查是任何分布式系统运行的基础。虽然我们喜欢用 tcpdump 和 ping，它们很好用，但我们努力为故障排除提供更好的工具。包括以下工具：

• 带有元数据的事件监测：当一个数据包被丢弃时，该工具不只是报告数据包的来源和目的地 IP，该工具还提供发送方和接收方的完整标签信息以及许多其他信息。
• 通过 Prometheus 输出指标。关键指标通过 Prometheus 导出，以便与你现有的仪表盘整合。
• Hubble：一个专门为 Cilium 编写的可观测性平台。它提供服务依赖拓扑、监控和警报，以及基于流量日志的应用和安全可视性。

• 下一章