Compatibility and limits
What the agent needs in order to run, and what its evidence can and cannot tell you.
Supported agent platform
Section titled “Supported agent platform”The supported baseline is Kubernetes 1.32 or newer, containerd 2.x through CRI, cgroup v2 in unified mode, Linux 6.1 LTS or newer with BTF, and x86_64 nodes. Workload ownership has to run Pod → ReplicaSet → Deployment. The server images being available for ARM64 says nothing about the agent: that is a separate question, and the answer is no.
The checks below run on a candidate Linux node, but they cover only part of the requirements: the operator still has to confirm the Kubernetes and runtime versions, the permissions needed to attach probes, and the workload ownership chain. Other runtimes, cgroup v1, unsupported owners and hardened managed-node configurations are not claimed as supported — they may happen to work, but nothing is promised.
test -e /sys/kernel/btf/vmlinuxtest "$(stat -fc %T /sys/fs/cgroup)" = cgroup2fsuname -mEnablement and resource bounds
Section titled “Enablement and resource bounds”Configuration controls every observation profile. processExec is set explicitly; processExit is false whenever you leave it out. In the parser, network connect, listen and accept as well as DNS all default to disabled — but the reference deployment turns several network probes on, so a sample is not the same thing as a default. File observation is off and experimental. When in doubt, read the ConfigMap that is actually running.
Collection is bounded from several sides at once: queue capacity, batch size, events per second, and how many Application streams a single agent keeps. DNS adds its own limits on transactions, reassembly and captured bytes, and inbound accept has a separate rate bound. If a required probe cannot attach, the agent stays unready instead of pretending otherwise. Watch the loss and capacity counters and measure your own workload — there is no universal number for overhead and no promise of completeness.
Thread lifecycle collection is bounded by process/task state, name buckets, snapshot size and returned windows. Names beyond the per-process capacity are counted under Other thread names and reported as overflow. A late observer may initialize active threads from a bounded /proc snapshot, but that snapshot cannot reconstruct earlier creation or rename history. If the snapshot is unavailable, races, or is truncated, or if kernel, decoding, attribution, capacity, or delivery gaps occur, the API marks the baseline or window incomplete. A bounded summary can also be marked truncated; its totals are lower bounds rather than zeros or exact lifetime values.
Thread activity requires server database migration 32 and a compatible runtime agent advertising task.lifecycle/v1. Installations that already applied migration 31 retain their stored windows when upgrading to migration 32. Earlier agents cannot reconstruct historical thread activity. Enable observation.processExit to collect task creation, rename, and exit evidence; task.lifecycle/v1 is advertised only after all required kernel hooks load and attach successfully. processExec controls executable execution independently. The API defaults to the last hour and accepts explicit ranges of at most 31 days. Thread-activity windows follow the Project’s effective raw runtime retention. Expired windows are removed; there is no separate historical snapshot that reconstructs their counts. Created and exited counters cover the selected windows, including counts by observed name. Active counts by name and the observed peak are available only for one qualified process and observation epoch; when multiple processes or epochs are present, the summary reports these values as unavailable instead of adding incompatible snapshots. Observation gaps or truncation make creation and exit counts lower bounds; an incomplete baseline also affects active and peak counts.
Evidence boundaries
Section titled “Evidence boundaries”A connect attempt does not always end in a connection. DNS correlation is a recent observation that happens to fit, not proof of cause; encrypted, cached or simply unmatched DNS leaves an IP without a name. File paths describe the arguments that supported calls passed in, not every change the filesystem saw. And a SIGKILL on its own does not prove an out-of-memory kill.
Filtering, gaps in attribution, queue and ring-buffer loss, rate limits, time windows and retention all remove evidence along the way. That is why an absence of findings cannot certify that nothing happened or that a workload is secure. Comparisons and inventory tell you what coverage they rest on, and a numeric summary can never bring back the Pod or container detail behind it.