Kubernetes tells you what failed. But what actually happened on the wire?
Packet capture has long been the shared troubleshooting language for network, platform, application, and security teams. When logs, metrics, traces, and flow records do not fully explain a behavior, a PCAP often does.
In the physical network, the workflow was familiar: capture traffic from a known point, export the trace, and analyze it in Wireshark. Kubernetes changes that model. Workloads move, nodes may be managed by a cloud provider, and traffic may live on primary or secondary pod interfaces. The capture request often crosses team boundaries, but the old access patterns do not map cleanly to cloud native operations.
That is why we are introducing Isopcap as part of the Isovalent Enterprise Platform. Isopcap is a Kubernetes-native packet capture product from Isovalent. It gives platform teams a declarative way to capture pod traffic using Kubernetes custom resources, while producing standard PCAP/PCAPng artifacts that networking, security, and application teams can analyze with familiar tools like Wireshark and tcpdump.
This blog explores Isopcap, why we built it, and how it helps platform, application, NetOps, and security teams bring packet capture back into the day-2 Kubernetes workflow.
Meet Isopcap
At its core, Isopcap takes a workflow that has historically lived on individual machines, jump hosts, switch ports, and capture appliances, and brings it into Kubernetes.
Instead of SSHing into nodes, installing tools, restarting workloads, adding sidecars, or asking application teams to modify pod security settings, users define a PacketCapture resource. Isopcap agents running as a DaemonSet watch for those resources, identify matching pods on each node, discover the relevant pod interfaces, and capture traffic from inside the pod network namespace.
Isopcap is not trying to replace observability signals like flows, metrics, logs, or traces. Those signals remain the right starting point for many investigations. Isopcap is for the moments when teams need packet-level evidence: the protocol exchange, the TCP behavior, the payload visibility available in the trace, or the artifact that can be handed to another team for deeper analysis.
Packet Capture, Built for Kubernetes
Packet capture is still one of the few troubleshooting artifacts that cloud native, NetOps, application, and security teams all understand. The challenge is that Kubernetes changed the operating model. Workloads move, node access is often limited, interfaces can be dynamic, and the person running the capture may not be the person analyzing it.
Isopcap brings that workflow into Kubernetes without forcing teams back to old operational patterns. Captures are defined with a PacketCapture custom resource, targeted with pod label selectors, scoped to specific interfaces, filtered with BPF, and bounded by duration or file size. Because Isopcap captures from the pod network namespace, it works across CNI choices and supports primary and secondary interfaces, including Multus, DRA, and SR-IOV use cases.
The result is a practical day-2 workflow: platform teams manage captures as Kubernetes state, while NetOps, application, and security teams receive standard PCAPng files with metadata they can trust. Isopcap also supports pre-trigger buffers, trigger-based capture behavior, file rotation, RSPAN live streaming, drop reporting, and per-node status through PacketCaptureNodeStatus.
Together, these capabilities make packet capture easier to request, safer to run, and faster to hand off during production troubleshooting and incident response.
How Isopcap Works
Isopcap is built around a simple technical idea: packet capture should behave like a Kubernetes-native operation. The user expresses intent through a Kubernetes custom resource. The Isopcap agent runs as a DaemonSet on every node, watches for PacketCapture resources, resolves matching pods on the local node, discovers the relevant pod interfaces, enters the pod network namespace, applies any BPF filters, and writes standard PCAPng output.
That model gives platform teams a controlled way to run packet captures while preserving the thing network engineers actually need: a real packet trace that can be opened in a network packet analyzer or passed to another team for analysis.
Kubernetes Packet Capture with Isopcap
Learn to capture and analyze live Kubernetes network traffic with Isovalent's Isopcap: install it, run targeted PacketCapture captures against labeled workloads, narrow them with BPF filters, and inspect the PCAPng files with tcpdump and termshark.
From Capture Request to Packet Trace
Isopcap makes packet capture feel like part of the Kubernetes workflow. Operators can select pods, choose interfaces, apply BPF filters, set capture bounds, and watch status without chasing node access or guessing at host-side interfaces. In an incident, fewer detours means faster evidence and lower MTTR.
Platform teams manage the capture as Kubernetes state. NetOps, application, and security teams get a standard PCAPng file plus enough metadata to trust the trace. Here is what that looks like in practice.
A basic Isopcap workflow starts with a PacketCapture resource. In this example, the capture targets pods labeled app: my-app and runs for 30 seconds.
apiVersion: isopcap.isovalent.com/v1alpha1
kind: PacketCapture
metadata:
name: basic-capture
namespace: default
spec:
selector:
matchLabels:
app: my-app
maxDuration: "30s"Apply the resource:
kubectl apply -f basic-capture.yamlThen watch the per-node status:
kubectl get pcapstatus -l isopcap.isovalent.com/capture=basic-capture -wImportant thing to note: the packet capture is not hidden inside a terminal session on a node. It is visible as Kubernetes state.
For a more focused capture, users can add a BPF filter and capture bounds:
apiVersion: isopcap.isovalent.com/v1alpha1
kind: PacketCapture
metadata:
name: filtered-capture
spec:
selector:
matchLabels:
app: my-app
filter: "tcp port 80"
maxDuration: "30s"
maxSize: "10Mi"This captures TCP port 80 traffic and stops when either the duration or size limit is reached.
For pods with multiple interfaces, Isopcap can target specific interfaces:
apiVersion: isopcap.isovalent.com/v1alpha1
kind: PacketCapture
metadata:
name: multi-interface-capture
spec:
selector:
matchLabels:
app: my-app
interfaces:
- name: eth0
- name: net1
maxDuration: "60s"
That is useful when the interesting traffic is not on the default pod interface, or when a workload uses secondary interfaces through Multus or DRA.
Isopcap also supports a more event-driven workflow with pre-trigger capture. Instead of continuously writing all packets to persistent storage, Isopcap can keep a rolling local buffer and only write the final pcap when a trigger fires.
apiVersion: isopcap.isovalent.com/v1alpha1
kind: PacketCapture
metadata:
name: pre-trigger-capture
spec:
selector:
matchLabels:
app: my-app
maxDuration: "10m"
preTrigger:
maxDuration: "30s"
maxSize: "10Mi"
triggers:
- name: tetragon-signal
fileWatch:
podPath: /var/run/isopcap-trigger
filePattern: "*.trigger"
postTrigger:
maxDuration: "5s"
maxSize: "50Mi"
In this example, Isopcap keeps the last 30 seconds or 10 MiB of traffic in a rolling buffer. When a matching trigger file appears inside the target pod, Isopcap captures an additional 5 seconds of post-trigger traffic and writes a merged pcap to persistent storage.
A trigger can be fired by creating the matching file:
kubectl exec my-app -- touch /var/run/isopcap-trigger/fire.triggerThis pattern is great because it captures the traffic around an event, not just after someone notices the event. For incident response and intermittent failures, that difference can be the difference between "we need to reproduce it" and "we already have the packets."
Once a capture completes, users can retrieve the file paths from status:
kubectl get pcapstatus -l isopcap.isovalent.com/capture=basic-capture \
-o jsonpath='{range .items[*].status.podStatuses[*]}{.filePaths}{"\n"}{end}'Capture output is stored under the configured output path, organized by namespace and capture name. Each pod/interface pair produces a PCAPng file and a JSON metadata file with details such as pod name, namespace, interface, label selector, filter, timestamps, capture statistics, and file paths.
From there, the workflow returns to familiar tools:
tcpdump -r capture.pcapor:
tshark -r capture.pcapor simply open the file in Wireshark.
For live workflows, Isopcap can also stream captured packets using RSPAN mode instead of writing files to persistent storage:
apiVersion: isopcap.isovalent.com/v1alpha1
kind: PacketCapture
metadata:
name: rspan-capture
spec:
selector:
matchLabels:
app: my-app
maxDuration: "10m"
export:
rspan:
subscriberBufferSize: "64Mi"After forwarding the agent port, users can inspect active streams:
curl -s http://localhost:9000/captures | jqAnd pipe a live stream into Wireshark:
or tshark:
curl -sN http://localhost:9000/stream/default/rspan-capture/default/my-app/eth0 \
| tshark -r -Together, these examples show the core promise of Isopcap: packet capture that feels native to Kubernetes, while remaining useful to the people and tools that have relied on packet traces for decades.
What's Next
Looking ahead, the next release of Isopcap will make packet capture even easier to use from the Isovalent Enterprise Platform UI. Users will be able to start captures directly from service and connection views, with enterprise-ready defaults for filters, limits, stop conditions, and auto-stop behavior. We are also adding a dedicated packet capture view to track running and completed captures, inspect status and metadata, understand why a capture stopped, and manage capture files from one place.
Learn more by attending the webinar!
Kubernetes Packet Capture with Isopcap
Kubernetes tells you what failed, but packet capture tells you what actually happened. Learn how Isopcap brings Kubernetes-native packet capture to platform teams, making troubleshooting, incident response, and collaboration across teams faster and easier.
Summary
Packet capture remains one of the most important tools for understanding what is really happening between systems. Kubernetes did not remove that need, but it changed the operational model around it. Pods are dynamic, interfaces can be layered, nodes may be inaccessible, and the teams involved in troubleshooting often span platform engineering, application development, NetOps, and security.
Isopcap brings packet capture into that reality.
By making packet capture Kubernetes-native, CRD-driven, CNI-independent, and safe for target workloads, Isopcap gives teams a practical way to collect packet-level evidence without falling back to fragile manual workflows. Platform teams can control the capture process. Application, NetOps, and security teams can work from standard PCAPng artifacts. And organizations can bring packet capture into day-2 operations with better boundaries, better status, and better collaboration.
Schedule a Demo With Our Engineers
Learn how our solution map to your challenges.
Christian Hernandez, Technical Marketing Engineer
Christian is a Technical Marketing Engineer and Tech Lead at Isovalent, now part of Cisco. He is a well rounded technologist with experience in infrastructure engineering, systems administration, enterprise architecture, tech support, advocacy, and product management. Passionate about OpenSource and containerizing the world one application at a time. He is currently a maintainer of the Argo Project and OpenGitOps. He focuses on GitOps practices, DevOps, Kubernetes, Network Security, and Containers. On his free time, he plays guitar, travels, and you can catch him touring wineries in California.