OCPSTRAT-2915: CPU-based control plane autoscaling#1946
OCPSTRAT-2915: CPU-based control plane autoscaling#1946csrwng wants to merge 1 commit intoopenshift:masterfrom
Conversation
|
@csrwng: This pull request references OCPSTRAT-2915 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the feature to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-reference
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
Extends the existing resource-based control plane autoscaling in HyperShift to consider CPU usage in addition to memory, and allows per-size resource fraction overrides in ClusterSizingConfiguration. Tracking: https://issues.redhat.com/browse/OCPSTRAT-2915 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
csrwng
force-pushed
the
cpu-autoscaling
branch
from
2433c8b to
987afae
Compare
csrwng
changed the title
|
@csrwng: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
openshift-ci
bot
added
the
do-not-merge/work-in-progress
joshbranham
left a comment
joshbranham
left a comment
There was a problem hiding this comment.
Excited to see this make progress, left some comments, let me know if I can help 👍
| Where `effectiveMemoryFraction` returns the per-size memory | ||
| fraction if set, otherwise the global memory fraction, otherwise | ||
| the default (0.65). The same precedence applies to | ||
| `effectiveCPUFraction`. |
There was a problem hiding this comment.
So the default will be 65% for CPU as well?
There was a problem hiding this comment.
so far yes, because I had to put something, but it'd be great if we could base the default on real data
| be consistently ordered across sizes (i.e., a size with more | ||
| memory also has more CPU). |
There was a problem hiding this comment.
Unfortunately as deployed today in ROSA this is not the case. We have sizes m5.4xlarge > r5.4xlarge which is only an increase in memory. I don't think it will matter much as both have 16 vCPU, and our issues with CPU are mostly isolated to the smaller 4/8 vCPU types.
| - **Disabling CPU-based sizing**: To revert to memory-only | ||
| sizing, remove the `kubeAPIServerCPUFraction` field from the | ||
| `ClusterSizingConfiguration` spec and remove any per-size CPU | ||
| fraction overrides. The controller will fall back to memory-only | ||
| sizing on its next reconciliation. |
There was a problem hiding this comment.
Is this true? Today we are not setting kubeAPIServerMemoryFraction and letting the default take place.
There was a problem hiding this comment.
Hmm, let me update it. I think you're right in that we would have a default even if we don't put anything in there.
3 participants
Summary
control plane autoscaling to consider CPU usage in addition to memory
ClusterSizingConfiguration, allowing different fractions fordifferent cluster sizes
recommendations to prevent under-provisioning on either dimension
Test plan
🤖 Generated with Claude Code