WIP: initial proposals of supporting in-place cpu resize#81
Open
sivanzcw wants to merge 1 commit intoopenkruise:masterfrom
Open
WIP: initial proposals of supporting in-place cpu resize#81sivanzcw wants to merge 1 commit intoopenkruise:masterfrom
sivanzcw wants to merge 1 commit intoopenkruise:masterfrom
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #81 +/- ##
==========================================
+ Coverage 45.75% 46.89% +1.13%
==========================================
Files 75 77 +2
Lines 4386 4506 +120
==========================================
+ Hits 2007 2113 +106
- Misses 2189 2198 +9
- Partials 190 195 +5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
furykerry
reviewed
Jan 14, 2026
| 1. **After Sandbox Claim**: Once a sandbox is successfully claimed from the pool | ||
| 2. **Metadata Check**: Check if `cpu-scale-factor` metadata exists | ||
| 3. **Current CPU Detection**: Read current CPU from pod spec or status | ||
| 4. **Target Calculation**: Calculate target CPU = current * scaleFactor |
Member
There was a problem hiding this comment.
pls elaborate the calculation for multi-container and burstable QoS:
- for multi-container pod, we can scale up the first non-sidecar container
- for burstable qos, maybe we should scale up both request and limit
| 1. **Enable Metadata-Based CPU Scaling**: Allow users to specify CPU scale factor | ||
| via E2B API metadata when creating sandboxes | ||
| 2. **In-Place Resize**: Leverage Kubernetes pod resize subResource to resize CPU without pod restart | ||
| 3. **Early Return Support**: Optionally return sandbox immediately |
Member
There was a problem hiding this comment.
shall we introduce an annotation or featuregate to enable this support
| | Yes / \ No | ||
| | | | | ||
| | v v | ||
| | [Return Error] [Call Pod /resize] |
Member
There was a problem hiding this comment.
if resize is infeasible, shall we continue to claim other sandbox? plz elaborate the error handling logic.
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
2 participants
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.
Ⅰ. Describe what this PR does
This enhancement proposes enabling in-place CPU resizing for sandboxes
allocated from the warm pool through a metadata-based approach.
When a sandbox is claimed via the E2B API, users can specify a CPU scale factor in the metadata
(e.g.,
e2b.agents.kruise.io/cpu-scale-factor: 2).The sandbox manager will automatically resize the allocated sandbox's CPU resources
in-place using Kubernetes' pod resize subResource, allowing the warm pool to maintain
minimal resource configurations while enabling on-demand CPU scaling for claimed sandboxes.
Ⅱ. Does this pull request fix one issue?
fixes #68
Ⅲ. Describe how to verify it
Ⅳ. Special notes for reviews