On Tue, Oct 31, 2017 at 6:54 AM, David Rosenstrauch <dar...@darose.net> wrote: > Hi Tim. Thanks much for your response, and I appreciate your suggestions. > Discussion inline. > > On 2017-10-31 12:24 am, 'Tim Hockin' via Kubernetes user discussion and Q&A > wrote: >> >> On Mon, Oct 30, 2017 at 7:56 PM, David Rosenstrauch <dar...@darose.net> >> wrote: >>> >>> The problem is that the way the system is currently built (out of my >>> control >>> - depends on idiosyncrasies of a piece of 3rd party software) these >>> micro-services have to operate more like "pets" than "cattle". > > >>> This is obviously different from the way most micro-service >>> systems work, where each individual instance is pretty much identical to >>> any >>> other > > >> This is not THAT uncommon. The typical answer is to create a Service >> per Pod. Obviously this doesn't scale very well if you have hundreds >> of replicas, but if you have a small (and stable) number of pods that >> each need a public IP, this works. >> >> You can do it with either a NodePort or a LoadBalancer, but you need >> to set up different labels on each pod, so it's not fully automated. > > > Yes, this technically would work. But, as you indicated, it really isn't > scalable. A big reason for us to move to k8s is so that we can just quickly > scale up to replicate 5 or 10 instances of a particular pod. That wouldn't > be possible in this scenario, as I'd have to manually create 5 or 10 > different services. So yes, doable, but not really a great solution IMO.
External IPs and ports are, fundamentally NOT an elastic resource (at least not cheaply), which is why they are managed carefully. The separation of Pods and Services means that there isn't a clear way to do what you want without Services. Another option would be to use a HostPort. If you have more nodes than replicas, you can use a static host port. If you have more replicas than nodes this won't work, though you could maybe shard your app into N sets of pods, each with less replicas than nodes, and use N static host ports. Hacky but workable. We do not have a dynamic HostPort option, and I am very much not in favor of adding it if we can avoid it. Another option would be to use HostNetwork, and just use a random port, and self-register your replicas in whatever registry (assuming you don't care about port numbers being random). Some game servers do exactly this. >>> What I've been trying to do is find a way for *each* of these individual >>> instances of a micro-service to get assigned a public ip/port, rather >>> than >>> just assigning one single public ip/port that points to a load balancer >>> in >>> front of them. But I don't see any way to do this properly in >>> Kubernetes. > > >> If you need this to be elastic, you might want a custom controller, or >> it might be something StatefulSet could handle. > > >> You can always do this. All the built-in controllers are just clients >> of the Kubernetes API. It's pretty easy to write your own to do >> whatever you need. > > > Thanks for the suggestions on StatefulSet and custom controllers - I'll read > up on them a bit more. > > > Best, > > > DR > > -- > 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. -- 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.
