eBPF ，让观测性走向神坛

Hello folks，我是 Luga，今天我们来介绍一下“下一代”可观测性工具 - eBPF，作为一种强大的内核技术，eBPF 启用了全新类别的可观测性模型，除此之外， 其程序能够无缝地与各种内核关联，以收集有关正在发生的事件数据。

     通常而言，可观测性不仅仅是操作和应用程序监控，它还涉及根据整个系统的输出结果以推断环境状况。从技术发展历程来讲，真正的下一代可观测性是能够具备向系统提出问题的能力，而不是仅仅是收集各种各样的监控数据并试图将其关联起来进行展示。

     在实际的业务场景中，通常与可观测性相关联紧密的数据便是“指标”、“日志”和“链路追踪”。然而，这些数据源中的每一项都有不同的收集方法，除此，针对这些数据项进行采集可能需要多种不同的产品和代理。如果有一种方法可以以一种不引人注目、安全且跨系统一致的方式收集遥测数据以实现可观测性，并且对当前系统性能和资源使用影响最小，那会怎么样？

     或许，eBPF 将是一个不错的选择！

     众所周知，作为新一代技术，eBPF 程序可以附加到各种内核组件中，以观测、收集有关正在发生的事件数据。假设，在没有 eBPF 的情况下，我们进行相同级别的数据采集通常需要加载额外的内核模块或修改内核本身，这可能需要数年才能完成。此外，这两项活动都会增加风险和资源性能开销。而基于 eBPF 技术，可用于在多个层级收集各种数据，包括进程 ID、时间戳、系统调用和资源使用情况。毕竟，eBPF 程序由验证过的程序保护，以确保它具有合适的权限，从而不会崩溃或对系统产生负面影响。      在本篇博文中，笔者将试图解析基于 eBPF 的可观测性是什么，以及 eBPF 可以增强网络可观测性、Kubernetes 可观测性、安全可观测性以及性能可观测性的一些方法

eBPF 基础功能

     eBPF 是一种嵌入到 Linux 内核中的顶尖技术，可以在内核空间（例如 ring-0）中运行沙盒程序。它能够用于增强和扩展内核功能，无需加载任何额外的内核模块，也无需以安全可靠的方式重新编译内核。

     如果计算机内部有任何地方可以实现安全、网络、监控和分析功能——那便是操作系统内核。另一方面，内核是保守的，因为它们是所有工作系统的关键任务部分。这会减慢任何内核内部新功能的开发速度，更不用说新功能可能带来的安全隐患和风险了。

     eBPF 通过带来在内核中运行沙盒程序的能力来改变游戏规则，使得开发人员现在无需编写内核驱动程序和模块即可轻松扩展对应功能。eBPF 子系统通过使用 JIT（Just-in-Time）编译器和字节码验证引擎来保证安全性和稳定性。

     eBPF 带来了大量软件，包括软件定义网络 (SDN)、可观测性项目和基于安全的软件。它还涵盖了许多领域和用例：提供高性能数据包处理、负载均衡、挂钩关键系统调用、调试正在运行的软件等等。基本上，eBPF 可以被称为 Linux 的超能力，它允许我们基于实际的环境诉求来释放无限的创造力以解决任何复杂程度的任务。

     eBPF 从硬件级别到应用程序级别基本上可以实现的功能，具体如下所示：

Image

eBPF 观测架构

众所周知，eBPF 是一种无需更改内核源代码或加载内核模块即可在 Linux 内核中运行沙盒程序的技术。通过使 Linux 内核可编程，基础设施软件可以利用现有层，使它们更加智能和功能丰富，而无需继续向系统添加额外的复杂层。

     eBPF 的通用型观测架构参考模型，如下所示：

     基于上述观测架构模型，我们可以看到，基于用户的不同场景，无论是网络、追踪、安全以及可观测性等，User space 程序基于特定的需求信息加载 BPF 字节码信息至 Kernel space，然后在 Kernel space 中执行一系列特定的事件，最终，将事件结果反馈至 User space。

