install
Kubeshark installation and deployment skill. Use this skill whenever the user wants to install Kubeshark, deploy Kubeshark to a Kubernetes cluster, set up…
KFL2 (Kubeshark Filter Language) reference. This skill MUST be loaded before writing, constructing, or suggesting any KFL filter expression. KFL is statically typed — incorrect field names or syntax will fail silently or error. Do not guess at KFL syntax without this skill
$ npx -y skills add kubeshark/kubeshark --skill kfl --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/kflContext preview
The summary Claude sees to decide when to auto-load this skill.
KFL2 (Kubeshark Filter Language) reference. This skill MUST be loaded before writing, constructing, or suggesting any KFL filter expression. KFL is statically typed — incorrect field names or syntax will fail silently or error. Do not guess at KFL syntax without this skill
name: kfl user-invocable: false description: > KFL2 (Kubeshark Filter Language) reference. This skill MUST be loaded before writing, constructing, or suggesting any KFL filter expression. KFL is statically typed — incorrect field names or syntax will fail silently or error. Do not guess at KFL syntax without this skill loaded. Trigger on any mention of KFL, CEL filters, traffic filtering, display filters, query syntax, filter expressions, write a filter, construct a query, build a KFL, create a filter expression, "how do I filter", "show me only", "find traffic where", protocol-specific queries (HTTP status codes, DNS lookups, Redis commands, Kafka topics), Kubernetes-aware filtering (by namespace, pod, service, label, annotation), L4 connection/flow filters, time-based queries, or any request to slice/search/narrow network traffic in Kubeshark. Also trigger when other skills need to construct filters — KFL is the query language for all Kubeshark traffic analysis. last-updated: 2026-05-08
You are a KFL2 expert. KFL2 is built on Google's CEL (Common Expression Language) and is the query language for all Kubeshark traffic analysis. It operates as a **display filter** — it doesn't affect what's captured, only what you see.
Think of KFL the way you think of SQL for databases or Google search syntax for the web. Kubeshark captures and indexes all cluster traffic; KFL is how you search it.
For the complete variable and field reference, see `references/kfl2-reference.md`.
KFL expressions are boolean CEL expressions. An empty filter matches everything.
| Category | Operators | |----------|-----------| | Comparison | `==`, `!=`, `<`, `<=`, `>`, `>=` | | Logical | `&&`, `\|\|`, `!` | | Arithmetic | `+`, `-`, `*`, `/`, `%` | | Membership | `in` | | Ternary | `condition ? true_val : false_val` |
str.contains(substring) // Substring search str.startsWith(prefix) // Prefix match str.endsWith(suffix) // Suffix match str.matches(regex) // Regex match size(str) // String length
size(collection) // List/map/string length key in map // Key existence map[key] // Value access map_get(map, key, default) // Safe access with default value in list // List membership
timestamp("2026-03-14T22:00:00Z") // Parse ISO timestamp
duration("5m") // Parse duration
now() // Current time (snapshot at filter creation)!http // Everything that is NOT HTTP
http && status_code != 200 // HTTP responses that aren't 200
http && !path.contains("/health") // Exclude health checks
!(src.pod.namespace == "kube-system") // Exclude system namespaceBoolean flags that indicate which protocol was detected. Use these as the first filter term — they're fast and narrow the search space immediately.
| Flag | Protocol | Flag | Protocol | |------|----------|------|----------| | `http` | HTTP/1.1, HTTP/2 | `redis` | Redis | | `dns` | DNS | `kafka` | Kafka | | `tls` | eBPF TLS interception | `amqp` | AMQP | | `tcp` | TCP | `ldap` | LDAP | | `udp` | UDP | `ws` | WebSocket | | `sctp` | SCTP | `gql` | GraphQL (v1+v2) | | `icmp` | ICMP | `gqlv1` / `gqlv2` | GraphQL version-specific | | `grpc` | gRPC (HTTP/2 sub-protocol) | `mongodb` | MongoDB | | `mysql` | MySQL | `postgresql` | PostgreSQL | | `radius` | RADIUS | | | | `diameter` | Diameter | `conn` / `flow` | L4 connection/flow tracking | | | | `tcp_conn` / `udp_conn` | Transport-specific connections |
The most common starting point. Filter by where traffic originates or terminates.
src.pod.name == "orders-594487879c-7ddxf" dst.pod.namespace == "production" src.service.name == "api-gateway" dst.service.namespace == "payments"
Pod fields fall back to service data when pod info is unavailable, so `dst.pod.namespace` works even for service-level entries.
Convenience variables that pick the best available identity for a peer:
src.name == "api-gateway" // pod > service > dns > process
dst.name.contains("payment") // works across identity types
src.namespace == "production" // pod namespace, falls back to service
dst.namespace != "kube-system" // exclude system namespaceMatch against any direction (src or dst):
"production" in namespaces // Any namespace match "orders" in pods // Any pod name match "api-gateway" in services // Any service name match
map_get(local_labels, "app", "") == "checkout" // Safe access with default map_get(remote_labels, "version", "") == "canary" "tier" in local_labels // Label existence check
Always use `map_get()` for labels and annotations — direct access like `local_labels["app"]` errors if the key doesn't exist.
node_name == "ip-10-0-25-170.ec2.internal"
local_process_name == "nginx"
remote_process_name.contains("postgres")src.dns == "api.example.com"
dst.dns.contains("redis")HTTP is the most common protocol for API-level investigation.
| Field | Type | Example | |-------|------|---------| | `method` | string | `"GET"`, `"POST"`, `"PUT"`, `"DELETE"` | | `url` | string | Full path + query: `"/api/users?id=123"` | | `path` | string | Path only: `"/api/users"` | | `status_code` | int | `200`, `404`, `500` | | `http_version` | string | `"HTTP/1.1"`, `"HTTP/2"` | | `request.headers` | map | `request.headers["content-type"]
eBPF-powered network observability for Kubernetes. Indexes L4/L7 traffic with full K8s context, decrypts TLS without keys. Queryable by AI agents via MCP and humans via dashboard.
Kubeshark installation and deployment skill. Use this skill whenever the user wants to install Kubeshark, deploy Kubeshark to a Kubernetes cluster, set up…
Kubernetes network root cause analysis skill powered by Kubeshark MCP. Use this skill whenever the user wants to investigate past incidents, perform…
Kubernetes network security audit skill powered by Kubeshark MCP. Use this skill whenever the user wants to audit a cluster for security threats, detect…