On Tue, Oct 31, 2017 at 10:32 AM, David Rosenstrauch <dar...@darose.net> wrote: > On 2017-10-30 10:56 pm, David Rosenstrauch wrote: >> >> Another possible way for me to work around this problem is that I >> could probably eliminate the "pets" constraint I'm bumping up against >> if I were able to run the pods behind a customized Service/load >> balancer that was a bit smarter about which specific pod instance it >> routed traffic to. > > > I've been following up this angle a bit today, and trying to see if it's > possible for Readiness Probes to accomplish what I'm trying to do here. > Long story short is that my pods are each running a single-threaded process > (again, a function of the 3rd party software we're running) so what I'm > primarily trying to do is avoid sending traffic to a pod whose thread is > already busy. Theoretically Readiness Probes can accomplish that. > > The docs say that Kubernetes Services won't send traffic to any pod that's > failing the Readiness Probe. And this proves out in my testing: when I set
Keep in mind this is fundamentally a distributed operation - it is never instantaneous. The failed readiness probe is polled, that info is propagated up to apiserver and back down to kube-proxies. > the Readiness Probe on an example nginx deployment to execute the command > /bin/false - thereby forcing a readiness failure, the service goes dead > (times out). Just looking to clarify, though: what exactly happens to > traffic that's sent to a service where all its pods are in a "not ready" > state? Does the traffic go to /dev/null? Does it queue up / block, so that > if one of the pods suddenly becomes ready again, then that pod will > (belatedly) handle the request? If all the pods are dead, new traffic goes to a black hole. New connections fail, but open connections are fine. -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
