Add CPUManager policy option to align CPUs by Socket instead of by NUMA node

[klueska]

Enhancement Description

• One-line enhancement description (can be used as a release note):
  Add CPUManager policy option to align CPUs by Socket instead of by NUMA node

• Kubernetes Enhancement Proposal:
  KEP-3327: Add CPUManager policy option to align CPUs by Socket instead of by NUMA node #3334

• Discussion Link:
  There is no public discussion of this. Only private slack messages with @fromanirh and @swatisehgal

• Primary contact (assignee):
  @klueska, @arpitsardhana

• Responsible SIGs:
  /sig node

• Enhancement target (which target equals to which milestone):

  • Alpha release target (1.25):
  • Beta release target (1.26):
  • Stable release target (1.27):

• Alpha

  • KEP (k/enhancements) update PR(s):
    KEP-3327: Add CPUManager policy option to align CPUs by Socket instead of by NUMA node #3334
  • Code (k/k) update PR(s):
    KEP-3327: Add CPUManager policy option to align CPUs by Socket instead of by NUMA node kubernetes#111278
  • Docs (k/website) update PR(s):
    Add docs for KEP-3327 Add CPUManager policy option to align CPUs by Socket instead of by NUMA node website#35569

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[arpitsardhana]

PR for above enhancement: #3334

[Priyankasaggu11929]

/milestone v1.25

[Priyankasaggu11929]

Hello @klueska, @arpitsardhana 👋, 1.25 Enhancements team here.

Just checking in as we approach enhancements freeze on 18:00 PST on Thursday June 16, 2022.

For note, This enhancement is targeting for stage alpha for 1.25 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP file using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable
• KEP has a updated detailed test plan section filled out
• KEP has up to date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements.

Looks like for this one, we would need to update the open KEP PR #3334 for following & get it merged by Enhancements Freeze:

• update the KEP README.md to add more details in the Test Plan section, in furtherance of the goal of increasing reliability across the project.

For note, the status of this enhancement is marked as at risk. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

[arpitsardhana]

Thanks @Priyankasaggu11929 for heads up!
I will update PR with test plan accordingly

[arpitsardhana]

@Priyankasaggu11929 Updated the KEP PR #3334 with test plan section and adhered to format
Let me know if you see any further concerns

[Priyankasaggu11929]

Hello @arpitsardhana, thanks for the heads up & quick update 🙂

Now we require to just get the open KEP PR merged before the updated enhancements freeze on Thursday, June 23, 2022 at 18:00 PM PT. Thank you!

Just one nit, we need marking this checkbox, in the Test Plan section:

[ ] I/we understand the owners of the involved components may require updates to
existing tests to make this code solid enough prior to committing the changes necessary
to implement this enhancement.

[arpitsardhana]

Updated the PR with above nit! Thanks

[Priyankasaggu11929]

With KEP PR #3334 merged, the PR is ready for the 1.25 Enhancements Freeze.

For note, the status is now marked as Tracked. Thank you so much! 🙂

[Atharva-Shinde]

Hi @klueska, Enhancements team here again 👋

Checking in as we approach Code Freeze at 01:00 UTC on Wednesday, 3rd August 2022.

Please ensure that the following items are completed before the code-freeze:

• All PRs to the Kubernetes repo that are related to your enhancement are linked in the above issue description (for tracking purposes).
• All PRs are fully merged by the code freeze deadline.
  KEP-3327: Add CPUManager policy option to align CPUs by Socket instead of by NUMA node kubernetes#111278
  Let me know if there are any additional k/k PRs besides the one listed above

Currently, the status of the enhancement is marked as at-risk

Thanks :)

[arpitsardhana]

Pull Request for feature: kubernetes/kubernetes#111278

[Atharva-Shinde]

Hey @arpitsardhana, reaching out again as we approach Code Freeze at 01:00 UTC on this Wednesday i.e 3rd August 2022.
Try to get this PR kubernetes/kubernetes#111278 merged before the code-freeze :)
The status of the enhancement is still marked as at-risk

[arpitsardhana]

Issues to track for beta:

1. Evaluate if AlignBySocket should be part of TopologyManager
2. Correct place for ValidateStaticPolicyOptions()
3. Unified container manager test cases covering multiple hint provider (under "pkg/kubelet/cm")
4. Improve FakeManager implementation to be more generic

Noted all issues to be tracked for Beta @klueska @fromanirh @swatisehgal

[Priyankasaggu11929]

With k/k code PR kubernetes/kubernetes#111278 merged now, this enhancement is marked as tracked for 1.25 code freeze. Thank you so much @arpitsardhana.

[klueska]

Just out of curiosity, why was this moved to "tracked/no"? The code for this merged as an alpha release in 1.25 and we plan to transition it to beta in 1.26. Shouldn't it be stage/alpha instead?

[Atharva-Shinde]

Hey @klueska 👋
As per the new release opt-in process SIG Leads are supposed to apply lead-opted-in label to the KEP issue to opt it in for the release cycle.

Please refer:
https://groups.google.com/a/kubernetes.io/g/dev/c/R1afPL7zpT4/m/lKv7eg3jBwAJ
https://www.kubernetes.dev/blog/2022/09/09/enhancements-opt-in/
Example KEP issue: #3325 (comment)

cc: @rhockenbury

[klueska]

Even though the code to bring this enhancement to alpha has already merged? I would expect a stage/alpha label in this case.

[rhockenbury]

Hi @klueska

Yes, enhancements need to opt into the current release cycle for when they are planned to graduate. We'll get this opted into v1.26 for beta, but for graduation to stable later on, you'll need to opt in again. The opt in process just involves applying the lead-opted-in label. This is targeting beta for 1.26 so the stage label should reflect that target stage. Let me know if you have any more questions.

/label lead-opted-in
/milestone v1.26
/label tracked/yes
/remove-label tracked/no
/stage beta

[rhockenbury]

No, we are set here and nothing additional is needed. This will remain in alpha for 1.26, and you'll need to opt in again when the 1.27 cycle starts to graduate the enhancements to beta.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[ffromani]

/remove-lifecycle rotten

[SergeyKanzhelev]

is this KEP will be worked on in 1.28?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ffromani]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ffromani]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[ffromani]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale