<p>I built a Kubernete cluster in local data center. There are 4 nodes and 1 master.
Looking for a L4 loadbalance solution for internal service.</p>

<pre><code>root@niubi01:/home/mesos# kubectl get nodes
NAME      STATUS         AGE
niubi01   Ready,master   7d
niubi02   Ready          7d
niubi03   Ready          7d
niubi04   Ready          7d
niubi05   Ready          7d
</code></pre>

<p>Assume we have three Pods with 'hello world' web service. A service with exposed External IP is created with 'NodePort'. The external IP is 'Nodes' and port is 30145.</p>

<pre><code>root@niubi01:/home/mesos# kubectl get service
NAME               CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
example-service    10.100.220.21    &lt;nodes&gt;       8080:30145/TCP   6d
</code></pre>

<p>As the document mentioned, we can access any node IP to access this 'hello world' service. Like:</p>

<pre><code>curl http://niubi01:30145
curl http://niubi02:30145
curl http://niubi03:30145
curl http://niubi04:30145
curl http://niubi05:30145
</code></pre>

<p>from outside.
The problem is we can't guarantee any node is active forever, even master. Which URL should we take to use? 
How to do a LoadBalance like Haproxy to provide high availability to this service?
Should we have another server provide loadbalance sevice between these 5 addresses? Seeking for any better solution for this case.</p>

<p>independent from where your <code>LoadBalancer</code> is located you could just have a virtual IP address load balanced between your nodes and include it in your service definition as shown <a href="https://kubernetes.io/docs/user-guide/services/#external-ips" rel="nofollow noreferrer">in the documentation</a>:</p>

<pre><code>---
kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 9376
  externalIPs:
  - 80.11.12.10
</code></pre>

<p>Once the traffic for this IP (<code>80.11.12.10</code>) hits any of the nodes, <code>kube-proxy</code> will redirect it to your service.</p>

<p>One option to implement this would be using Pacemaker on the nodes as described in many <a href="http://jensd.be/156/linux/building-a-high-available-failover-cluster-with-pacemaker-corosync-pcs" rel="nofollow noreferrer">blog posts</a>. But also having a dedicated load balancer in front of the cluster would work just fine.</p>

<p>The benefit of using virtual IPs is that you don't have to mess with the NodePorts in firewalls or related configuration. Another benefit is that this isn't limited to HTTP traffic.</p>

<p>The downside is that the configuration of the external load balancer and the IP assignment for the service is not automated and has to be done manually. To mitigate this issue you could either implement your own provider (see other <a href="https://github.com/kubernetes/kubernetes/tree/e7950e6f4961595e6c9df878bbc6dd520c792d03/pkg/cloudprovider/providers" rel="nofollow noreferrer">provider implementations on Github</a>) or you could read the service configuration from etcd and use that as source for the configuration of your external load balancer.</p>
