fix(crowdsec): request 50m CPU instead of the chart's 500m #567

2026-08-25T15:05:25Z

claude-bot commented

2026-08-25 15:05:25 +00:00

Blocks the jupiter bare-metal conversion. Draining k8s-1 left influxdb-influxdb2-0, woodpecker-server and wp-pg-1 unschedulable — k8s-2 and k8s-3 were both at 100% of requested CPU while actually using 21–23%.

Measured, cluster-wide:

	Requested	Actual
k8s-1	3,785m	4,386m
k8s-2	7,950m (100%)	1,714m (21%)
k8s-3	7,945m (99%)	1,857m (23%)
total	19,680m	7,957m

The workload fits on two nodes comfortably in reality; only the requests accounting says otherwise. The three stuck pods request 250m combined, against ~105m free across both nodes.

crowdsec is the clearest single contributor:

Pod	Requests	Uses
`crowdsec-agent` (DaemonSet, x3)	500m	1–2m
`crowdsec-lapi`	500m	2m

Nothing in this HelmRelease had ever set resources, so the 500m is an inherited upstream chart default rather than a decision made here. Value paths confirmed against the chart's values.yaml (agent.resources, lapi.resources).

This frees 450m per node — comfortably more than the ~150m shortfall — and helps again when saturn and neptune are converted.

Only the request changes. Limits stay at the chart default so a log flood can still burst to 500m. Note this moves both pods from Guaranteed to Burstable QoS; memory headroom is 62% cluster-wide, and crowdsec is not on the storage or control-plane critical path.

Other obvious over-provisioning left alone for now (immich-machine-learning requests 500m and uses 2m, im-pg-1 500m/12m) — this PR does only what unblocks the maintenance.

🤖 Generated with Claude Code

**Blocks the jupiter bare-metal conversion.** Draining k8s-1 left `influxdb-influxdb2-0`, `woodpecker-server` and `wp-pg-1` unschedulable — k8s-2 and k8s-3 were both at 100% of *requested* CPU while actually using 21–23%. Measured, cluster-wide: | | Requested | Actual | |---|---|---| | k8s-1 | 3,785m | 4,386m | | k8s-2 | 7,950m (100%) | 1,714m (21%) | | k8s-3 | 7,945m (99%) | 1,857m (23%) | | **total** | **19,680m** | **7,957m** | The workload fits on two nodes comfortably in reality; only the requests accounting says otherwise. The three stuck pods request 250m combined, against ~105m free across both nodes. crowdsec is the clearest single contributor: | Pod | Requests | Uses | |---|---|---| | `crowdsec-agent` (DaemonSet, x3) | 500m | 1–2m | | `crowdsec-lapi` | 500m | 2m | Nothing in this HelmRelease had ever set `resources`, so the 500m is an inherited upstream chart default rather than a decision made here. Value paths confirmed against the chart's `values.yaml` (`agent.resources`, `lapi.resources`). This frees 450m per node — comfortably more than the ~150m shortfall — and helps again when saturn and neptune are converted. **Only the request changes.** Limits stay at the chart default so a log flood can still burst to 500m. Note this moves both pods from Guaranteed to Burstable QoS; memory headroom is 62% cluster-wide, and crowdsec is not on the storage or control-plane critical path. Other obvious over-provisioning left alone for now (`immich-machine-learning` requests 500m and uses 2m, `im-pg-1` 500m/12m) — this PR does only what unblocks the maintenance. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit 2026-08-25 15:05:26 +00:00

fix(crowdsec): request 50m CPU instead of the chart's 500m

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

315c9aeb46

Draining k8s-1 for the jupiter conversion left three pods unschedulable:
k8s-2 and k8s-3 both sat at 100% of requested CPU while actually using 21-23%.
Cluster-wide the gap is 19,680m requested against 7,957m used.

crowdsec is the clearest single contributor. The chart defaults reserve 500m
for each agent and for the LAPI; measured draw is 1-2m. As a DaemonSet the
agent alone parks half a core on every node. Nothing here had ever set
resources, so this was an inherited default rather than a decision.

Only the request changes. Limits stay at the chart default, so a log flood can
still burst to 500m; what shrinks is the reservation the scheduler subtracts
from every node whether or not the process uses it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

review-bot reviewed

2026-08-25 15:07:18 +00:00

review-bot left a comment

🤖 Automated review — model claude-haiku-4-5-20251001 (complexity: trivial), commit 315c9aeb463396a1980fd0c8aaaad58a4ce4124d.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

This PR reduces CPU request overallocation in the crowdsec HelmRelease by setting both the LAPI pod and agent DaemonSet to request 50m instead of the chart's 500m default. The change is well-measured (LAPI uses ~2m steady-state, agents use 1–2m each), appropriately scoped to unblock a maintenance issue, and leaves limits untouched to preserve burst capacity. No blocking issues.

🟢 Nits

The comments explaining the reasoning are thorough and well-placed — good attention to maintainability. Minor note: "half a core" (line 91) and "half a core" (line 136) make clear what the waste amounts to, which helps readers understand the impact.

Tests

This is infrastructure configuration (Helm values override). Deployment testing would verify:

Pods still start and function normally under the new requests
Previously unschedulable pods can now be scheduled (the unblocking goal)
No increase in pod evictions under normal operation (should decrease with more free CPU headroom)

These would be validated by CI (Helm template validation) and post-merge cluster observation. The measured baseline (1–2m actual use vs. 50m request) gives strong confidence the pods won't hit the new reservation in normal operation.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `claude-haiku-4-5-20251001` (complexity: trivial), commit `315c9aeb463396a1980fd0c8aaaad58a4ce4124d`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary This PR reduces CPU request overallocation in the crowdsec HelmRelease by setting both the LAPI pod and agent DaemonSet to request 50m instead of the chart's 500m default. The change is well-measured (LAPI uses ~2m steady-state, agents use 1–2m each), appropriately scoped to unblock a maintenance issue, and leaves limits untouched to preserve burst capacity. No blocking issues. ## 🟢 Nits - The comments explaining the reasoning are thorough and well-placed — good attention to maintainability. Minor note: "half a core" (line 91) and "half a core" (line 136) make clear what the waste amounts to, which helps readers understand the impact. ## Tests This is infrastructure configuration (Helm values override). Deployment testing would verify: 1. Pods still start and function normally under the new requests 2. Previously unschedulable pods can now be scheduled (the unblocking goal) 3. No increase in pod evictions under normal operation (should decrease with more free CPU headroom) These would be validated by CI (Helm template validation) and post-merge cluster observation. The measured baseline (1–2m actual use vs. 50m request) gives strong confidence the pods won't hit the new reservation in normal operation. ## Recommendation Looks reasonable — no blocking issues; comments above are optional.

k.renner merged commit 2038cd34ae into master

2026-08-25 15:07:23 +00:00

k.renner referenced this issue from a commit

2026-08-25 15:07:24 +00:00

Merge pull request 'fix(crowdsec): request 50m CPU instead of the chart's 500m' (#567) from crowdsec-cpu-requests into master

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: konairius/homelab#567