Merge pull request #2319 from brendandburns/external

Externalized services v2
This commit is contained in:
Tim Hockin
2014-11-14 21:01:19 -08:00
14 changed files with 94 additions and 25 deletions

View File

@@ -127,16 +127,10 @@ being aware of which `pods` they are accessing.
![Services detailed diagram](services_detail.png)
## External Services
For some parts of your application (e.g. your frontend) you want to expose a service on an external (publically visible) IP address. To achieve this, you can set the ```createExternalLoadBalancer``` flag on the service. This sets up a cloud provider specific load balancer (assuming that it is supported by your cloud provider) and also sets up IPTables rules on each host that map packets from the specified External IP address to the service proxy in the same manner as internal service IP addresses.
## 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 it is still possible for users to collide with
each other's 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. See [the original
design proposal for