<p>I have encountered a scalability problem when trying out the kubernetes cluster. To simplify the topology in my test machine, NodePort type is used to expose the individual service externally. The baremetal to host the node and master is a RHEL 7 with 24 CPUs and 32G RAM; I don't yet have a dedicated load balancer, or a cloud provider like infrastructure. A snippet of the service definition looks just like below</p>

<pre><code>    "spec": {       
         "ports": [{
             "port": 10443,             
             "targetPort": 10443,               
             "protocol": "TCP",                                
             "nodePort": 30443
    } ],
   "type": "NodePort",
</code></pre>

<p>Through this way the application can be accessible via <code>https://[node_machine]:30443/[a_service]</code> </p>

<p>Such service is only backed by one Pod. Ideally I would want to have several services deployed on the same node (but using different NodePort's), and and running concurrently.</p>

<p>Things were working well until it became evident that for a similar workload, increasing the number of services deployed (therefore backend pods as well) makes the applications degrade in performance. Surprisingly, when breaking down the service loading time, I noticed there's dramatic degradation in 'Connection Time' which seems to indicate there is a slowdown somewhere in the 'network' layer. Please note that the load isn't high enough to drive much of the CPU on the node yet. I read about the <a href="https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/services.md#shortcomings" rel="nofollow">shortcomings</a> in the doc, but not sure if what I hit is exactly the limitation of the kube-proxy/Service described there. </p>

<p>The questions are:</p>

<ol>
<li><p>Is there any suggestion on how to make it more scalable? I.e. to be able to support more services/Pods without scarifying the applications' performance? The NodePort type is the easiest way to setup the 'public' address for our services but is there any limitation for scalability or performance if all services and Pods are setting up this way?</p></li>
<li><p>Would there be any difference if we change the type to LoadBalancer? 
"type": "LoadBalancer"</p></li>
<li><p>Further more, is there a benefit to have a dedicated LoadBalancer or reverse proxy to improve the scalability, e.g. HAProxy or alike, that routes traffic from external to the backend Pods (or Services)? I noticed there's some work done for Nginx darkgaro/kubernetes-reverseproxy - unfortunately the doc seems incomplete and there's no concrete example.  In some of the other threads folks talked about Vulcan - is it the recommended LB tool for kubernetes? </p></li>
</ol>

<p>Your recommendation and help are highly appreciated!</p>

<p>Hello am kinda new to <a href="https://github.com/kubernetes/kubernetes" rel="nofollow">kubernetes</a> but I have similar questions and concerns. Will try to answer some of them or redirect you to the relevant sections of the user guide.</p>

<p>In case you are deploying Kubernetes on a non cloud enabled providers like for example vagrant /local, etc then some features are not currently offered or automated by the platform for u. </p>

<p>One of those things is the 'LoadBalancer' type of Service. The automatic provision and assignment of a PUBLIC IP to the service (acting a L.B) happens currently only in platforms like Google Container engine. </p>

<p>See issue <a href="https://github.com/kubernetes/kubernetes/issues/7514" rel="nofollow">here</a>  and <a href="http://kubernetes.io/v1.0/docs/user-guide/services.html#type-loadbalancer" rel="nofollow">here</a>.</p>

<p>The official documentation states</p>

<blockquote>
  <p>On cloud providers which support external load balancers, setting the
  type field to "LoadBalancer" will provision a load balancer for your
  Service.</p>
</blockquote>

<p>Currently an alternative is being developed and documented, see <a href="https://github.com/kubernetes/contrib/tree/master/service-loadbalancer" rel="nofollow">here</a> using <a href="http://www.haproxy.org/" rel="nofollow">HAProxy</a>.</p>

<p>Maybe in the near future, kubernetes will eventually support that kind of feature in all the available platforms that can be deployed and operate, so always check their updated features.</p>

<p>What you are referring as performance degrade is most probably due to the fact, PublicIP (<a href="http://kubernetes.io/v1.0/docs/user-guide/services.html#type-nodeport" rel="nofollow">NodePort</a> from version 1.0 and onwards) feature is working. Meaning that with the use of NodePort service type, kubernetes assigns a port on ALL nodes of the cluster for this kind of service. Then the kube-proxy intercepts the calls to this ports to the actual service  etc.</p>

<p>An example on using HaProxy trying to solve the very same problem can be found <a href="http://www.dasblinkenlichten.com/kubernetes-101-external-access-into-the-cluster/" rel="nofollow">here</a>.</p>

<p>Hope that helped a bit.</p>
