[danielmartins]

By default, all ELBs created by Kubernetes are external, and they load balance traffic to every node in the cluster to the service port (each service gets its own port number which is the same in every node).

[machbio]

So, thats a lot of AWS traffic cost for the traffic between different services :(

[swozey]

You can stay within the cluster via connecting with "servicename"(ie, https://mynodeapp/) - they're added to one another as environment variables.

If you need to communicate with another namespace on the cluster you can do servicename.myothernamespace.svc.cluster.local, etc.

[danielmartins]

That's true if you reference each service via its external ELB CNAME (or a Route53 DNS that points to it); however, Kubernetes comes with a built-in DNS server that you can use to discover the endpoint IP addresses in the pod CIDR (all pods are in the same subnet via the overlay network).

[DigitalJack]

You can define services to be internal. I presume this does not use an elb but I have not tried it yet.

[swozey]

A lb (glbcd/elb) is only provisioned if you declare type: LoadBalancer. ClusterIP and NodePort don't provision one, and you can always communicate over podIP or via the sky-dns cluster.svc.local records, the former having HA implications.

[smarterclayton]

There has been some work towards having a bare metal IP allocator for metal (you route a subnet to the cluster and when someone adds a Service with type loadbalancer you get handed a magic HA VIP). Not yet in Kube, just OpenShift, but I think we'll eventually work to have it be something you can use if you control your network infra.

[swozey]

Is there any work toward utilizing Openshift Origin on GKE? I'm aware that I can manually configure things to do so but I'd really prefer to to it just be a deployment/daemonset that ties into my GKE instance. This probably affects the customer base of Openshift so I assume it's not likely, but I'd really love to use Openshift on GKE.