WIP: ip per service #1038
WIP: ip per service #1038
Conversation
|
Very interesting. Scales pretty well logically as well. I assume then if you wanted your service to be exposed external you'd bind an external address as well and ensure it routes external to internal. |
|
Exactly. It also allows for intra-pod ambassadors (proxies), rather than On Tue, Aug 26, 2014 at 8:05 AM, Clayton Coleman notifications@github.com
|
| } | ||
|
|
||
| // FIXME: probably should be [4]byte and also carry the subnet part | ||
| type ipSubnet [4]string |
There was a problem hiding this comment.
Ow, my eyes! ;) Can you make this work instead: http://golang.org/pkg/net/#IP
There was a problem hiding this comment.
Yeah - let's try to future proof ourselves for IPv6 here.
There was a problem hiding this comment.
Oh yeah, that was my other comment which I forgot to actually say. IPv6!!
|
So what happens if the machine "holding" the service IP goes away? I thought the way it works today is that the service proxy would round-robin across N pods to ensure you always hit the service from anywhere in the cluster. Since the proxy runs on every host, all external clients can hit any member of the cluster and end up in the right place. |
|
I think the model at the moment is that every minion just pretends (via IPTables magic) that X IP address gets routed to Y service, and nothing else changes. @thockin, is that right? |
|
It looks like I never filed an issue specifically for IP per service, but FYI this is a roadmap.md item and is covered in networking.md. It was perhaps first discussed in #146 and #188. |
|
I'm going to write this up a bit before pushing further with this PR. I On Thu, Aug 28, 2014 at 2:38 PM, bgrant0607 notifications@github.com
|
|
Such discipline! |
|
It takes every ounce of my being not to write a 20 page doc with diagrams, On Thu, Aug 28, 2014 at 4:43 PM, Clayton Coleman notifications@github.com
|
Bug 2021936: Read k8s version from hyperkube Dockerfile
This is filled with cruft, but I wanted to float the idea. It actually works.
Overview: When a service object is created, allocate it an IP. Broadcast that IP to all kube-proxies. Each one will set up iptables rules to forward traffic for that IP:port to a random local port. Clients connect to a stable ip:port but no more port collisions!