Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] [FG:InPlacePodVerticalScaling] A proposal for CPU allocated strategy when Pod scale up and down #8

Open
wants to merge 8 commits into
base: esotsal/policy_static
Choose a base branch
from

Conversation

Chunxia202410
Copy link

@Chunxia202410 Chunxia202410 commented Nov 7, 2024

What type of PR is this?

/kind cleanup

This PR is based on the kubernetes#123319.

What this PR does / why we need it:

When Guaranteed QoS Class Pod scale up and down without restart with Static CPU management policy alongside InPlacePodVerticalScaling, the allocated CPU should meet the kubernetes CPUs allocation rules.

For scaling up, keep the original CPUs, and only allocate the additional number of CPUs. when allocate additional CPUs, it is necessary to ensure that the combination of the original CPUs and the additional CPUs complies with the Kubernetes CPU allocation rules.
For example:
Assuming the CPU topology is as follows, and kubernetes CPUs allocation rules is Packed(takeByTopologyNUMAPacked):
image
Allocated CPUs of Pod0 is {2,3}, Allocated CPUs of Pod1 is {13}. Other CPUs are free.
-When scale up of Pod 1 from 1 CPU to 2 CPUs. ==> CPU {12} should to be allocated to Pod1, so CPUset of Pod1 is {12,13}
-When scale up of Pod 1 from 1 CPU to 4 CPUs. ==> CPU {12,14,15} should to be allocated to Pod1, so CPUset of Pod1 is {12,13,14,15}
-When scale up of Pod 1 from 1 CPU to 8 CPUs. ==> CPU {8-12,14,15} should to be allocated to Pod1, so CPUset of Pod1 is {8-15}

For scaling down, if there are mustKeepCPUsForResize, when allocate remained CPUs, it is necessary to ensure that the combination of the mustKeepCPUsForResize CPUs and the allocated remained CPUs complies with the Kubernetes CPU allocation rules.

Which issue(s) this PR fixes:

The step as follows for allocate additional CPUs when scale up with CPU allocated packet(takeByTopologyNUMAPacked) rule, and assume that the NUMA nodes are higher than Sockets in the memory hierarchy.

  1. Keep the original CPUs.
  2. Take remain CPUs in the numa which only allocated CPUs to this Pod. (newly add step)
  3. Take full numa nodes.
  4. Take remain CPUs in the socket which only allocated CPUs to this Pod, than take full sockets in numa nodes which allocated CPUs to this Pod. (newly add step)
  5. Take full sockets.
  6. Take remain CPUs in the physical cores which only allocated CPUs to this Pod, than take full cores in sockets which allocated CPUs to this Pod, than take remain full cores in numa which allocated CPUs to this Pod. (newly add step)
  7. Take full physical cores.
  8. Take remain CPUs in the physical cores which only allocated CPUs to this Pod, than take remain CPUs in sockets which allocated CPUs to this Pod, than take remain CPUs in numa which allocated CPUs to this Pod. (newly add step)
  9. Take remain CPUs

Special notes for your reviewer:

Work in progress to modify the code in takeByTopologyNUMADistributed
Work in progress to add Unit/End-To-End Tests

Does this PR introduce a user-facing change?

NONE

@esotsal esotsal force-pushed the esotsal/policy_static branch 6 times, most recently from cb0c2f9 to c3cdfa2 Compare November 13, 2024 16:30
@esotsal esotsal force-pushed the esotsal/policy_static branch 2 times, most recently from b9e6355 to 8c3741d Compare November 25, 2024 02:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant