Enhancements: Deprecate ComponentStatus

[rphillips]

Feature Description

• One-line feature description (can be used as a release note): Deprecate ComponentStatus APIs and kubectl componentstatus functionality
• Primary contact (assignee): @rphillips
• Responsible SIGs: @kubernetes/sig-cluster-lifecycle-feature-requests
• Design proposal link (community repo):
• Link to e2e and/or unit tests:
• Issue https://github.com/kubernetes/kubernetes/issues/19570
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: /cc @justinsb @hongchaodeng
• Approver (likely from SIG/area to which feature belongs):
• Feature target (which target equals to which milestone):
  
  
  
  • Alpha release target (x.y): add code to deprecate kubectl get cs. 1.10 add code to deprecate the APIs
  
  
  • Beta release target (x.y): change documentation and commandline deprecation to beta
  
  
  • Stable release target (x.y): Remove kubectl componentstatus functionality and APIs
  
  

ComponentStatus is functionality to get the health of kubernetes components: etcd, controller manager, and scheduler. The code attempts to query controller manager and scheduler at a static (127.0.0.1) address and fixed port. This requires the components to be run alongside the API server, which might not necessarily be the case in all installations (see: https://github.com/kubernetes/kubernetes/issues/19570#issuecomment-354812863). In addition, the code queries etcd servers for their health which could be out of scope of kubernetes, or problematic to query from a networking standpoint as well.

We could add registration of the controller manager and scheduler (ip+port), like we do with the Lease Endpoint Reconciler for API servers directly within the storage-api (etcd), but this was a stop-gap solution.

This proposal is to deprecate the ComponentStatus API and cli, and eventually remove them around the 1.12-1.13 release.

[rphillips]

I am not sure if this deprecation proposal fits under features or kubernetes issues. If it needs to be moved, just let me know.

[roberthbailey]

eventually remove them around the 1.12-1.13 release.

Have you found out who is using this API and confirmed that they will be able to move off it in this timeframe? It's relatively short given that the api deprecation is effectively being announced just before the 1.10 code freeze.

[roberthbailey]

/cc @hulkholden

[roberthbailey]

Rather than just saying "we should delete this because it isn't perfect" what about finishing the replacement (see https://github.com/kubernetes/kubernetes/issues/18610)? Then we could give consumers of this API something to move _to_ instead of just saying that the API is going away.

[hulkholden]

Agreed - I don't think it's helpful to deprecate something without having a clear recommendation of what it should be replaced with. At the very least we need at least one minor release with both the old and new thing around so we can safely migrate all our clusters.

[idvoretskyi]

Feature target (which target equals to which milestone):
Alpha release target (x.y): 1.10 add code to deprecate kubectl get cs. 1.10 add code to deprecate the APIs

Apologies, but the feature freeze deadline for 1.10 has already passed - https://github.com/kubernetes/sig-release/blob/master/releases/release-1.10/release-1.10.md#timeline.

I can recommend starting working on this within the @kubernetes/sig-cluster-lifecycle-feature-requests in the scope of 1.11.

[timothysc]

imho this no longer belongs to sig-cluster-lifecycle and falls into api-deprecation policy.

/cc @kubernetes/sig-api-machinery-feature-requests

[deads2k]

Rather than just saying "we should delete this because it isn't perfect" what about finishing the replacement (see kubernetes/kubernetes#18610)? Then we could give consumers of this API something to move to instead of just saying that the API is going away.

Agreed - I don't think it's helpful to deprecate something without having a clear recommendation of what it should be replaced with. At the very least we need at least one minor release with both the old and new thing around so we can safely migrate all our clusters.

The current feature that only works for "special" deployments with the right hardcoded ports, exposed insecurely, on localhost. None of those assumptions work in the general case. If we were honest about the level of API, it would have been alpha all this time.

This isn't so much removal without a plan as a recognition that bad assumptions were made in the original design and it probably shouldn't have merged in the first place. I don't think it is incumbent upon the community at large to build a replacement for a feature that doesn't fit in the ecosystem that it purports to watch.

[deads2k]

imho this no longer belongs to sig-cluster-lifecycle and falls into api-deprecation policy.

/cc @kubernetes/sig-api-machinery-feature-requests

apimachinery owns how the the API is served, but we try to stay out what the content of a particular API is. @kubernetes/sig-cluster-lifecycle-feature-requests seems like a pretty good fit given their perspective on how clusters are deployed.

[rphillips]

My takeaway from this thread:

ComponentStatus, in its current form, has large gaps in functionality (hard coded IP and ports, under specced use cases) and the current proposals for ComponentRegistration don't seem to reuse any of the existing ComponentStatus infrastructure. Could we separate out the discussion into 1) deprecating ComponentStatus, and 2) ComponentRegistration to let us proceed without mudding that water with the other feature? Deprecating the broken state doesn't stop someone from implementing a real replacement.

Thoughts?

[idvoretskyi]

/assign @rphillips

[idvoretskyi]

@rphillips @kubernetes/sig-cluster-lifecycle-feature-requests @k8s-mirror-api-machinery-feature-rqusts do you already have a defined roadmap for this feature? Any plans for 1.11?

cc @justaugustus

[rphillips]

Definitely on my TODO list for 1.11.

[mdlinville]

@rphillips please fill out the appropriate line item of the
1.11 feature tracking spreadsheet
and open a placeholder docs PR against the
release-1.11 branch
by 5/25/2018 (tomorrow as I write this) if new docs or docs changes are
needed and a relevant PR has not yet been opened.

[rphillips]

@mistyhacks We can delete it out of the milestone. It isn't done.

[mdlinville]

@justaugustus

[justaugustus]

This feature current has no milestone, so we'd like to check in and see if there are any plans for this in Kubernetes 1.12.

If so, please ensure that this issue is up-to-date with ALL of the following information:

• One-line feature description (can be used as a release note):
• Primary contact (assignee):
• Responsible SIGs:
• Design proposal link (community repo):
• Link to e2e and/or unit tests:
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
• Approver (likely from SIG/area to which feature belongs):
• Feature target (which target equals to which milestone):
  
  
  
  • Alpha release target (x.y)
  
  
  • Beta release target (x.y)
  
  
  • Stable release target (x.y)
  
  

Set the following:

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

Once this feature is appropriately updated, please explicitly ping @justaugustus, @kacole2, @robertsandoval, @rajendar38 to note that it is ready to be included in the Features Tracking Spreadsheet for Kubernetes 1.12.

---

Please note that Features Freeze is tomorrow, July 31st, after which any incomplete Feature issues will require an Exception request to be accepted into the milestone.

In addition, please be aware of the following relevant deadlines:

• Docs deadline (open placeholder PRs): 8/21
• Test case freeze: 8/28

Please make sure all PRs for features have relevant release notes included as well.

Happy shipping!

P.S. This was sent via automation

[kacole2]

Hi @rphillips
This enhancements is missing a milestone. So we'd like to check in and see if there are any plans for this to graduate stages in Kubernetes 1.13. This release is targeted to be more ‘stable’ and will have an aggressive timeline. Please only include this enhancement if there is a high level of confidence it will meet the following deadlines:
Docs (open placeholder PRs): 11/8
Code Slush: 11/9
Code Freeze Begins: 11/15
Docs Complete and Reviewed: 11/27

Please take a moment to update the milestones on your original post for future tracking and ping @kacole2 if it needs to be included in the 1.13 Enhancements Tracking Sheet

Thanks!

[jpbetz]

Looks like there has been no real activity on this since May. Can we get a update on current plans or close this if there are none?

cc @cheftako @logicalhan

[rphillips]

We can close this out for now. I am not actively working on it.

[errordeveloper]

/close

On Mon, 22 Oct 2018, 3:23 pm Ryan Phillips, [e-mail]
wrote:

We can close this out for now. I am not actively working on it.

—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/features/issues/553#issuecomment-431850239,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPWSzDdIxRdVyHEpqnc9iWrjajRD-USks5undTPgaJpZM4SJBFI
.

[liggitt]

The current state of this API is problematic, and requires reversing the actual data flow (it requires the API server to call to its clients), and is not functional across deployment topologies.

Leaving it in place attracts new attempts to make additions to it (https://github.com/kubernetes/kubernetes/issues/74643, https://github.com/kubernetes/kubernetes/pull/82247) and leads to confusion or bug reports for deployments that do not match its topology assumptions (https://github.com/kubernetes/kubernetes/issues/93342, https://github.com/kubernetes/kubernetes/issues/93472). I think it should be clearly marked as deprecated.

[lavalamp]

I agree.

We do not really give a place for exposing / declaring service health, as opposed to individual pod/container health.

I would like the solution to this to have a large component of standardization, such that it can be used for services that are running on the cluster, as well as services that the control plane depends on.

As evidence that these really are, in fact, the same problem, consider that the control plane for cluster A could be running in cluster A (self hosted), or it could be running in cluster B (in some sort of cluster stack). In the self-hosted case it is literally the exact same problem (etcd is behind a service object in the cluster somewhere and also something depended on by the control plane). In the cluster-stack case, the same service health information should probably be exposed in both the parent and child cluster--it makes sense that the same format should be used in both places.

[palnabarun]

Hey there @lavalamp @liggitt , 1.17 Enhancements shadow here. I wanted to check in and see if you think this Enhancement will be graduating to alpha/beta/stable in 1.17?

The current release schedule is:

• Monday, September 23 - Release Cycle Begins
• Tuesday, October 15, EOD PST - Enhancements Freeze
• Thursday, November 14, EOD PST - Code Freeze
• Tuesday, November 19 - Docs must be completed and reviewed
• Monday, December 9 - Kubernetes 1.17.0 Released

If you do, I'll add it to the 1.17 tracking sheet (https://bit.ly/k8s117-enhancement-tracking). Once coding begins please list all relevant k/k PRs in this issue so they can be tracked properly. 👍

Thanks!

[liggitt]

not for 1.17

[johnbelamaric]

Hi @liggitt, think there will be any progress here in 1.18? Need to update the enhancements tracking for the release team (I am shadowing this cycle).

[lavalamp]

I don't think we have planned anything to fix this at the moment.

[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

[palnabarun]

/remove-lifecycle stale

[msedzins]

Hey there @rphillips -- 1.19 Enhancements shadow here. I wanted to check in and see if you think this Enhancement will be graduating in 1.19?

In order to have this part of the release:

1. The KEP PR must be merged in an implementable state
2. The KEP must have test plans
3. The KEP must have graduation criteria.

The current release schedule is:

• Monday, April 13: Week 1 - Release cycle begins
• Tuesday, May 19: Week 6 - Enhancements Freeze
• Thursday, June 25: Week 11 - Code Freeze
• Thursday, July 9: Week 14 - Docs must be completed and reviewed
• Tuesday, August 4: Week 17 - Kubernetes v1.19.0 released

If you do, I'll add it to the 1.19 tracking sheet (http://bit.ly/k8s-1-19-enhancements). Once coding begins please list all relevant k/k PRs in this issue so they can be tracked properly. 👍

Thanks!

[logicalhan]

Hey there @rphillips -- 1.19 Enhancements shadow here. I wanted to check in and see if you think this Enhancement will be graduating in 1.19?

Hi @msedzins, I believe it is unlikely we'll be moving forward with this in 1.19.

[msedzins]

Thank you @logicalhan for the information , if things change - please let me know.

[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

[neolit123]

we saw a number of reports about us breaking this feature further on slack and in k/k - e.g. https://github.com/kubernetes/kubernetes/issues/93342

i personally think that the kubernetes distributed component model and topology variance makes such a feature hard to acheive.
what we have currently should be deprecated and KEPs for new alternatives should be a follow up.

/remove-lifecycle stale

[liggitt]

I personally think that the kubernetes distributed component model and topology variance makes such a feature hard to acheive.

I agree. As a starting point, I've opened https://github.com/kubernetes/kubernetes/pull/93570 to mark the API as deprecated (with no other behavior change) to at least indicate to consumers that it is not the recommended approach.

[fejta-bot]

Enhancement issues opened in kubernetes/enhancements should never be marked as frozen.
Enhancement Owners can ensure that enhancements stay fresh by consistently updating their states across release cycles.

/remove-lifecycle frozen

[liggitt]

Enhancement Owners can ensure that enhancements stay fresh by consistently updating their states across release cycles.

heigh-ho, heigh-ho, it's off to the label mines I go

[logicalhan]

/cc @rngy

[fabioy]

With kubernetes/kubernetes#93570 being reviewed (with a goodbye wave to this hack), what is the proposal for the replacement to this?

[liggitt]

The release note in https://github.com/kubernetes/kubernetes/pull/93570 describes the mechanisms that can be used to determine etcd, scheduler, and controller-manager health instead

[kikisdeliveryservice]

Hi @liggitt @rphillips

Enhancements Lead here. Any plans for this in 1.20?

Thanks,
Kirsten

[liggitt]

This was marked deprecated in 1.19 in https://github.com/kubernetes/kubernetes/pull/93570, with pointers to the recommended alternatives for the components checked by that API. There is not a planned removal timeframe for the existing functionality.