Relax namespace restriction for critical pods#76310
Relax namespace restriction for critical pods#76310k8s-ci-robot merged 2 commits intokubernetes:masterfrom
Conversation
|
/sig scheduling |
There was a problem hiding this comment.
I think we would desire that quota is required mandatorily to be present in a namespace for allowing SystemPriorityClasses to be created in that namespace. To enforce this, AdmissionConfiguration object with matching scopes for SystemPriorityClasses must be configured.
Then to allow creation, quota can be created in desired namespaces.
There was a problem hiding this comment.
Thnx, @vikaschoudhary16, yes that's what I am planning to do. Will create an admission config obj with SystemPriorityClasses in kube-system namespace at the bootstrap phase so that we are backwards compatible.
/cc @bsalamat
There was a problem hiding this comment.
The problem with this approach is that users will need to add extra configuration to their clusters when they enable ResourceQuotaScopeSelectors. If they don't, this change may create a security gap in their clusters.
Whatever solution we propose here should not need extra configuration by users.
bsalamat
left a comment
There was a problem hiding this comment.
This restriction was an informed decision that we made to prevent a potential vulnerability where a user may create a lot of high priority pods that would preempt system critical components. I still believe that other pods in the system shouldn't be run with those predefined priority classes reserved for system critical components. Why pods in other namespaces need to run with these special priority classes instead of running with a user defined priority that is higher than any other priority, but lower than the system critical priorities?
There was a problem hiding this comment.
Our recent benchmarks show that checking feature gates is relatively slow. We should avoid checking feature gates here. Instead we should check the feature gates at the time of plugin creation and store it in a member variable and use that variable instead.
|
Is there any estimate as to when this will be merged and released? My team and I could really use it |
f989af8 to
c00ebc2
Compare
c00ebc2 to
b392aa2
Compare
b392aa2 to
9dd6107
Compare
d7c6b81 to
f2cbbe2
Compare
|
/hold cancel |
|
matches changes discussed with @deads2k, @ravisantoshgudimetla, and @ahg-g |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: liggitt, ravisantoshgudimetla The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@ravisantoshgudimetla: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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/test-infra repository. I understand the commands that are listed here. |
|
/retest |
|
Can someone please clarify why this is labeled as a bug, has been fixed but not backported? Right now, every version where the feature-gate is enabled actually didn't get this relaxation. So what is the point of validating the feature-gate is enabled when it is already GA in 1.17? |
This was incorrectly labeled as a bug. It is the completion of the feature which includes support for default quota limiting critical pods.
In 1.17, the feature is enabled unconditionally, and the supporting quota configuration graduated to v1 status. |
|
Thanks. |
What type of PR is this?
/kind bug
What this PR does / why we need it:
I think, we should relax the restriction on critical pods to be created within
kube-system, I have outlined an approach which ensures that, initial quota will be restricted tokube-systemnamespace which can later be expanded to other namespaces(https://github.com/kubernetes/kubernetes/pull/76310/files#diff-4e1245d9faac6e47c01c1c068f4de517R199). Let me know, if I have missed something.Which issue(s) this PR fixes:
Fixes #76308
Special notes for your reviewer:
/cc @bsalamat @vikaschoudhary16
Does this PR introduce a user-facing change?:
Ref: document