ready/provisioned condition for v1/service

[cppforlife]

What would you like to be added:

it would be great if there would be a generic way to identify if v1/Service is done provisioning and ready to be used (not implying that endpoints are ready to be used; may be "ready" is not a good name for this).

Why is this needed:

when writing deployment software such as helm it would be nice to avoid having api client figure out when service is ready. example:

https://github.com/helm/helm/blob/4634f5f2faa0caa7de390c95c7d27be22d56a156/pkg/kube/wait.go#L212-L231

[cppforlife]

/sig network

[phoenixking25]

@cppforlife i am interested in this as i got the basic idea, but i am new to kubernetes codebase so need help for sure.

[thockin]

In general there isn't a notion of "ready" for a Service.

If a service has 100 pods, how many must be ready for the service to be ready? Just 1? All 100? Some user-defined proportion?

If a service has a load-balancer, and that LB IP has not been allocated, it's pretty clearly NOT ready. But we report that already. And if that IP has been provisioned, it doesn't mean that traffic is end-to-end flowing yet. You really need to try sending traffic to find out.

Should Service have a health-check? Maybe, but the semantics of that are pretty undefined. ClusterIPs and NodePorts are node-local constructs, so node A might be ready but node B not. Even some LoadBalancer implementations appear as node-local. We could test to endpoints directly, but we already do that via pod readiness.

I'm open to the idea of service-level health-checks, but like so many things, it would need a champion to define the requirements and drive the design.

TL;DR - we have a proxy for this - send traffic.

[thockin]

I'm going to leave this as triage/unresolved for now. Though I have a bias here, I am listening.

[cppforlife]

If a service has 100 pods, how many must be ready for the service to be ready? Just 1? All 100? Some user-defined proportion?

i was not intending for this issue to cover that kind of functionality. to me what you are describing is more of endpoint heathiness state not service resource readiness. this is similar to aws making distinction between provisioning load balancer state, and separate state of target healthiness.

If a service has a load-balancer, and that LB IP has not been allocated, it's pretty clearly NOT ready. But we report that already.

however, there are at least two different types of services: cluster ip / pure kubernetes vs external load balancer. it would be ideal if clients didnt have to know about these different cases (and/or other service configurations) to know when service is “done provisioning”. not neccessarily packet wise ready, but rather done creating/updating.

And if that IP has been provisioned, it doesn't mean that traffic is end-to-end flowing yet. You really need to try sending traffic to find out.

agreed.

…

Sent from my iPhone

On Apr 4, 2019, at 12:44 PM, Tim Hockin ***@***.***> wrote: I'm going to leave this as triage/unresolved for now. Though I have a bias here, I am listening. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[thockin]

however, there are at least two different types of services: cluster ip / pure kubernetes vs external load balancer. it would be ideal if clients didnt have to know about these different cases (and/or other service configurations) to know when service is “done provisioning”. not neccessarily packet wise ready, but rather done creating/updating.

If you don't care that packets can flow, why do you care that some arbitrary progress towards that is complete? It seems to me that you either depend on the Service being reachable "right now" or you don't depend on it. "Provisioned" is meaningless from a functional point of view.

[athenabot]

@thockin
If this issue has been triaged, please comment /remove-triage unresolved.

Meta:
/athenabot mark-triage-reminder

🤖 I am a bot run by @vllry. 👩‍🔬