Inspektor Gadget: eBPF Inspection for Kubernetes and Linux

What Inspektor Gadget Is For

The problem is visibility below the container boundary. Once a workload is running, the interesting failures often live in syscalls, file opens, network connections and scheduler behaviour, and those are not visible from application logs or from the Kubernetes API. Inspektor Gadget exists to collect that data with eBPF, the kernel's in-tree tracing and programmability layer, and to present it in terms of Kubernetes resources rather than raw PIDs.

The audience is narrow but real. The README describes the project as "a set of tools and framework for data collection and system inspection on Kubernetes clusters and Linux hosts using eBPF". That covers platform engineers debugging a node, security teams watching for unusual syscall patterns, and developers who write their own eBPF tooling. The repository layout reflects this: cmd/ holds the binaries, gadgets/ holds the shipped gadgets, pkg/ holds the reusable machinery, and internal/ holds the parts that are not part of the public surface. A Go module at go.mod exposes the library for embedding, so the same code that powers the CLI can be called from a Go program.

It is not a general observability platform. There is no long-term storage, no dashboard, and no alert routing in the README. The project collects and exports; something else has to keep the data.

Gadgets as OCI Images, and How Enrichment Works

The central design decision is packaging. An eBPF program, its maps and its metadata are built into an OCI image, and the project calls the result a Gadget. That means the same distribution machinery used for containers applies: a gadget has a tag, can be pulled from a registry, and can be pinned by digest. The README lists "Build and package eBPF programs into OCI images called Gadgets" as the first feature, and the note points to v0.31.0 as the release where this image-based model arrived.

The second mechanism is enrichment. Raw kernel events carry identifiers such as a PID or a cgroup ID. Inspektor Gadget maps those to higher-level resources, so an event can be attributed to a Kubernetes pod, namespace or container runtime. The README calls this out as a feature and links to a section titled "What is enrichment". This is the part that makes the tool usable on a cluster: without it, you are reading kernel output and guessing which workload produced it.

A third layer is WebAssembly. The README states that the project supports WASM modules to post-process data and to customize operators, using any WASM-supported language. The wasmapi/ directory at the repository root is the interface for that. In practice this means filtering and reshaping can happen in the gadget pipeline rather than in a downstream consumer.

The framework also supports several modes of operation: a CLI, a client-server split, an API, and embedding as a Go library. Those are not separate products; they are entry points into the same collection path.

Installing kubectl gadget with krew and Running trace_open

On Kubernetes, the README recommends krew for installing the kubectl plugin. After krew itself is set up, three commands install the plugin, deploy the cluster-side components, and run a gadget. The deploy step is what creates the DaemonSet that gives the gadget access to each node, so it should be run once per cluster.

kubectl krew install gadget
kubectl gadget deploy
kubectl gadget run trace_open:latest

The trace_open gadget fires when a file is opened. After the third command you should see a stream of events, each with the process and the file path, and on a cluster with enrichment, the owning pod and namespace. The README also notes that kubectl-gadget is packaged for several distributions, with a link to a repology page listing them.

If you would rather not install anything, the README shows running ig on a node through kubectl debug:

kubectl debug --profile=sysadmin node/minikube-docker -ti --image=ghcr.io/inspektor-gadget/ig:latest -- ig run trace_open:latest

The node name and the profile are part of the command; the sysadmin profile is what grants the privileges the gadget needs. On a plain Linux host, the README installs the ig binary from a GitHub release tarball into /usr/local/bin and then runs the same gadget:

