Exposing Pod Status via new Kubelet API

[Rob Scott]

Hey Everyone,

I'm interested in exploring the possibility of adding a new Kubelet API that can serve Pod status, specifically the readiness information of the Pod. Although there's already a podresources endpoint, this does not appear to be officially supported and does not contain the information we need (Pod readiness). 

From a networking perspective, it would be very helpful to have the result of the health check available and served directly by the same component doing the health check (Kubelet). In a situation where a component running on a node wants to understand the health of other Pods on the same Node, currently the only option is to make a request to the Kubernetes API. This means that a local health check failure will need to be propagated through API Server before any other component on the Node is aware of the failure. This is obviously not ideal in terms of reliability or efficiency.

Is anyone else interested in this? If so, responses here would be very appreciated. I've also added this to the sig-node agenda next week.

Thanks!

Rob

[Francesco Romani]

On 6/8/23 00:44, 'Rob Scott' via kubernetes-sig-node wrote:

Hi!

> Hey Everyone,
>
> I'm interested in exploring the possibility of adding a new Kubelet
> API that can serve Pod status, specifically the readiness information
> of the Pod. Although there's already a podresources endpoint, this
> does not appear to be officially supported and does not contain the
> information we need (Pod readiness).

I'm interested in this proposal and yes, pod resources endpoint may be
not the best fit for this proposal (but I think we can evaluate?). But
may I ask what do you mean with not officially supported?

While the semantics may need some cleanup (per June 5 sig-node meeting),
both the API and the endpoint are GA or GA'ing in 1.28


To reiterate, in general I'm very interested in having a endpoint local
to the kubelet exposing a well defined set of attributes of a pod, and I
know there could be interest in the node area, recalling past discussion
related to podresources API.


Bests,


--
Francesco Romani
SWE @ Red Hat
github: @ffromani

[smarter...@gmail.com]

+1 - this seems reasonable.  I assume this is a bit like how kube-proxy exposes an endpoint so service load balancer impls can ask a node whether it has an endpoint for that service, just one level up (so a local agent can ask the kubelet - the source of truth for readiness - whether a pod is ready without crossing a distributed system line to the api)?

[Rob Scott]

I'm interested in this proposal and yes, pod resources endpoint may be
not the best fit for this proposal (but I think we can evaluate?)

Yep, open to wherever this fits best.

But may I ask what do you mean with not officially supported?

Woops, looked like I got something mixed up here, thanks for catching this!

I assume this is a bit like how kube-proxy exposes an endpoint so service load balancer impls can ask a node whether it has an endpoint for that service, just one level up (so a local agent can ask the kubelet - the source of truth for readiness - whether a pod is ready without crossing a distributed system line to the api)?

Yep, that's a great example.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-node" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-node/1a764749-61d7-4f29-b695-a387e469b22fn%40googlegroups.com.