fix(shield): drop the default CPU limit on the host shield

[mnacharov]

solves #2716

What this PR does / why we need it:

Removes host.resources.shield.limits.cpu: 1000m from the chart defaults. Requests (250m CPU / 384Mi) and the memory limit (1Gi) are unchanged.

The host shield's CPU demand is set by two things the chart cannot see: the node's vCPU count — its userspace side is a single consumer draining one ring buffer per CPU — and the container creation rate. A flat 1000m that is comfortable on an 8-core node is structurally undersized on a 64-core one: same quota, 8× the buffers to drain and 8× the aggregate syscall volume.

The limit also doesn't bound the cost it appears to bound. The eBPF program or kernel-module hook runs in the context of whichever process issued the syscall, so that CPU time is charged to that container's cgroup; capping the shield container constrains only the drain side. And CFS throttling is all-or-nothing within a period — the shield freezes for tens of milliseconds rather than running proportionally slower.

On large, high-churn nodes this propagates off the container. Sustained throttling produces event drops, drops leave the thread and fd tables inconsistent and force /proc rescans that are CPU- and IO-heavy, which drives more throttling. Meanwhile per-container runtime metadata queries and their retries add latency to the containerd socket that kubelet's PLEG relist shares. The observed end state is PLEG is not healthy and NodeNotReady on a node whose other 63 cores are idle.

Changes

values.yaml (remove the key, add a comment on the trade-off and how to set one back) · tests/host/daemonset_test.yaml (no CPU limit by default; an explicit limit is honoured)
· Chart.yaml version bump

No template change is needed — host.resources already passes straight through toYaml. values.schema.json is unaffected ($defs.Host has additionalProperties: true).

For reviewers

Out of scope: host.resources.kmodule, host_windows.resources, and the 1000m mirrored in rh-shield-operator samples and the CSV. Happy to follow up on any of them — I only have evidence for the Linux host shield.

Checklist

• Title of the PR starts with type and scope, (e.g. feat(agent,node-analyzer,sysdig-deploy):)
• Chart Version bumped for the respective charts
• Variables are documented in the README.md (or README.tpl in some charts)
• Check GithubAction checks (like lint) to avoid merge-check stoppers
• All test files are added in the tests folder of their respective chart and have a "_test" suffix

[github-actions]

Hi @mnacharov. Thanks for your PR.

After inspecting your changes someone with write access to this repo needs
to approve and run the workflow.