IG_ARCH=amd64
IG_VERSION=$(curl -s https://api.github.com/repos/inspektor-gadget/inspektor-gadget/releases/latest | jq -r .tag_name)

curl -sL https://github.com/inspektor-gadget/inspektor-gadget/releases/download/${IG_VERSION}/ig-linux-${IG_ARCH}-${IG_VERSION}.tar.gz | sudo tar -C /usr/local/bin -xzf - ig

sudo ig run trace_open:latest

There is also a container path, which the README shows as a single docker run with --privileged, / mounted at /host, and --pid=host. That combination is the minimum for a gadget to see host processes, and it is worth reading twice before running it on a shared machine.

Running ig on a Host from macOS or Windows

eBPF is a Linux kernel feature, so ig cannot collect data on macOS or Windows. The project's answer is a split: ig runs on a Linux machine in daemon mode and exposes an endpoint, and a separate gadgetctl binary on the client machine talks to it. The README shows the daemon started with TLS disabled and bound to all interfaces on port 1234:

sudo ig daemon --tls-insecure --host=tcp://0.0.0.0:1234

The --tls-insecure flag and the 0.0.0.0 bind are both worth pausing on. That configuration accepts unencrypted connections from anywhere that can reach the port, and the README presents it as the simplest way to get started, not as a hardened deployment. The client side then points at the daemon's address:

gadgetctl run trace_open:latest --remote-address=tcp://$IP:1234

The README links gadgetctl downloads for macOS amd64, macOS arm64 and Windows amd64. Note that those links point at v0.30.0 in the text, older than the v0.56.0 release listed at the top of this article. If you follow the README literally you may end up with a client from an earlier line than the daemon you are running. Check the releases page rather than copying the URL.

Where Inspektor Gadget Is the Wrong Tool

The first constraint is privilege. Running a gadget means loading eBPF programs into the kernel, which requires capabilities most clusters deliberately withhold. The kubectl debug example uses the sysadmin profile for exactly this reason, and the container example uses --privileged. On a cluster with a restrictive Pod Security admission policy, or on managed nodes where you cannot create privileged pods, the deploy step will not produce a working DaemonSet. The README does not document a fallback for that case.

The second constraint is the kernel itself. eBPF features vary by kernel version, and the Makefile's CI kernel image is pinned at 6.15.5-debug, which gives a sense of what the project tests against. Older distribution kernels will not support every gadget. The README does not publish a minimum kernel version, so this is something to establish against your own fleet rather than from the documentation.

The third is scope. If your question is "why is this HTTP request slow", you want distributed tracing, not syscall events. Inspektor Gadget answers questions about what the kernel is doing, and it will not tell you which of your services is misconfigured. It also has no storage layer, so anything you want to keep has to be exported. The README mentions export to observability tools and a Prometheus exporter appears in the repository topics, but the README itself does not describe the export configuration in the excerpt available here.

How It Compares to bpftrace and BCC

The obvious alternative for the same job is bpftrace. Both load eBPF programs and both can trace file opens, syscalls and network activity, so the difference is not what they can observe but how the program is delivered and who consumes it.

bpftrace is a single binary with a scripting language. You write a short script, run it, and read the output. There is no image, no registry, no deployment step, and no Kubernetes awareness beyond whatever you build into the script. That makes it faster for one-off questions on a single host, and it means the script is the artifact you version and share.

Inspektor Gadget inverts that. The gadget is a packaged artifact with an OCI tag, deployed through a DaemonSet on Kubernetes or run by ig on a host, and the output is enriched with Kubernetes and container metadata before you see it. The cost is infrastructure: you deploy something, and it needs privileges. The benefit is that the same gadget runs identically across a fleet, and its output already knows which pod it came from. If you are debugging one machine, bpftrace is lighter. If you are running the same query across a hundred nodes and need to know which workload each event belongs to, the packaging and enrichment are the reason to pick Inspektor Gadget.

For a third point of comparison, the repository's go.mod depends on github.com/cilium/ebpf, the same Go library many eBPF tools build on. That is not an alternative product, but it does mean the low-level loading path is shared with a large part of the ecosystem.

Maintenance, Licensing and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-23. Recent releases are v0.56.0 on 2026-09-07, v0.55.1 on 2026-08-21 and v0.55.0 on 2026-08-03, so the release cadence is roughly monthly with patch releases in between. Those are pre-1.0 version numbers, which is the practical upgrade signal: minor releases can carry behaviour changes, and the README's own note that "Major new functionality was released in v0.31.0" shows the project has already made one large architectural shift to image-based gadgets.

That shift is the main upgrade cost. Gadgets are OCI images referenced by tag, and a tag like trace_open:latest moves. Pinning by digest is the way to keep a deployment reproducible, and the project's security features for restricting which gadgets can run suggest the maintainers expect operators to care about that. The Makefile shows a VERIFY_GADGETS variable defaulting to false, and the go.mod pulls in sigstore and notaryproject dependencies, so signature verification exists as an option rather than a default.

On licensing: the repository is Apache-2.0, and there is a second file, LICENSE-bpf.txt, carrying GPL-2.0 for the eBPF programs. That split is normal in this space because of kernel licensing conventions, but it means the answer to "what licence is this" depends on which part you are redistributing. The README does not spell out the boundary between the two, so if you plan to ship a modified gadget inside a product, read both files and get your own legal advice rather than inferring from the badge.

Editorial conclusion

Adopt Inspektor Gadget if you debug Linux kernels or Kubernetes nodes and can run privileged workloads there; skip it if you need a managed service or cannot grant those privileges. Before rolling it out, verify that your kernel exposes BTF, that your cluster policy allows the gadget DaemonSet, and that the trace_open gadget returns events on one node. The project is Apache-2.0, with eBPF programs under GPL-2.0 in LICENSE-bpf.txt, and the last push was on 2026-09-23.

Frequently asked questions

Official sources

1. inspektor-gadget/inspektor-gadget on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases