fix: give ArgoCD real resource requests/limits - #54
Merged
Conversation
Confirmed live 2026-08-11: none of argo-cd's components declare resources, so kube-scheduler has nothing to balance the pool's 2 nodes on and Cluster Autoscaler never sees a reason to reach for the 3rd — a fresh boot piles ~30 pods onto one node and OOMs. Companion fix to the same problem across the rest of the platform (gitops repo). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mqgrku7T7sfPYHvg9fmBMB
kubectl top pods -n argocd (2026-08-11, two samples ~15min apart) showed the first pass was anchored on generic sizing rather than this cluster's reality: argocd-application-controller's limit (512Mi) sat barely above its observed 405-471Mi, giving it essentially no OOM headroom — the exact failure mode this fix exists to remove, just moved from "no request" to "a limit too close to actual usage". CPU requests were also oversized fleet-wide relative to observed 1-10m idle usage. Re-derived every value from the live numbers instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Mqgrku7T7sfPYHvg9fmBMB
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
controller,repoServer,server,redis,applicationSet,notifications) shipresources: {}by default in argo-helm — this root'shelm_release.argocdnever overrode that.scaleway-homelabboot: without real requests anywhere in the platform, kube-scheduler has no signal to balance the pool's 2 nodes, and Cluster Autoscaler never sees a Pending pod to justify reaching for the 3rd node — one node ended up with 31 pods vs 12, hitMemoryPressure, and started evicting/crashlooping workloads.gitops: fix: give every requestless platform chart real resource requests/limits gitops#23 — same fix applied to every other platform chart (cert-manager, external-dns, external-secrets, openbao, velero, wireguard).controller/repoServerget the widest limit-over-request headroom: controller tracks the live state of everything this GitOps repo manages, and repo-server's footprint scales with whatever chart it's rendering (kube-prometheus-stack being the largest synced here).Test plan
terraform fmt -check/terraform validatepass on10-cluster/scalewayvaluesheredoc extracted and parsed standalone (valid, all 6 component keys present with expected values)scaleway-upand confirm pod distribution across nodes evens out (tracked alongside the gitops PR)🤖 Generated with Claude Code
https://claude.ai/code/session_01Mqgrku7T7sfPYHvg9fmBMB