-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
kubectl: Use metrics-server for kubectl top commands #56206
Conversation
/cc @kubernetes/sig-cli-maintainers |
0569a4d
to
95d5b33
Compare
/test pull-kubernetes-e2e-gce-device-plugin-gpu |
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.
overall looks fine. I'd add a comment to the code about why the getNodeMetricsFromMetricsAPI
isn't just implementing the same interface as the existing client (your logic makes sense, but you should probably leave a note).
Can you simplify the testing by using a fake metrics client instead of stubbing out the HTTP client?
pkg/kubectl/cmd/testing/fake.go
Outdated
fakeClient := f.tf.Client.(*fake.RESTClient) | ||
clientset := metricsclientset.NewForConfigOrDie(f.tf.ClientConfig) | ||
|
||
clientset.MetricsV1alpha1().RESTClient().(*restclient.RESTClient).Client = fakeClient.Client |
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.
we've got fake clientsets generated for the metrics clients. Do you really need to do this?
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.
Tried that and getting this error:
error: no kind "NodeMetricsList" is registered for version "metrics/v1beta1"
Any idea?
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.
hmm... not off the top of my head. I'll have to try and reproduce locally
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'll prepare a branch to share to show you what I mean.
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.
Not sure what I did wrong there, but I managed to get it to work. Do you mind re-reviewing @DirectXMan12 ? :) (oh and happy new year! 🎉)
/unassign |
Due to KubeCon and now vacation this was delayed a bit, but I'm hoping I will get back to it the week before Christmas. |
95d5b33
to
20a9ea9
Compare
20a9ea9
to
1597c70
Compare
/test pull-kubernetes-e2e-gce-device-plugin-gpu |
Now using the fake metrics client in tests as suggested by @DirectXMan12. PTAL @fgrzadkowski @piosz @DirectXMan12 . |
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 think we're almost there. A couple more issues with the tests, and the discovery mechanics may need tweaking.
tf.Printer = &testPrinter{} | ||
tf.Client = &fake.RESTClient{ | ||
NegotiatedSerializer: ns, | ||
Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, 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.
if this is for discovery, this should be structured so that you can use a fake version of the discovery client to accomplish this. You should basically never have to use a fake HTTP client except for when simulating a Heapster response
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.
It is, but the problem is that the underlying testFactory deeply integrates only with the fake rest client. My feeling is that changing that is out of scope for this PR, it would have a lot of impact on the kubectl code, and those changes would be much larger then the PR so far.
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.
ack, we'll put that off until later.
pkg/kubectl/cmd/top_node.go
Outdated
if group.Name == metricsapi.GroupName { | ||
metricsAPIAvailable = true | ||
} | ||
} |
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.
We might want to check version as well
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.
Alternatively, we could try the metrics API client out of the box, and then retrying with the Heapster client if it returns a NotFound error. I'm conflicted as to which is the correct approach
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.
Yes true, I'll make sure to add a version check.
@kubernetes/kubectl-maintainers |
/lgtm |
/retest /assign @pwittrock |
/test pull-kubernetes-e2e-kops-aws |
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.
/lgtm
/approve
/lgtm just waiting on someone from the kubectl owners. |
/approve no-issue |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: brancz, DirectXMan12, piosz, pwittrock, soltysh Associated issue: #55489 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 (batch tested with PRs 56206, 58525). If you want to cherry-pick this change to another branch, please follow the instructions here. |
Since kubernetes#56206, `kubectl top` uses the Resource Metrics API (metrics.k8s.io) and falls back to Heapster, which is deprecated. This commit updates the description of command `kubectl top` to reflect this behavior.
What this PR does / why we need it:
This PR implements support for the kubectl top commands to use the metrics-server as an aggregated API, instead of requesting the metrics from heapster directly. If the
metrics.k8s.io
API is not served by the apiserver, then this still falls back to the previous behavior.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #55489
Special notes for your reviewer:
As utilizing heapster as well as the v1alpha1 version of the metrics API is discouraged, I intentionally implemented the support very separated, so that once it is decided, that support is entirely removed, this will make it easy.
Release note:
/cc @kubernetes/sig-instrumentation-pr-reviews @DirectXMan12 @fgrzadkowski @piosz