<p>Well there are 2 possibble options.</p>

<p>One is to create a <strong>LoadBalancer</strong> type for each service you want to be exposed. In case you have just one service that's great. That's rarely the case of course :) </p>

<p>If you build your k8s cluster properly ( having Prometheus-Operator doing the monitoring for example ) most likely besides the business logic service/s, you would want to expose  internal cluster valuable services like Grafana.</p>

<p>That's why even if you have just 1 service, for future extension of such type of need the best would be to use an <strong>Ingress</strong> resource. It providees a way to expose multiple services through a single IP address —  HTTP level (network layer 7). </p>

<p>You could play with HTTP headers essentially and do some path/host routing.</p>

<p>You express the definition for your object and helm would do the installation. Another option is to use a tool like ArgoCD, basically sticking to GitOps policy.</p>

<p>A fundamnetal knowledge is to be aware that the Load Balancer/Ingress would forward the traffic to the service, not the pods. Services are abstracted entities by kube-proxy, by default kube-proxy uses a round-robin algorithm.</p>

<p><a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/services-networking/service/</a></p>

<p>Regarding the definition, it follows the standart K8s scheme [ <strong>apiVersion</strong>, <strong>kind</strong>, <strong>metadata</strong>, <strong>spec</strong> fields]. Example would be an Ingress created from AWS-Ingress-Controller.</p>

<pre class="lang-yaml prettyprint-override"><code>apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: management
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
spec:
  rules:
  - host: grafana.com
    http:
      paths:
      - backend:
          serviceName: grafana
          servicePort: 80
        path: /*

</code></pre>

CC BY-SA 4.0
2020-03-27T09:37:32.773Z
2020-03-27T10:04:37.937Z
2020-03-27T10:04:37.937Z
Recoba20
<p>I am researching different types of <code>loadbalancing</code> methods available through kubernetes .I want to implement &amp; see before deciding on one .I'm stuck at how to actually define <code>typeof-loadbalancer</code>.If it isn't possible through <code>helm</code>  can anyone suggest other options please .</p>

<amazon-web-services><kubernetes><helm><load-balance>
Is there a way through which I can control type of load balancer like round robin , least-connections etc using helm charts?
YoganA
# Is there a way through which I can control type of load balancer like round robin , least-connections etc using helm charts?

(Asked by: username_0 on 2020-03-27)

I am researching different types of `loadbalancing` methods available through kubernetes .I want to implement & see before deciding on one .I'm stuck at how to actually define `typeof-loadbalancer`.If it isn't possible through `helm` can anyone suggest other options please .

**Tags:** amazon-web-services, kubernetes, helm, load-balance


---

## 1 answers

### Answer by username_1 on 2020-03-27. Score: 1

Well there are 2 possibble options.
One is to create a LoadBalancer type for each service you want to be exposed. In case you have just one service that's great. That's rarely the case of course :) 
If you build your k8s cluster properly ( having Prometheus-Operator doing the monitoring for example ) most likely besides the business logic service/s, you would want to expose  internal cluster valuable services like Grafana.
That's why even if you have just 1 service, for future extension of such type of need the best would be to use an Ingress resource. It providees a way to expose multiple services through a single IP address —  HTTP level (network layer 7). 
You could play with HTTP headers essentially and do some path/host routing.
You express the definition for your object and helm would do the installation. Another option is to use a tool like ArgoCD, basically sticking to GitOps policy.
A fundamnetal knowledge is to be aware that the Load Balancer/Ingress would forward the traffic to the service, not the pods. Services are abstracted entities by kube-proxy, by default kube-proxy uses a round-robin algorithm.
https://kubernetes.io/docs/concepts/services-networking/service/
Regarding the definition, it follows the standart K8s scheme [ apiVersion, kind, metadata, spec fields]. Example would be an Ingress created from AWS-Ingress-Controller.
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  namespace: management
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
spec:
  rules:
  - host: grafana.com
    http:
      paths:
      - backend:
          serviceName: grafana
          servicePort: 80
        path: /*


---

