WIP: Services v2 (ip-per-service)

DO NOT COMMIT.  Needs test updates and a new e2e test.  Some FIXMEs still.  95% complete.

Add support for IP-per-service behavior.  This creates virtual IP addresses for each service, and uses iptables to route traffic "magically".

The first few commits are relatively independent, and could be extracted to different PRs, if you feel like making me suffer.

See #1107 for background.
Can you explain a bit more what you want to see?  I'm too close to it, I
think.

On Thu, Oct 2, 2014 at 7:10 AM, Clayton Coleman <notifications@github.com>
wrote:

> In docs/services.md:
>
> > +
> > +![Services detailed diagram](services_detail.png)
> > +
> > +## Shortcomings
> > +
> > +Part of the `service` specification is a `createExternalLoadBalancer` flag,
> > +which tells the master to make an external load balancer that points to the
> > +service.  In order to do this today, the service proxy must answer on a known
> > +(i.e. not random) port.  In this case, the service port is promoted to the
> > +proxy port.  This means that is is still possible for users to collide with
> > +each others services or with other pods.  We expect most `services` will not
> > +set this flag, mitigating the exposure.
> > +
> > +We expect that using iptables for portals will work at small scale, but will
> > +not scale to large clusters with thousands of services.  We hope that, by that
> > +time, we will have moved to a model wherein each pod declares which services
>
> Maybe we should sketch out what the user flow for both user-directed
> services and global services looks like and determine whether we want both
> or just one. Also have the discussion about how the ordering problems as
> implemented today for global services and pods affects actual user
> interaction.
> ... <#148d1324a4b6f164_>
> ----- Original Message -----
>  > + > +![Services detailed diagram](services_detail.png) > + > +##
> Shortcomings > + > +Part of the `service` specification is a
> `createExternalLoadBalancer` > flag, > +which tells the master to make an
> external load balancer that points to > the > +service. In order to do this
> today, the service proxy must answer on a > known > +(i.e. not random)
> port. In this case, the service port is promoted to the > +proxy port. This
> means that is is still possible for users to collide > with > +each others
> services or with other pods. We expect most `services` will > not > +set
> this flag, mitigating the exposure. > + > +We expect that using iptables
> for portals will work at small scale, but > will > +not scale to large
> clusters with thousands of services. We hope that, by > that > +time, we
> will have moved to a model wherein each pod declares which > services I
> agree that we shouldn't do the optimization now. My point was that
> requiring users to declare services used isn't the only solution, and I
> have concerns about the impact that would have on ease of use and use-case
> coverage. --- Reply to this email directly or view it on GitHub:
> https://github.com/GoogleCloudPlatform/kubernetes/pull/1402/files#r18324012
>
> --
> Reply to this email directly or view it on GitHub
> <https://github.com/GoogleCloudPlatform/kubernetes/pull/1402/files#r18341089>
> .
>