-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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
Add support for disabling /logs endpoint in kubelet #87273
Conversation
Hi @SaranBalaji90. 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 Once the patch is verified, the new status will be reflected by the 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. |
/ok-to-test |
pkg/kubelet/kubelet.go
Outdated
func (kl *Kubelet) ListenAndServe(address net.IP, port uint, tlsOptions *server.TLSOptions, auth server.AuthInterface, enableCAdvisorJSONEndpoints, enableDebuggingHandlers, enableContentionProfiling bool) { | ||
server.ListenAndServeKubeletServer(kl, kl.resourceAnalyzer, address, port, tlsOptions, auth, enableCAdvisorJSONEndpoints, enableDebuggingHandlers, enableContentionProfiling, kl.redirectContainerStreaming, kl.criHandler) | ||
func (kl *Kubelet) ListenAndServe(address net.IP, port uint, tlsOptions *server.TLSOptions, auth server.AuthInterface, enableCAdvisorJSONEndpoints, enableDebuggingHandlers, enableContentionProfiling, enableSystemLogHander bool) { | ||
server.ListenAndServeKubeletServer(kl, kl.resourceAnalyzer, address, port, tlsOptions, auth, enableCAdvisorJSONEndpoints, enableDebuggingHandlers, enableContentionProfiling, kl.redirectContainerStreaming, enableSystemLogHander, kl.criHandler) |
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.
enableSystemLogHander
maybe Handler
I guess.
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.
Ah thanks. Will fix this.
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
Most of the tests except those in "kubernetes-e2e-kind", failed during cluster creation itself. "Cluster failed to initialize within 300 seconds. For kubernetes-e2e-kind: I see two test runs - 1217685941636829186 and 1217685946661605376. One of the run succeeded and other one failed because of following tests
Even though both of these looks like an issue associated with the worker node, these are not related to this PR. Looking at kubelet logs might help, but not sure how to get those logs. Any help would be appreciated. |
/retest |
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.
Thanks for your pr!
For me, my decision on whether we'd want to merge this pr rests on two questions:
- How many users/cluster admin are interested in disabling the
/logs
endpoint? - Of those who do want to disable it, how important is it to do so?
In my mind, the answer to those two questions will help us weigh the benefits of allowing disabling the /logs
endpoint vs the cost of adding additional configuration to the Kubelet (which already has a whole bunch of tunable parameters).
I think either #sig-node in slack or attending a sig-node meeting would be the best place to get an answer to these questions. Or perhaps folks will weigh in on the issue/pr?
If we do decide to move forward with this feature, your high-level implementation looks sound. I'll look at the details once we have answers to the product questions.
/retest Unsure if these test failures are legit or not... retesting should give us more info :) |
@mattjmcnaughton thanks for taking a look. Will bring this up in next sig-node meeting to get others opinion as well. |
@mattjmcnaughton Regarding the test, I tried couple of times and all test run failed while provisioning the cluster. Given that this is my first PR, I would like to dig into these errors irrespective of whether we merge this PR or not. Just to understand how this process works. Do you happen to have any doc link handy to look into why master provisioning failed? |
/retest |
But this might fail again with the same error. When I look at job history, seems like other test are able to create cluster successfully and run tests. So something might be wrong with the PR itself? |
Sure, just wanted to eliminate chances of some flaky or transient issues. Especially because I see that |
Kubelet is crashing on the master instance. See:
More specifically this seems to be the problem:
Here are the kubelet logs - https://storage.googleapis.com/kubernetes-jenkins/pr-logs/pull/87273/pull-kubernetes-e2e-gce/1217886262732525569/artifacts/e2e-f59951d578-674b9-master/kubelet.log (in general, you can find them under the 'Artifacts' tab in the prow page) It's surprising why the 100-node test didn't see this issue though. Needs digging. |
Thanks Shyam. I will take a look at this. |
/retest |
/remove-area kubeadm |
/approve API bits lgtm, will leave final lgtm to kubelet reviewer |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: derekwaynecarr, liggitt, neolit123, SaranBalaji90 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
/retest |
2 similar comments
/retest |
/retest |
@SaranBalaji90: 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. 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. |
/retest |
kubernetes/kubernetes#87273 Signed-off-by: Maxim Filatov <pipopolam@gmail.com>
kubernetes/kubernetes#87273 Cluster admins can now turn off /logs endpoint in kubelet by setting enableSystemLogHandler to false in their kubelet configuration file. enableSystemLogHandler can be set to true only when enableDebuggingHandlers is also set to true. Signed-off-by: Maxim Filatov <pipopolam@gmail.com>
What type of PR is this?
/kind feature
What this PR does / why we need it:
This PR adds "EnableSystemLogHandler" flag to kubelet configuration similar to "EnableDebuggingHandler". Based on the value of EnableSystemLogHandler, /logs handler will be made available in kubelet. Default value for this flag is true.
Special notes for your reviewer:
Let me know if this change sounds reasonable or if it needs additional changes on top of this.
Which issue(s) this PR fixes:
Fixes #87252
Does this PR introduce a user-facing change?:
/sig node