Pixie lets you see what’s happening inside your Kubernetes cluster in real-time, without you having to instrument your applications.
Let’s see it in action. Imagine you’ve got a service called frontend that’s talking to a service called user-db.
apiVersion: apps/v1
kind: Deployment
metadata:
name: frontend
spec:
replicas: 2
selector:
matchLabels:
app: frontend
template:
metadata:
labels:
app: frontend
spec:
containers:
- name: frontend
image: your-frontend-image # Replace with your actual image
ports:
- containerPort: 8080
apiVersion: apps/v1
kind: Deployment
metadata:
name: user-db
spec:
replicas: 1
selector:
matchLabels:
app: user-db
template:
metadata:
labels:
app: user-db
spec:
containers:
- name: user-db
image: your-db-image # Replace with your actual image
ports:
- containerPort: 5432
With Pixie installed in your cluster, you can run a simple px/vizier command to get a live graph of this traffic:
kubectl exec -it deploy/newrelic-pixie-vizier-0 -c vizier-pem -n vizier-system -- px ui
This opens a web UI. Navigate to the "Live Taps" section. You’ll see a list of network connections. If you filter by app: frontend, you’ll see connections to user-db on port 5432.
The magic here is eBPF. Pixie uses eBPF programs, which run directly in the Linux kernel. These programs can hook into kernel functions that handle network packets and system calls. When a packet arrives or a system call is made, the eBPF program is triggered. It can then extract information like source/destination IP addresses, ports, and even the contents of the packets (if you choose to tap them), all without modifying your application code or requiring agents to be installed on your pods.
Pixie’s core component is the Vizier-REPL, which runs inside your cluster. It’s responsible for deploying eBPF programs to the kernel of each node. When you run a Pixie script (written in a Python-like language called Pixie Cloud Scripting - PxSC), the Vizier-REPL translates it into eBPF programs and deploys them. The data collected by these eBPF programs is then sent back to the Vizier-REPL, which processes and visualizes it.
You can go deeper. Want to see the specific SQL queries your frontend service is making to user-db?
kubectl exec -it deploy/newrelic-pixie-vizier-0 -c vizier-pem -n vizier-system -- px run px/examples/http/request_table.yaml
This script, running via eBPF, intercepts network traffic and reconstructs HTTP requests. You’ll see tables of requests, including the method, path, latency, and even the request body if it’s an HTTP POST. For database traffic, you can use similar scripts to see the exact SQL statements or other database-specific commands being executed.
The real power comes from its ability to inspect traffic at the network layer and system call layer, abstracting away the complexities of different protocols and languages. You don’t need to know if your frontend is written in Go, Python, or Java, or if user-db is PostgreSQL or MySQL. Pixie sees the network packets and system calls and can reconstruct the conversations.
Most people think of Pixie as just a network monitoring tool. But its eBPF foundation means it can tap into a much wider range of kernel events. For instance, you can use it to profile CPU usage within specific pods or even trace function calls within your applications if you define specific kernel tracepoints. This makes it incredibly versatile for debugging performance issues, security investigations, and general observability.
The next step is often understanding how to correlate this low-level network and system call data with higher-level application metrics.