this belongs in docs/design/. Once it is implemented, user-centric documentation would go into docs/.

Mostly looks good. A couple of comments inline. I'll suggest that @bgrant0607 and @thockin may optionally want to comment.

Remaining comments below are topics for discussion but needn't block getting this design merged:

I don't quite understand why you want to separate autoscaling from unidling. They seem like quite closely related problems. Is that just a short term thing to keep the problem scope manageable, or are you arguing that they should always be separate? If the latter, I didn't follow the argument.

Another thing that I wondered about is whether we will be able to unidle pods in a couple of seconds reliably. If a pod needs an image that has not been cached and takes a long time to pull and unpack, then it might not start in a few seconds. If we cannot do that reliably, then we may need to have the pods be in some intermediate state between non-existent and ready-to-serve. That could change the design of unidling, I think. Thoughts?

Yet another thing I wondered about was how this interacts, if at all, with (proposed) readiness checks: #620. Do we need to buffer the packet until the created endpoint is not just live but also ready to serve? Doesn't the thrashing logic need to distinguish the following types of conditions:

• no pods at all, so need to create one
• 1 pod, which is not ready yet, but was just started, so we should keep waiting
• 1 pod, which is not ready yet and has been wedge for some time, so we need to start another one.
• etc.

The last thing I wondered about is QoS/DoS. The kube-proxies are shared, and need to have bounded memory usage. A burst of traffic to one idled service should not hog all the buffer space so that other innocent idled services have no buffering space left.

I'm sort of confused how we can have a discussion about un-idling without also discussing idling. What does it mean to be idle? Does it imply a new kind of controller than manipulates the replication controller's count? Are idle pods dead, or are they started and frozen (a la CRIU)?

I have a super-naive question. Are events intended to be used as an RPC mechanism between Kubernetes components? I thought they were just for logging/debugging, but they seem to be used here for communication from proxy to unidler to request unidling of a pod. I'm not saying this is a bad idea, it just surprised me. Are we already using this pattern elsewhere?

Great question

On Tue, Jan 6, 2015 at 9:18 PM, davidopp notifications@github.com wrote:

I have a super-naive question. Are events intended to be used as an RPC
mechanism between Kubernetes components? I thought they were just for
logging/debugging, but they seem to be used here for communication from
proxy to unidler to request unidling of a pod. I'm not saying this is a bad
idea, it just surprised me. Are we already using this pattern elsewhere?

Reply to this email directly or view it on GitHub
#3247 (comment)
.

@davidopp @thockin AFAIK, no components are using events for messaging at the moment, but the idea has been proposed in several scenarios, and there is also an expectation that users could use them in this way. We could decide not to use them, but would need to define hooks to call out in addition to generating the events.

Rather than buffering requests indefinitely, is Retry-After a possibility?

Going to take a pass through this at some point in the next day or two to incorporate comments.

@erictune @thockin @bgrant0607 @pweil- @abhgupta Circling back after having my attention diverted for a long while on other matters. This is a bit stale now, but I no longer personally think it makes sense to address in a vacuum. I think it's probably best to do one of the following:

1. Make this proposal primarily about the behaviors of system components for services that are idled
2. Examine idling in this PR and address idling / unidling together

Once #2863 is merged we can fully flesh out links and intersections with the auto-scaling proposal.

Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.

I predict that it may take a while longer to reach consensus on #2863.
If you want to make progress on this, I'd focus on, as you say, behaviors when there are no pods in a service. How packets are buffered and released. etc.

Is this PR active? If not please close it according to https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/devel/pull-requests.md

Closing according to the mentioned policy.

We should give the user flexibility to the user to set min=0. Specially after custom metrics scaling coming into pictur. We have a use case where in we want to scale our deployments from zero to n based on queue length. So when the target of the hpa is not related to pods existense we should give the user option to set min=0
What do you think?
@erictune @thockin

cc @mwielgus @MaciekPytel

@alok87 If I understand correctly what you're asking is just a change in HPA, not unidling as described by this proposal. Can you open a new issue with feature request for sig-autoscaling?

Sure will do that