mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-09 05:25:14 +09:00
IvanHunters
7801f7748e
## What this PR does Under node CPU contention the host `linstor-controller` JVM cannot answer its `GET /health` liveness probe within the piraeus-operator default timing (`timeoutSeconds: 1`, `failureThreshold: 3`). The kubelet then liveness-kills the container (exit 137, reason `Error`, not `OOMKilled`). The resulting crash-loop leaves the `linstor-controller` Service with no ready endpoints, `linstor-csi` gets `EPERM`, and RWX-Filesystem `DataVolume`s never bind — breaking tenant Kubernetes / NFS provisioning. The operator-generated controller pod sets no `resources` (so no CPU request and no scheduling/CPU guarantee) and ships the tight default probe. This change, on the `linstor-controller` container in `spec.controller.podTemplate`: - adds `resources.requests` (cpu `250m`, memory `700Mi`) — requests only, no limits: a CPU request guarantees CPU shares so the JVM keeps answering `/health` under contention, while omitting limits avoids throttling the JVM or OOM-killing it. The memory value is a conservative starting estimate; tune it to observed RSS. - relaxes the liveness timing to `timeoutSeconds: 5` and `failureThreshold: 6` so a JVM GC pause or CPU contention does not trip a liveness kill. piraeus-operator merges `spec.controller.podTemplate` into the generated Deployment as a strategic merge patch, so the liveness override carries only the two timing fields; the operator's `httpGet` target (`GET /health` on the api port) is left intact to avoid pinning a wrong path or scheme. Both knobs are exposed under `controller.*` in `values.yaml` for tuning. This is a latent chart weakness amplified by load, not a regression: on the same branch, image, and chart, a green run had the controller stable at `restartCount=0`, while a CPU-loaded run on identical code crash-looped. Same code, different outcome under load. ### Screenshots N/A — no UI changes. ### Release note ```release-note fix(linstor): give the linstor-controller CPU/memory requests and a more tolerant liveness probe so it no longer crash-loops under node CPU contention, which previously left the controller Service with no endpoints and blocked RWX volume provisioning ``` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added default controller resource requests for the Linstor controller. * Added configurable liveness probe timing settings for the controller container. * **Tests** * Added coverage to verify the controller pod template applies the expected resource requests and liveness probe timing values. * Confirmed the controller image remains correctly pinned while the new settings are applied. <!-- end of auto-generated comment: release notes by coderabbit.ai -->