@@ -127,16 +127,10 @@ being aware of which `pods` they are accessing.
...
@@ -127,16 +127,10 @@ being aware of which `pods` they are accessing.


## Shortcomings
## 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.
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.
## Shortcomings
We expect that using iptables for portals will work at small scale, but will
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
not scale to large clusters with thousands of services. See [the original