Pixie: Kubernetes Observability with eBPF and No Code Changes

Zero-Instrumentation Visibility for Kubernetes Engineers

The core problem Pixie solves is that conventional observability tools require application-level changes: SDK imports, manual trace spans, metric registrations, or sidecar proxies. Teams operating many services cannot always guarantee that every deployed binary carries the right instrumentation. Pixie bypasses that entirely.

Pixie is built for engineers who operate Kubernetes clusters and need to diagnose incidents, inspect traffic, or profile applications without touching source code or waiting for a redeploy. It is particularly useful when debugging services built by other teams, analysing black-box dependencies, or responding to an incident where redeployment is not an option.

The project is part of the Cloud Native Computing Foundation (CNCF) ecosystem, which means it follows CNCF governance and contribution standards. The repository lists an ADOPTERS.md file, suggesting organizations are running it in production.

How eBPF Auto-Telemetry Collects Data Without Instrumentation

eBPF (extended Berkeley Packet Filter) is a Linux kernel mechanism that lets programs run in a sandboxed environment inside the kernel without modifying kernel source or loading kernel modules. Pixie attaches eBPF probes to the kernel at the system call and network layer, which means it intercepts data as it passes through the operating system rather than at the application level.

This architecture gives Pixie three capabilities that instrumentation-based tools cannot match without code changes. First, it captures full-body HTTP, gRPC, MySQL, PostgreSQL, Redis, Kafka, and DNS requests and responses as they traverse the kernel. Second, it records CPU profiles and memory usage per pod and node. Third, it captures network flow data including TCP drops and retransmits. All of this happens on every pod in the cluster by default.

Pixie runs its data collection agents inside the cluster through a component called Vizier. Vizier stores all collected data locally in the cluster nodes. According to the README, Pixie uses less than 5% of cluster CPU and in most cases less than 2%. The in-cluster storage model means no telemetry data leaves the cluster boundary unless the operator explicitly exports it.

PxL: Querying Cluster State with a Pythonic Script Language

Once Vizier is collecting data, the primary way to extract insights is through PxL (Pixie Language), described in the README as a flexible Pythonic query language. PxL scripts run across Pixie's web UI, CLI, and client APIs, which means the same query logic works interactively in a browser and programmatically in automation.

The scripting model is a deliberate design choice. Rather than building a fixed dashboard per use case, Pixie exposes a data model that engineers can query directly. The project ships scripts for common scenarios including service maps, CPU flame graphs, individual request traces, and database query profiling. Because the query language is Pythonic, engineers familiar with pandas-style data manipulation can write custom scripts without learning a proprietary DSL.

The CLI component is versioned separately from Vizier. The latest CLI release documented in the repository is v0.8.8. The API interface allows embedding Pixie data into external tools or custom dashboards.

Installing Pixie and Getting to the First Query

The README states that installation takes a few minutes and directs users to the Install Guides at docs.px.dev/installing-pixie/install-guides/. The site documents multiple installation paths depending on the Kubernetes distribution (GKE, EKS, AKS, kind, and others). The README does not include the actual installation commands, which differ by Kubernetes distribution.

Once Vizier is running in the cluster, there are three interfaces available: the web-based Live UI, the CLI (the px command), and a client API. The Live UI shows a service topology view and a script browser immediately after install. The CLI allows scripting and automation. The API allows integration with external dashboards or incident-response workflows.

The Makefile in the repository shows that the build system is Bazel, and the go.mod declares Go 1.24.6 as the minimum version. The repository contains C++ source alongside Go, reflecting the eBPF probes and Vizier data plane being written in C++ while the control plane and tooling use Go.

Use Case Coverage: Protocols, Profiles, and bpftrace Programs

The README documents eight named use cases: network monitoring (DNS, TCP drops, flow), infrastructure health (CPU flame graphs per pod and node, resource usage by namespace), service performance (latency, error and throughput rates per endpoint), database query profiling (full-body queries with latency breakdowns), request tracing (full-body requests for supported protocols), continuous application profiling, distributed bpftrace deployment, and dynamic Go logging.

