Inspektor Gadget：云原生时代下的 eBPF 工具链框架

Inspektor Gadget 的设计目标是简化 Kubernetes Cluster 的调试和故障排除过程。通过自动将低级内核原语映射到高级 Kubernetes 资源，提供了更直观、更快速的方式来查找相关信息。基于此，开发人员和运维人员可以更轻松地监视和分析 Kubernetes Cluster 中的应用程序行为。

使用 Inspektor Gadget，我们可以执行各种任务，例如，跟踪应用程序的系统调用、监视网络流量、分析容器之间的通信和资源利用情况等。通过与 eBPF 技术的结合，Inspektor Gadget 提供了更深入的洞察力，从而帮助我们更好地理解和解决 Kubernete s环境中的问题。

二、Inspektor Gadget 运行机制

Inspektor Gadget 通常在 Kubernetes Cluster 中作为 DaemonSet 模式部署到每个节点。利用内核的 eBPF（extended Berkeley Packet Filter）辅助程序来监控与每个 Pod 中的用户空间程序相关的系统调用事件。通过在每个节点上部署 eBPF程序，Inspektor Gadget 能够捕获和收集与应用程序行为密切相关的系统调用日志数据。

具体而言，Inspektor Gadget 的 eBPF 程序在内核中运行，并通过监视系统调用事件来收集相关的日志数据。这些事件可以涉及文件访问、网络通信、进程管理等与应用程序行为有关的操作。eBPF 程序将这些日志数据存储在内核的环形缓冲区中。

 Inspektor Gadget 的用户空间实用程序负责从内核的环形缓冲区中获取这些日志数据，并将其显示给用户。从而使得开发人员和运维人员能够查看和分析与每个 Pod 中用户空间程序相关的系统调用的详细信息，以帮助他们识别潜在的问题、调试应用程序和进行性能优化。

我们来看一下整个拓扑架构设计，具体如下所示：

基于上述拓扑架构，整个处理机制主要涉及如下：

1、Inspektor Gadget 的 eBPF 程序在运行时收集的事件会被写入一个专门的内核缓冲区。这个缓冲区是为了有效地存储和管理大量的事件数据。而I nspektor Gadget 的用户空间组件负责从这个缓冲区中读取事件，并将其发布到一个称为 “Stream” 的通道中。

2、Stream 是 Inspektor Gadget 的用户空间组件使用的一种数据流机制。它允许事件数据以实时或近乎实时的方式进行传输和处理。通过将事件发布到 Stream 中，Inspektor Gadget 提供了一种方便的方式来传递和处理从 eBPF 程序收集的事件数据。

3、为了展现这些事件数据，Inspektor Gadget 使用了内部的 kubectl exec API 接口。kubectl exec 是 Kubernetes 的一个命令行工具，用于在容器中执行命令。Inspektor Gadget 利用这个 API 接口来与容器中运行的用户空间组件进行通信，并从 Stream 中获取事件数据。

4、一旦获取到事件数据，Inspektor Gadget 的用户空间组件可以进行各种操作，比如实时显示事件日志、进行分析或将事件数据发送到其他监控系统。这种集成了 kubectl exec API 接口的方式使得 Inspektor Gadget 的用户界面更加灵活和可扩展。

针对 Gadget Tracer Manager，作为一个负责管理正在运行的小工具和容器列表的组件，维护了一个记录当前活动的小工具和容器的清单。每个正在运行的小工具都与一个 eBPF 映射相关联，该映射中存储了要跟踪的容器的挂载命名空间标识符。这些标识符是根据传递给小工具的命名空间、标签、Pod名称等参数进行填充的。

为了了解当前正在运行的容器，Gadget Tracer Manager 利用 runc-fanotify 技术。监视容器运行时的文件系统活动。通过与 runc-fanotify 集成，Gadget Tracer Manager 能够获取有关当前正在运行的容器的信息。

基于上述的这些信息，Gadget Tracer Manager 可以动态地添加或删除容器到其集合中。这意味着当容器启动或停止时，Gadget Tracer Manager 能够相应地更新其管理的容器列表。这种动态管理的能力使得 Gadget Tracer Manager 能够实时地跟踪和监控容器的行为。

