-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Monitoring Pipeline Metrics HPA API #118
Comments
cc @piosz @fgrzadkowski @derekwaynecarr @kubernetes/autoscaling @kubernetes/sig-instrumentation |
@DirectXMan12 any updates on this issue? Can you provide the actual status of it and update the checkboxes above? |
The proposal is posted, but has not been approved yet. We only recently reached general consensus about the design. Still finalizing the exact semantics. It should be removed from the 1.5 milestone, since no code will have gone into 1.5 |
@DirectXMan12 thank you for clarifying. |
@DirectXMan12 there maybe users who are currently using the previous alpha implementation of custom metrics. Can we prepare user documentation for such users ahead of the release? We would like to be careful not to break pod auto-scaling for any users. |
@DirectXMan12 please, provide us with the release notes and documentation PR (or links) at https://docs.google.com/spreadsheets/d/1nspIeRVNjAQHRslHQD1-6gPv99OcYZLMezrBe3Pfhhg/edit#gid=0 |
done :-) |
…2beta1 Automatic merge from submit-queue (batch tested with PRs 51335, 51364, 51130, 48075, 50920) Graduate custom metrics API to v1beta1 This graduates custom-metrics.metrics.k8s.io/v1alpha1 to custom-metrics.metrics.k8s.io/v1beta1. The move is more-or-less just a straightforward rename. Part of kubernetes/enhancements#117 and kubernetes/enhancements#118 ```release-note the custom metrics API (custom-metrics.metrics.k8s.io) has moved from v1alpha1 to v1beta1 ```
Automatic merge from submit-queue (batch tested with PRs 51603, 51653) Graduate metrics/v1alpha1 to v1beta1 This introduces v1beta1 of the resource metrics API, previously in alpha. The v1alpha1 version remains for compatibility with the Heapster legacy version of the resource metrics API, which is compatible with the v1alpha1 version. It also renames the v1beta1 version to `resource-metrics.metrics.k8s.io`. The HPA controller's REST clients (but not the legacy client) have been migrated as well. Part of kubernetes/enhancements#118. ```release-note Migrate the metrics/v1alpha1 API to metrics/v1beta1. The HorizontalPodAutoscaler controller REST client now uses that version. For v1beta1, the API is now known as resource-metrics.metrics.k8s.io. ```
@idvoretskyi this is beta in 1.8 |
…2beta1 Automatic merge from submit-queue (batch tested with PRs 51335, 51364, 51130, 48075, 50920) Graduate custom metrics API to v1beta1 This graduates custom-metrics.metrics.k8s.io/v1alpha1 to custom-metrics.metrics.k8s.io/v1beta1. The move is more-or-less just a straightforward rename. Part of kubernetes/enhancements#117 and kubernetes/enhancements#118 ```release-note the custom metrics API (custom-metrics.metrics.k8s.io) has moved from v1alpha1 to v1beta1 ``` Kubernetes-commit: d375e1595f74b2cd80a700809a9e4ac0fd5335db
Automatic merge from submit-queue (batch tested with PRs 51603, 51653) Graduate metrics/v1alpha1 to v1beta1 This introduces v1beta1 of the resource metrics API, previously in alpha. The v1alpha1 version remains for compatibility with the Heapster legacy version of the resource metrics API, which is compatible with the v1alpha1 version. It also renames the v1beta1 version to `resource-metrics.metrics.k8s.io`. The HPA controller's REST clients (but not the legacy client) have been migrated as well. Part of kubernetes/enhancements#118. ```release-note Migrate the metrics/v1alpha1 API to metrics/v1beta1. The HorizontalPodAutoscaler controller REST client now uses that version. For v1beta1, the API is now known as resource-metrics.metrics.k8s.io. ``` Kubernetes-commit: 0076f02df0d6979fe89911d1070e7cfc02ba6b0c
@DirectXMan12 did we move to beta with any changes? I could not find any documentation of any changes, just wanted to confirm... |
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
@DirectXMan12 If so, can you please ensure the feature is up-to-date with the appropriate:
cc @idvoretskyi |
I'm going to close this feature issue, and we'll roll it into the HPA one. The features are so tightly entwined that it makes sense to track together. |
Thanks for consolidating, Solly! |
cleanup misplaced enhancements
Description
The new monitoring vision (https://docs.google.com/document/d/1z7R44MUz_5gRLwsVH0S9rOy8W5naM9XE5NrbeGIqO2k/) proposes several APIs for the HPA to access metrics. The master metrics API, used to access "core" resource metrics, is already implemented, but still needs to be stabilized. The vision also proposes an adapter API that allows the HPA to access arbitrary metrics from the monitoring pipeline.
This feature tracks defining the API(s), producing an initial implementation (most likely on top of Heapster), and making sure that the HPA is set up to consume the API.
Sponsored by SIG Instrumentation (@kubernetes/sig-instrumentation) and SIG Autoscaling (@kubernetes/autoscaling)
Progress Tracker
/pkg/apis/...
)@kubernetes/api
@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
on docs PR@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/api
@kubernetes/feature-reviewers
on this issue to get approval before checking this off@kubernetes/docs
@kubernetes/feature-reviewers
on this issue to get approval before checking this offFEATURE_STATUS: IN_DEVELOPMENT
More advice:
Design
@kubernetes/feature-reviewers
member, you can check this checkbox, and the reviewer will apply the "design-complete" label.Coding
and sometimes http://github.com/kubernetes/contrib, or other repos.
@kubernetes/feature-reviewers
and they willcheck that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.
Docs
@kubernetes/docs
.The text was updated successfully, but these errors were encountered: