Metrics Server (for resource metrics API)

[DirectXMan12]

Feature Description

• One-line feature description (can be used as a release note): Introduces a lightweight monitoring component for serving the core resource metrics API used by the Horizontal Pod Autoscaler and other components.
• Primary contact (assignee): @piosz
• Responsible SIG: sig/instrumentation
• Design proposal link (community repo): Metrics server
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @DirectXMan12
• Approver (likely from SIG/area to which feature belongs): @DirectXMan12
• Initial target stage (alpha/beta/stable) and release (x.y): alpha in 1.7, beta in 1.8

[DirectXMan12]

@piosz @fabxc I've marked myself as the approver/reviewer and @piosz as the assignee -- feel free to change either if you'd like, but I'm happy to review/approve.

[fgrzadkowski]

I think this work is strictly under SIG/instrumentation, not SIG/autoscaling. I also feel that someone from that sig should be approver. Another reviewer should be someone from api-machinery to make sure we will be using aggregator correctly.

[piosz]

Thanks @DirectXMan12 for creating the issue. I updated it a bit.

I agree that this is purely sig-instrumentation work. @DirectXMan12 is involved in sig-instrumentation too and I think he is the best main approver here, though probably it would make sense to have someone from api-machinery involved too.

[DirectXMan12]

Fine by me (although, FWIW, I've been doing a lot of standing up different add-on API servers recently, so I can prob review the aggregator-related stuff too, at least for the initial reviews).

[DirectXMan12]

WIP repository: https://github.com/kubernetes-incubator/metrics-server

[idvoretskyi]

@DirectXMan12 please, provide us with the design proposal link and docs PR link (and update the features tracking spreadsheet with it).

[DirectXMan12]

this is @piosz's project, but I'm uncertain if it's going to make 1.7.

[idvoretskyi]

@piosz ?

[piosz]

@idvoretskyi the design was reviewed and approved in the doc. I forgot to make it a proposal on github. I'll turn it into the proposal ASAP.

Regarding the feature itself it's almost implemented (the last PR is in flight kubernetes-sigs/metrics-server#4). I'll also add there some documentation. Since this is an alpha feature in incubator I don't think we need an official documentation in Kubernetes docs.

[piosz]

@idvoretskyi I'd like to graduate this to beta in 1.8. Should I create a new feature entry or reuse this one?

[luxas]

@piosz Thanks, yeah, please reuse.

[idvoretskyi]

@piosz yes, please reuse the current one (as it will be the same feature, in a different stage).

[piosz]

The remaining part of work here is to sync metrics-server repo with the recent changes in Kubernetes kubernetes/kubernetes#51653. The problem is that syncing script is broken and it needs to be done manually.

cc @sttts @eparis

[jdumars]

@piosz do you have an update on missing docs? The PR for this is due today.

[jdumars]

@piosz we need docs ASAP for this in order to make 1.8 documentation

[piosz]

@jdumars I'm working on this. We be ready today or tomorrow.

[jdumars]

@piosz when you have a PR could you please link it to this issue? Thanks!

[piosz]

kubernetes/website#5560

[nikhiljindal]

Filed kubernetes/kubernetes#52811 to track missing e2e tests

[ericchiang]

This was discussed today during our release team burndown.

We're extremely worried about adding e2e tests this late in the cycle. Best case scenario those tests get in today or Monday, we wait a day for the e2e tests to give us signal, then have to de-bug an flakes in the test, or identify any actual failures. This is all before the release on Wednesday.

Can someone try to address these concerns? What's the risk if we leave this feature off by default?

cc @kubernetes/kubernetes-release-managers

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[DirectXMan12]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[justaugustus]

@piosz
Any plans for this in 1.11?

If so, can you please ensure the feature is up-to-date with the appropriate:

• Description
• Milestone
• Assignee(s)
• Labels:
  • stage/{alpha,beta,stable}
  • sig/*
  • kind/feature

cc @idvoretskyi

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close