eBPF ，让观测性走向神坛

eBPF 观测架构

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

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

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

网络观测性

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

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

     基于上述 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 !