网络观测性

     通常，在没有大量开销的情况下收集网络链路追踪是使用 eBPF 的一个巨大优势。一个经典的场景案例便是 Cilium 基于 eBPF 在不需要代理或使用大量系统资源的情况下深入追踪网络流量走向。 

     基于 eBPF 技术，使得其能够访问 L3、L4 以及 L7 等不同层级的网络流量数据，基于此，我们可以观测有关流量的详细分析。在这里，我们将会看到哪些网络数据被允许或拒绝，哪些网络策略或配置导致连接出现问题等。

Image

     基于上述 2 种不同的容器网络模型场景，我们可以看到，基于传统的观测模型，如果没有 eBPF，上面的场景将需要挖掘 iptables 日志，或部署资源密集型的第三方代理和工具来跟踪流量走向，然后尝试将它们映射到策略和应用程序进程中，以实现某些特定的业务需求。

Kubernetes 观测性

     其实，除了最基础的网络层面，eBPF 在 Kubernetes Cluster 观测性层面也带来巨大优势。

     由于 Kubernetes 自身的分布式架构，其复杂性和 Kubernetes 指标的抽象性，监控和扩展 Kubernetes 集群传统上一直具有较大挑战性。Kubernetes 管理员对内核级别的资源消耗缺乏可见性，这使得缩放和微调变得相当困难。此时，基于 eBPF 可以通过跨 Kubernetes Cluster 在内核级别收集粒度数据来提高可观察性。

     诚然，随着容器技术的发展，云原生生态理念的普及，Kubernetes 提供了很多平台都无法具备的功能，但它也带来了额外的复杂性。将 eBPF 用于 Kubernetes 可观测性是非常有必要的，因为无需（或开销）在整个集群中推送代理或 Sidecar 即可对遥测进行内在访问。eBPF 程序可以访问 Pod 级别的网络指标，并且不仅可以本地理解 IP 和端口，还可以理解服务身份和 API 调用，然后将数据暴露至 Grafana 等操作仪表板。相同的可观测流量数据和身份意识让用户更进一步动态了解整个 Kubernetes Cluster 网络运行策略。

     事实上，在 eBPF 技术之前，能够实时了解应用层事件行为发生的情况，然后使用数据进行故障排除和主动策略管理并不容易，这在很大程度上是由于 iptables 等内置工具的局限性所导致。

     除此之外，eBPF 还可以通过资源利用增强 Kubernetes 的可观测性，同样不会增加系统开销。通过 eBPF 技术，可以展现系统资源运行情况以便我们能够基于说收集的数据进行更深入的理解、分析，并指导和优化其他工具和流程，例如布局、大小调整以及一般应用程序和基础架构优化等。

     基于上述所述，eBPF 程序可以在整个 Kubernetes Cluster 中收集内核级别的粒度数据，使团队能够更轻松地扩展集群。eBPF 能够提供如下好处：

     1、服务级监控—监控特定容器实例级别中的流程更容易，使得团队能够追踪资源消耗模式。

     2、粒度— eBPF 程序提供比日志更详细的信息，提高了整体可见性。

     3、易于部署— eBPF 不需要像日志代理使用的 Sidecar 容器那样的特殊模式，基于操作系统层面工作，使得其消耗的资源更少，开销最小，效益最大化。

性能观测性

     针对资源的性能可观测性讨论较少，但随着应用程序变得更加多样化并转向微服务和容器化云原生环境，eBPF 所提供的增强可观测性功能变得尤为重要。虽然，许多性能优化用例仍处于早期开发阶段，但到目前为止性能可观测性方面的进展是有希望的，并且显示了用例的流行程度。

     增强性能可观测性所涉及的功能场景包括如下：

     1、映射 Pod 级网络吞吐量

     2、端到端网络吞吐量和延迟

     3、每个进程的 CPU 和内存利用率等能力。

     或许，在不远的将来，eBPF 将成为云原生领域中性能可观测性的核心工具之一，因为我们继续寻找在“最佳瓶颈点”（Process/Container/Pod）优化系统和应用程序性能的方法，以及通过映射端到端的总体系统性能（节点/集群/跨集群/跨云等）。

