-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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
Allow nodes to create evictions for its own pods in NodeRestriction admission controller #48707
Allow nodes to create evictions for its own pods in NodeRestriction admission controller #48707
Conversation
Hi @danielfm. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with I understand the commands that are listed here. 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. I understand the commands that are listed here. |
Okay, now I think this is ready for review @deads2k @tallclair @liggitt |
@kubernetes/sig-auth-pr-reviews @kubernetes/sig-node-pr-reviews |
return admission.NewForbidden(a, fmt.Errorf("unexpected type %T", a.GetObject())) | ||
} | ||
// get the existing pod from the server cache | ||
existingPod, err := c.podsGetter.Pods(eviction.Namespace).Get(eviction.Name, v1.GetOptions{ResourceVersion: "0"}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect the namespace to be pulled from the admission attributes, and the pod name to be pulled from the admission attributes as well, if set, rather than from the submitted object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
// wasn't found in the server cache, do a live lookup before forbidding | ||
existingPod, err = c.podsGetter.Pods(eviction.Namespace).Get(eviction.Name, v1.GetOptions{}) | ||
} | ||
if existingPod == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
check err != nil
, rather than existingPod == nil
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
both here and in the delete case, I wonder if we should return a NotFound error instead of a Forbidden error if the err
here is a NotFound error...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
check
err != nil
, rather thanexistingPod == nil
Done.
both here and in the delete case, I wonder if we should return a NotFound error instead of a Forbidden error if the err here is a NotFound error...
What do you propose we do? Should these be addressed here, or in a different PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would change it here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something like 8f7cd82a84c17bf7a8f8bb78b737116dd133a4b3?
podKind = api.Kind("Pod").WithVersion("v1") | ||
podResource = api.Resource("pods").WithVersion("v1") | ||
podKind = api.Kind("Pod").WithVersion("v1") | ||
evictionKind = api.Kind("Eviction").WithVersion("policy/v1beta1") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be policyapi.Kind("Eviction").WithVersion("v1beta1")
@@ -161,6 +164,9 @@ func (c *nodePlugin) admitPod(nodeName string, a admission.Attributes) error { | |||
if errors.IsNotFound(err) { | |||
// wasn't found in the server cache, do a live lookup before forbidding | |||
existingPod, err = c.podsGetter.Pods(a.GetNamespace()).Get(a.GetName(), v1.GetOptions{}) | |||
if errors.IsNotFound(err) { | |||
return admission.NewNotFound(a) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it work to just return the error as-is, with no wrapping?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
this looks pretty good to me, go ahead and rebase on latest master and squash |
@kubernetes/sig-scheduling-pr-reviews @davidopp wanted to make sure it made sense to allow a node to perform evictions on its own pods... it can already delete them directly |
Rebased and squashed. |
@k8s-bot ok to test |
@liggitt Can you please take another look? I implemented the suggested changes, although I'm not so sure about the change in which we return HTTP 404, particularly in how to document the expected behavior in integration tests (the comment is probably wrong). I'd be happy to address any other issues you might find. |
err: "forbidden: unexpected operation", | ||
}, | ||
{ | ||
name: "allow create of unnamed eviction for mirror pod to another", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
test name is wrong, this is expecting a forbidden error
test/integration/auth/node_test.go
Outdated
@@ -230,7 +255,9 @@ func TestNodeAuthorizer(t *testing.T) { | |||
expectForbidden(t, getPV(node1Client)) | |||
expectForbidden(t, createNode2NormalPod(nodeanonClient)) | |||
expectForbidden(t, createNode2MirrorPod(node1Client)) | |||
expectForbidden(t, deleteNode2MirrorPod(node1Client)) | |||
// mirror pods do not exist from the apiserver stand point |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think a comment is needed here... the pod doesn't exist from any stand point :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hahah got it. :)
Done. Thanks again for your input, @liggitt. |
/test pull-kubernetes-kubemark-e2e-gce |
Any updates? /cc @liggitt @davidopp @tallclair |
/retest |
Sorry for the delay. Yes, this is fine. Evict is just a delete that can sometimes be rejected by the API server. So since a node can already delete, it's fine for it to be able to use the eviction subresource. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danielfm, liggitt Associated issue: 48666 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
Automatic merge from submit-queue |
Can it be cherry-picked to release-1.7 please? |
backports are typically limited to fixes for bugs and regressions |
@liggitt , it is kinda bug no? NodeRestriction admission controller can't be used in all cases it was designed to be used. Missing eviction permission is clearly an oversight and was never an intent. Maybe you can consider to including it to 1.7? |
Is there code in the kubelet that calls the evict subresource? If so, I would agree this is a bug. If not, I'd consider it an enhancement. |
@liggitt , yes there is eviction code in a kubelet. It is invoked when it tried to free resources when under pressure: kubernetes/pkg/kubelet/eviction/eviction_manager.go Lines 524 to 545 in 74b1f5b
|
I stand corrected, I'll open a cherry-pick |
Commit found in the "release-1.7" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked. |
What this PR does / why we need it: This PR adds support for
pods/eviction
sub-resource to the NodeRestriction admission controller so it allows a node to evict pods bound to itself.Which issue this PR fixes: fixes #48666
Special notes for your reviewer: The NodeRestriction already allows nodes to delete pods bound to itself, so allowing nodes to also delete pods via the Eviction API probably makes sense.