fix(k8s): raise schemas CPU request from 20m to 100m #840

Merged

argoyle merged 1 commits from bump-schemas-cpu-request into main 2026-05-19 07:23:06 +00:00

Conversation 0 Commits 1 Files Changed 1

+1 -1

argoyle commented 2026-05-19 07:08:16 +00:00

Owner

Copy Link

Copy Source

The HPA was pinning the deployment at maxReplicas (4) even though aggregate CPU usage was low.

Diagnosis

The service is event-driven: pods sit at ~0-1m idle but spike to 100-300m per supergraph query. With requests.cpu=20m those bursts read as 500-1500% utilization, so the HPA's 60% target was constantly exceeded on whichever pod handled the request.

Observed per-pod samples (15s apart):

sample 1 : cckcp=110m, others ~0m
sample 2 : vznkq=181m, others ~0m
sample 3 : vznkq=304m, others ~0m

HPA status confirmed: ScalingLimited TooManyReplicas + ScaleDownStabilized kept replicas pinned at 4.

Fix

Raise requests.cpu to 100m. Bursts now read as 100-300% instead of 500-1500%. Combined with the HPA's downscale stabilization window this lets replicas settle back to minReplicas (2) between bursts.

The HPA was pinning the deployment at maxReplicas (4) even though aggregate CPU usage was low. ## Diagnosis The service is event-driven: pods sit at ~0-1m idle but spike to 100-300m per supergraph query. With `requests.cpu=20m` those bursts read as 500-1500% utilization, so the HPA's 60% target was constantly exceeded on whichever pod handled the request. Observed per-pod samples (15s apart): ``` sample 1 : cckcp=110m, others ~0m sample 2 : vznkq=181m, others ~0m sample 3 : vznkq=304m, others ~0m ``` HPA status confirmed: `ScalingLimited TooManyReplicas` + `ScaleDownStabilized` kept replicas pinned at 4. ## Fix Raise `requests.cpu` to `100m`. Bursts now read as 100-300% instead of 500-1500%. Combined with the HPA's downscale stabilization window this lets replicas settle back to `minReplicas` (2) between bursts.

argoyle added 1 commit 2026-05-19 07:08:17 +00:00

fix(k8s): raise schemas CPU request from 20m to 100m ... dae4e8a135

HPA was pinning the deployment at maxReplicas (4) even though aggregate
CPU usage was low. The service is event-driven: pods sit at ~0-1m idle
but spike to 100-300m per supergraph query. With requests.cpu=20m those
bursts read as 500-1500% utilization, so the HPA's 60% target was
constantly exceeded on whichever pod handled the request.

Raise the request to 100m so bursts read as 100-300% instead. Combined
with the HPA's downscale stabilization window this lets replicas settle
back to minReplicas (2) between bursts.

argoyle scheduled this pull request to auto merge when all checks succeed 2026-05-19 07:09:04 +00:00

argoyle canceled auto merging this pull request when all checks succeed 2026-05-19 07:09:50 +00:00

argoyle scheduled this pull request to auto merge when all checks succeed 2026-05-19 07:10:04 +00:00

argoyle merged commit 9a4b05d897 into main 2026-05-19 07:23:06 +00:00

argoyle deleted branch bump-schemas-cpu-request 2026-05-19 07:23:07 +00:00

argoyle referenced this pull request 2026-05-19 07:38:22 +00:00

perf(graph): cache merged SDL and SchemaUpdate per ref #841

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

dependencies

Pull requests that update a dependency file

docker

go

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

acctest (Shiny Acctest) argoyle (Joakim Olsson) buildtools (Buildtools) kubernetes (Kubernetes) releaser (Unbound Releaser) renovate (Renovate Bot)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unboundsoftware/schemas#840