安全观测性

     针对安全性观测，或许是 eBPF 天生所具备的优势。eBPF 能够为用户提供了对整个系统中通信流的内在、深入的可见性。基于 eBPF 的安全可观测性用例场景较为丰富，不但包括解锁极其精细的流程可见性，以及端到端流程和流观测。即使在 Kubernetes 中运行的简单微服务应用程序中，了解短暂的无状态环境中的通信模式通常也需要基于代理的深度访问虚拟和物理网络。添加具有多种协议的 L4-L7 流量，我们便有了 eBPF 的理想候选者。借助 eBPF，TLS 流量遍历 Pod、Node 和云平台来跨层进行检测。       类似的项目，例如 Hubble 便是基于 eBPF 来收集网络流量数据，例如行为的突然变化、特定进程的活动微爆发表明潜在的利用或攻击、服务到服务的通信模式等等。它们还允许用户扫描以查看网络事务，以了解涉及哪些 Pod、进程和系统调用。eBPF 使用户能够访问 5 元组信息，以便通过历史数据实时深入了解 UDP 和 TCP 事务状况。

🚀 process default/privileged-pod /usr/local/bin/crictl exec -it e1accc0422efb7f21b5063c4b3eaf530b28eb9ede373f94e86bf13a58bf02550 /bin/bash🔧 
tcp_connect default/privileged-pod /usr/local/bin/crictl 127.0.0.1:64205 -> 127.0.0.1:43213🚀 
process kind-control-plane /usr/bin/python 🚀 
process kind-control-plane /usr/bin/curl https://raw.githubusercontent.com/realpython/python-scripts/master/scripts/18_zipper.py🔧 
tcp_connect kind-control-plane /usr/bin/curl 10.244.0.5:61673 -> 185.199.110.133:443⁉️ 
syscall kind-control-plane /usr/bin/curl tcp_close💥 
exit    kind-control-plane /usr/bin/curl https://raw.githubusercontent.com/realpython/python-scripts/master/scripts/18_zipper.py 0💥 
exit    kind-control-plane /usr/bin/python  0

     其实，从本质上来讲，安全性和网络可观测性是相互相辅相成的，用户可以利用 eBPF 和 API 驱动的基础架构的功能来创建可编程控件，并可以创建可以在实时环境中观测甚至采取行动的策略。

     eBPF 为用户空间和内核提供统一的跟踪接口，不需要额外的代码检测。首先，因为追踪发生在内核中，即使在基于代理或 Sidecar 追踪失败的情况下，eBPF 追踪也会继续。其次，eBPF 不会停止正在运行的进程来观测其状态，这极大地有助于保持应用程序运行时性能。eBPF 跟踪在任何系统的内核中实时发生，从而减少性能损失并降低正在运行的进程和应用程序的风险。

     使用 eBPF 进行跟踪的第三个好处是 eBPF 可以追踪系统中的所有内容，而不是局限于特定的层或进程。为了能够基于 eBPF 进行应用程序进程观测，在实际的业务场景中，我们往往无需将代码注入到所构建的应用程序中。 

     eBPF 是一个令人印象深刻的可观测性工具，与更传统的可观测性解决方案相比，它可以提供更深入的洞察力。从整个系统收集遥测数据的安全、非侵入性方式的优势是过去没有许多产品、应用程序级代理和非常复杂的操作所无法获得的。无需深入了解 eBPF 编程即可获得使用 eBPF 的优势。eBPF 正在发展成为可观测性的标准基础，将数据输入 Grafana 等工具，以及 Kubernetes 和其他系统中的技术，例如许多顶级云公司的技术。eBPF 不是最终目标，而是使用户能够达到深度最终目标的工具和方法。

        Adiós !