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. 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. Apply the resource: Then watch the per-node status: Important 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: 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: 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. 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: This 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: 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: or: or 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: After forwarding the agent port, users can inspect active streams: And pipe a live stream into Wireshark: or tshark: 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! 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.