Mark componentstatus as deprecated

[liggitt]

What type of PR is this?
/kind api-change
/kind deprecation

What this PR does / why we need it:
xref kubernetes/enhancements#553 (comment) and #19570

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 (#74643, #82247) and leads to confusion or bug reports for deployments that do not match its topology assumptions (#93342, #93472). It should be clearly marked as deprecated.

Does this PR introduce a user-facing change?:

kube-apiserver: the componentstatus API is deprecated. This API provided status of etcd, kube-scheduler, and kube-controller-manager components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints.

/cc @deads2k @lavalamp @neolit123
/sig api-machinery cluster-lifecycle

[liggitt]

/cc @smarterclayton

[liggitt]

/priority important-longterm

[liggitt]

/hold for api-review

[dims]

@liggitt when will we be able to remove it? (if at all?)

[liggitt]

/retest

[liggitt]

@liggitt when will we be able to remove it? (if at all?)

I'm not sure (a core/v1 API predating the deprecation policy, with no replacement, is sort of unprecedented), but communicating the lack of continued development and known inconsistent behavior of what is currently there is important.

[smarterclayton]

A Kubernetes provider is not required to follow the configuration necessary to expose this data, nor is this required for all distributions to implement. We have explicitly stated that we would not put this in conformance because conformant distributions may choose not to expose this. Component status should be removed.

/approve

I will leave the hold for another reviewer.

[neolit123]

thanks!
/lgtm

[lavalamp]

/approve
/lgtm

[lllamnyp]

If reversing data flow is a problem re

The current state of this API is problematic, and requires reversing the actual data flow

then are we to expect a deprecation of kubectl logs and kubectl exec at some point?

[lavalamp]

then are we to expect a deprecation of kubectl logs and kubectl exec at some point?

YES

(Actually this is really hard, because those are much-used features. The current "plan" is to add the notion of subresource to the aggregator, and then move "model breaking" subresources, such as those, out of the main apiserver into a separate binary. Ideally also adding a redirect rather than proxy mode, so that actual traffic doesn't have to go through apiserver at all. This isn't staffed or being worked on right now but if it's something someone wants to work on, come talk to SIG API Machinery...)

[YanzhaoLi]

Hi, any idea for alternative method to check status?

[Napsty]

Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints.

Any example on this would be greatly appreciated. ;-)

edit: Found etcd check example on https://kubernetes.io/docs/reference/using-api/health-checks/, but only seems to work starting with Kubernetes 1.20:

curl -k https://localhost:6443/livez/etcd

[eumel8]

Now it comes nearly to an end for the componentstatus. If you headed here from Google and you are a Rancher user you can use Rancher management API to ask the status:

$ kubectl get clusters.management.cattle.io <your-cluster-id> -o json | jq  '.status.componentStatuses[] | .name,.conditions[].message'
"controller-manager"
"ok"
"etcd-0"
"{\"health\":\"true\"}"
"etcd-1"
"{\"health\":\"true\"}"
"etcd-2"
"{\"health\":\"true\"}"
"scheduler"
"ok"

plain curl:

$ curl -s -H "Content-Type: application/json" -H "authorization: Bearer <token>"  https://<rancher-server>/k8s/clusters/local/apis/management.cattle.io/v3/clusters/<your-cluster-id> | jq '.status.componentStatuses[] | .name,.conditions[].message'
"controller-manager"
"ok"
"etcd-0"
"{\"health\":\"true\"}"
"etcd-1"
"{\"health\":\"true\"}"
"etcd-2"
"{\"health\":\"true\"}"
"scheduler"
"ok"'