hack endpoint controller so that services map to hostIp:hostPort

... instead of podIp:containerPort

This is a hack and was meant to be a temporary thing to validate that we can run the guestbook examples (with modified, mesos-friendly ports). It deviates from default k8s functionality to simplify networking requirements for k8s-mesos cluster.

Instead of a k8s service endpoint mapping to a `podIP:containerPort` it maps to `hostIP:hostPort`. This means that for any service that wishes to expose pod services, those pod services must specify a hostPort in their manifest. Leaving hostPort blank or set to zero in a pod manifest will result in no hostPort being mapped to the pod's containerPort and so services will be unable to connect.

A significant consequence of this is that end-users publishing pods are more likely to collide on hostPort's since they must specify them in order to expose pod functionality through services. A possible workaround (*currently unimplemented on this branch*) would be to allow the k8s-mesos scheduler to randomly assign hostPort's to pods if users publish a pod/container that specifies "magic" hostPort of 1. Ugly, ugly, ugly but it makes life simpler for end-users at the expense of a lost port (since 1 is magical now).

Use this branch at your own peril for now.
Well, within a Mesos "framework" we usually talk about the "scheduler" vs. "executor" rather than master/slave. Or are you talking about the Kubernetes master? I'm imagining a future where we've got the K8s master running on a separate machine from the K-M scheduler, and wonder which component you're referring to here. Presumably the K8s API server (master), since that's what you're curling.