V2.00 first drop

src/config.ts

@@ -57,7 +57,13 @@ export const SIDEBAR: Sidebar = {
       { text: 'Best Practices', link: 'en/best_practice' },   
       // { text: 'Getting Support', link: 'en/support' },   
     ],
-    'Basic Functionality': [
+    'V2.00': [
+      // { text: 'Network Sniffing', link: 'en/network_sniffing' },
+      { text: 'Cluster-wide PCAP Export', link: 'en/v2/pcap_export' },
+      { text: 'L4 to L7 Mapping', link: 'en/v2/l4_to_l7' },
+      // { text: 'L7 API Dissection', link: 'en/v2/API_dissection' },
+    ],
+    'V1.00': [
       // { text: 'Network Sniffing', link: 'en/network_sniffing' },
       { text: 'Dashboard', link: 'en/ui' },
       { text: 'Decrypt TLS/HTTPS', link: 'en/encrypted_traffic' },

src/pages/en/v2/API_dissection.md

@@ -0,0 +1,19 @@
+---
+title: L7 API Dissection
+description: Reconstructing the API Context by Correlating Information from All Layers
+
+layout: ../../../layouts/MainLayout.astro
+mascot:
+---
+
+## API Dissection
+
+API dissection goes beyond basic traffic inspection. It reconstructs complete API calls from network data by identifying requests and responses, protocol metadata, and payloads.
+
+This process requires buffering both ingress and egress traffic between two peers, matching requests to responses, detecting the underlying protocol, and parsing payloads according to the protocol specification.
+
+Once API calls are successfully dissected, each call is enriched with workload and application identities. These identities are derived by correlating Kubernetes events from the Kubernetes API server with operating system context collected from distributed nodes via eBPF. The result links each API call to its originating pod, service, namespace, labels, and, when available, the specific process that generated the traffic.
+
+Unlike raw packet data, which lacks higher-level context, API dissection provides structured, semantically meaningful information. 
+
+![API Dissection](/api_dissect.png)

src/pages/en/v2/l4_to_l7.md

@@ -0,0 +1,33 @@
+---
+title: L4 to L7 Mapping
+description: This document outlines the new feature in **Kubeshark** V2.00 that introduces mapping between L4 connections and L7 API calls, along with access to raw packet data via an integrated online PCAP viewer.
+layout: ../../../layouts/MainLayout.astro
+mascot: Hello
+---
+
+> This feature is part of **Kubeshark** V2.00, scheduled to release in early 2026.
+
+## L4 (TCP or UDP) Connection
+
+Each dissected API call now includes a reference to its corresponding L4 connection, which contains the raw packets of the traffic.
+
+An L4 connection represents a stream of traffic between a source (identified by an IP) and a destination (identified by an IP and port).
+Each connection has a defined start and end, and a state: OPEN, CLOSED, or IN-PROGRESS.
+Connections include both ingress and egress raw packets, which can be downloaded as a PCAP file or viewed directly in **Kubeshark**'s new online PCAP viewer.
+
+## Online PCAP Viewer
+
+While you can download the raw packets of any L4 connection as a PCAP file for inspection in Wireshark, **Kubeshark** also provides a built-in online PCAP Viewer for quick and easy packet analysis.
+
+![Online PCAP Viewer](/pcapviewer.png)
+
+## L4 to L7 Mapping
+
+You can now view the relationship between all L7 API calls dissected from a specific L4 connection.
+
+![L4 to L7 Mapping](/l4_l7_map.png)
+
+In the example above, all dissected Kafka API calls are associated with the first listed TCP connection.
+This functionality is accessible by clicking the L4 to L7 mapping icon:
+
+![L4 to L7 Mapping](/l4_l7_map_cta.png)

src/pages/en/v2/pcap_export.md

@@ -0,0 +1,58 @@
+---
+title: Cluster-wide PCAP Export
+description: Export PCAP files from **Kubeshark** Snapshots with a single click—no manual setup or node-level copying required.
+layout: ../../../layouts/MainLayout.astro
+mascot: Hello
+---
+
+> This feature is part of **Kubeshark** V2.00, scheduled to release in early 2026.
+
+Imagine having a cluster-wide [TCPDump](https://www.tcpdump.org/)-like capability—exporting a single [PCAP](https://www.ietf.org/archive/id/draft-gharris-opsawg-pcap-01.html) file that consolidates traffic from multiple nodes, all accessible with a single click.
+
+1. Go to the **Snapshots** tab
+2. Create a new snapshot
+3. **Optionally** select the nodes (default: all nodes)
+4. **Optionally** select the time frame (default: last one hour)
+5. Press **Create**
+
+![The Snapshots Tab](/snapshots.png)
+
+Once the snapshot is ready, click the PCAP file to export its contents and open it in Wireshark.
+
+![Opening the PCAP in Wireshark](/wireshark.png)
+
+## Configuration
+
+Here's an example Helm chart segment with the relevant configuration values:
+
+```yaml
+tap:
+  storageLimit: 50Gi        # Ensure `tap.capture.raw.storageSize` is less than this value
+  capture:
+    raw:
+      enabled: true         # Enable or disable raw capture
+      storageSize: 10Gi     # Node-level FIFO buffer size; must be smaller than `tap.storageLimit`
+  snapshots:
+    storageClass: gp2       # PVC storage class (e.g., gp2 for EKS) – highly recommended
+    storageSize: 1000Gi     # Storage size allocated for the snapshots folder
+```
+
+## Backend Capture Rules
+
+Use the following Helm chart segment to include or exclude specific workloads. If no rules are defined, **Kubeshark** captures all TCP and UDP traffic.
+
+```yaml
+tap:
+  regex: .*
+  namespaces: []
+  excludedNamespaces: []
+```
+
+> Read more about [Capture Filters](/en/pod_targeting)
+
+## Recommended Usage
+
+* Enable raw capture by default
+* Use a PVC with ample storage
+* Allocate significant storage limits, especially for the snapshots folder (e.g., 1TB–2TB)
+* Apply backend capture rules to target specific workloads and reduce noise