Further differentiate performance characteristics associated with pod level QoS

[derekwaynecarr]

Feature Description

• One-line feature description (can be used as a release note): Provide a reason why users would choose to run Guaranteed pods over Burstable pods. Right now, Guaranteed pods have a penalty (due to cpu limit enforcement). Ideally, we can optimize how the kubelet manages Guaranteed pods to provide material benefits over Burstable pods, particularly with respect to latency sensitivity.
• Primary contact (assignee): @sjenning @ConnorDoyle
• Responsible SIGs: sig-node
• Design proposal link (community repo): Add CPU manager proposal. community#654
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @vishh @derekwaynecarr
• Approver (likely from SIG/area to which feature belongs): @derekwaynecarr
• Initial target stage (alpha/beta/stable) and release (x.y): Alpha 1.8, Beta 1.10

[dchen1107]

@derekwaynecarr I didn't target this for 1.7 since it relies on our design.

[ConnorDoyle]

/assign

[derekwaynecarr]

@ConnorDoyle @dchen1107 - updated as follows:

• Primary contacts to @sjenning and @ConnorDoyle
• Link to design proposal added Add CPU manager proposal. community#654
• Reviewers to @vishh and @derekwaynecarr
• Approver to @derekwaynecarr
• Target for Alpha in 1.8

[ConnorDoyle]

xref #375

[idvoretskyi]

@ConnorDoyle @sjenning @kubernetes/sig-node-feature-requests any updates for 1.8? Is this feature still on track for the release?

[sjenning]

@idvoretskyi yes, there were a series of PRs that were merged to enable CPU manager, which is a component of this issue

1/6 kubernetes/kubernetes#49186 (closed, broken out into following PRs)
2/6 kubernetes/kubernetes#51132
3/6 kubernetes/kubernetes#51140
4/6 kubernetes/kubernetes#51357
5/6 kubernetes/kubernetes#51180
6/6 kubernetes/kubernetes#51041 (still open, e2e tests)

[calebamiles]

last PR looks like it's scheduled to merge. @sjenning, do you have a docs PR in flight?

[balajismaniam]

@calebamiles Some docs related to CPU manager have already merged (https://github.com/kubernetes/kubernetes.github.io/blob/release-1.8/docs/tasks/administer-cluster/cpu-management-policies.md). There are some PRs in flight to update them.

[calebamiles]

Thanks for the update, @balajismaniam. @derekwaynecarr suggested that this feature issue was essentially a dupe of #375 but predates it. How would we feel about closing this issue in favor of #375?

cc: @kubernetes/sig-node-feature-requests, @kubernetes/kubernetes-release-managers

[ConnorDoyle]

Depends on what else besides CPU manager @derekwaynecarr has in mind to differentiate the G class. If there's nothing specific planned for now then +1 to close it.

[resouer]

@balajismaniam @derekwaynecarr One thing seems missing in doc and proposal is, for example when I set cpu: "2", what's the value should be in Pod level cgroup? We may need to skip container with cpu request >= 1 during ensuring pod qos.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[sjenning]

/remove-lifecycle stale

[derekwaynecarr]

updated beta status for 1.10

[justaugustus]

@ConnorDoyle @sjenning @derekwaynecarr @kubernetes/sig-node-feature-requests
Any plans for this in 1.11?

If so, can you please ensure the feature is up-to-date with the appropriate:

• Description
• Milestone
• Assignee(s)
• Labels:
  • stage/{alpha,beta,stable}
  • sig/*
  • kind/feature

cc @idvoretskyi

[justaugustus]

This feature current has no milestone, so we'd like to check in and see if there are any plans for this in Kubernetes 1.12.

If so, please ensure that this issue is up-to-date with ALL of the following information:

• One-line feature description (can be used as a release note):
• Primary contact (assignee):
• Responsible SIGs:
• Design proposal link (community repo):
• Link to e2e and/or unit tests:
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
• Approver (likely from SIG/area to which feature belongs):
• Feature target (which target equals to which milestone):
  • Alpha release target (x.y)
  • Beta release target (x.y)
  • Stable release target (x.y)

Set the following:

• Description
• Assignee(s)
• Labels:
  • stage/{alpha,beta,stable}
  • sig/*
  • kind/feature

Once this feature is appropriately updated, please explicitly ping @justaugustus, @kacole2, @robertsandoval, @rajendar38 to note that it is ready to be included in the Features Tracking Spreadsheet for Kubernetes 1.12.

---

Please note that Features Freeze is tomorrow, July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.

In addition, please be aware of the following relevant deadlines:

• Docs deadline (open placeholder PRs): 8/21
• Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.

Happy shipping!

P.S. This was sent via automation

[kacole2]

Hi
This enhancement has been tracked before, so we'd like to check in and see if there are any plans for this to graduate stages in Kubernetes 1.13. This release is targeted to be more ‘stable’ and will have an aggressive timeline. Please only include this enhancement if there is a high level of confidence it will meet the following deadlines:

• Docs (open placeholder PRs): 11/8
• Code Slush: 11/9
• Code Freeze Begins: 11/15
• Docs Complete and Reviewed: 11/27

Please take a moment to update the milestones on your original post for future tracking and ping @kacole2 if it needs to be included in the 1.13 Enhancements Tracking Sheet

Thanks!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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 kubernetes/test-infra repository.