Repository navigation
fix(http-cache,vpa): fix haproxy 3.3 backend name conflict and vpa-for-vpa OOM - #2654
Conversation
…r-vpa OOM HAProxy 3.3 disallows frontend and backend sharing the same name. Rename backend 'http' to 'cache' to resolve the conflict. Increase vpa-for-vpa recommender memory limit from 512Mi to 1Gi to prevent OOMKilled restarts. Signed-off-by: IvanHunters <[email protected]>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughUpdates HAProxy to use the ChangesHAProxy cache routing
VPA recommender resources
Estimated code review effort: 2 (Simple) | ~5 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8)packages/apps/http-cache/templates/haproxy/configmap.yamlTraceback (most recent call last): packages/system/vertical-pod-autoscaler/templates/vpa-for-vpa.yamlTraceback (most recent call last): Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
LGTM — both fixes are correct and minimal.
Business context: http-cache runs haproxy:latest, so the image silently rolls to 3.3, which refuses to start when a frontend and a backend share a name; this PR also raises the vpa-for-vpa recommender's memory ceiling to stop OOMKills.
I verified the HAProxy behavior: 3.1 emits the deprecation warning that duplicate proxy names "will not be supported anymore in version 3.3", and 3.3 enforces it. Renaming backend http → backend cache with the matching default_backend cache resolves the conflict, and cache is unique among the proxy sections in this config. The VPA change (limit 512Mi → 1Gi, request unchanged at 512Mi) is a sane remedy. helm template renders both files correctly.
Blockers: none.
Non-blocking:
-
The same HAProxy 3.3 break is present and unfixed in tcp-balancer, which also runs
haproxy:latest. Every frontend/backend pair there shares a name and will refuse to start on 3.3. Evidence:packages/apps/tcp-balancer/templates/configmap.yaml:38,52(frontend http/backend http),:60,78(https),:89,111(kubernetes),:100,117(talos);packages/apps/tcp-balancer/templates/deployment.yaml:35(image: haproxy:latest). Worth a follow-up so the next 3.3 rollout does not take tcp-balancer down the same way. -
haproxy:latestis unpinned in both charts, which is what turned a major HAProxy upgrade into a surprise outage. Pinning to a tracked major (e.g.haproxy:3.3) would make such breaks deliberate and reviewable. Evidence:packages/apps/http-cache/templates/haproxy/deployment.yaml:34,packages/apps/tcp-balancer/templates/deployment.yaml:35. -
Two unrelated fixes are bundled in a single commit (
fix(http-cache,vpa): ...). Splitting them would allow either to be reverted independently. Evidence: commit999298510touches bothpackages/apps/http-cache/templates/haproxy/configmap.yamlandpackages/system/vertical-pod-autoscaler/templates/vpa-for-vpa.yaml.
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
|
Successfully created backport PR for |
What this PR does
Fixes two independent issues found during cluster operations:
http-cache (HAProxy 3.3 breaking change)
HAProxy 3.3 no longer allows a frontend and backend to share the same name. The existing config had both
frontend httpandbackend http, which causes haproxy to refuse to start on upgrade. Renamebackend http→backend cacheand update thedefault_backenddirective accordingly.vpa-for-vpa (OOMKilled recommender)
The VPA recommender deployed by
vpa-for-vpawas hitting its 512Mi memory limit and being OOMKilled. Increase the limit to 1Gi to keep the recommender running stably.Release note
Summary by CodeRabbit