The distributed bpftrace deployment capability is notable: operators can push a bpftrace program to every node in the cluster through Pixie, which then collects the output into a queryable table. This turns bpftrace from a per-node tool into a cluster-wide diagnostic primitive.

Dynamic Go logging allows debug logging to be injected into a compiled Go binary running in production without recompiling or redeploying the binary. The README frames this as useful for production debugging scenarios where modifying and redeploying a service would take too long or introduce risk.

Where In-Cluster Storage Creates Constraints

The in-cluster storage model that keeps resource usage low also creates a hard boundary: all Pixie data lives inside the cluster. For compliance frameworks that require log or trace data to be shipped to a centralized SIEM or long-term storage system, Pixie alone does not cover that requirement. The README does not document an export path or a retention configuration for telemetry data.

eBPF requires a compatible Linux kernel, so Pixie does not run on Windows nodes or on clusters using older kernel versions. The project is designed exclusively for Kubernetes; it cannot observe workloads running on bare metal or virtual machines outside a cluster.

Protocol support is bounded. Pixie traces the protocols it ships with: HTTP, gRPC, MySQL, PostgreSQL, Redis, Kafka, and DNS are documented in the README, but proprietary binary protocols or custom application-layer protocols over raw TCP would not be decoded. Requests on unsupported protocols appear in Pixie's network flow data but without body content.

The Vizier component, which runs in the cluster, is versioned separately from the CLI and UI. The repository shows Vizier releases at v0.14.16-pre-* as of mid-2026, indicating that the cluster-side component is still on a pre-release track.

Pixie Versus Prometheus and Grafana

Prometheus is a pull-based metrics system where applications expose a /metrics endpoint, or where exporters translate service-specific data into the Prometheus format. Grafana visualizes those metrics. This model gives teams fine control over exactly what data is collected and at what cardinality, but it requires that every service either expose a Prometheus endpoint or have an exporter maintained alongside it.

Pixie's difference is the collection layer: there is no endpoint to expose and no exporter to maintain. The trade-off runs the other direction. Prometheus excels at long-term metric storage, alerting rules, and recording rules that derive new metrics from existing ones. Its ecosystem includes hundreds of exporters and connectors to alert managers and on-call systems. Pixie's in-cluster retention means it is not suited for trend analysis over weeks or months, and it does not have a native alerting layer.

The two tools address different layers of observability. Pixie handles deep, real-time inspection of individual requests and profiles with zero instrumentation. Prometheus handles aggregated metrics over time with a mature ecosystem for alerting. Teams often run both, using Pixie for incident investigation and Prometheus for SLO tracking.

License and Maintenance

The repository carries an Apache-2.0 license, which permits commercial use, modification, and distribution without requiring derivative works to carry the same license. The CNCF governance structure means contribution and decision-making processes are documented in GOVERNANCE.md and CODEOWNERS.

The last push to the repository was on 2026-09-24, reflecting recent development activity. The Vizier component releases follow a pre-release cadence with tags like v0.14.16-pre-*, so teams tracking a stable Vizier version should monitor the release page for the component they depend on. The go.mod requires Go 1.24.6, and the Bazel build system version is pinned in .bazelversion. Upgrading Go or Bazel across a major version may require corresponding changes to the build configuration.

The SECURITY.md and .snyk files indicate the project has an active security policy and dependency scanning in place.

Editorial conclusion

Pixie is a practical choice for teams running Kubernetes who need immediate visibility into request traffic, database queries, and service latency without writing instrumentation code. The eBPF approach means it works on existing clusters right away, but teams with strict data-residency requirements or long-term retention needs should verify that in-cluster-only storage fits their compliance posture before adopting it. Workloads running outside Kubernetes have no path to Pixie. The repository carries an Apache-2.0 license, and the last push was on 2026-09-24.

Frequently asked questions

Official sources

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