Skip to main content

​
Controller Issues

​
Controller Pods Not Starting

Symptoms:
Common Causes:
kguardian requires Linux kernel 6.2+.Check:
Solution: Upgrade nodes to kernel 6.2+ or use a distribution with eBPF CO-RE support.
Some cloud providers disable eBPF by default.Check controller logs:
Look for errors like: “Failed to load network probe eBPF”Solution: Enable eBPF in cloud provider settings or use privileged security context.
Controller needs CAP_BPF, CAP_PERFMON, CAP_SYS_RESOURCE.Check pod security:
Solution: Ensure pod has privileged: true or the required capabilities.

​
Broker Issues

​
No Traffic Data

Symptoms:
  • CLI says “No traffic data found”
  • Empty response from /pod/traffic/ endpoint
Solutions:
1

Check pods are generating traffic

2

Check broker is receiving data

The controller logs its batch flushes (“Flushing network event batch of N events”) only at DEBUG, and the chart pins RUST_LOG=INFO — so verify ingest at the broker side, or raise the controller log level (see Debug Mode).
3

Query the broker directly

The per-pod path takes a pod name, not an IP. If you only have an IP, resolve it first with GET /pod/ip/{ip}:

​
CLI Issues

​
Can’t Connect to Broker

Symptoms:
Solution: The CLI creates its own port-forward to the broker service — no manual port-forward is needed. Ensure you have permissions:
If kguardian is installed in a non-default namespace or with a renamed broker service, point the CLI at it:
A manual port-forward is only needed when curling the broker API directly:

​
Policy Generation Issues

​
Generated Policy Too Permissive

Cause: Pods lack specific labels, so broader selectors are used. Solution:
  1. Add specific labels to your pods
  2. Manually edit generated policies
  3. Re-generate after labeling

​
Policy Breaks Communication

Cause: Incomplete observation - not all traffic was captured. Solution:
  1. Extend observation period (let app run longer)
  2. Check pod logs for connection errors
  3. Manually add missing rules to the policy

​
Debug Mode

Enable debug logging for more details:
The kubectl set env override reverts on the next helm upgrade, which re-renders the DaemonSet with the chart’s pinned value.

Still having issues?

Ask for help in GitHub Discussions →