fix(k8s): raise schemas CPU request from 20m to 100m
schemas / vulnerabilities (pull_request) Successful in 2m7s
schemas / check (pull_request) Successful in 2m52s
schemas / check-release (pull_request) Successful in 5m32s
pre-commit / pre-commit (pull_request) Successful in 7m2s
schemas / build (pull_request) Successful in 6m24s
schemas / deploy-prod (pull_request) Has been skipped
schemas / vulnerabilities (pull_request) Successful in 2m7s
schemas / check (pull_request) Successful in 2m52s
schemas / check-release (pull_request) Successful in 5m32s
pre-commit / pre-commit (pull_request) Successful in 7m2s
schemas / build (pull_request) Successful in 6m24s
schemas / deploy-prod (pull_request) Has been skipped
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.
This commit is contained in:
+1
-1
@@ -42,7 +42,7 @@ spec:
|
|||||||
- name: schemas
|
- name: schemas
|
||||||
resources:
|
resources:
|
||||||
requests:
|
requests:
|
||||||
cpu: "20m"
|
cpu: "100m"
|
||||||
memory: "128Mi"
|
memory: "128Mi"
|
||||||
limits:
|
limits:
|
||||||
memory: "768Mi"
|
memory: "768Mi"
|
||||||
|
|||||||
Reference in New Issue
Block a user