基于上述的拓扑架构以及链路请求，我们可以窥探到，对于 Inspektor Gadget 而言，主要分为四个核心任务，每个任务都由以下包管理：

1、Tracers

基于整个架构角度，Inspektor Gadget 的 Tracers 主要负责从主机收集各种与应用程序行为和系统操作相关的事件的组件，利用 eBPF 技术拦截和记录进程创建、文件访问等事件，并将其保存到日志系统中，以供后续分析和检查。基于对事件的收集和记录能力为应用程序的调试和优化提供了有价值的数据来源。

2、Container-Collection 

Container-Collection 组件通过追踪主机中容器的创建和删除操作，利用容器信息来丰富事件的上下文。通过将容器的元数据与事件相关联，Inspektor Gadget 能够提供更丰富和准确的事件分析和诊断功能。基于对容器信息的加工、利用从而使得事件数据更具有可操作性和可理解性。

3、Trace-Collection

而对于 Inspektor Gadget 的 Trace-Collection 组件而言，其主要利用 Container-Collection 提供的容器信息，实现了按容器的过滤和筛选功能。从而使得用户可以根据容器的标识符或其他属性，对事件进行个性化的分析和监控。基于容器过滤的能力，增强了 Inspektor Gadget 的灵活性和可定制性。

4、 Columns 

Columns 组件则主要用于创建跟踪器生成的事件的列表表示。通过解析和格式化事件记录，并以清晰的列形式呈现，使用户能够方便地浏览、分析和比较事件的属性值。这种列表视图提供了高效的事件导航和分析功能，提升了事件数据的可读性和可操作性。

三、Inspektor Gadget 运行要求

内核层面：

Inspektor Gadget 使用 eBPF 来提供其功能，并根据不同的内核版本和内核配置启用不同的 eBPF 功能。Inspektor Gadget 依赖于一种编译-导出运行（CO-RE）方法，并需要 BTF（BPF Type Format）信息来实现。BTF 信息可以从多个来源收集，如果一个来源不可用，它会尝试另一个来源。

以下是关于每个来源的更详细说明：

1、内核 BTF：内核编译时如果启用了CONFIG_DEBUG_INFO_BTF 选项，它会在 /sys/kernel/btf/vmlinux 路径下公开 BTF 信息。

2、小工具容器镜像：Inspektor Gadget 使用 BTFGen 生成一些已知内核版本的 BTF 信息，并将其包含在小工具的容器映像中。

3、BTFHub 下载：如果以上两个来源都不可用，nspektor Gadget 会尝试从 BTFHub下载 BTF 信息。

如果内核不支持 CO-RE，建议大家使用旧版本的 Inspektor Gadget（例如 v0.21.0-bcc ），该版本提供基于 BCC（BPF Compiler Collection）的工具。

需要注意的是，所有小工具在运行时都需要满足以下条件才能正常工作：

1、CONFIG_BPF=y：内核配置选项，需要确保 BPF（Berkeley Packet Filter）功能已启用。BPF 是一种灵活的内核技术，允许在内核中执行特定的程序来过滤和操作数据包、系统调用等。

2、CONFIG_BPF_SYSCALL=y：内核配置选项，需要确保 BPF 系统调用支持已启用。BPF 系统调用是用户空间程序与内核BPF程序之间进行交互的接口，允许用户空间程序加载和执行 BPF 程序。

3、CONFIG_DEBUG_INFO_BTF=y：这是与 BTF（BPF Type Format）相关的内核配置选项。BTF 是一种调试信息格式，用于描述内核中的数据结构和类型。如果主机内核的 BTF 信息不受 BTFHub 支持（即“无法从 BTFHub 下载”），则需要启用此选项以确保小工具能够访问所需的 BTF 信息。

Kubernetes 平台层面：

容器运行时层面：

针对 Inspektor Gadget 的安装配置，相对来说较为简单，大家若有兴趣，可查阅官方相关文档。